Parallel ABAP programming while using references

[Former Member]

Hi SCN,

first of all the context of my problem, to get to its root:

I have created a kind of Framework (object oriented), which later on will provide an easy way to set up Charts in a Dashboard.

Put simply, the framework works like this:
There is a interface for the source of the data and customizing to be shown in the chart, with the methods 'get_data' and 'get_customizing'.

You can simply implement the specific interface in a class, which therefore is a 'source object' for the chart classes later on (getting the Chart Customizing and the Chart data using the defined methods mentioned above). The chart classes use the functionality of CL_GUI_CHART_ENGINE.

This concept works fine so far.

But I added a quite important feature - every chart should be refreshed after some time. Therefore I use the class CL_GUI_TIMER, which triggers the refreshing after some time. The problem is: if there are for instance two graphs shown and the first one is refreshing it's data (so the 'get_data' method of the source object is processed, which could mean there are some select statements implemented and therefore need some time). WHILE this is processing, the time may has come for the second graph to refresh (so CL_GUI_TIMER raises the 'finished' event) - so the event will be fired, but the handler method for the won't be executed, because the first chart is currently processing the GET_DATA method. This means, nothing happens when the second chart should be refreshed.

Fine, I told myself, parallel programming could easily fix this (later on, I figured out I was horribly mistaken (comment: I had no experience in parallel programming in ABAP so far)).

My intention was to give every chart object a separate 'thread', so they wouldn't be in each others ways (and thereby, as a side effect, the whole construct would gain some performance).

Finally we got to the actual problem:

There my problems started - the only way, to do some parallel programming in ABAP seems to be function modules using RFC (event though I always want to stay on the same application server). So the 'parallel thread' has to be a RFC function module - which means, there is no possibility for me to supply some object references to the function module (in my example, this would be the graph objects). So far I tried to do some workarounds like:

- using serialization, whereby I give the serialized objects into the function module as a string and rebuild it in there, which would work fine, if there where no attributes of objects, that are not serialize-able, in the chart objects (like a instance of CL_GUI_TIMER and some more).

- using shared objects, which gives me a way to access the object from the function module as well. But - there is no way to use event-handler methods in shared objects classes. So if I mark the 'Root class' of the chart classes as shared memory-enabled in SE24, I can't activate it, because it contains some event-handler methods (for example the one that reacts on the 'finished' event of CL_GUI_TIMER).

Now I'm running out of ideas, how I could solve my problems and use parallel programming in ABAP actually using references and all the object oriented features I need (events, interfaces, inheriting and so on).

Does someone of you out there have any idea how I could fix this - if there may is another way of parallel programming in ABAP, or another way to access objects using RFC function modules, or anything else?

I really appreciate any hint you could give me.

Let me know, if you need some more information.

Thank you very very much for your help and best regards

Sebastian

[Former Member]

Would it be possible for you to set a flag for every graph indicating whether graph can be refreshed?

When cl_gui_timer finished event is being handled, only those graphs will be refreshed whose flag is set as can_be_refreshed.

[Former Member]

Hi Manish,

thank you for your answer.

I'm sorry - I think I didn't explain the cause of the refreshing mess up problem clearly enough.

Every graph class has it's own instance of CL_GUI_TIMER,because the refresh intervals can differ from one graph to another. This means: If, for example, graph 1 has a refresh interval of 15 seconds, but graph 2 has an interval of 45 seconds - they will mess up after the 3rd refresh of graph one. Because either graph 1 is currently running the get_data method, or graph 2 is - and therefore, if the 'finished' event of the timer of one chart is fired, while the other one is refreshing (respectively is processing the get_data method), the event won't be handled and disappear into nirvana...

But thanks for the suggestion anyway.

Sebastian

[Former Member]

Ok. Since cl_gui_timer event does not have anything specific to tell apart the instances, it would be better to have a single timer instance firing event every second.

Your graph classes would have their own event handlers, all getting called every second. Based on graph specific interval (say 6 seconds), you can choose to do nothing for 5 triggers and take action only for 6th trigger of handler using a class attribute.

[Former Member]

Hi Manish,

thanks for the reply again.

I'll create a local test scenario and give it a try (so I don't have to straight change all of the concept right now) - but I think that won't fix the problem like I would want it to be fixed.

In this scenario there would also be the problem, that some chart could be currently processing the 'get_data' method - so the event of CL_GUI_TIMER will be lost again (and therefore, the timer would not be set again, because - according to the architecture of CL_GUI_TIMER - you have to set the timer again at the end of every handler method for the finished event). But I'll test it anyway.

I think, a more 'beautiful' way would be, to actually use parallel/asynchronous programming, and give every chart object a separate 'Thread'. Do you know of any parallel programming paradigm provided by ABAP, that also allows me to work with objects (and the object oriented paradigms)?

Or does someone else out there?

Best regards

Sebastian

[Former Member]

Hi Manish,

sorry for the late reply. Unfortunately I still haven't found a way to go along with parallel processing and actually used a single-threaded work-around, which is a little bit of a modification of your answers:

1. For every chart I calculate a refresh point of time (combination of date and time) according to the specific refresh interval of the chart. (As long, as there is no refresh point of time for the chart yet).

2. I determine the chart, which has the closest refresh point of time.

3. I calculate the time in seconds till that point of time will be reached and trigger CL_GUI_TIMER accordingly.

4. After the FINISHED event of CL_GUI_TIMER was triggered, I refresh the chart. (And delete the refresh point of time for this chart.)

5. Afterwards I check the refresh point of times of every other chart, to see if that point was reached during the refreshing of the other chart. If so, I refresh those charts again (and delete their refresh point of time).

6. Finally I'm done with a refresh cycle  and will start all over with step 1 again.

This algorithm provides continuous chart refreshing while acknowledging the specific refresh intervals of every chart. Unfortunately it's not palatalized, but a nice single-threaded solution though.
On the contra side it is possible (of course, because it is single-threaded), that charts with short refresh intervals have to wait for charts that need lots of time to refresh.

In my case it works just fine anyway.

Thank you very much for your help and best regards

Sebastian

[Former Member]

Unfortunately I found no solution so far, that solved my problem...

Does anyone else have any idea what I could try? Your reward will be my endless gratitude.

Thank you very much and best regards

Sebastian

[Former Member]

As you said RFC Enabled function modules are the only way to enable parallel processing.

Your event handler for the 'finished' event of your timer can call an RFC FM with another method on the class being performed when it's done:

CALL FUNCTION func STARTING NEW TASK task
              [DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
              parameter list
              CALLING meth ON END OF TASK].

You can pass in what you need for the select and get back the results. Then the method you call 'on end of task' can perform the rest of the refresh. If you want to stick to mostly OO concepts then the RFC function module could just be a wrapper for a static method on your class which gathers data for your refresh...

[Former Member]

Hi Lucas,

thank you very much for your help and sorry for the late reply.

I really liked that idea but it didn't work for me neither, because the data selection part (as well as some other logic) is what is provided by in a class that implements a interface the framework can use.

This class is of course created by the user of the framework, who can add charts easily to the framework in that way.
The refreshing (and therefore the parallelization)  is something the framework should take care of anyway. This is where the problem comes in: I can't parameterize a RFC function module with references to the interface, so i can't pass the necessary object into it.

I've found a little single-threaded workaround for the problem, you can find in the answer to manish in the upper part of the thread.

I thank you really much for your answer anyway and wish you best regards

Sebastian