Assuming you have the chance to start up wit a new ERP or S/4 SAP system - yes they are also still alive in an S/4 Hana - and you can work on an untouched SAPMV45A (as example). How would you do it? What is clean (for you)?
Here are some of my thoughts – but no final conclusion. Maybe you can add yours.
- Direct implementation in ZZ include:
- Pros
- Direct access to all data objects
- Easiest way
- Cons
- Complete include locked by one change
- No unit tests
- Direct access to all data objects, when doing it wrong (ok that's always the case when doing it wrong, but ... )
- Direct implementation using includes, one (or more) per USEREXIT form :
Similar like direct implementation
- Pros
- several developers/projects can work in parallel
- Cons
- Looks a little bit like fake modularization, as include is not an own object
- Tendency to grow wild. “May-be another include in or after the original include helps me with my problem?”
- A return or check statement leaves the subroutine and not just the include
- External performs to programs, that share the data object with tables/common part
- Pros:
- Still direct access to data
- Can have own screens
- Implementation could be done by local classes and unit tests
- Cons
- External performs look like a misuse of the private objects, that are public by technical reasons.
- Real OO with global interfaces/classes/BAdis
- Pros
- Advantages of OO: Encapsulation, Inheritance ..
- “Modern” Exception handling
- Development support by ADT
- Unit tests
- Cons
- Cannot have screens
- Frequent changes of public interface when starting with a reduced/minimal interface
- Variants
- One class/interface/BADI per main program / one instance per document/transaction
- Pros
- Can have own attributes / member variables
- Cons
- One class/interface/BADI per USEREXIT form
- How to perform the modification
- Modification of the SAP include
- Pros
- Easier to transport in an running system
- Cons
- Needs a registry key
- More complicated in SPAU
- Implicit enhancement
- Pros
- No key needed
- Easier in SPAU
- Can have a different transport route than a modified SAP object
e.g. when applying notes in a central development system
- Cons
- Import of an enhancement creates a new runtime object. So it cannot be imported that easy in a running system.
Currently my thoughts go in direction of having a program that shares the data with the master program. The call from the USEREXIT form is done by external subroutine call:
E.g. like this for USEREXIT_FIELD_MODIFICATION.
perform field_modification in program <your program> if found.
Starting point for the implementation of the custom code would be a local class, as there are easy refactoring paths to global classes.
The modification would be done using an implicit enhancement.
Let me know your thoughts.
