Enhancement Points and Implementations

[csyadlapalli]

Dear All,

I am new to Enhancement technologies like Enhancement Points, Enhancement section and Enhancement Implementation. I need to know the impact if I create an enhancement implementation for Implicit points. Do we need access key for then creation of explicit points and sections?? What are the system level mandatory steps to create these enhancement points and Implementations??

Plz help me out.

Regards,

Chandra.

[thomas_weiss · Accepted solution]

Hello Chandra,

the Enhancement and Switch Framework is the technology that empowers the development of SAP Enhancement Packages of SAP ERP 6.x. It is due to this framework that all additions that come with enhancement packages can be inactive before the relevant functionality is activated in the transaction SFW5. This way, enhancement packages and Enhancement Framework are not the same, but have a very close relation.

As for the usage of explicit enhancement points, in general customers may use explicit points defined by SAP. But SAP cannot guarantee the stability of these points. Moreover, if you implement a point already implemented by a SAP IS, we do not guarantee the order in which these implementations are called.

Though customer enhancements belong to the customer`s namespace, the enhancement option (for example, enhancement points, BAdI, overwrite exit for the method of a global class) they are assigned to may vanish or change in an upgrade. The transaction SPAU_ENH offers tool support to adjust the enhancement options after an upgrade or an support package installation. Still you can minimize this effort by choosing an appropriate enhancement technology:

o High-order enhancements technologies like BAdI or CMOD should be your first choice if they can do your job.

o If there is none of these technologies around to change the code the way you want to use class enhancements or source code plug-ins in function groups or reports. How stable a particular enhancement option of this kind is heavily depends on its particular position: Generally an enhancement option in a function module or a public method is more stable than one in a private method or a form routine. In many cases, an experienced developer can probably assess himself how stable a particular enhancement option probably is.

In the future, it will be a property of explicit enhancement points if they can be implemented only SAP internally or also externally.

You should be very care with implementing enhancement sections that are already implemented, because a section must not have more than one active implementation. The content of the implementation replaces the content of the section. This is why many implementations of a sections are useless in a way.

You find a whole bunch of information on these topics in my weblog series on the technology of the Enhancement Framework that starts with the weblog

[What the New Enhancement Framework Is For - Its Basic Structure and Elements For Beginners|https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/3056] [original link is broken]; and my other series on that topic that describes the relation of the Enhancement and Switch Framework to its use cases that begins with the weblog Th[The Three Use Cases of the Enhancement and Switch Framework - Part 1: Overview of the Use Cases and the Advantages of Enhancements Over Modifications |https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/8021] [original link is broken];

Regards

Thomas Weiss, NetWeaver Product Management

[former_member288881]

Dear Chandra,

first of all "Enhancement Packages" and "Enhancement Framework" have no direct relation. Enhancement Packages for ERP 6.0 use the technique of the Switch Framework (Business Functions) and only some aspects of the Enhancement Framework. If you would like to add own extensions and developments to the SAP Standard you may use the Enhancement Framework. The Switch Framework is in general not necessary since you would like to have your implementations active.

You will find a good overview about the Enhancement Framework in the help-portal (http://help.sap.com/saphelp_nw70/helpdata/EN/70/63da4023a28631e10000000a1550b0/frameset.htm).

If you use implicit enhancement technique the development takes completely place in customer namespace. The objects are attached/linked to the SAP-core, but can be transported independantly. So the TADIR-object (type ENHO) is in customer namespace.

We do not recommend to use existing explicit Enhancement-Points/Sections from SAP. They are needed for industry solutions and can change. So this can result to higher conflict resolution efforts.

If the implicit points and BAdI-definitions are not sufficient, you can of course create own enhancement points. But this is again a standard modification. This is similar to a direct modification then. You create the point as a modification and attach your code via the enhancement implementation. So still in SPAU this will come up if SAP changes the standard object.

But also for implicit enhancements you may have to resolve conflicts via SPAU_ENH. Since of course your change takes place "directly" in the SAP-code. There is no interface for an implicit enhancement (direct access to variables, except for global class enhancements). So if SAP changes something this can have an impact on your implementation.

I hope these explanations help you.

With best regards,

Christoph Vehns

[csyadlapalli]

Dear Christoph Vehns

Thank you so much for the detailed explanation. I am looking for Enhancement Framework only. What I understood from your explanation is that what ever the enhancement it is just like modification of SAP standard and we are not going to have support from SAP during upgrade and we need to take care of that manually. Correct?? So it not like our User exits and BADIs. But I thought it would be supported by SAP during upgrade. In this case of implicit and explicit enhancements, will system ask for accesskey?? What's the extra advantage of enhancements?? From your explanation, we have to use Implicit enhancements at max... correct me if I am wrong.

Looking for your help..

Regards,

Chandra.

[csyadlapalli]

And one more thing, where ever I see the documentation they are saying like this...

"As part of the enhancement concept, it is possible to enhance ABAP source code, without modifications, using source code plug-ins. You can execute enhancements to implicit and explicit enhancement options. The Enhancement Builder tool for defining explicit enhancement options and for implementing enhancements is integrated in the ABAP Editor."

Here It means we are just enhancing the system not modifying...

Plz clarify...

Regards,

Chandra.

[former_member288881]

Dear Chandra,

code enhancements are technically no "modifications", but nevertheless you plug-in own code into the SAP-core. You do not have an interface as for BAdIs or User-Exits. So SAP cannot in advance take care of all possible plug-ins. Otherwise it would not be allowed to apply any bug fix at all. For modifications you have the upgrade support with the SPAU. For enhancements you have a similar upgrade support via SPAU_ENH. But the effort should be less depending on the "modification degree". So if you use implicit points (e.g. at the end of modules) a change in that module does not overwrite your plug-in. A modification would have been overwritten by the SAP change. But nevertheless your solution may be affected. I give an example. A module fills some table EX_TAB_DATA. Now via an implicit enhancement point you change one entry. In your case it is always the first entry. So you add:

FIELD-SYMBOLS: <data> TYPE any.

READ TABLE ex_tab_data ASSIGNING <data> INDEX 1.

IF sy-subrc = 0.

• apply the change...

ENDIF.

Now SAP does not know that you apply this manipulation. Of course this solution can be corrupted if

(a) SAP changes the name of the module (hard conflict in SPAU_ENH, plug-in hook missing)

(b) SAP changes the name of the table EX_TAB_DATA (hard conflict in SPAU_ENH)

(c) SAP changes the code so that it is not the first entry, but the last you need to modify in your solution (no hard conflict, but reported)

So you have no protected interface as for a BAdI which SAP will keep stable. You simply plug-in your code somewhere into the SAP-Standard and SAP does not control where you do this.

The main advantage is that you have a separate transport object for your plug-in. And most of the changes in an support package will not affect your solution. But still this is an individual solution which always may require some conflict resolution efforts.

If possible try to use BAdIs in the first place or implicit points at the end of modularization units. This should keep SPAU_ENH-efforts small.

I think registration keys are not necessary since the development takes place in customer namespace. I am not 100% sure about SSCR-Key, but I think this should work this way.

Best regards,

Christoph

[csyadlapalli]

Dear All,

Now I got better Idea. Thanks for your responses.

Regards,

Chandra.