W najnowszej wersji SAP NetWeaver 2004s (począwszy od Release 7.0) mamy do czynienia z innowacyjnym podejściem do tworzenia modyfikacji i rozszerzeń w systemie SAP. Enhancement Framework to nowa idea na drodze do jak najpełniejszego dostrajania systemu do potrzeb i wymagań firmy.

Łączy w sobie zalety oprogramowania ściśle dopasowanego do potrzeb, a zarazem sprawia, że rozszerzenia ABAP nie wymagają dużych, dodatkowych nakładów pracy przy upgradzie systemu.

Docelowo Enhancement Framework ma zunifikować wszystkie techniki tworzenia rozszerzeń i modyfikacji w systemach SAP oraz zapewnić zintegrowane narzędzia do ich tworzenia i utrzymywania.

Obiekty, relacje, narzędzia

Idea jest całkiem prosta: w pewnych miejscach kodu (zwanych enhancement options) mogą być dołączane fragmenty kodu, które będą ich implementacją (enhancement implementations). W architekturze zakłada się również istnienie trzeciej grupy obiektów, które pełnią rolę nadrzędną i zarządzającą w stosunku do enhancement point, to jest enhancement spot.

Te trzy typy obiektów, wraz z ich wzajemnymi relacjami, narzędziami do ich tworzenia i zarządzania, składają się na Enhancement Framework.

Modyfikacje – zło konieczne?

Konieczność wprowadzania zmian i modyfikacji w procesie zarówno wdrażania, jak i utrzymania systemu jest w większości przypadków nieunikniona. Specyfika biznesu musi być możliwie najpełniej odzwierciedlona w systemie. Jeśli możliwości konfiguracji systemu się wyczerpują, SAP proponuje dwa możliwe podejścia:

  • modyfikacje – zmiany wprowadzane bezpośrednio w kodzie dostarczonym przez SAP,
  • rozszerzenia – zmiany wprowadzane w predefiniowanych miejscach, przewidzianych przez programistów SAP AG.

Dzięki modyfikacjom mamy praktycznie nieograniczone możliwości dostosowywania systemu i konieczność wprowadzania kolejnej techniki modyfikacji może wydawać się wątpliwa. Warto się jednak zastanowić, jakim ograniczeniom podlegają modyfikacje.

Po pierwsze dokonywanie modyfikacji bezpośrednio w oryginalnym kodzie może być niebezpieczne. Pamiętajmy, że działamy tu bezpośrednio w przestrzeni nazw oryginalnego programu, tzn. mamy dostęp do wszystkich danych i zmiennych w danym fragmencie kodu.

Wraz ze wzrostem możliwości stosowania rozszerzeń wzrasta też odpowiedzialność wynikająca z ich stosowania. Ewentualna pomyłka może mieć trudne do przewidzenia skutki (nawet najbardziej podstawowe transakcje i procesy mogę zacząć źle działać).

Co ważniejsze, błędy mogą być trudne do wytropienia, a więc w konsekwencji bardzo kosztowne. Niemniej doświadczony i rozważny programista może skutecznie zniwelować to niebezpieczeństwo.

Kolejnym, dużo poważniejszym ograniczeniem w stosowaniu modyfikacji jest ich zachowanie podczas upgrade’u. Początkowo wszystkie modyfikacje nie istnieją w nowym systemie i muszą być ponownie wstawione za pomocą Asystenta Modyfikacji. Przy dużej liczbie modyfikacji jest to bardzo złożony i czasochłonny proces.

Sytuacja komplikuje się dodatkowo, gdy mamy kilka równoległych systemów SAP, w których są rozwijane modyfikacje. W konsekwencji uruchomienie nowej wersji systemu opóźnia się o czas potrzebny na ponowne wstawienie wcześniejszych modyfikacji.

Ponadto modyfikacji nie da się grupować w semantycznie powiązane grupy, co dodatkowo utrudnia zarządzanie nimi i ich śledzenie. Z powyższych powodów SAP AG zaleca korzystanie z modyfikacji dopiero w ostateczności, kiedy wyczerpią się możliwości dostosowania systemu za pomocą konfiguracji czy też rozszerzeń.

Mogą oczywiście wystąpić sytuacje, kiedy nie jest możliwe uniknięcie zmian oryginalnego kodu, dlatego jednym z założeń Enhancement Framework jest zmniejszenie liczby koniecznych zmian do niezbędnego minimum. Warto w tym miejscu podkreślić, że wraz ze wzrostem możliwości stosowania rozszerzeń wzrasta też odpowiedzialność wynikająca z ich stosowania.

Architektura

Zanim bliżej przyjrzymy się właściwościom Enhancement Framework, zapoznajmy się z jego architekturą.

Jedną z podstawowych właściwości nowych obiektów rozszerzeń jest możliwość ich grupowania w powiązane ze sobą jednostki.

Zarówno na poziomie definicji, jak i implementacji mamy dwa typy obiektów: podstawowe (odpowiednio Simple Enhancement Spot oraz Simple Enhancement Implementation) oraz złożone (Composit Enhancement Spot oraz Composit Enhancement Implementation). Obiekty złożone mogą zawierać inne obiekty złożone bądź podstawowe (ale podstawowe tylko jednego typu).

Nowe techniki rozszerzeń

Zobaczmy zatem, jakie techniki rozszerzeń oferuje nam Enhancement Framework. Wyróżniamy cztery techniki dostarczania rozszerzeń:

  • rozszerzenia klas i interfejsów (class enhancements) – pozwalają na dodawanie nowych metod i atrybutów klas i interfejsów, umożliwiają też zdefiniowanie pewnych typów metod wykonywanych przed wywołaniem i po wywołaniu danej metody (odpowiednie pre- i post-methods),
  • rozszerzenia modułów funkcyjnych (function modules enhancements) – pozwalają na definiowanie dodatkowych parametrów wywołania modułów funkcyjnych,
  • rozszerzenia kodu (source code enhancements) – pozwalają na dodawanie w pewnych szczególnych miejscach fragmentów kodu, który jest wywoływany podczas działania programu (tzw. source code plug-ins),
  • nowe BADI (new BADI) – nowe podejście do już znanej techniki tworzenia rozszerzeń w oparciu o podejście obiektowe. Od BADI starego typu (tzw. klasyczne BADI) różni się dużo większą wydajnością oraz dodaniem nowych elementów języka ABAP, które ułatwiają wywołanie rozszerzeń

Ze względu na sposób deklaracji możliwych miejsc rozszerzeń (enhancement options) techniki dzielimy na dwie grupy:

  • jawne (explicit) – miejsca przewidziane przez programistę jako potencjalne miejsca implementacji rozszerzeń (do technik jawnych należą rozszerzenia kodu oraz nowe BADI)
  • niejawne (implicit) – grupa stałych i niezależnych od danej implementacji miejsc w kodzie, w które rozszerzenie może być wstawione; nie wymagają od programisty jawnej deklaracji i istnieją zawsze (do jawnych należą rozszerzenia klas, modułów funkcyjnych oraz pewna podgrupa rozszerzeń kodu).