cancel
Showing results for 
Search instead for 
Did you mean: 

FPM Best Practise - Performance Queries

Former Member
0 Kudos

Hi Experts,

We have a FPM application(OVP) which has around 7 GUIBBs inside. Now, two feeder classes are used, one class acts as the feeder of 6 GUIBBs and one separate for one GUIBB.

Now, whenever user performs some operation in one of the GUIBBs, process_event for all GUIBBs gets triggered inside a loop. Now in UAT, users are facing performance issues.

Any particular tips that I can follow to improve performance in these kind of scenarios..?

Many thanks in advance.

Saikat

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Saikat,

If you have one feeder class for multiple GUIBB, maybe you can try to use Feeder class parameters. That should allow you to determine which GUIBB is relevant for you event processing according to the current value of the parameter.

For example, GUIBB1 set feeder class param value to 1 and GUIBB2 sets this param value to 2. In process event, I guess you can access this param value (maybe taken from FLUSH or INITIALIZE methods?).

This is just an idea, I've not yet used feeder class parameters.

Other solution is to *not* use same feeder class for all GUIBB but create a master feeder class that will hold every common processings and inherit from it for each GUIBB, redefining relevant methods.

Good luck.

Former Member
0 Kudos

Hi Thomas,

Thanks for your reply.

It will be good if you can explain the concept of master feeder class once, I did not quite get how you can implement that and benefit from it,
.

Thanks,

Saikat

Former Member
0 Kudos

Hi Saikat,

By master feeder class, I do not refer to any FPM related concept, but just basic OO inheritance concept.

I'll try to explain it with an example.

Let's say you have three ATS list UIBB to display on your FPM application. Each UIBB can have its own feeder class. But if those lists share the same event processing (eg. all list may have a Refresh button).

In such a case, you can create an abstract class which would implement IF_FPMT_GUIBB_LIST, and code only the PROCESS_EVENT method. Then, on your three feeder classes, inherit from this abstract class. At run time, when the event will be triggered, it will call your feeder class PROCESS_EVENT method, but as it won't be redefined in this feeder class, the abstract class (ie master feeder class) will be executed.

This way, you do not have to copy-paste your common coding three times.

If any FPM method of a feeder class should differs in one single List UIBB from the other list UIBBs, just redefine the method in order to not use the method of the abstract class.

The abstract class just holds programming logic common to all concerning UIBBs.

Warning, be sure to control the origin of the EVENT triggered in your feeder class with this simple code snippet:

«

  " our screen has several LIST GUIBBs and therefore when selected one line

  " of any of those lists, this PROCESS EVENT method is called

  " for example, the user clics one 2nd line of 3rd LIST GUIBB to display the

  " corresponding sales order, then PROCESS EVENT would be fired 3 times

  " (one per LIST GUIBB) and will try to display the 3 2nd sales order

  " of course, this behavior is not wanted, thus we have to check if current

  " PROCESS EVENT execution is fired by the good UIBB, and this is done

  " just here:

if iv_raised_by_own_ui = abap_false.

  " that means this PROCESS EVENT (or GET_DATA) execution is related to another GUIBB

  return.

endif.

»

This will prevent your code to be executed for each and every UIBB attached to the feeder class.

Hope this helps you.

ulrich_miller
Active Participant
0 Kudos

Hi Saikat,
the behaviour you are observing is the way FPM works and is normal so to speak. However the important thing is this: Whenever the process_event (or get_data) is called in a feeder class, the very first thing you should do is: Query what FPM event id is currently processed. Only if the FPM event ID is relevant for your business logic should you continue, otherwise just exit the method. By doing so, no unnecessary coding will be traversed and thus contribute to a good performance.

Kind regards,
Ulrich

Former Member
0 Kudos

Thanks Ulrich for your reply. Yes, I have also implemented that but still the application is slow. Actually there are so manu UIBBs that the calls are taking time.

Anyway, thanks again.

Saikat