Einmal habe ich zu diesem Thema bereits kurz einen Blog erfasst - in diesem konnte man mit einem brconnect Befehlt prüfen welche Patches man installiert hat - doch mit diesem SAP Hinweis kann man seinen aktuell installierten Patchstand mit dem aktuellsten Patchstand vom SAP Markteplace quer prüfen und die neuesten Patches installieren!
Link zur Patchcheck Tool
https://service.sap.com/~sapidb/012003146900000618932009E/sap_patchcheck.htm
Symptom
Sie möchten die installierten Oracle-10g-Patches mit den erforderlichen Patches für SAP vergleichen.
Weitere Begriffe
Patch-Überprüfung, Oracle
Ursache und Voraussetzungen
Sie verwenden Oracle 10g.
Sie haben eine Liste der installierten Patches und die Ausgabe eines der folgenden Befehle:
o opatch lsinventory
o RSORAPATCHINFO
o brconnect -u / -c -F lsinv
Lösung
Diesem SAP-Hinweis ist eine HTML-Seite mit einem JavaScript-Programm beigefügt, das eine automatische Prüfung durchführt.
Das Programm wird synchron zu den Patch-Hinweisen gepflegt.
Aktuell
* SAP-Hinweis 871735 Version 45
* SAP-Hinweis 871096 Version 189 (10.2.0.2)
* SAP-Hinweis 1137346 Version 78 (10.2.0.4 und Windows-Mini-Patches)
Gehen Sie folgendermaßen vor, um die Prüfung durchzuführen:
o Öffnen Sie die beigefügte HTML-Seite in einem Browser, der JavaScript unterstützt (getestet wurde dies bisher in Firefox 3.0, 3.5, Safari 4.0 und Internet Explorer 7, sollte aber problemlos in allen neueren Browsern funktionieren).
o Geben Sie an, ob Sie eine kurze Ausgabe (lediglich fehlende und veraltete Patches) oder eine lange (alle zugehörigen Patches und SAP-Hinweise) benötigen.
o Wählen Sie das Datenbank-Betriebssystem aus.
o Fügen Sie die Liste der abgerufenen Patches mit einem der erwähnten Befehle in das Textfeld ein.
o Wählen Sie die Drucktaste zum Prüfen ("Check").
Daraufhin wird ein neues Fenster mit Informationen zur Prüfung geöffnet.
Freitag, 4. Dezember 2009
Freitag, 27. November 2009
Wie ändert man das Kennwort vom SDM (Software Deployment Manager)
Es kann sein das man im SDM mal das Kennwort ändern muss!
dazu geht man in das Verzeichnis /usr/sap///SDM/program
und ruft folgende Befehle auf:
StopServer.sh
sdm.sh jstartup "mode=standalone"
sdm.sh changepassword "newpassword=xxx"
sdm.sh jstartup "mode=integrated"
StartServer.sh
Kennwort wurde in diesem Fall auf xxx geändert...
dazu geht man in das Verzeichnis /usr/sap/
und ruft folgende Befehle auf:
StopServer.sh
sdm.sh jstartup "mode=standalone"
sdm.sh changepassword "newpassword=xxx"
sdm.sh jstartup "mode=integrated"
StartServer.sh
Kennwort wurde in diesem Fall auf xxx geändert...
Mittwoch, 25. November 2009
Tipps & Tricks zur Fehlersuche bei Workflow-Problemen
[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
[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
Donnerstag, 5. November 2009
Kurzdump LOAD_TYPEPOOL_VERSION_MISMATCH ab 7.00
Der Laufzeitfehler LOAD_TYPEPOOL_VERSION_MISMATCH tritt normalerweise dann auf, wenn sich während des Ablaufs der Transaktion die Typgruppe ändert;
in diesem Fall liegt kein Fehler vor:
die Transaktion muss abgebrochen werden, um einen inkonsistenten Programmablauf zu vermeiden. Nach einem Neustart der Transaktion tritt dieser Laufzeitfehler dann aber nicht mehr auf.
Doch nach dem Einspielen vom EHP04 hatten wir das Problem das bei einer Transaktion das Neustarten nichts gebracht hat und wir mussten wie im Hinweis 1298341
beschrieben die Programme neu generieren!
Dürft ein SAP Bug sein da die Ursache auch noch nicht bekannt ist...
in diesem Fall liegt kein Fehler vor:
die Transaktion muss abgebrochen werden, um einen inkonsistenten Programmablauf zu vermeiden. Nach einem Neustart der Transaktion tritt dieser Laufzeitfehler dann aber nicht mehr auf.
Doch nach dem Einspielen vom EHP04 hatten wir das Problem das bei einer Transaktion das Neustarten nichts gebracht hat und wir mussten wie im Hinweis 1298341
beschrieben die Programme neu generieren!
Dürft ein SAP Bug sein da die Ursache auch noch nicht bekannt ist...
Montag, 2. November 2009
SAP NetWeaver Application Server EHP02
Ein kurzer Ausblick auf das neue EHP 02 für den NW Applikationsserver gab es beim Jahreskongress der DSAG!
Titel der Präsentation
SAP NetWeaver Application Server Infrastructure
News for NW 7.0 Enhancement Package 2
DSAG 2009
Gehalten von Dr. Oliver Stiefbold (SAP)
Anbei die FOLIEN
Titel der Präsentation
SAP NetWeaver Application Server Infrastructure
News for NW 7.0 Enhancement Package 2
DSAG 2009
Gehalten von Dr. Oliver Stiefbold (SAP)
Anbei die FOLIEN
Samstag, 31. Oktober 2009
Virtualisierung von SAP-Systemen
Neus buch zum Thema Virtualisierung von SAP-Systemen
* Grundlagen, Konzeption und Betrieb
* Technologien und Lösungen im Vergleich
* Detaillierte Darstellung des Einsatzes von VMware vSphere, Microsoft Hyper-V, SLES mit Xen und Sun Solaris-Zonen
Endlich Durchblick beim Betrieb von virtuellen SAP-Systemen! Dieser Leitfaden klärt nicht nur die Frage, was Virtualisierung bedeutet, sondern hilft Ihnen bei der Entscheidung für eine bestimmte Lösung und wie Sie sie betreiben – von der Einrichtung und Verwaltung virtueller Serverwelten bis zum eventuellen Ausstieg.
Sie werden aus Sicht eines unabhängigen Beobachters lernen, welches Produkt (VMware vSphere, Microsoft Hyper-V, SLES mit Xen, Sun Solaris-Zonen) sich für Ihren Einsatzzweck am besten eignet. Dabei lernen Sie neben technischen Aspekten auch die organisatorische Seite der Einführung und des Betriebs von Virtualisierungslösungen in einem Rechenzentrum kennen – und können so fundierte Entscheidungen zur optimalen Gestaltung der Systemarchitektur bzw. für eine verbesserte Arbeit der IT-Abteilung treffen. Wenn Sie mit dem Gedanken der Virtualisierung Ihrer SAP-Systeme spielen, werden Sie dieses Buch nicht mehr missen wollen: Als Ideengeber, Projektbegleiter und Nachschlagewerk.
* Grundlagen, Konzeption und Betrieb
* Technologien und Lösungen im Vergleich
* Detaillierte Darstellung des Einsatzes von VMware vSphere, Microsoft Hyper-V, SLES mit Xen und Sun Solaris-Zonen
Endlich Durchblick beim Betrieb von virtuellen SAP-Systemen! Dieser Leitfaden klärt nicht nur die Frage, was Virtualisierung bedeutet, sondern hilft Ihnen bei der Entscheidung für eine bestimmte Lösung und wie Sie sie betreiben – von der Einrichtung und Verwaltung virtueller Serverwelten bis zum eventuellen Ausstieg.
Sie werden aus Sicht eines unabhängigen Beobachters lernen, welches Produkt (VMware vSphere, Microsoft Hyper-V, SLES mit Xen, Sun Solaris-Zonen) sich für Ihren Einsatzzweck am besten eignet. Dabei lernen Sie neben technischen Aspekten auch die organisatorische Seite der Einführung und des Betriebs von Virtualisierungslösungen in einem Rechenzentrum kennen – und können so fundierte Entscheidungen zur optimalen Gestaltung der Systemarchitektur bzw. für eine verbesserte Arbeit der IT-Abteilung treffen. Wenn Sie mit dem Gedanken der Virtualisierung Ihrer SAP-Systeme spielen, werden Sie dieses Buch nicht mehr missen wollen: Als Ideengeber, Projektbegleiter und Nachschlagewerk.
Freitag, 30. Oktober 2009
Custom Development Management Cockpit
Mit dem EHP01 vom Solution Manager liefert die SAP das
Custom Development Management Cockpit oder kurz CDMC aus.
Man startet das Tool mit der Transaktion CNV_CDMC!
Mit diesem Tool kann man zwei verschiedene Funktionen durchführen -
einmal eine Upgrade/Change Impact Analyse und einmal eine Clearing Anlasyse!
In diesem Fall möchte ich auf die Upgrade/Change Impact Analyse eingehen da wir
gerade ein Upgrade auf EHP 04 machen.
Für was ist so eine Upgrade/Change Impact Analyse überhaupt?
Mit diesee Analyse werden alle Z* Programme untersucht ob diese SAP Standard Funktions Bausteine / Reports indirekt aufrufen und ob sich diese durch das Upgrade
geändert haben.
Die erste Analyse wird in diesem System gestartet welches bereits upgegradet worden ist (die SAP nennt das Analysesystem) - dann wird eine zweite Analyse in dem System
gestartet welchen noch nicht upgegradet worden ist (die SAP nennt das System Referenzsystem).
Als nächstes werden dann alle von den Z* Programmen verwendeten SAP Objekte verglichen ob sich mit dem Upgrade die Version und somit eine Funktion geändert hat.
Z.B. ob ein Importparameter bei einem Funktionbaustein dazugekommen ist den man bei seinem Z Programm noch nicht inkludiert hat!
Somit kann man im vorhinein schon fesstelllen ob es auch im Bereich der Kundenentwicklung zu Anpassungen kommt.
anbei ein paar Screenshots:
Einstieg
SAP Doku
Custom Development Management Cockpit oder kurz CDMC aus.
Man startet das Tool mit der Transaktion CNV_CDMC!
Mit diesem Tool kann man zwei verschiedene Funktionen durchführen -
einmal eine Upgrade/Change Impact Analyse und einmal eine Clearing Anlasyse!
In diesem Fall möchte ich auf die Upgrade/Change Impact Analyse eingehen da wir
gerade ein Upgrade auf EHP 04 machen.
Für was ist so eine Upgrade/Change Impact Analyse überhaupt?
Mit diesee Analyse werden alle Z* Programme untersucht ob diese SAP Standard Funktions Bausteine / Reports indirekt aufrufen und ob sich diese durch das Upgrade
geändert haben.
Die erste Analyse wird in diesem System gestartet welches bereits upgegradet worden ist (die SAP nennt das Analysesystem) - dann wird eine zweite Analyse in dem System
gestartet welchen noch nicht upgegradet worden ist (die SAP nennt das System Referenzsystem).
Als nächstes werden dann alle von den Z* Programmen verwendeten SAP Objekte verglichen ob sich mit dem Upgrade die Version und somit eine Funktion geändert hat.
Z.B. ob ein Importparameter bei einem Funktionbaustein dazugekommen ist den man bei seinem Z Programm noch nicht inkludiert hat!
Somit kann man im vorhinein schon fesstelllen ob es auch im Bereich der Kundenentwicklung zu Anpassungen kommt.
anbei ein paar Screenshots:
Einstieg
SAP Doku
Abonnieren
Posts (Atom)
