Korzyści z łamania uznanych reguł w SAP

Nie zmieniaj standardowych programów SAP

Jedną w pierwszym mądrości jakie poznają programiści ABAP jest konwencja nazw – własne programy należy poprzedzać prefiksem Z lub Y, aby odseparować te programy od standardowych i nie wkroczyć na teren SAP. Ta reguła jest tak powszechnie znana i akceptowana, że w istocie jest stosowana nadmiernie. Kiedykolwiek zachodzi potrzeba zmodyfikowania standardowego programu SAP cały program jest kopiowany „na Z”, a zmiany są wprowadzane tylko do tej kopii. To podejście jest często wykorzystywana podczas implementacji wydruków do rozszerzenia programów drukujących.

Na pierwszy rzut oka takie podejście wydaje się rozsądne – zmiany są wyraźnie oddzielone od standardowych programów SAP, zatem noty, poprawki czy upgrade mogą być importowane bez przeszkód. Taki jest powszechny tok rozumowania, który chciałbym zakwestionować.

Przede wszystkim, w większości przypadków kod, który ma zostać zmieniony jest zagnieżdżony głęboko w strukturze programu głównego. Zatem skopiowanie i modyfikacja tego kodu wymaga skopiowania całego programu głównego wraz ze wszystkim jego komponentami. W konsekwencji spory kawałek kodu SAP zostaje skopiowany w celu wprowadzanie nawet niewielkiej modyfikacji.

Ponadto, SAP nie wie nic o wykonanej kopi – wszelkie poprawki czy nowe funkcje wprowadzane przez noty czy patch’e zostaną zaimplementowane tylko w oryginalnym kodzie SAP, a nie w kopii. Przez to znaczna część systemu ERP pozostaje poza oficjalnym wsparciem i aktualizacjami, za które przecież wnosi się znaczne opłaty serwisowe.

Zadecydowanie odradzam kopiowanie standardowych programów SAP. Zamiast tego proponuję wprowadzenie dobrze udokumentowanej zmiany do standardowego kodu. Jeśli pojawia się wymaganie, którego nie można spełnić przy pomocy konfiguracji czy typowych rozszerzeń, jeśli to wymaganie ma solidne uzasadnienie biznesowego, sprawdź jak można je spełnić przy pomocy modyfikacji kodu SAP – może to być zmiana statusu komunikatu, modyfikacja logiki programu czy wprowadzenie dodatkowych walidacji. Następnie zarejestruj zmianę na http://service.sap.com/sscr i zaimplementuj ją wykorzystując Asystenta Modyfikacji. Dzięki temu zmiana będzie się wyraźnie widoczna w kodzie. Zawsze staraj się zminimalizować efekty uboczne zmiany i zadbaj o jej precyzyjną dokumentację. Naturalnie tak zmodyfikowany program zostanie oznaczony jako naprawiony, a noty czy patch’e nie będą implementowane dla niego automatycznie. W istocie to jest największa zaleta tego podejścia.

Spójrzmy co się stanie jeśli nota czy patch dotyczą naprawionego obiektu. Przede wszystkim nie zostaną automatycznie zaimplementowane. System poda komunikat o konflikcie między lokalną zmianą obiektu, a zmianą wprowadzaną przez notę czy patch. Takie konflikty należy naturalnie rozwiązać, np. przy pomocy transakcji SPAU. To daje możliwość ponownego przeanalizowania wprowadzonej modyfikacji standardu:

  • stwierdzenia czy naprawa jest nadal wymagana z technicznego i biznesowego punktu widzenia,
  • sprawdzenia czy pierwotne wymaganie, które spowodowało wprowadzenie zmiany może być teraz spełnione przez standardową funkcjonalność,
  • wprowadzenia noty czy patch’a i reimplementacji modyfikacji.

W sumie pieczemy tutaj dwie pieczenie na jednym ogniu:

  1. System jest aktualizowany zgodnie ze wsparciem SAP
  2. Modyfikacja wyróżnia się podczas implementacji not i patch’y, dzięki czemu nie zostanie zapomniana.

Pola ZZ w APPEND STRUCTURE

APPEND STRUCTURE jest doskonałą techniką dodawania pól do tablic i struktur słownika danych SAP. Nazwy tych pól powinny być poprzedzone prefiksem ZZ, aby uniknąć potencjalnych konfliktów z polami SAP. Ta konwencja jest poprawna i powinna być przestrzegana prawie zawsze. Jednakże, jeśli wiesz co robisz, złamanie tej konwencji może oszczędzić nieco programowania i ułatwić utrzymanie systemu zgodnie z przyszłymi rozwojem SAP. Najczęściej złamanie reguły ZZ opłaca się podczas rozszerzania struktur komunikacyjnych.

A co jeśli SAP doda w przyszłości takie samo pole? Cóż, wtedy system stwierdzi konflikt nazw podczas aktualizacji czy upgrade’u. Taki konflikt należy naturalnie obsłużyć w transakcji SPDD. Wtedy właśnie masz szanse sprawdzenia czy faktycznie dodatkowe pole jest jeszcze potrzebne oraz czy można wykorzystać jednak standardowe pola.

Podam przykład z życia. Podczas jednego z ostatnich projektów ustalanie informacji wyjściowej z dokumentów materiałowych musiało być sterowane przy pomocy rodzaju ruchu MM. Pole BWART „rodzaj ruchu materiałowego” nie jest dostępne w strukturach komunikacyjnych KOMB i KOMPME. Dodałem zatem pole BWART poprzez APPEND STRUCTURE do KOMB i KOMPME świadomie łamiąc regułę ZZ. Korzyść jest dwojakiego rodzaju. Po pierwsze, nie musiałem się już zajmować oprogramowaniem w rozszerzeniu napełnienia tego nowego pola. Po drugie, jeśli SAP rozszerzy w przyszłości te struktury komunikacyjne o pole BWART, konflikt nazw powie mi, że dodane przeze mnie pole nie jest już potrzebne i że mogę użyć standardowego pola.

Nie używaj komend „do użytku wewnętrznego”

Pewne komendy ABAP są oznaczone „do użytku wewnętrznego”, co oznacza, że nie mogą być wykorzystywane w własnych programach, np.

CALL – Call a System Function 

 

Note

 

This statement is for internal use only.

It cannot be used in application programs.

czy

ASSIGN (PROG)DOBJ
Note

 

The label in name can also have the form (PROG)DOBJ for internal use only, where PROG is the name of an ABAP program and DOBJ is the name of a global data object of this program. If the program PROG is loaded during execution of the statement ASSIGN in the same internal mode as the current program, the data object (PROG)DOBJ is searched for in this program, and the field symbol points to this data object after the object has been successfully assigned.

Mimo że niedopuszczone oficjalnie, są często bardzo przydatne, zwłaszcza ta druga. Na przykład podczas programowania rozszerzeń. Rozszerzenia dostarczane przez SAP, takie jak customer exits czy BADI posiadają jasno zdefiniowany interfejs. Dane dostępne w rozszerzeniu są określone przez ten interfejs. Jednak często potrzebne są dodatkowe dane spoza interfejsu. Zwykle te dane są dostępne w zmiennych globalnych programów głównych wywołujących rozszerzenie. Chociaż nie są one bezpośrednio dostępne wewnątrz rozszerzenia można je łatwo odczytać wykorzystując instrukcje ABAP ASSIGN (program główny)zmienna.

Zostaw komentarz