W całej różnorodności realizowanych zadań programistycznych, nieuniknionym elementem jest powtarzalność pewnych procedur. W wielu programach dochodzimy do momentu, gdy realizujemy funkcjonalność, która pojawiła się w poprzednich zadaniach i/lub pojawi się w kolejnych niczym stały fragment gry w meczu piłki nożnej. Identyfikacja takich fragmentów i ponowne użycie już raz zaimplementowanych procedur odgrywa szczególne znaczenie. Jest to jedna z fundamentalnych zasad programowania, czyli możliwość powtórnego wykorzystania kodu (eng. Code Reusability).

Programując w języku ABAP,  mamy niejednokrotnie możliwość pójść o krok dalej – użyć gotowych mechanizmów, które zostały dostarczone przez środowisko programistyczne SAP.

Zastosowanie takich rozwiązań przynosi podwójne korzyści. Z jednej strony przyspiesza i usprawnia proces realizacji nowych funkcjonalności, z drugiej, podnosi jakość oprogramowania  – daje możliwość budowania sprawdzonych, przetestowanych i rozbudowanych rozwiązań, których samodzielne zaimplementowanie „od zera” wiązałoby się z dodatkowym nakładem środków. Jednym z takich mechanizmów jest log aplikacji SAP.

Czym jest log aplikacji?

Log aplikacji to mechanizm udostępniający możliwość rejestrowania wszystkich, bądź wybranych komunikatów, które wystąpiły podczas przebiegu aplikacji ABAP oraz interfejs do ich prezentacji. Komunikaty mogą być zaprezentowane użytkownikowi zaraz po zakończeniu przebiegu aplikacji lub, w przypadku programów działających w tle czy uruchamianych za pomocą interfejsów, zapisane w systemie i odczytane w dowolnym, późniejszym terminie. Elastyczność ustawień i duża konfigurowalność logu umożliwiają przejrzystą prezentację dużej liczby komunikatów.

Rozwiązanie takie świetnie sprawdza się w przypadku, gdy przetwarzanie jest wieloetapowe i jeden ogólny komunikat po zakończeniu przetwarzania  może okazać się niewystarczający.

Rozbudowany log w programie ABAP; komunikaty pogrupowane tematycznie – przydatny w przypadku dużej ilości komunikatów (zrzut ekranu z demonstracyjnego programu SBAL_DEMO_04)

Przykładowe zastosowania

Zastosowanie 1

Wystarczającym argumentem dla zastosowania logu jest program, gdzie w pojedynczym przebiegu tworzonych jest kilka różnych dokumentów. Nawet jeśli nie wystąpią żadne błędy, log umożliwi zaprezentowanie wszystkich numerów dokumentów w przejrzysty sposób, każdego w osobnym komunikacie. W przypadku błędów widać, które dokumenty zostały utworzone, a które nie i dlaczego, gdyż wyświetlone zostaną wszystkie komunikaty o błędach.

Przykład

Tworzymy program w ABAP służący do kopiowania materiałów. Poza kopią danych podstawowych samego indeksu materiałowego i danych z klasyfikacji, automatycznie utworzona zostaje specyfikacja materiałowa, marszruta technologiczna, aby na końcu wygenerowana została wersja produktu dla nowo utworzonego materiału.

Jak łatwo się domyśleć, podczas przebiegu powyższego programu dużo rzeczy może pójść nie tak. I w dużej mierze od jakości informacji zwrotnej zależy, jak sprawnie użytkownik poradzi sobie z poprawą ewentualnych błędów. Ważne, żeby dostarczyć użytkownikowi jak najpełniejszej informacji na temat przebiegu programu i ewentualnych błędów, które wystąpiły w jego trakcie.

Zastosowanie 2

Log okazuje się być szczególnie pomocny w przypadku programów nieuruchamianych ręcznie przez użytkownika. Takie programy działają w tle i nie ma możliwości zasygnalizowania od razu, że przetwarzanie nie przebiegło poprawnie. Za pomocą logu aplikacji użytkownik może np. sprawdzić wszystkie przebiegi z danego dnia i prześledzić ich status. W przypadku błędów  wszystkie komunikaty są widoczne w logu.

Przykład

Zamówienia tworzone w systemie zewnętrznym są przesyłane do systemu SAP za pomocą interfejsu. Tam, na podstawie otrzymanego dokumentu, tworzone jest zamówienie, dostawa przychodząca oraz faktura.

Powyższy program działa w tle. Uruchamiany jest za pomocą interfejsu. Użytkownik nie ma możliwości „podejrzenia”, co w danym momencie jest przetwarzane. Efekt jest zauważalny w postaci nowych dokumentów utworzonych w SAP. Ale to za mało. Co w przypadku, gdy wystąpił błąd i automat nie mógł zadziałać? Kolejny z dokumentów nie mógł zostać utworzony np. z powodu niekompletnych danych podstawowych materiału.

Tu po raz kolejny z pomocą może przyjść log aplikacji. Komunikaty z każdego przebiegu są rejestrowane, w tym przypadku w bazie danych, i mogą zostać odczytane w późniejszym terminie. Użytkownik przegląda wszystkie przebiegi z bieżącego dnia i może sprawdzić, w którym wystąpił błąd oraz co było jego przyczyną.

Jak to działa?

Wszystkie operacje związane z logiem, czyli inicjalizacja, konfiguracja, rejestracja komunikatów oraz zapis lub wyświetlenie logu wykonujemy w ABAP za pomocą modułów funkcyjnych z grupy SBAL. Poniżej przedstawione są przykładowe, najczęściej używane moduły:

  • ‘BAL_LOG_CREATE’ – inicjalizacja logu; konieczne jest wywołanie tego modułu przed dodaniem pierwszego komunikatu do logu
  • ‘BAL_LOG_MSG_ADD’– dodanie komunikatu do logu
  • ‘BAL_DSP_PROFILE*’– wywołanie odpowiedniego modułu determinuje wybór wariantu prezentacji logu
  • ‘BAL_DSP_LOG_DISPLAY’ –  wyświetlenie logu
  • ‘BAL_LOG_MSG_DELETE_ALL’ – oczyszczenie pamięci z komunikatów

WSKAZÓWKA!
Idealnym sposobem na szybkie zrozumienie działania logu i dopasowanie odpowiedniego wariantu do własnych potrzeb jest zapoznanie się z programami demonstracyjnymi ABAP z pakietu SZAL (SBAL_DEMO_*), w których zaprezentowane są  różne warianty użycia logu.

Kiedy warto zastosować log aplikacji programując w ABAP?

Warto zastanowić się nad zastosowaniem logu, jeśli w aplikacji:

  • Zestaw informacji zwrotnych nie ogranicza się do pojedynczego komunikatu
  • Przetwarzanie jest złożone i możemy się spodziewać wystąpienia wielu różnych informacji zwrotnych istotnych dla użytkownika
  • Przetwarzamy dużą liczbę rekordów podczas jednego przebiegu programu i musimy zaprezentować użytkownikowi kompletną informację zwrotną
  • Program jest uruchamiany automatycznie (działa w tle jako zadanie cykliczne lub wywołanie odbywa się za pośrednictwem interfejsu). Użytkownik chce mieć możliwość sprawdzenia wyników w dowolnym momencie, po zakończeniu przetwarzania.

Ciekawostki

Powyższe przykłady to nie jedyne sytuacje, w których log aplikacji przychodzi z pomocą. Dzieje się tak również podczas wywoływania standardowych funkcjonalności SAP w programach ABAP.

Oto konkretny przykład. Przy pomocy Naszej Aplikacji X użytkownik ma możliwość tworzenia specyfikacji materiałowej. W kodzie programu ABAP wywoływany jest standardowy moduł funkcyjny ‘CSAP_MAT_BOM_CREATE’. Jego wadą jest niestety to, że w przypadku błędu nie jest zbyt komunikatywny. Jako informację zwrotną, moduł wskaże jedynie kod powrotu różny od 0, czyli błąd.

Jeżeli taki błąd wystąpi podczas działania programu, na podstawie informacji zwrotnej z wywołanego modułu, można tylko wyświetlić komunikat informujący użytkownika, że tworzenie/zmiana specyfikacji materiałowej nie powiodła się. Po otrzymaniu przez użytkownika tak eufemistycznego komunikatu,  można z dużym prawdopodobieństwem przewidzieć, że przypadek ten wkrótce pojawi się w skrzynce konsultanta serwisu aplikacyjnego, który następnie spędzi kilka godzin, analizując kod standardowych funkcjonalności SAP, aby dojść do tego, że powodem błędu był nieprawidłowy wpis w danych podstawowych jednego z indeksów materiałowych wchodzących w skład specyfikacji .

Faktycznie mogło by się wydawać, że jedynym wyjściem z tej sytuacji jest żmudne i czasochłonne debugowanie kodu, a jednak nie. SAP również korzysta z mechanizmu logowania komunikatów podczas przebiegu standardowych modułów ABAP. W przypadku modułów z zaprezentowanego przykładu do opracowywania specyfikacji materiałowej, jedyne co należy zrobić, aby uzyskać dostęp do logu, to:

  1. Przed wywołaniem właściwych funkcjonalności zainicjować logowanie komunikatów za pomocą modułu ‘CALO_INIT_API'( warto zaznajomić się z dokumentacją SAP na temat tego modułu, gdyż wybierając odpowiednie opcje możemy zainicjować zapis do pamięci lokalnej lub bazy danych, rejestrowanie komunikatów indywidualne/zbiorcze itd.).
  2. Po zakończeniu przetwarzania, aby odczytać komunikaty z pamięci lokalnej, należy wywołać moduł ‘CALO_LOG_READ_MESSAGES’.
  3. Na końcu, w celu oczyszczenia lokalnej pamięci z komunikatów, wywołujemy moduł ‘CALO_LOG_INIT_MEMORY’.

Otrzymane komunikaty możemy wyświetlić użytkownikowi za pomocą mechanizmów opisywanych wcześniej.

Log aplikacji SAP jest przykładem na to, w jaki sposób, wykorzystując gotowe i niezawodne rozwiązania, możemy otrzymać wartość dodaną, uzyskaną niewielkim nakładem środków. Jednakże, nawet jeśli w danej sytuacji nie dysponujemy gotowymi mechanizmami stworzonymi wcześniej przez kogoś innego, należy pamiętać o zasadzie ponownego wykorzystania kodu przy tworzeniu własnych rozwiązań. Pozwala to zaoszczędzić czas podwójnie – najpierw przy tworzeniu kodu, a później przy jego testowaniu. A na tym zawsze korzystają zarówno dostawcy, jak i odbiorcy takich rozwiązań.