Samouczek programowania w oknie dialogowym: Pula modułów w SAP ABAP

⚡ Inteligentne podsumowanie

Programowanie dialogowe w SAP ABAP tworzy programy puli modułów, które komunikują się z użytkownikiem za pośrednictwem ekranów i zmieniają zawartość bazy danych. Ta strona wyjaśnia kody transakcji, ekrany, status GUI, logikę przepływu ekranów, Dynpros oraz strukturę puli modułów.

  • 💬 Definicja podstawowa: Program dialogowy obsługuje wszelką interakcję użytkownika, taką jak wprowadzanie danych, wybieranie pozycji menu lub klikanie przycisku, a także może aktualizować bazę danych.
  • 🅼 Rodzaj programu: Programy dialogowe są pulami modułów typu M, nie mogą działać samodzielnie i muszą być powiązane przynajmniej z jednym kodem transakcji z ekranem początkowym.
  • 🧩 Składniki: Kod transakcji, ekrany, status GUI, pula modułów ABAP i logika przepływu tworzą razem jedną aplikację dialogową.
  • 🔄 Logika przepływu: PBO uruchamia się przed pojawieniem się ekranu, PAI uruchamia się po wykonaniu akcji przez użytkownika, POH odpowiada na F1, a POV odpowiada na F4.
  • 🖥️. Dynpro: Ekran wraz z logiką przepływu to dynpro, a każdy dynpro kontroluje dokładnie jeden krok dialogu.
  • 📦 Pula modułów: Wszystkie funkcje dynpros wywoływane w ramach jednej transakcji odnoszą się do wspólnej puli modułów, która przechowuje moduły dialogowe.
  • 🛠️. Ścieżka tworzenia: SE80 tworzy pulę modułów, SE51 projektuje ekran, SE41 buduje status GUI, a SE93 łączy kod transakcji.

SAP Programowanie dialogów ABAP

Czym jest programowanie dialogowe?

SAP-ABAP obsługuje dwa typy programów – Program Raportowy i Program Dialogowy.

Jeśli Twój program ABAP wymaga wkładu użytkownika, używane jest programowanie Dialog.

Dialog użytkownika to dowolna forma interakcji między użytkownikiem a programem, która może przybierać następujące formy:

  • Wprowadzanie danych
  • Wybór pozycji menu
  • Kliknięcie przycisku
  • Kliknięcie lub dwukrotne kliknięcie wpisu

Programu dialogowego używamy także wtedy, gdy musimy poruszać się pomiędzy ekranami

Programy dialogowe tworzone są z typem „M” – Pula modułów. Nie mogą być wykonane niezależnie i muszą być dołączone do co najmniej jednego kodu transakcji, w którym określisz ekran początkowy.

Różnica między programami raportującymi i dialogowymi

Różnica między programami raportującymi i dialogowymi

Program raportujący:

Raport to program, który zazwyczaj odczytuje i analizuje dane w tabelach bazy danych bez zmiany pliku baza danych.

Program dialogowy:

Program dialogowy umożliwia interaktywną pracę z systemem oraz zmianę zawartości tabel bazy danych. Każdy program dialogowy ma określoną sekwencję ekranów, które system przetwarza jeden po drugim.

kryteria Program raportów Program Dialogowy
Rodzaj programu Typ 1, wykonywalny Typ M, pula modułów
Dostęp do bazy danych Odczytuje i analizuje dane Odczytuje i zmienia dane
Egzekucja Działa samodzielnie Działa tylko za pomocą kodu transakcji
Control: Wydarzenia raportu Logika przepływu ekranu każdego dynpro

Sekwencję ekranową transakcji dialogowej łatwiej prześledzić na przykładzie.

Przykładowe przetwarzanie transakcji w programie Dialog Programming

Przykładowe przetwarzanie transakcji

Diagram przedstawia jedną transakcję od pierwszego ekranu do aktualizacji bazy danych. Użytkownik wprowadza dane na ekranie 100, PAI weryfikuje wpis i decyduje o kolejnym ekranie, ekran 200 zbiera pozostałe dane, a zadanie aktualizacji ostatecznie zapisuje rekord. Każdy z tych kroków jest generowany przez komponenty wymienione poniżej.

Składniki programu Dialog

w odróżnieniu raport co ogólnie wiąże się ze stworzeniem jednego autonomicznego programu, który może być wykonywany niezależnie od innych obiektów, tworzenie programów dialogowych pociąga za sobą tworzenie wielu obiektów, z których żaden nie może być wykonywany samodzielnie. Zamiast tego wszystkie obiekty są powiązane hierarchicznie z programem głównym i są wykonywane w kolejności określonej przez program główny dialogu.

Składniki programu dialogowego to:

Kod transakcji

  • Kod transakcji rozpoczyna sekwencję ekranów.
  • Kody transakcji tworzysz w Przeglądarce Repozytorium w ABAP Workbench lub za pomocą Transakcji SE93.
  • Kod transakcji jest powiązany z programem ABAP i ekranem początkowym.
  • Sekwencję ekranów można rozpocząć z dowolnego programu ABAP za pomocą instrukcji CALL SCREEN.

Screens

  • Każde okno dialogowe w pliku SAP system jest kontrolowany przez jeden lub więcej ekranów.
  • Tworzysz ekrany za pomocą ekranu Painter w ABAP Workbench poprzez transakcję SE51
  • Każdy ekran należy do programu ABAP.
  • Ekrany te składają się z „maski ekranu” lub „układu” i jego logiki przepływu. Ekran ma układ, który określa pozycje pól wejścia/wyjścia i innych elementów graficznych, takich jak pola wyboru i przyciski radiowe. Logika przepływu określa logiczne przetwarzanie w obrębie ekranu.

Stan interfejsu graficznego

  • Każdy ekran ma status(y) GUI, które są niezależnymi komponentami programu.
  • Kontroluje paski menu, standardowy pasek narzędzi, pasek narzędzi aplikacji, za pomocą których użytkownik może wybierać funkcje w aplikacji.
  • Tworzysz je w środowisku roboczym ABAP za pomocą Menu Painter.

Program ABAP

  • Każdy ekran i status GUI w systemie R/3 należy do jednego programu ABAP.
  • Program ABAP zawiera moduły dialogowe wywoływane przez logikę przepływu ekranu, a także przetwarzają dane wejściowe użytkownika ze stanu GUI.
  • Programy ABAP korzystające z ekranów nazywane są także programami dialogowymi.
  • W puli modułów (program typu M); pierwszym wywoływanym blokiem przetwarzania jest zawsze moduł dialogowy. Można jednak używać ekranów także w innych programach ABAP, takich jak programy wykonywalne lub moduły funkcyjne. Pierwszy blok przetwarzania jest wówczas wywoływany inaczej; na przykład przez środowisko wykonawcze lub wywołanie procedury. Następnie rozpoczyna się sekwencja ekranów za pomocą instrukcji CALL SCREEN.

Logika przepływu ekranu

Logika Screen Flow składa się zasadniczo z czterech komponentów.

  • Przetwarzaj przed wyjściem (PBO) zdarzenie: które jest przetwarzane przed wyświetleniem ekranu
  • Proces po wprowadzeniu (PAI) zdarzenie: które jest przetwarzane po akcji użytkownika na ekranie
  • Przetwarzaj na prośbę o pomoc (PO): który jest przetwarzany po naciśnięciu klawisza F1
  • Przetwarzaj na żądanie wartości (POV): który jest przetwarzany po naciśnięciu klawisza F4

POH i POV są szczegółowo wyjaśnione na stronie o proces dotyczący żądania wartości i proces dotyczący żądania pomocy.

Dynpro

  • Ekran wraz z logiką przepływu nazywany jest Dynpro („Programem dynamicznym”, ponieważ logika przepływu ekranu wpływa na przepływ programu)
  • Każdy dynpro kontroluje dokładnie jeden krok Twojego Programu Dialogowego.
  • Ekrany należące do programu to numerowaneSekwencja przepływu ekranów może być liniowa lub cykliczna. Z poziomu łańcucha ekranów można nawet wywołać kolejny łańcuch ekranów i po jego przetworzeniu powrócić do pierwotnego łańcucha. Można również zastąpić statycznie zdefiniowany następny ekran z poziomu modułów dialogowych programu ABAP.

Pula modułów ABAP

  • W przypadku zdarzenia PBO lub PAI Dynpro wywołuje program dialogowy ABAP. Zbiór takich programów nazywa się pulą modułów ABAP.
  • Na przykład moduły wywoływane w przypadku zdarzenia PAI służą do sprawdzania danych wejściowych użytkownika i wyzwalania odpowiednich kroków okna dialogowego, takich jak zadanie aktualizacji.
  • Wszystkie dynpro należy wezwać od wewnątrz pierwszej transakcja odnosi się do wspólnej puli modułów.

Struktura programu dialogowego

Struktura programu dialogowego

Schemat struktury pokazuje, w jaki sposób kod transakcji, ekrany, status GUI i pula modułów są powiązane z tym samym programem głównym.

Przebieg procesu dla programu dialogowego

Przebieg procesu dla programu dialogowego

Schemat blokowy procesu pokazuje naprzemienne działanie między ekranem i programem ABAP: PBO wypełnia pola ekranu, użytkownik podejmuje działanie, a PAI przetwarza dane wejściowe przed wywołaniem następnego ekranu.

Jak utworzyć program puli modułów

Powyższe komponenty są tworzone w ustalonej kolejności. Poniższe kroki budują działającą transakcję z pustej puli modułów.

  1. Utwórz pulę modułów: W SE80 lub SE38 utwórz program, którego nazwa zaczyna się od SAPMZ i ustaw typ programu na M – Pula modułów. Typu nie można później zmienić bez usunięcia obiektu.
  2. Deklaracja danych globalnych: Umieść polecenie TABLES i zmienne globalne w elemencie TOP include, który będzie mógł zostać odczytany przez każdy moduł dialogowy puli.
  3. Zaprojektuj ekran: Utwórz ekran 100 za pomocą ekranu Painter (SE51), umieść pola wprowadzania danych na układzie i wprowadź kolejny numer ekranu w atrybutach ekranu.
  4. Napisz logikę przepływu: Na karcie Logika przepływu wywołaj jeden moduł dla PBO i jeden dla PAI, jak pokazano poniżej.
  5. Zbuduj status GUI: Utwórz status za pomocą menu Painter (SE41) i ustaw go w module PBO za pomocą instrukcji SET PF-STATUS, tak aby polecenia Save, Back i Exit dotarły do ​​programu jako kody funkcji.
  6. Powiąż kod transakcji: W SE93 utwórz transakcję dialogową, nazwij pulę modułów i wpisz 100 jako ekran początkowy.
* Screen 100, flow logic
PROCESS BEFORE OUTPUT.
  MODULE status_0100.

PROCESS AFTER INPUT.
  MODULE user_command_0100.

* Module pool SAPMZDEMO
MODULE status_0100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
  SET TITLEBAR 'TITLE_100'.
ENDMODULE.

MODULE user_command_0100 INPUT.
  CASE sy-ucomm.
    WHEN 'SAVE'.
      PERFORM save_data.
    WHEN 'BACK' OR 'EXIT'.
      LEAVE TO SCREEN 0.
  ENDCASE.
ENDMODULE.

💡 Wskazówka: LEAVE TO SCREEN 0 kończy bieżący ekran i powraca do punktu wywołania, co jest standardowym sposobem na czyste opuszczenie transakcji dialogowej.

FAQ

Polecenie CALL SCREEN otwiera nowy ekran i pozostawia ekran wywołujący na stosie, więc przetwarzanie wraca do niego. Polecenie LEAVE TO SCREEN zastępuje bieżący ekran i nic nie wraca do ekranu wywołującego.

Pula modułów o nazwie SAPMZDEMO jest podzielone na MZDEMOTOP dla danych globalnych, MZDEMOO01 dla modułów PBO, MZDEMOI01 dla modułów PAI i MZDEMOF01 dla podprogramów. Workbench generuje je automatycznie.

Podaj typ funkcji przycisku E w statusie GUI i wywołaj jego moduł poleceniem MODULE exit AT EXIT-COMMAND. Moduł zostanie uruchomiony przed walidacją pól, dzięki czemu użytkownik może opuścić ekran z nieprawidłowymi wpisami.

Tak. Asystenci AI w narzędziach programistycznych ABAP tworzą moduły PBO i PAI, instrukcję CASE w SY-UCOMM oraz walidacje pól na podstawie opisu ekranu. Sam układ jest nadal rysowany na ekranie. Painter.

Dynpros nadal jeździ wszystkimi klasycznymi SAP Transakcja GUI. Nowe interfejsy użytkownika są zazwyczaj tworzone z wykorzystaniem Fiori, a narzędzia AI pomagają, odczytując istniejącą logikę przepływu i proponując odpowiedni projekt usługi i aplikacji.

Podsumuj ten post następująco: