Schmerzhaft deshalb, da es leider nicht selten vorkommt, dass man als Unternehmen mit diesem Thema erst nach dem EWM Go-Live konfrontiert wird, nicht adäquat darauf vorbereitet wurde und sich nun damit überfordert und allein gelassen fühlt. Häufig beobachten wir es, dass Systemfehler, welche binnen weniger Minuten gelöst werden können, aufgrund mangelnder Kenntnisse durch unnötige und kostspielige Prozessbürokratie gejagt werden. Sei es aufgrund unnötiger Beantragungen von Notfall-User-Berechtigungen, Streitigkeiten um die Fehlerursache und entsprechende Verantwortlichkeit für die Fehlerlösung zwischen den SAP-Modulbetreuern oder aufgrund der unnötigen Weitergabe an Debugging-affine Offshore- bzw. Nearshore Supports.
Dabei gibt es einige Tipps und Tricks, die das Abarbeiten der Fehler innerhalb der Nachrichtenqueue erheblich leichter machen, welchen wir uns in diesem Blog widmen möchten. Bevor wir zu diesem Teil kommen, müssen wir kurz auf die technischen Basics eingehen.
Technische Grundlagen
Die ERP/EWM-Kommunikation der Bewegungsdaten läuft technisch via qRFC (Queued Remote Function Call). Dies gilt sowohl für das Embedded EWM als auch für das dezentrale EWM. Die Bewegungsdaten wie beispielsweise das Buchen des Warenausgangs aus EWM werden an das ERP zurückgemeldet und durchlaufen dabei die Nachrichtenqueue. Treten bei der Datenverarbeitung Fehler auf, bleibt die Rückmeldung in der Nachrichtenqueue hängen und muss vom Verantwortlichen analysiert und manuell verarbeitet werden.
Der qRFC stellt eine Erweiterung des tRFC (Transaktionaler Remote Function Call) dar, die es erlaubt, tRFC-Aufrufe über eine Queue zu serialisieren. Das eigentliche Versenden der Aufrufe erfolgt über einen tRFC-Aufruf.
- Die Serialisierung hat den Vorteil, dass die Aufrufe in einer festen Reihenfolge erfolgen müssen, um Inkonsistenzen zu vermeiden.
- Der transaktionale RFC hat den Vorteil, dass das System zum Zeitpunkt des Aufrufs nicht zwingend verfügbar sein muss. Alle dazugehörigen Daten werden gespeichert und können zu einem späteren Zeitpunkt erneut ausgeführt werden.
Dies gilt auch für Fehlerfälle!
Monitoring der Nachrichtenqueue
Die auszuführenden qRFCs können über eine Inbound- oder eine Outbound-Queue verarbeitet werden. Ob Inbound oder Outbound, hängt davon ab, ob die Queue-Verarbeitung vom Sende- oder vom Empfangssystem gesteuert wird. Standardseitig wird die Inbound Queue im Customizing gewählt. Deshalb ist die Inbound Queue das Mittel der Wahl, um eingehende Fehler zu überwachen. Die Transaktion zum Aufruf der Inbound Queue lautet SMQ2.
Alternativ zur SMQ2 existiert im Lagerverwaltungsmonitor ein Knoten zur Überwachung der Queues. Die Funktion erweist sich als erheblich benutzerfreundlicher im Vergleich zur SMQ2. Es bietet eine übersichtlichere Fehlerdarstellung, ermöglicht die Selektion auf Lagernummern-Ebene und bietet zusätzliche Funktionen wie beispielsweise Filtermöglichkeiten. Darüber hinaus ist die Fehlerbeschreibung hier weniger kryptisch.
Anzeige des Queue-Datenkontainers
Ergänzend zu den einleitenden Worten sollte erwähnt werden, dass selbst nach Erlernen der Tipps und Tricks nicht jeder Fehler in der Nachrichten-Queue binnen weniger Minuten zu lösen ist. Insbesondere die Findung der Fehlerursache ist und bleibt die Königsdisziplin bei der Queue-Bearbeitung. Die Behebung jedoch steht Dank der folgenden Tools auf einem anderen Blatt.
Nicht immer kann der Fehler durch Customizing oder Anpassung der Stammdaten behoben werden, da die Bewegungsdaten fest im Queue-Datencontainer gespeichert sind. Nachfolgend wird gezeigt, wie dieser Datencontainer angezeigt und bei Bedarf sogar angepasst werden kann, ohne dass dadurch per Debugger und Notfalluser eingegriffen werden muss.
Merke: Sofern der Fehler im Datencontainer liegt, ist ein Beantragen eines Notfallusers unnötig!
Im Lagerverwaltungsmonitor kann man über die folgende Funktion zum Queue-Datencontainer gelangen:
Die Anzeige des Datencontainers ist auch über die Transaktion SMQ2 möglich, muss jedoch erst in jedem System eingerichtet werden.
Bearbeiten des Queue-Datenkontainers
Die Bewegungsdaten, welche im Datencontainer gespeichert sind, können beliebig angepasst und anschließend der fehlerhafte Queue Eintrag neu angestoßen werden. Beispielsweise kann bei einem Buchungsfehler aufgrund abgelaufener Buchungsperiode das Buchungsdatum auf einen Wert innerhalb der aktiven Periode gesetzt werden.
Um die Bearbeitung des Datencontainers zu ermöglichen, müssen zuvor einige Schritte durchgeführt werden.
Diese sind über zwei zentrale Transaktionen durchzuführen:
- /SPE/MQWL_CUS
- /SPE/MQWL_APPL
In diesen muss das Queue-Containerfeld gepflegt werden, welches geändert werden soll. Die Pflege erfolgt auf den folgenden Ebenen:
- Des Funktionsbausteins, welcher gerufen wird
- Der Datentabelle, welche das zu ändernde Datenfeld beinhaltet
- Das zu ändernde Datenfeld
Diese Informationen lassen sich über den Datencontainer selbst herausfinden:
Letztendlich erfüllen beide Transaktionen denselben Zweck, allerdings:
- werden die Änderungen der /SPE/MQWL_CUS über Customizing Aufträge transportiert, die _APPL ändert sofort im aktuellen System. Dieses System muss jedoch ein Produktivsystem sein.
- Die /SPE/MQWL_CUS erlaubt nur bestimmte Felder als änderbar im Datencontainer, wohingegen über die /SPE/MQWL_APPL jedes Feld im Datencontainer als änderbar gesetzt werden kann.
- Daraus lässt sich schließen, dass die /SPE/MQWL_APPL als Notfalltransaktion für Produktivsysteme angesehen werden kann.
Zuletzt wird noch ein spezielles Berechtigungsobjekt benötigt: /SPE/QEDIT. Dieses muss dem User vergeben werden, ansonsten ist eine Änderung des Datencontainers nicht möglich.
Hat man alles richtig gepflegt, ist der Datencontainer änderbar:
Mit einigen Tipps und Tricks können die Fehler innerhalb der Nachrichtenqueue erheblich leichter abgearbeitet werden, was die Beantragung eines Notfall-Users obsolet macht.
