[1] Bearbeiterzuordnung/Bearbeiterermittlung
[2] Hängender Workflow
[3] Performance in SAP Business Workplace (SBWP)
[4] Ereignisse
[5] Transport von Workflow-Mustern
[6] Extended Notifications
[7] Transaktionen zur Fehlersuche
------------------------------------------------------------------------------------
[1] Bearbeiterzuordnung/Bearbeiterermittlung
Workitems werden nicht dem richtigen Benutzer oder allen Benutzern im System zugewiesen. Sie müssen den Fehler beheben. Ermitteln Sie das Workflow-Muster und den Schritt, bei denen das Problem auftritt, und prüfen Sie Folgendes:
Mögliche Bearbeiter
Bestimmen Sie die dem Schritt im Workflow-Muster über den Workflow-Editor zugewiesene Aufgabe und klicken Sie auf die Drucktaste 'Bearbeiterzuordnung'. Das Bildschirmbild 'Bearbeiterzuordnung &' für die Aufgabe wird angezeigt. (Alternativ können Sie die Aufgabe über Transaktion PFTS anzeigen oder auf die Aufgabenkennung im Schritt doppelklicken. Nutzen Sie hierzu den Menüpfad Weitere Daten => Bearbeiterzuordnung => Pflegen oder Anzeigen.)
Wenn der Aufgabe keine möglichen Bearbeiter zugeordnet sind oder die Aufgabe nicht den Status 'Allgemein' (verfügbar für alle Benutzer) hat, ist dies höchstwahrscheinlich die Ursache für das Problem bei der Bearbeiterzuordnung. Sie müssen der Aufgabe Benutzer/Planstellen/Organisationseinheiten usw. zuweisen, um sie als 'Allgemein' einstufen zu können.
Zuständige Bearbeiter
Zuständige Bearbeiter werden im Workflow-Schritt im Abschnitt 'Bearbeiter' zugewiesen. Normalerweise sehen Sie Planstellen, Ausdrücke oder Regeln zum Bestimmen der zuständigen Bearbeiter. Sie müssen prüfen, ob Bearbeiter zur Laufzeit zurückgegeben werden. Wenn die mögliche Bearbeiterzuordnung Ihrer Aufgabe in Ordnung ist, müssen Sie die zuständigen Bearbeiter prüfen. Gehen Sie zur Fehlersuche wie folgt vor:
o Regel Wenn Sie eine Regel verwenden, können Sie die Regelausführung über die Drucktaste 'Regelauflösung simulieren' in PFAC simulieren. Eine Regel empfängt zur Laufzeit Daten vom Workflow-Container. Prüfen Sie daher den Datenfluss in der Workflow-Definition darauf, welche Daten vom Workflow-Container an den Regel-Container übergeben werden sollen. Wählen Sie anschließend die Workitem-Instanz, bei der das Problem auftritt, und verwenden Sie die Daten aus dem Workflow-Container für Ihre Simulation. Geben Sie beim Verwenden der Simulationsoption in PFAC über F4 die Testcontainerdaten ein. Wenn nicht die erwarteten Bearbeiter zurückgegeben werden, müssen Sie die Regelimplementierung prüfen, z.B. ob Sie einen benutzerdefinierten Funktionsbaustein verwenden oder Zuständigkeiten gepflegt haben. Wenn die Rückgabe der Bearbeiter während der Simulation reibungslos funktioniert, zur Laufzeit jedoch Probleme auftreten, lesen Sie bitte SAP-Hinweis 755767.
SAP-Hinweis Beschreibung
755767 Besonderheit bei Berechtigungen im Workflow
o Ausdruck Wenn Sie zum Festlegen der zuständigen Bearbeiter einen Ausdruck verwenden, müssen Sie die Workitem-Instanz prüfen, in der das Problem aufgetreten ist, und nachschauen, welcher Wert im Ausdruck im Workflow-Container enthalten ist. Im Falle eines unerwarteten Werts müssen Sie bestimmen, wo im Workflow der Ausdruck gefüllt wird und untersuchen, warum der Wert falsch ist. Eine gute Möglichkeit zum Herausfinden, welche Schritte genau ein bestimmtes Container-Element verwenden, ist das Klicken mit der rechten Maustaste auf das Container-Element im Workflow-Builder und Auswählen der "Anzeigen Verwendungsnachweis"-Grafik. Auf diese Weise werden alle Schritte hervorgehoben, in denen das Container-Element/der Ausdruck verwendet wird.
Nützliche Transaktionen
* PFAC - Pflegen/Anzeigen der Standardregel
* PFTC - Pflegen/Anzeigen von Aufgaben
* SWDD - Workflow Builder
* PPOSW - Anzeigen der Aufbauorganisation
[2] Hängender Workflow
Dieser Bereich ist in vier Abschnitte eingeteilt.
o Workitem-Enqueue
o SM58/SWU2
o Kurzdump während Methodenausführung
o Transaktionen zum Neustart von fehlerhaften Workitems
Workitem-ENQUEUE
Wenn ein Workitem ausgeführt wird und das Workflow-Laufzeitsystem versucht, auf das Workitem zuzugreifen, funktioniert dies nicht, da für das Workitem zurzeit eine Sperre oder Enqueue gilt. Einige Beispiele:
Beispiel 1
Ein Benutzer führt eine asynchrone Aufgabe aus. Während der Ausführung des Workitems wird das beendende Ereignis im System ausgelöst und versucht, den Workitemstatus auf KOMPLETT zu setzen. Dies ist jedoch aufgrund der Sperre/Enqueue nicht möglich. In diesem Fall wird das Ereignis in der Ereignis-Queue gepuffert. Sobald das Workitem freigegeben wird, liefert es sofort das gepufferte Ereignis. Weitere Informationen finden Sie in SAP-Hinweis 749945.
Beispiel 2
Sie verwenden Parallelverarbeitung mit einem parallelen Abschnitt mit 2 Zweigen (1 Zweig ist zum Abschließen erforderlich). In einem Zweig befindet sich ein Dialogaktivitätsschritt und in dem anderen ein 'Warten auf Ereignis'-Schritt. Während der Dialogschritt von einem Benutzer durchgeführt wird, empfängt der 'Warten auf Ereignis'-Schritt sein Ereignis und fährt entlang des Zweigs fort und beendet den parallelen Abschnitt (zu Erinnerung: nur 1 Zweig ist zum Abschließen erforderlich). Wenn das Ende des parallelen Abschnitts erreicht ist, sollte das Dialog-Workitem auf den Status "Logisch gelöscht" gesetzt werden. Wegen der Sperre/Enqueue auf dem Workitem während der Ausführung durch den Benutzer geschieht dies jedoch nicht. Da ein Workflow zur weiteren Ausführung ein Callback benötigt, wird dieser Callback angehalten (in der Tabelle SWP_SUSPEN gespeichert). Diese Callbacks werden über den Report RSWWERRE erneut gestartet. Wenn Sie den Report RSWWERRE nicht eingeplant haben, verbleiben die Workitems in der Tabelle SWP_SUSPEN, empfangen kein Callback und werden daher nicht fortgeführt.
Fehlerbehebung
Wenn Workitems hängen, schauen Sie in der Tabelle SWP_SUSPEN nach, ob die entsprechende Workitem-Kennung dort vorhanden ist. Wenn ja, vergewissern Sie sich, dass der Job RSWWERRE ausgeführt wird, um das Workitem erneut auszuliefern. Wenn RSWWERRE ausgeführt wird und der Eintrag nicht ausgeliefert wird, suchen Sie mithilfe der Suchbegriffe "RSWWERRE" und "SWP_SUSPEN" nach entsprechenden SAP-Hinweisen. Wenn kein Eintrag in SWP_SUSPEN vorhanden ist, prüfen Sie in der Workflow-Definition, ob das Workitem asynchron ist, d.h. ob es ein beendendes Ereignis wie in Beispiel 1 oben benötigt. Prüfen Sie über Transaktion SWEQADM, ob das beendende Ereignis in der Ereignis-Queue gepuffert wird. Wenn ja, sollte es automatisch erneut ausgeliefert werden. Suchen Sie in den SAP-Hinweisen nach der Ereignis-Queue.
SM58 oder SWU2
Gelegentlich können Workitems bei Netzwerkproblemen, einem Systemabsturz und tRFC- und qRFC-Problemen im System hängen. Im technischen Workflow-Protokoll finden Sie Workitems mit dem Status "In Bearbeitung" oder "Komplett" die nicht mit dem nächsten Schritt fortgeführt werden. Suchen Sie in diesem Fall am besten in Transaktion SM58 nach Einträgen in Bezug auf die tRFC-Ausführung.
Wenn Sie herausfinden möchten, welches Workitem dem Eintrag in SM58 entspricht, doppelklicken Sie auf den Eintrag unter 'Transaktion-ID'. Hier erhalten Sie nützliche Informationen, z.B. die Standardaufgabe, das Business-Objekt, die Objektinstanz, das entsprechende Ereignis und die Workitem-Kennung. Diese Details sind nicht immer angegeben. Sie sollten jedoch ausreichend Informationen erhalten, um die Workitem-Kennung herauszufinden. Z.B. wenn die Aufgabenkennung angegeben ist, rufen Sie SWI1 auf, geben Sie die Aufgabenkennung und Datum und Uhrzeit des Eintrags ein und Sie sollten die Workitem-Kennung herausfinden können.
Nützliche Informationen
Die Einträge in SM58 können neu gestartet werden, wenn das Problem, wegen dem sie in der Liste vorhanden sind, behoben wurde. Wählen Sie den Eintrag aus der Liste aus und wechseln Sie zum Menü: BEARBEITEN => LUW ausführen, um einen Eintrag neu zu starten. Wenn Sie mehrere Einträge verarbeiten möchten, wechseln Sie zum Menü BEARBEITEN => LUWs ausführen oder planen Sie den Report RSARRCEX mit den richtigen Daten ein.
Kurzdump während Methodenausführung
Prüfen Sie in ST22, ob Kurzdumps in Bezug auf das hängende Workitem vorhanden sind. Wenn Sie in ST22 sowohl nach Datum und Uhrzeit der Workitem-Ausführung als auch nach dem ausführenden Benutzer oder WF-BATCH suchen, können Sie normalerweise exakt herausfinden, wo der Dump aufgetreten ist und ob es sich um benutzerdefinierten Code oder SAP-Standardcode handelt. Ein Kurzdump kann z.B. in benutzerdefiniertem Code aufgrund einer schlechten Ausnahmenbehandlung im Methodencode auftreten. In diesem Fall ist die beste Option, die Objektmethode über Transaktion SWO1 mit den Daten aus dem Workitem-Container zu testen, den Sie dem Workflow-Protokoll entnehmen können.
Wenn es sich bei der Objektmethode um SAP-Standardcode handelt, müssen Sie herausfinden, welcher Anwendungsbereich für die Objektmethode verantwortlich ist und in dieser Komponente eine Meldung erstellen.
Nützliche Informationen
Rufen Sie SWO1 auf, geben Sie das Business-Objekt ein und klicken Sie auf die Drucktaste "Anzeigen". Klicken Sie anschließend auf die Drucktaste "Grunddaten". Hier ist der mit dem Business-Objekt verbundene Programmname aufgelistet. Führen Sie den Report RSSTATUS also aus, um die Komponente, zu der das Objekt gehört, z.B. Objekt FORMABSENC, zu finden.
Programmname: SWUFORMA
Führen Sie den Report RSSTATUS aus: Komponente BC-BMT
Transaktionen zum Neustart von fehlerhaften Workitems
* SWPR - Workflow-Restart nach Fehler
* SWPC - Fortsetzen von Workflows nach Systemabsturz
* SWF_ADM_SUSPEND - Restart von angehaltenen Workflow-Callbacks
* SWF_ADM_SWWWIDH - Restart von angehaltenen Termin-Callbacks
[3] Performance in SAP Business Workplace (SBWP)
Die allgemeine Performance von SBWP kann durch eine Reihe von Faktoren gesteuert werden, die im Folgenden aufgelistet sind.
o Archivierung
o Tabellenzugriff und Performance
o Performance von SBWP (verfügbare BAdIs)
o RFC
Archivierung
Setzen Sie eine WORKITEM-Archivierungsstrategie ein, um die Kontrolle über die Größe Ihrer Workflow-Tabelle zu behalten. Sie verwenden die Transaktion SARA und das Archivierungsobjekt WORKITEM zum Archivieren von Workitems. Dadurch werden die betroffenen Tabellen aufgelistet. Weitere Informationen finden Sie im SAP-Hinweis 573656. Je geringer die Anzahl der Einträge in den Workflow-Laufzeittabellen, desto besser die Performance der Workflow Engine.
SAP-Hinweis Beschreibung
573656 Sammelhinweis zur Archivierung im Workflow
621258 Archivierung WORKITEM Vereinheitlichungen
Tabellenzugriff und Performance
Lesen und spielen Sie folgende SAP-Hinweise ein.
SAP-Hinweis Beschreibung
98407 Performance Workflow
799002 Fehlender CLIENT im Datenbank Index
72873 Performance des Workflow-Systems, Empfehlungen
72923 Performance des Business Workflow, Sammelhinweis
861380 SWW_CONTOB nach SWW_WI2OBJ Migration
Performance von SBWP (verfügbare BAdIs)
Wenn Sie Performance-Probleme in SBWP feststellen, finden Sie in SAP-Hinweis 764707 einige Ursachen hierfür. Die Hauptursache ist, dass Benutzer viel zu viele Workitems (mehrere Tausend) in ihren Eingängen haben. Für den Geschäftsablauf einiger Kunden ist es notwendig, alle Workitems im Eingang zu haben anstatt die genauere Bearbeiterzuordnung zu verwenden (Call-Center-Szenario). Daher wurden mehrere BAdIs bereitgestellt, um die Performance zu verbessern, z.B. indem die Anzahl der Workitems in den Benutzereingängen verringert wird.
o WF_BWP_SELECT_FILTER Mit diesem BAdI kann die Anzahl der angezeigten Workitems durch Filterung eingeschränkt werden. Es ist vor allem für Szenarien geeignet, in denen alle Benutzer am gleichen Vorrat von Workitems arbeiten (z.B. Callcenter). (siehe SAP-Hinweis 765783)
o WF_BWP_DYN_COLUMN Mit dem Ausblenden der dynamischen Spalten kann die Performance im Business Workplace verbessert werden. Ist dies nicht möglich, können Sie das BAdI WF_BWP_DYN_COLUMN implementieren, um die Werte der dynamischen Spalten direkt aus den Anwendungsdaten zu ermitteln. Das BAdI wird mit SAP-Hinweis 848382 zur Verfügung gestellt.
o WF_BWP_OBJ_ATTRIBUTE Mit diesem BAdI ist es möglich, die Defaultattribute des führenden Objekts (_WI_Object_ID) und des Gruppierungsmerkmals (_WI_Group_ID) zu setzen. Die Defaultattribute werden für die Gruppierung nach Inhalt, Gruppierung nach Ordnungsbegriff und zum Ausblenden der Spalten Gruppenobjekt und Workitem-Inhalt verwendet. Das BAdI wird mit SAP-Hinweis 848382 zur Verfügung gestellt.
SAP-Hinweis Beschreibung
76578 BADI für Business Workplace
764707 Performance im Business Workplace
848382 BAdIs zur Performance-Verbesserung im Business Workplace
RFC
Seien Sie bei der Implementierung der Vorschläge aus SAP-Hinweis 888279 vorsichtig. Wenn Sie das Ziel registrieren, müssen Sie Ihre RFC-Parameter richtig festgelegt haben, sodass keine Verzögerungen bei der Verarbeitung der Workitem-Ausführung durch einen Mangel an verfügbaren Dialog-Prozessen usw. auftreten.
SAP-Hinweis Beschreibung
888279 Reglementierung / Verteilung der Workflowlast
98407 Performance Workflow
[4] Ereignisse
Deaktivierung der Ereigniskopplung
Wenn die Ereigniskopplung deaktiviert wird, wird eine E-Mail an den SBWP des WF-Administrators geschickt, in der die Fehlerursache angegeben ist. Normalerweise ist die Ursache die Übergabe von falschen Daten vom Objektereignis an den Ereignisverbraucher/das Workflow-Muster. Prüfen Sie den Eingang (nicht den Workflow-Eingang) des WF-Administrators ungefähr zum Zeitpunkt der Deaktivierung. Dort sollten Sie die Antwort finden.
Haben Sie daran gedacht, die Ereignis-Queue (Transaktion SWEQADM) zu verwenden?
Mithilfe der Ereignis-Queue können Sie versuchen, die Last der ausgelösten Workflows auszugleichen. Die Ereignis-Queue speichert die Ergebnisse der Ereigniskopplung temporär in einer Datenbanktabelle, nachdem die Startbedingungen und die Prüffunktionen ausgewertet sind (falls Sie Startbedingungen verwenden).
Sie können die Ereignis-Queue jedoch auch verwenden, um fehlerhafte Ereignisse zu speichern und diese nach der Korrektur erneut auszuliefern.
Setzen Sie in SWE2 das Kennzeichen 'Ereignis-Queue ermöglichen' in der Ereigniskopplung.
Setzen Sie darüber hinaus 'Verhalten bei Fehlerrückmeldung' auf 'Kopplung als fehlerhaft markieren'.
Sie können die Grunddaten der Ereignis-Queue mit der Transaktion SWEQADM festlegen.
Fehlersuche bezüglich der Deaktivierung
Aktivieren Sie den Ereignis-Trace (Transaktion SWELS). Wenn die Kopplung erneut deaktiviert wird, prüfen Sie den Ereignis-Trace mit Transaktion SWEL. Er sollte einen Eintrag für alle erfolgreichen Einträge und auch einen Eintrag für den Eintrag enthalten, der die Kopplung deaktiviert hat. Wenn Sie darauf doppelklicken, sollten Sie Informationen über die Ursache der Deaktivierung erhalten. (Es wird nicht empfohlen, den Ereignis-Trace während der Produktion lange eingeschaltet zu lassen, da dies zu Performance-Problemen führen kann. Schalten Sie ihn aus, sobald die Kopplung deaktiviert ist.)
Welches Ereignis löst den Workflow aus? Handelt es sich dabei um ein SAP-Standardereignis oder ein kundenspezifisches Ereignis? Bei kundenspezifischen Ereignissen kann es gelegentlich vorkommen, dass nicht alle Informationen vom Ereignis an den Verbraucher/Workflow übergeben werden, und so zu einer Deaktivierung führen.
Zum Analysieren des Ereignis-Containers sollten Sie folgendermaßen vorgehen: Definieren Sie einen neuen Eintrag in SWE2:
Geben Sie das Ereignis ein, geben Sie für den Verbrauchertyp einen Benutzernamen (Ihren Benutzernamen) ein und für den Verbraucherfunktionsbaustein SWE_EVENT_MAIL. Sie erhalten dann für jedes Ereignis den Ereignis-Container per E-Mail und können sehen, ob Daten fehlen. Es ist möglich, dass ein obligatorisches Eingabeelement im Workflow nicht vom Ereingis übergeben wird.
Nützliche Transaktionen
* SWELS - Ein-/Ausschalten des Ereignis-Trace
* SWEL - Anzeigen des Ereignis-Trace
* SWU0 - Ereignissimulation
* SWUE - Erstellen eines Ereignisses
* SWEQADM - Ereignis-Queue
* SWETYP - Typkopplungen
* SWEINST - Instanzkopplungen
[5] Transport von Workflow-Mustern
Lesen Sie zunächst SAP-Hinweis 571302 und vergewissern Sie sich, dass Sie alle genannten SAP-Hinweise in Ihr System eingespielt haben.
SAP-Hinweis Beschreibung
571302 Sammelhinweis zur Archivierung im Workflow
Versionen und Aktivierung
In diesem Abschnitt wird erklärt, wie Versionen in Bezug auf den Transport von Workflow-Mustern funktionieren.
o Erstellen oder ändern Sie einen Workflow in Ihrem Entwicklungssystem und transportieren Sie ihn nach Test.
o Wenn der Workflow bereits in Test vorhanden ist und Instanzen davon ausgeführt werden, wird automatisch eine neue Version des Workflows in Test erstellt. Dies geschieht, damit die vorhandenen Instanzen die alte Version und neue, nach dem Transport erstellte Instanzen die neue Version verwenden können. Wenn der Workflow bereits vorhanden ist, jedoch keine Instanzen (in Test) vorhanden sind, wird er durch den Transport einfach überschrieben.
Es ist NICHT notwendig, Versionen zwischen den Systemen zu synchronisieren.
Fehlersuche in Bezug auf Versionen und Aktivierung
o Stimmen Datum und Uhrzeit von Quell- und Zielsystem überein?
o Wenn Sie neue Container-Elemente in Ihrem Workflow erstellt haben, vergewissern Sie sich, dass ihre Datenreferenzen ebenfalls im Testsystem vorhanden sind.
o Haben Sie neue Aufgaben erstellt und diese dem Workflow im Entwicklungssystem hinzugefügt? Falls ja, vergewissern Sie sich, dass Sie die Aufgabe ebenfalls in das Qualitätssicherungssystem transportiert haben.
o Haben Sie im Zielssystem unter Transaktion SWDM -> Sonstiges -> Transportierte Workflows nachgeschaut? Falls Probleme vorliegen, wird dies in rot angezeigt.
o
Nützliche Transaktionen
* SWDM - Business Workflow Explorer
[6] Extended Notifications und Delta Pull
Wenn bei SWN_SELSEN oder RSWNUWLSEL Performance-Probleme auftreten, beachten Sie die folgenden Anmerkungen:
SAP-Hinweis Beschreibung
1105696 WF Notif: Speicherverbrauch und Performance von SWN_SELSEN
* Die Auswahl der Notification/Workitems wird mithilfe des Anwendungslog protokolliert. Sie können den Log-Level über die Transaktion SWNCONFIG beeinflussen. Rufen Sie hierzu die Transaktion SWNCONFIG auf und navigieren Sie zu den Allgemeinen Einstellungen (General Settings). Dort finden Sie die Einstellung MAX_PROBCLASS. Wenn Sie z.B. den Log-Level 1 auswählen, werden nur äußerst wichtige Informationen protokolliert. Eine Änderung des Log-Levels kann sich auf die Performance positiv auswirken.
* Im Folgenden werden die Hauptaufgaben des Programms RSWNUWLSEL (im Modus FULL) aufgelistet:
o Auswahl aller offenen Dialog- und Deadline-Workitems im System. "Offen" bedeutet, diese besitzen den Status READY, SELECTED, STARTED und COMMITTED.
o Festlegung der Bearbeiter dieser Workitems.
o Notifications anlegen (Relation des Workitems zum Benutzer)
o Speichern der Notifications in der Tabelle SWN_NOTIF. Dies bedeutet das Einfügen neuer, das logische Löschen veralteter und das Aktualisieren bestehender Notifications.
Überprüfen Sie Folgendes:
o Sind offene Workitems vorhanden, die zu Aufgaben gehören, bei denen eventuell ein Problem bei der Bearbeiterzuordnung besteht, z.B. wenn einer oder mehreren Aufgaben eine Position zugeordnet wurde, diese aber nicht mehr besteht. Ist dies der Fall, versucht RSWNUWLSEL, die Bearbeiter für diese Workitems festzulegen, jedoch ohne Ergebnis und mit langsamer Performance. Um dies festzustellen, führen Sie die Transaktion SWI2_ADM1 aus und prüfen Sie, ob diese viele Workitems ohne Bearbeiter enthält. Ist dies der Fall, reorganisieren Sie die Workitems in Ihrem System. Überprüfen Sie ebenfalls, ob die Workitems noch relevant sind; falls nicht, können diese eventuell archiviert oder gelöscht werden. Weitere Informationen zum Löschen und Archivieren von Workitems finden Sie im SAP-Hinweis 573656.
o Des Weiteren gibt es das Programm RSWNNOTIFDEL. Dieses löscht solche Einträge aus der Tabelle SWN_NOTIF, die sich im Status "logisch gelöscht" befinden. Eine Notification erhält den Status "logisch gelöscht", wenn die entsprechenden Workitems abgeschlossen (verarbeitet) sind. Um also die Anzahl der Einträge in SWN_NOTIF so gering wie möglich zu halten, planen Sie RSWNNOTIFDEL regelmäßig ein. Es wird empfohlen, das Programm mit dem standardmäßigen Wert von 10 Tagen auszuführen. Wenn dies nicht ausreicht, können Sie den Wert zu einem späteren Zeitpunkt verändern.
[7] Transaktionen zur Fehlersuche
* SWUD - Workflow-Diagnose
* SWDM - Business Workflow Explorer
* SWUS - Testen des Workflows
* SWU8/SWF_TRC - Workflow-Trace ein/aus
* SWU9/SWF_TRC - Anzeigen des Workflow-Trace
* SWF_APPL_DISPLAY - Anzeigen des Application Log
* SWU0 - Ereignissimulation
* SWELS - Ereignis-Trace ein/aus
* SWEL - Anzeigen des Ereignis-Trace
* SWPR - Workflow-Restart nach Fehler
* SWPC - Fortsetzen von Workflows nach Systemabsturz
* SWI2_DIAG - Diagnose von Workflows mit Fehlern
* SWU2/SM58 - Workflow-RFC-Monitor
