Wiederaufruf der SAP ERP Meldung nach Ausführung einer Aktivität

11. Juni 2024

SAP bietet mit Aktivitäten eine Möglichkeit, zusätzliche kundeneigene Funktionen für Meldungen bereitzustellen. Da Meldungen auch im SAP S/4HANA System weiter existieren, steht dieses Feature folglich auch dort und nicht nur im ECC zur Verfügung (bei Nutzung des SAP Gui oder Webgui). Die nachfolgend beschriebene Implementierungslogik – hier exemplarisch für Qualitätsmeldungen gezeigt – ist ebenso für Servicemeldungen und Instandhaltungsmeldungen identisch implementierbar.

Manche Aktivitäten erfordern die Verbuchung der Meldung. In diesen Fällen muss bei der Definition der Aktivität im Feld „Funktionsbaustein beim Sichern“ ein Funktionsbaustein angegeben werden.

Nach erfolgreicher Ausführung der Aktivität wird die Verbuchung getriggert, die Meldung geschlossen und der Anwender muss für weitere Bearbeitungsschritte die Meldung erneut über das Einstiegsbild der Transaktion aufrufen.

Nachfolgend wird exemplarisch aufgezeigt, wie – abweichend vom SAP Standard Prozess – die Meldung wieder im Änderungsmodus aufgerufen wird. Im konkreten Fall sind in der Regel weitere, komplexere Kriterien und Bedingungen zu berücksichtigen.  Die Implementierung besteht aus drei Teilen, die nachfolgend erläutert werden.

 

1) Klasse zur Kapselung der benötigten Methoden

In einer neuen Klasse werden nachfolgend aufgeführte Methoden implementiert. Die Methoden sind STATIC PUBLIC deklariert, um an jeder Aufrufstelle den Aufruf ohne Instanzerzeugung zu ermöglichen.

• RE_ENTRY_TRANSACTION
  Wiederaufruf der Meldung. Um zu verhindern, dass die Verbuchung der Meldung noch nicht abgeschlossen ist und die Meldung daher noch gesperrt ist, werden zunächst die Sperreinträge gelesen und erst nach vollständiger Verbuchung der Meldung (und damit Löschen der Sperre) die Meldung wieder aufgerufen:

• ACTIVATE_RE_ENTRY_TRANSACTION
  Diese Methode aktiviert den Wiederaufruf durch Setzen der Attribute
  • GV_RE_ENTRY_TRANSACTION
  • GV_QMNUM
  • GV_CALLING_TRANSACTION

 

Da sich der komplette Ablauf innerhalb einer LUW abspielt, sind alle Attribute STATIC und PUBLIC. So sind die Attributwerte – innerhalb der LUW – unabhängig von der Aufrufstelle abrufbar ohne Umwege über das SAP Memory zu gehen.

Die Klasse steht damit in der Tradition der Klassiker der „Objektorientierten Funktionsgruppen“ wie CL_GUI_FRONTEND_SERVICES oder CL_ABAP_CHAR_UTILITIES. Diese Anmerkung nur, um dem Hinweis vorzubeugen: „Warum OO, wenn man ohnehin nur statische Methoden verwendet?“.

 

2) Implizite Erweiterung in Funktionsgruppe IQS0

Im Include LIQS0F20 wird zu Beginn des Unterprogramms LEAVE_TO_TCODE ein implizites Enhancement angelegt.

Dort wird die unter dem ersten Punkt  erläuterte Methode RE_ENTRY_TRANSACTION aufgerufen.

3) Aktivierung des Wiederaufrufs

Hier gibt es zwei Möglichkeiten.

a) Aufruf im Verbuchungs-Funktionsbaustein der Aktivität

Ist der Verbuchungs-Funktionsbaustein eine kundeneigene Entwicklung, kann dort der Wiederaufruf aktiviert werden. Hierzu ist die Methode ACTIVATE_RE_ENTRY_TRANSACTION mit der Meldungsnummer aufzurufen.

b) Aufruf in der Implementierung zum BAdI NOTIF_EVENT_SAVE

Stammt der Verbuchungs-Funktionsbaustein aus dem SAP Standard, muss der Wiederaufruf in der Implementierung des BAdIs NOTIF_EVENT_SAVE aufgerufen werden. Auch dort erfolgt der Aufruf der Methode ACTIVATE_RE_ENTRY_TRANSACTION mit Übergabe der Meldungsnummer.
Hierbei muss geprüft werden, ob Sichern durch eine Aktivität im aktuellen Transaktionsaufruf getriggert wurde, hier durch einen entsprechenden LOOP über Tabelle CT_IWQMSM umgesetzt.