Fehlersuche bei Workflow-Problemen – SAP ERP

Fehlersuche bei Workflow-Problemen – Leicht gemacht. Mit SAP Workflow können in SAP ERP Automatisierungen durchgeführt werden. Das erleichtert die Arbeit, erhöhte die Transparenz und ermöglicht eine schnellere Arbeit mit dem System. Mit dem SAP Business Workflow können Geschäftsprozesse, die wiederholt ausgeführt werden sollen, abgebildet werden und teil- oder vollautomatisiert ausgeführt werden.

Vor allem da SAP Business Workflow in allen SAP Business-Suite-Systemen zur Verfügung steht, werden diese Vorteile oft genutzt und Prozesse automatisiert abgebildet (Transaktion SWDD zur Anlage von Workflows). Typische Anwendungsfälle von Workflows sind: Optimierung des Informationsflusses, Genehmigungsverfahren, Fehler- und Ausnahmebehandlungen, automatische Unterstützungen, Ablaufunterstützung.

Doch leider können bei einem Workflow auch Fehler auftreten. Die Ursachen sind sehr unterschiedlich. In diesem umfangreichen Artikel werden einmal die besten Tipps und Tricks erläutert, um potenzielle Fehler bei Workflow-Problemen in SAP ERP zu finden und zu beheben.

Transaktionen für die Fehlersuche bei Workflow-Problemen im Überblick

Transaktionscode	Beschreibung
SWUD	Workflow-Diagnose
SWDM	Business Workflow Explorer
SWDD	Workflow-Builder
SWI1	Workitem-Selektion
SWEQADM	Administration der Ereignis-Queue
SWUS	Workflow testen
SWETYPV	Ereignistypkopplung
SWU8	Trace der Komponente BC-BMT-WFM
SWU9	Trace der Komponente BC-BMT-WFM
SWF_APPL_DISPLAY	Anwendungslog auswerten
SWU0	Simulation eines Ereignisses
SWUE	Erzeugen eines Ereignisses
SWELS	Ereignis-Trace ein-/ausschalten
SWEL	Ereignis-Trace anzeigen
SWPR	Workflow-Restart nach Fehler
SWPC	Workflows fortsetzen nach Systemabsturz
SWI2_DIAG	Einstieg in Workitem-Analyse (SWI2)
SWU2	Transaktionaler RFC
ST22	ABAP Laufzeitfehler
SWO1	Business Object Builder
SWF_ADM_SUSPEND	Restart von suspendierten Callbacks

Workflow-Diagnose

Von der SAP als vorgeschlagene Transaktion für die Workflow-Diagnose gilt die Transaktion SWUD. Dadurch können typische Problemsituationen, die im Umgang mit SAP Business Workflow auftreten, identifiziert und behoben werden. Durch ein Diagnosereport kann man Schritt-für-Schritt mögliche Fehler analysieren.

Diese Transaktion ist sehr mächtig und enthält die wichtigsten und relevantesten Transaktionen. Durch Klick auf den entsprechenden Aktivieren-Button werden Untermenüs geöffnet bzw. der relevante Report gestartet.

Fehlersuche bei Workflow-Problemen und gleichzeitiges Beheben in einem Workflow? -Diagnose mit der Transaktion SWUD ist einer der ersten Anhaltspunkte.

Abgestürzter Workflow

Kurzdump im Programm

Gerade wenn man eigene Workflows mit ABAP-Code implementiert hat, ist es wahrscheinlich, dass es zu einem Kurzdump gekommen ist. Die zentrale Anlaufstelle ist die Übersicht der ABAP Laufzeitfehler in der Transaktion ST22.

Workflows können sowohl im Vordergrund durch den SAP-Benutzer als auch im Hintergrund durch den Workflow-Benutzer (WF-BATCH bzw. SAP_WFRT unter S/4HANA) ausgeführt werden. Wenn man direkt den Benutzer weiß, kann man danach filtern. Ansonsten kann man sich einfach einmal alle Laufzeitfehler anzeigen lassen und die Fehler untersuchen.

Wenn man die Ursache des Fehlers gefunden hat, kann man diesen entweder direkt im ABAP Workbench (Transaktion SE80) im entsprechenden ABAP-Paket bzw. Coding beheben oder man testet erst einmal mit einem Breakpoint im Debugging die Programmausführung. Hierzu eignet sich vor allem der Business Object Builder in der Transaktion SWO1, um den Objekttyp testen zu können.

Sehr nützlich für die Analyse sind die Grunddaten des Objekttyps. Hierzu gibt man in der Transaktion SWO1 den Objekttyp an, klickt auf „Anzeigen“ und anschließend auf „Grunddaten“. Hier findet man ebenfalls interessante Informationen, die für die Programmierung bzw. das Verständnis sehr nützlich sind.

Fehlerhafter Workflow wegen Sperre

Bei den meisten Workflows wird auf ein SAP-Objekt zugegriffen. Hierbei kann es vorkommen, dass wenn zeitgleich das SAP-Objekt bereits gesperrt ist, dass der Workflow nicht darauf zugreifen kann und auf einen Fehler läuft. Möglicherweise greift im gleichen Zeitpunkt bereits ein SAP-Benutzer asynchron auf das Objekt zu. Wenn das im Programm selber nicht geprüft und sichergestellt ist, entsteht ein Fehler (Siehe OSS-Hinweis 749945).

Des Weiteren kann eine Sperre entstehen, wenn man mit einer Parallelverarbeitung im Workflow arbeitet. In einem Zweig wird das Workitem vom SAP-Benutzer gesperrt, obwohl im zweiten Zweig bereits das notwendige Ereignis eingetreten ist. Obwohl der Workflow erfolgreich beendet ist, kann das „Logische gelöscht“-Kennzeichen wegen der Sperre nicht gesetzt werden. Der Callback bleibt also aus und wird in der Tabelle SWP_SUSPEN gespeichert.

Systemabsturz oder Netzwerkproblemen

Es kann zudem vorkommen, dass bei einem Systemabsturz oder generellen Netzwerkproblemen Workitems mit tRFC- oder qRFC-Problemen im SAP-System hängen.

In der Transaktion SM58 kann man Informationen über tRFC-Aufrufe erhalten. Hier sieht man sofort, wenn in Verbindung mit tRFC Workflow-Probleme aufgetreten sind. Zudem hinaus sieht man sofort, in welchem ABAP-Programm der Fehler entstanden ist.

Fehlerhafte tRFC-Aufrufe können auch neugestartet werden in der Transaktion SM58. In diesem Abschnitt wird es näher erläutert.

Workitem-Analyse (SWI2_DIAG)

Eine der zentralen Transaktion für die Fehleranalyse von Workflows ist SWI2_DIAG. Denn mit dieser Transaktion ist es möglich, die fehlerhaften Workitems zu analysieren bzw. gefiltert nach Zeiträumen angezeigt zu bekommen.

Man erhält eine Übersicht über alle fehlerhaften Workitems und kann direkt durch Doppelklick eine Fehler-Diagnose darüber erhalten. Das ist, abhängig von der Programmierung, sehr ausführlich und zeigt einem woran das Programm auf einen Fehler gestoßen ist.

Fehler mit der Ereigniskopplung

Oft startet ein Workflow, wenn ein bestimmtes Ereignis in Verbindung mit einem Objekttyp erzeugt wird. Das kann an mehreren Stellen eingestellt werden:

• Ereignistypkopplung – Transaktion SWETYPV
• Ereignisse zum Änderungsbeleg – Transaktion SWEC

Ereignis-Queue

Die zentrale Transaktion für die Analyse und Fehlersuche von Workflows im Zusammenhang mit Ereigniskopplungen ist SWEQADM.

In der Transaktion für die Administration der Ereignis-Queue kann man schnell und übersichtlich erkennen in welchen Ereignissen Fehler aufgetreten sind. Dafür eignet sich vor allem der Tab „Fehlerhafte Kopplung“ für die Übersicht.

Deaktivierung der Ereigniskopplung

Wenn die Ereigniskopplung deaktiviert wird, ist häufig eine falsche Übergabe von Daten vom Ereignis an den Ereignisverbraucher bzw. das Workflow-Muster die Ursache. Wenn man den Eingang zum Zeitpunkt der Deaktivierung überprüft, findet man schnell die Ursache.

Um die Ursache noch weiter eingrenzen zu können, eignet sich der Ereignis-Trace hervorragend. Hierzu schaltet man als Erstes den Ereignis-Trace in der Transaktion SWELS ein bzw. überprüft, ob er bereits eingeschaltet ist.

In der Transaktion SWEL kann man letztlich den Ereignis-Trace anzeigen. Durch Doppelklick auf die gewünschte Zeile kann man in der Detailansicht schließlich die Nachricht erkennen. Wenn die Verbrauchermethode gut implementiert ist, wird hier ausreichend geloggt, so dass die Ursache des Fehlers schnell und einfach identifiziert werden kann.

Sehr nützlich ist es, sich den Ereignis-Container per E-Mail übergeben zu lassen. Hierzu legt man in der Transaktion SWE2 einen weiteren Eintrag mit dem gleichen Objekttyp und Ereignis an, das man untersuchen möchte. Zusätzlich trägt man unter „Verbrauchertyp“ seinen SAP-Benutzer ein und unter Verbraucher-Funktionsbaustein SWE_EVENT_MAIL.

Nun erhält man gemäß der E-Mail in seinem Benutzerstamm (Transaktion SU01) eine E-Mail mit den übergebenen Informationen im Ereignis-Container. Man kann sich alternativ auch in der Transaktion SOST die gesendete E-Mail ansehen, wenn der E-Mail-Versand im SAP-System nicht eingerichtet ist.

Simulation eines Ereignisses

Mit der Transaktion SWU0 kann man ein Ereignis an einem Objekttyp simulieren. Wenn man also einen Breakpoint im Verbraucherbaustein gesetzt hat, kann man direkt im Debugger die Programmierung analysieren.

Die Transaktion SWUE eignet sich ebenfalls hervorragend, um ein Ereignis zu simulieren und somit potenzielle Fehler in einem Workflow zu analysieren. Hierzu kann man dabei das Ereignis an einem echten SAP-Objekt im System testen.

Fehlerbehebung nach Workflow-Problem

Fehleranalyse und Neustart temporär fehlerhafter Workitems

In der Tabelle SWP_SUSPEN werden alle suspendierten Workitems-Callbacks aufgelistet. Man kann hierfür mit der Transaktion SE16N bspw. nach der gewünschten Workflow-Kennung suchen und so prüfen, ob ein Fehler aufgetreten ist.

Sind hier Einträge vorhanden, so gilt es einmal zu prüfen, ob der Report RSWWERRE als Job in der Transaktion SM37 eingeplant und ausgeführt wird. Im Standard heißt dieser Job SWWERRE.

Wenn auch damit der Fehler nicht identifiziert bzw. behoben werden kann, gilt es zu prüfen, ob in der Workflow-Definition (Transaktion SWDD) das Workitem asynchron ist, also ein Ereignis benötigt und eventuell gesperrt ist wegen zeitgleichem Zugriff.

Wenn auch das nicht hilft, ist es von Vorteil einmal im SAP Support Portal nach nützlichen Hinweisen zu suchen. Hier eignen sich Suchbegriffe wie „RSWWERRE“ oder „SWP_SUSPEN“.

Workflow-Neustart nach Fehler

In der Transaktion SWPR kann man einen fehlerhaften Workflow bzw. fehlerhaftes Workitem neustarten. Direkt nach der Eingabe des Transaktionscodes kann man nach den fehlerhaften Sätzen suchen und diese neustarten durch Klick auf „Restart Workflow“.

Hierbei wird der Workflow an dem Punkt neugestartet, an dem der Fehler aufgetreten ist.

Natürlich muss die Ursache des Problems behoben sein, da ansonsten der Workflow erneut auf einen Fehler läuft. Diese Transaktion ist eine der zentralen Transaktionen, um fehlerhafte Workflows schnell und einfach zu beheben.

Mit der Transaktion SWPR können nur fehlerhafte Workflows neugestartet werden.

Möchte man generell einen Workflow neustarten, muss man einen neuen Workflow erstellen, der auf den alten Workflow referenziert. Der alte Workflow muss daraufhin gelöscht werden. Mit der Transaktion SWUS_WITH_REFERENCE kann man einen neuen Workflow erstellen basierend auf den alten Workflow. Den alten Workflow kann man entweder mit dem Funktionsbaustein SWW_WI_ADMIN_CANCEL (Transaktion SE37) oder mit der Transaktion SWI1 (Doppelklick auf ID in erster Zeile im Workflow Log > Änderungsmodus > Button für logisches Löschen).

Workflows fortsetzen nach Systemabsturz

Sollte es zu einem Systemabsturz gekommen sein, kann man den abgestürzten bzw. unterbrochenen Workflow mit der Transaktion SWPC fortsetzen.

Neustart von angehaltenen Callbacks

In der Transaktion SWF_ADM_SUSPEND kann man angehaltenen bzw. suspendierte Callbacks neustarten. Dazu wählt man die gewünschte Zeile aus und klickt anschließend auf den Button „Eintrag reaktivieren“ bzw. die F9-Taste.

Fehlerhafte tRFC-Aufrufe neustarten

Wegen Netzwerkproblemen oder Systemabbrüchen kann es vorkommen, dass RFC-Aufrufe unterbrochen werden. In der Transaktion SM58 können die fehlerhaften RFC-Aufrufe jedoch neugestartet werden. Dazu klickt man auf „Bearbeiten > LUW Ausführen“. Möchte man dafür mehrere Aufrufe neustarten wählt man „Bearbeiten > LUWs ausführen“.