Sperrproblematik MV45AFZZ

Im Laufe der Zeit sammeln sich häufig sehr viele Anpassungen an den User-Exits der Kundenauftragsbearbeitung MV45AFZZ.
Es kommt in in einem größeren Projekt mit mehreren SAP-Entwicklern relativ häufig zur Konstellation, dass mehrere Entwickler gern das Include MV45AFZZ ändern möchten, sie sich aber gegenseitig sperren und man Überlegungen anstellt, wie man diese Sperrproblematik verringern kann.

Nicht empfehlenswerte Strategien zur Verringerung Sperrproblematik

Sehr gefährlich ist die Vorgehensweise, dass lediglich ein SAP-Entwickler Änderungen am Include MV45AFZZ vornimmt.
Es hätte den Vorteil, dass dieser Entwickler sich nicht mit anderen Entwicklern abstimmen muss, wenn Änderungen an User-Exits in der MV45AFZZ vorgenommen werden.
Allerdings wenn dieser Entwickler krank wird, im Urlaub ist oder plötzlich die Firma verlässt, kommt es zu einem riesigen Know-how-Verlust, was sehr große Probleme für den nachfolgenden SAP-Entwickler bringen wird bei vorher umfangreichen Änderungen an der MV45AFZZ. Dieses Risiko sollte man nicht eingehen und besser die Verantwortung in diesem zentralen Bereich auf mehrere Köpfe verteilen.

Eine recht einfache wirksame Strategie ist es, im zentralen MV45AFZZ Includes zu verwenden, z. B.

include ZSD_SALESORDER_USER_EXIT1 if found.

Dieser Aufruf vom Include im MV45AFZZ sollte schnell ins Produktivsystem transportiert werden. Der Zusatz "IF FOUND" bewirkt, dass der Include-Aufruf ignoriert wird, weil der aufgerufene Include im Produktivsystem noch nicht existiert.
Der Include (hier "ZSD_SALESORDER_USER_EXIT1") wird erst später ins Produktivsystem transportiert, wenn die Entwicklung an dieser Funktionalität abgeschlossen und vom Fachbereich abgenommen ist. Dieser Transport braucht dann nicht mit anderen Entwicklungen am MV45AFZZ abgestimmt zu werden, da die Änderung am Include nur diese eine Funktionalität im Include betrifft.
Man sollte allerdings die Parameter vom Include kommentieren im Kopfbereich vom Include, damit man nicht erst mühsam den Include debuggen/analysieren muss, um zu sehen was der Include macht. Diese Kommentare sollten im Include sein und nicht im MV45AFZZ, damit nicht ein Transport nötig wird, wenn man die Kommentare im MV45AFZZ ändert.

Sehr verwandt zum einfachen Coding in Includes ist es Form-Routinen in Includes aufzurufen.
Diese Form-Routinen können im MV45AFZZ aufgerufen werden

perform formname 
   using ..
   changing ..
   in program ZSD_SALESORDER_USER_EXIT if found.

Man muss beachten das man hier nicht den Include-Namen aufruft, sondern das Hauptprogramm, in dem sich der Include befindet. Der direkte Aufruf eines Inludes führt zu einem Laufzeitfehler.
Der Aufruf der Form-Routine mit Parametern hat den Vorteil, dass man die Parameter beim Aufruf in der MV45AFZZ mitgeben kann und so gleich transparent ist, welche Parameter in der Form-Routine genutzt, bzw. geändert werden.
Den Include MV45AFZZ kann man dann wiederum schnell ins Produktivsystem transportieren, auch wenn die zu rufende Formroutine (hier "FORMNAME") noch nicht im Produktivsystem existiert.
Es hat jedoch auch den Nachteil, dass nicht immer gleich bekannt ist welche Parameter in einer Form-Routine genutzt, bzw. geändert werden und man dann nicht gleich die Perform-Routine im ersten Versuch korrekt aufruft und dann Nachtransporte nötig sind. Aber dieser Nachteil ist meiner Meinung nach akzeptabel. Die Transporte der MV45AFZZ ins Produktivsystem sind mit einem sehr geringen Risiko verbunden, solange die gerufene Form-Routine bzw. Include noch nicht existiert.
Eine Alternative wäre auch die Form-Routine ohne Parameter aufzurufen. Dann muss das Hauptprogramm vom Include jedoch im MV45AFZZ eingebunden sein, damit die Form-Routine auf die globalen Daten von der MV45AFZZ zugreifen kann.

include ZSD_SALESORDER_USER_EXIT.
 
perform formname in program ZSD_SALESORDER_USER_EXIT if found.

Aber dann sehe ich nicht, warum eine Form-Routine besser sein sollte als direkt das Coding in einen Include zu schreiben

include ZSD_SALESORDER_USER_EXIT1 if found.