Łatwe testowanie BAPI w SE37

W wersji 4.5 systemu R/3 SAP został wprowadzony nowy model transakcji w interfejsach BAPI: Transaction Model for Developing BAPIs:

Transactionality
A BAPI must be implemented so that it is transactional. In other words, it complies with the ACID principle. The BAPI transaction model must also enable users to combine several BAPIs in one LUW.
The BAPI transaction model, therefore, implies both that individual BAPIs must be transactional and that several BAPIs combined in one LUW must comply with the ACID principle.

Transaction Control in Client
The BAPI transaction model must afford the user explicit transaction control. Therefore, if several BAPIs are called together, the caller can decide him/herself when to execute a COMMIT WORK (or, as the case may be, a ROLLBACK WORK). This means that BAPIs themselves cannot (generally) execute a COMMIT WORK command.

W konsekwencji interfejsy BAPI nie wykonują COMMIT WORK, wynik ich działania jest zapisywany w bazie danych dopiero po wywołaniu funkcji BAPI_TRANSACTION_COMMIT. To jest oczywiście generalna zasada, od której można znaleźć odstępstwa.

Taki model transakcyjny znacznie utrudnia przetestowanie funkcji BAPI w transakcji SE37. Wynik działania funkcji jest tylko widoczny w parametrach wyjściowych i logu przetwarzania. Wyniku działania, który nie został zapisany w bazie danych nie można sprawdzić w standardowych transakcjach SAP.

Przykładowo BAPI_GOODSMVT_CREATE księguje dokumenty materiałowe. Wyniki działania (numer dokumentu materiałowego) jest zwracany w parametrach GOODSMVT_HEADRET oraz MATERIALDOCUMENT i MATDOCUMENTYEAR. Ewentualne błędy przetwarzania są raportowane przez parametr RETURN. Poprawne wywołanie BAPI_GOODSMVT_CREATE w transakcji SE37 przekaże numer dokumentu materiałowego w parametrach wyjściowych. Jednak tego dokumentu nie będzie można wyświetlić w transakcji MB03 czy MIGO – BAPI nie wykonuje COMMIT WORK, dokument jest zapisywany w bazie danych dopiero po wykonaniu funkcji BAPI_TRANSACTION_COMMIT.

Uruchomienie w SE37 testowanego BAPI i następnie BAPI_TRANSACTION_COMMIT nie rozwiązuje kwestii, gdyż obie funkcje są wtedy wykonywane w oddzielnych LUWs (ang. Logical Unit of Work).

Można znaleźć kilka rozwiązań problemu testowania funkcji BAPI. Można napisać prosty raport testowy, który wywoła testowane BAPI i funkcję BAPI_TRANSACTION_COMMIT. Można też zamiast raportu przygotować funkcje-wrapper o interfejsie identycznym jak testowane BAPI. Te podejścia, choć skuteczne mają podstawową wadę – wymagają dodatkowego programowania i przenoszenia transportu z systemu rozwojowego do testowego.

Moim zdaniem najwygodniejszym rozwiązaniem jest wykorzystanie sekwencji testowych dostępnych w transakcji SE37. W tym celu należy uruchomić transakcję SE37 i z menu wybrać:

W kolejnym oknie dialogowym należy podać testowaną funkcję BAPI oraz funkcję BAPI_TRANSACTION_COMMIT:

i wykonać obie funkcję przyciskiem: 

Teraz obie funkcje zostaną kolejno uruchomione w środowisku testowym transakcji SE37. Będzie można podać parametry wejściowe testowanego BAPI i sprawdzić wynik działania w parametrach wyjściowych BAPI. Wykorzystanie sekwencji testowej powoduje, że obie funkcje są wykonywane w tej samej LUW. Dzięki temu BAPI_TRANSACTION_COMMIT zapisze w bazie danych wynik działania BAPI.

Po wykonaniu sekwencji testowej zostanie wyświetlone okno dialogowe, w którym całą sekwencję testową można zapisać w celu ponownego wykorzystania:

Więcej o sekwencjach testowych znajdziesz na SAP Help: Saving Tests and Test Sequences.

Komentarze o “Łatwe testowanie BAPI w SE37

  1. Wypełnianie interfejsu BAPI czasem jest dość ciężkie.
    Na szczęście w simple finance SAP wprowadził możliwość zapisania każdego wywołania BAPI księgowych.
    (Nota 2286603). Miejmy nadzieję, że inne bapi też będzie można tak obsłużyć

Zostaw komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.