Enhancing a dinosaur – clean(?) modification of SAP objects with “USEREXIT” Forms

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 or function calls to function groups, 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 looks like a misuse of the private objects, that are public by technical reasons
      • Function group with no functions (when doing external performs) or functions with no interface (as working on global data of the main program) do not look not “clean”
  • Real OO with global interfaces/classes/BAdis
    • Pros
      • Advantages of OO: Encapsulation, Inheritance ..
      • “Modern” Exception handling (yes, it is also possible with function modules….)
      • 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 function group that shares the data with the master program. I would prefer a function group to a normal program as it is more clean looking at the naming conventions for includes; normal programs have the tendency to become a little bit unclean. The call from the USEREXIT form is done by a function call, although the function does not have any parameters.

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.