topic Re: Performance and Runtime behavior: Explicit v/s Implicit Enhancement in Application Development and Automation Discussions

Performance and Runtime behavior: Explicit v/s Implicit Enhancement

Former Member — Mon, 14 Mar 2016 08:10:47 GMT

Background: For 'form exits' like MV45AFZZ and customer exits, at our project we are planning to use implicit enhancement to handle multiple simultaneous modification in order to avoid dependency between two developers modifying the code. However, there is a doubt that multiple implicit can lead to performance issues.

Question: Purely from technical point of view at run time,

a> is there any difference between explicit and implicit? Which is better?

b>What happens at code compilation time or how does these two behave at run time?

c>and are there any performance issues?

d>will it be better if we use kernel BADIs?

Re: Performance and Runtime behavior: Explicit v/s Implicit Enhancement

matt — Mon, 14 Mar 2016 08:27:45 GMT

Why should an implicit enhancement cause a performance issue? People do come up with some very odd concerns. Have you searched to see if anyone has ever reported performance issues using an implicit enhancement? What possible way could it cause a performance issue?

Since you're in control - the object is in the customer namespace - I cannot see any reason not to use an explicit enhancement. The difference is that it's explicit - I.e. you are saying "Here is where to enhance".

Re: Performance and Runtime behavior: Explicit v/s Implicit Enhancement

Former Member — Mon, 14 Mar 2016 09:13:34 GMT

I guess there is no big difference between implicit, explicit and (explicit) kernel BADIs regarding the runtime performance. In each case you have an additional "method call". Using multi active implementations could be a little bit more organizational work for the runtime, but not as much you will recognize it as a user (maybe some micro or nano seconds).

But I'm not sure if this approach is the correct ones for your root cause. Maybe you should modularize your coding much more to avoid these mentioned dependencies.

Re: Performance and Runtime behavior: Explicit v/s Implicit Enhancement

Former Member — Mon, 14 Mar 2016 10:39:13 GMT

Completely agree with Matthew; as MV45AFZZ is a very highly used Include in the Sales Order application program for a range of changes. In my last project we created a explicit enhancement.

Only point is don't write the code there directly it will create a mess create an encapsulation, we created a method and called it. so may be create a custom kernel stuff and write the code in it.

As this things are part of the actual run time code and not add on calls , do not worry about performance they will be smooth.

Regards,

Prasenjit

Re: Performance and Runtime behavior: Explicit v/s Implicit Enhancement

SuhaSaha — Mon, 14 Mar 2016 11:59:46 GMT

I would suggest you to check for available SAP enhancements beforehand.

E.g., SAP provides the enhancement spot ES_SAPMV45A which you can use as an alternative to the MV45AFZZ include.

PS - There are a couple other enh. spots (e.g., BADI_SD_SALES), but unfortunately some of them are marked as "SAP-internal" use only

Re: Performance and Runtime behavior: Explicit v/s Implicit Enhancement

Former Member — Wed, 16 Mar 2016 06:36:10 GMT

Thanks for the reply. I couldn't agree more. But this is for the 'legends' who only agree to disagree.

Re: Performance and Runtime behavior: Explicit v/s Implicit Enhancement

Former Member — Wed, 16 Mar 2016 06:37:58 GMT

Thanks for the reply. So what do you suggest?

Re: Performance and Runtime behavior: Explicit v/s Implicit Enhancement

Former Member — Wed, 16 Mar 2016 06:40:12 GMT

Thanks for your reply . Surely, we have kept that in mind.