Analiza programów ABAP – powody

Pojawia się kilka powodów zmuszających do analizy programów. Jednym z nich może być chęć zoptymalizowania programu. Kolejnym, znalezienie interesującego nas kawałka kodu. Możemy także mieć potrzebę porównania działanie programu na dwóch systemach.

Wyszukiwanie konkretnego fragmentu kodu

Czasem zdarza się że program robi coś w nieodpowiedni sposób i zadaniem programisty jest to zmienić. Żeby móc dokonać stosownej zmiany trzeba wyszukać odpowiedni fragment w kodzie i go edytować. Zadanie to może być dość czasochłonne dla programisty jeśli wymagałoby to od niego przeczytania całego kodu programu, metod i modułów funkcyjnych. Na szczęście, w takim przypadku można skorzystać z narzędzia ABAP Runtime Analysis dostępnego spod transakcji SAT. Narzędzie to pozwala nam na pomiar czasu wykonywania programu wraz z wyszczególnieniem jaki procent czasu zajęło jakie polecenie. Dzięki temu możliwe jest zlokalizowanie zbyt długo wykonujących się poleceń w raportach. Pomiary te zależą od aktualnego natężenia ruchu w sieci a także od zawartości buforów. Na szczęście, można też dokonywać porównani pomiarów co umożliwia sprawdzenie jak dany raport zachowuje się gdy ilość użytkowników się zmienia. Udogodnieniem jest też wybór elementów programu na jakie chcemy zwracać uwagę podczas działania narzędzia. Pozwala to na ograniczenie rozmiaru pomiarów – zajmują mniej miejsca i prezentują tylko interesujące nas dane. Oprócz czasów wykonywania możliwe jest także sprawdzenie jak wiele pamięci zajmuje dany raport podczas działania. W narzędziu możemy także przejść do przygotowanych przez SAP optymalnie napisanych przykładów kodu i ich potencjalnie gorszych odpowiedników. Przykłady te można znaleźć klikając w przycisk Tips & Tricks gdzie zostały również opisane. SAT oferuje też podgląd działających w tle programów i uruchomienie pomiaru dla nich – jesteśmy w stanie sprawdzić na czym nasz program utknął podczas wykonywania.

Aby wyszukać interesujący nas fragment kodu, uruchamiamy transakcję SAT i tworzymy w niej wariant.

Po podaniu nazwy ustawiamy aggregation na None, odblokowuje to mierzenie zużycia pamięci. Wykonane identyczne polecenia nie zostaną pogrupowane w jeden wiersz. Dzięki temu można podążać za logiką programu. Dodatkowo można zaznaczyć w opcjach Explict Switching On and Off Measurement. Pozwoli to na włączanie i wyłączanie pomiaru na życzenie, zmniejsza się w ten sposób rozmiar pliku z pomiarami.

Aby uruchomić pomiar musimy napisać „/ron” w polu tekstowym w lewym górnym rogu ekranu lub przechodzimy przez ścieżkę System->Utilities->Runtime Analysis->Switch On. Zakończenie odbywa się w analogiczny sposób(„/roff” lubSystem->Utilities->…). W zakładce Statements oznacza się tylko takie polecenia, o jakich chcemy zbierać dane podczas analizy programu. Po zaznaczeniu interesujących nas opcji zapisujemy wariant. Dostępne opcje:

Rozpoczynamy pomiar po podaniu nazwy w odpowiednim polu (Transaction, Program, Function Module), zaznaczeniu odpowiednich opcji i kliknięciu Execute.
Eval. Immediatly uruchamia analizę od razu po pomiarze.

Determine Names of Internal Tables pozwala na określenie nazw tabel wewnętrznych.

Wyniki pomiarów znajdują się w zakładce Evaluate w transakcji SAT.

Przechodzimy do naszego wyniku klikając na niego dwukrotnie.

W otworzonym w ten sposób oknie przechodzimy do zakładki Call Hierarchy. Wyszukujemy odpowiednie polecenia lub zdarzenie. Jeśli dwukrotnie je klikniemy, otworzy się edytor ABAP ustawiony na odpowiedniej linii programu. W zakładce tej możemy też kliknąć na interesujące nas polecenie i znaleźć jego pozycję w innym narzędziu(Hit List, Processing Blocks, Times Tool).

Dodatkowo w zakładce Processing Blocks wypisane są wszystkie zdarzenia wykonane w czasie programu, co pozwala na zrozumienie przebiegu programu. Można tam też podświetlić na czerwono wszystkie zdarzenia, które przekroczyły podany procent czasu wykonywania całego programu. Aby to zrobić trzeba kliknąć w .

Przetwarzanie długo działających zadań

Może zdarzyć się sytuacja gdy jakiś proces działa długo i blokuje inne procesy. Aby dowiedzieć się co taki proces właściwie robi uruchamiamy transakcję SAT. W transakcji utworzymy sobie wariant, w którym aggregation ustawimy na None. Klikamy Switch On/Off aby pobrać dane o procesach działających w równoległej sesji. Lista wygląda podobnie do tej z SM50.

Aby rozpocząć lub zakończyć pomiar korzystamy z guzików Activate measurement / Deactivate measurement.

W zakładce Evaluate należy znaleźć swój pomiar i kliknąć na niego dwukrotnie. W Call Hierarchy możemy przeanalizować co się dzieje. Dzięki temu wszystkie nieskończone pętle stają się doskonale widoczne na pierwszy rzut oka.

Śledzenie żądań HTTP/RFC i procesów innych użytkowników

Takie żądania są trudne do prześledzenia. Na szczęście ABAP Runtime Analysis umożliwia nam zaplanowanie śledzeń dla wszystkich użytkowników na serwerze.

Aby przeprowadzić takie działanie, w transakcji SAT tworzy się wariant z aggregation ustawionym na None. Następnie klika się Schedule w zakładce For User/Service Area i Schedule measurment w Overview of Scheduled Measurements. W okienku, które wyskoczy możemy dopercyzować: użytkownika, klienta, sesję, kategorię procesu, typ obiektu (transakcja, raport, moduł, itp), obiekt, maksymalna ilość pomiarów, czas trwania pomiarów.

Śledzenie przeprowadzane jest gdy wymagania zostaną spełnione. Wyniki wyglądają analogicznie do poprzednich.

Podsumowanie

Używanie wariantów pozwala zmniejszyć rozmiar pomiarów. Dzięki Call Hierarchy można odnaleźć odpowiednie polecenia ABAP. Processing Blocks wyświetla Call Hierarchy jako strukturę folderów – drzewo. Hierarchia jest czytelniejsza. Aggregation Per Call Position umożlwia pogrupowanie takich samych poleceń w jedno. Zmniejszy to rozmiar naszego pliku. Aggregation None sprawi że będzie można dokładnie prześledzić działanie programu.

Zapisz się do
naszego newslettera

Nie przegap nowych aktualizacji