Managing Explicit and Implicit Enhancements

[Former Member]

We have developers worldwide. We provide them with a a "developer's work role", that allows them to maintain any repository object, In the older SAP ABAP systems, if a developer was implementing abap code in a user exit or in a very few cases if we were modifying an SAP delivered object, the system would require an object key to be supplied. The grating of object keys is very tightly controlled at our company and developers have to request them in a formal/approved manner.

In the ECC 6.0 world, we now have explicit and implicit enhancement capability where it seems that a developer (assuming that he has the authorization) can "enhance" (either explicitly or implicily), SAP delivered objects without being granted a developer's key.

In order to control the explicit and implicit enhancements, MUST we limit the authorization in the developer's work role, or is their nother way to manage this?

We do, of course have code reviews/development reviews prior to moving work from development, which is another way (although manual) that we could control this.

[marcin_cholewczuk]

Hi Rod,

It sounded strange to me, so I've checked it and it is not possible to create enchancment implementation without developers key.

How do you enforce object keys for user/customer exits? Normaly this is not needed.

Are you also checking BTE and BAdi?

Best regards

Marcin Cholewczuk

[Former Member]

It was a typo, it should have read object key. Object keys are required in 4.6c

[Sandra_Rossi]

Hi Rod,

In the ECC 6.0 world, we now have explicit and implicit enhancement capability where it seems that a developer (assuming that he has the authorization) can "enhance" (either explicitly or implicily), SAP delivered objects without being granted a developer's key.

I guess "developer's key" is a typo error, you undoubtfully mean "object's key" (as you primarily said)

I think you point out a big issue of the enhancement framework (according to me). Lots of developers feel free to enhance anything (in fact modify the standard), anytime, and without any limit and control.

Doing the code review, which often happens at a late stage, is a loss of time as enhancement framework is often used in a bad manner (my apologizes to people who use it efficiently) and the development must often be completely redesigned. So, your idea to limit it is good.

I don't think SAP provides an SSCR-object-key-like process for enhancement framework.

One way is to use authorizations (S_DEVELOP, all object except those of type ENHO for activity 01; always tough to authorize everything except a few ones using the SAP authorization concept). Some super-developers should be still allowed to create them, and provide the other developers an interface to add their code, so that they can only change verified variables or verified flow logic.

Another way is to change function module SUBST_CHECK_CENTRAL_BASIS, which forbides enhancements for some SAP_BASIS packages.

BR

Sandra

[SuhaSaha]

Hello Sandra,

One way is to use authorizations (S_DEVELOP, all object except those of type ENHO for activity 01; always tough to authorize everything except a few ones using the SAP authorization concept).

But wouldn't that mean we're restricting the developers from developing any enhancements viz., UEs, BAdIs, BTEs? I agree with MArcin's comment here, SAP never restricted us from implementing BAdIs, UEs so what's the need of doing so for "Explicit & Implicit Enhancements"?

BR,

Suhas

[Sandra_Rossi]

Hi Suhas,

But wouldn't that mean we're restricting the developers from developing any enhancements viz., UEs, BAdIs, BTEs?

No. Only enhancement framework, but you're right for the new BAdis, these ones should not be restricted. You make me think that ENHO is also used for new BAdIs. With the authorizations, there's no means to check if it's a new BAdI implementation or a "new modification of the standard" ;-). So, modyfing the function module above is probably better.

You also make me think that SAP recommends (edit: see note 1257033 - Cookbook: Modification/enhancement for standard SAP system) to create enhancement options inside older user exit technologies (UEs, BTEs, ...), implement them, and use the switch framework. In that case, we should also modify the function module to check if it enhances a Z enhancement option spot (edit).

These "new modifications of the standard" are really dangerous in some companies with bad organization : developers can change the standard without any control. I'd really like to know how SAP support finds out that the customer has changed one program's behavior, somewhere (they probably have a secret here, I'd like to know )...

I agree with MArcin's comment here, SAP never restricted us from implementing BAdIs, UEs so what's the need of doing so for "Explicit & Implicit Enhancements"?

In the past, SAP restricted us from doing modifications of the standard. So why wouldn't we do so for the "new modifications of the standard". What I said is only to define a 2-level development organization at the company side. If second level needs to change the standard, then they must ask the first level who will create the "envelop" in which the second level will develop.

Of course, all this depends on the organization, how companies trust the developers... I have seen the situation where there was no control, it was "discovered" when there were big bugs in production (like database integrity error: budget errors, ...)

Sandra

Edited by: Sandra Rossi on Apr 10, 2011 11:36 AM

[SuhaSaha]

Hi Sandra

OSS Note 1257033 makes a nice read!

As a matter of fact this is exactly what i have done in the programs RGGBS000 & RGGBR000(for FI validations & substitutions). Instead of copying them to Z-versions i had implemented source code enhancements to add the new UE routines.

All other objects: Perform a modification. If possible, you must avoid these modifications because they are not switchable.

Classic SAP! Lol ...

Cheers,

Suhas

[Former Member]

Hi Sandra,

you mention that S_DEVELOP for ENHO might be checked to prevent this - I am assuming this is when a developer goes to actually create a new implicit enhancements, as a user without this value on S_DEVELOP still has the menu / tool bar options to go and create such enhancements.

We are looking to limit which developers can create such implicit enhancements, and would prefer to stop those developers without such authorisations from doing anything with this part of SE80!

[kevin_pinto]

Hi Chris,

We are in the same boat as you.   I was wondering if you ever found a solution to prevent (or limit) developers from creating implicit enhancements without having to rework the S_DEVELOP authorizations.

Thanks !

Kevin