Architektur CCM Prozessmonitor

Einleitung

Dieses Dokument beschreibt die grundlegende Architektur des CCM Prozessmonitors. Es dient u.a. als Grundlage für Erweiterungen für Code-unkundige Mitarbeiter, um den Einstieg in die das Produkt und damit auch in die Code-Basis zu erleichtern.

Grundlegende Architektur

Die in dem Schaubild dargestellte Architektur des CCM Prozessmonitors zeigt die unterschiedlichen Komponenten / Akteure. Der CCM Prozessmonitor erhält seine Messpunktdaten aus unterschiedlichen Systemen. Dies können SAP- oder auch Non-SAP-Systeme seine. Diese Datenquellen werden mit Extraktoren ergänzt, welche die Messpunktdaten aus den Datenquellen extrahieren und dem Prozessmonitor übergeben. Im Zugriffsbereich des Prozessmonitors angekommen werden die Messpunktdaten in einer Queue gepuffert, wo sie zur Verabeitung bereitstehen. Ein SchedulerService holt in definierbaren Intervallen eine konfigurierbare Menge an Daten ab und lässt diese durch die sogenannte CorrelationEngine verarbeiten.

Die Hauptaufgabe der CorrelationEngine ist nun anhand der mitgegebenen Identifkationsmerkmale (z.B. Wechselbelegsnummer) die neu erhaltenen Daten bereits bestehenden Daten zuzuordnen. Falls keine Korrelation möglich ist, wird von einem neuen Vorgang (im Folgenden auch Instanz genannt) ausgegangen. Bei einer erfolgreichen Korrelation werden die Messpunktdaten eines Prozesses aktualisiert, was dazu führt, dass ein Vorgang in seinem definierten Prozesspfad voranschreitet. Hierfür wird anhand der Prozesskonfiguration und der übermittelten Prozesschritte (inkl. der neuesten Aktualisierung) geschaut, ob ein Prozess weiter voranschreiten kann.

Indizes

Im CCM Prozessmonitor werden insgesamt 4 unterschiedliche Indizes verwendet, die im Folgenden näher beschrieben werden.

Overview Index

Im Overview Index wird der aktuelle Stand eines jeden Vorgangs festgehalten. Die Oberfläche greift direkt auf diesen Index zu, um den aktuellen Zustand der Vorgänge auszugeben.

Controlpoint Index

Im Controlpoint Index werden alle erreichten Prozessschritte aller Vorgänge persistiert. Dieser Index wird v.a. bei der Aktualisierung von Vorgängen herangezogen, um die neu erhaltenen Prozessschritte mit den bereits erhaltenen abzugleichen und ggf. den Prozess auf einen fortgeschritten Prozessschritt zu heben. Der Index wird ebenfalls dazu verwendet, aus der Oberfläche heraus die Historie aller durchlaufenen Prozessschritte für einen einzelnen Vorgang darzustellen.

Object Index

Zusätzlich zu den reinen Messpunktdaten (welche Prozessschritte wurden erreicht), können auch noch weitere Daten oder Objekte (z.B. Wechselbelegsnummer oder Sperrbelegsnummer) übertragen werden. Diese Objeke ermöglichen dann einen Absprung in das jeweilge Quellsystem. Gleichfalls können die Objekte oder vielmehr die Objektstatus dazu verwendet werden, den Status eines Vorgangs umzusetzen oder einen Vorgang sogar gänzlich zu beenden.

Instance ID Index

In diesem Index werden alle übertragenen Identifikationsmerkmale aller Vorgänge gespeichert. Dies ist damit der zentrale Anlaufpunkt für die Correlation Engine, die anhand der hier gespeicherten Daten versucht, Vorgänge zu korrelieren.

Queue und Error Queue

Der Prozessmonitor verfügt über 2 Queues zur Verarbeitung der eingehenden Daten. In der Haupt-Queue werden alle angekommenden Daten persistiert und nach einer erfolgreichen Verarbeitung wieder gelöscht. Sollte es bei der Verarbeitung zu einem Fehler kommen (z.B. aufgrund einer unzureichenden Prozesskonfiguration) so wird der entsprechende Datensatz in die Error Queue verschoben. In der Error Queue werden die Datensätze nun in größer werdenen (konfigurierbaren) Intervallen erneut verarbeitet. Bei Erfolg (z.B. weil zwischenzeitlich die Konfiguratoin angepasst wurde) werden die Datensätze gelöscht. Ansonsten wird ein Zähler erhöht, was zum Ziel hat, dass bei Erreichen eines definierbaren Maximums kein weiterer Versuch gestartet wird, den Datensatz zu verarbeiten.

TransferData

Das TransferData Objekt ist das zentrale Objekt für die Übermittlung und Verarbeitung von eingehenden Daten. Für alle Dienste, die Daten aus Systemen abrufen oder erhalten, gilt, dass sie ein solches Objekt (oder eine Menge dieser Objekte) erstellen müssen, um es der Prozessmonitor Queue zu übergeben.

Korrelationsmechanismus

Der Korrelationsmechanismus basiert auf dem Zusammenspiel von Identifikationsmerkmalen (auch Identifier genannt). Der Begriff Identifikationsmerkmal umfasst dabei sämtliche Daten, die einen Vorgang eindeutig identifizierbar machen. Oftmals wird die eindeutige Identifizierbarkeit erst im Zusammenspiel von mehreren Identifikationsmerkmalen ermöglicht.

Bei der Korrelation der Daten nimmt der Prozessmonitor alle ihm von dem sendenen System zur Verfügung gestellten Identifier und versucht, anhand dieser einen bereits bestehenden Vorgang ausfindig zu machen. Falls es keinen Treffer gibt, wird über die Liste der Identifier iteriert und Vorgänge separat gesucht. Falls kein bestehender Vorgang gefunden wird, geht der Korrelationsmechanismus von einem neuen Vorgang aus und legt diesen an. Falls es mehrere Vorgänge geben sollte, auf die die Identifier zutreffen, wird ein Korrelationsfehler gemeldet und die Daten werden in die Error Queue ausgesteuert.

Messpunktermittlung aus der B2B

Kurzbeschreibung

Dieses Features soll eine Messpunktermittlung in der B2B ermöglichen, und die gesammelten Messpunktdaten dem CCM Prozessmonitor übergeben.

Die Konfiguration der Kriterien für das Erreichen eines Messpunktes innerhalb der B2B ist dabei generisch gehalten, so dass unterschiedlichste Szenarien abbildbar sind. Die Messpunkte müssen nicht zwangsläufig auf vordefinierte Mako-Prozesse begrenzt sein, sondern sollen auch unterschiedliche Verarbeitungsschritte umfassen. Einige Beispiele für solche Messpunkte werden nachfolgend genannt:

· Versand einer Anmeldeanfrage (UTILMD) Nachricht für den Lieferbeginn Prozess

· Erhalt einer Anmeldeantwort (UTILMD) Nachricht für den Lieferbeginn Prozess (positiv / negativ)

· Empfang einer CONTRL / APERAK Nachricht auf eine versendete EDIFACT Nachricht

 Event Subscriber

In der B2B wird bereits ein Event-basiertes Verfahren eingesetzt, welches die Nachrichtenindizierung zur Aufbereitung für die CCM Arbeitsvorräte absolviert. Ein CCM Event Subscriber registriert sich dabei bei einem EventPublisher, der bei jeder Nachrichtenverarbeitung ein Event wirft.

Ein zusätzlicher EventSubscriber für den CCM Prozessmonitor registriert sich ebenfalls beim EventPublisher und reagiert beim Erhalt eines Events (einer verarbeiteten Nachricht) und führt daraufhin die Messpunktermittlung anhand des Regelwerk aus.

Regelwerk

Zur Überprüfung, ob und welche Messpunktdaten aus einer verarbeiteten Nachricht ermittelt werden können wird auf das bereits existierende Regel-Framework (Klasse org.b2bbp.rules.parser.RulesParser) zurückgegriffen. Das Framework bietet die Möglichkeit Regeln anhand von Edipath-Ausdrücken, Objekten im Messagekontext (u.a. dem Format-Objekt) oder eigenen Funktionen auszuwerten. Falls eine oder mehrere Regeln getroffen werden, wird für diese Regeln ein Schlüssel zurückgegeben, anhand dessen eine Messpunktdefinition geladen wird. Diese Messpunktdefinition enthält dann die typischen Attribute für einen Messpunkt:

• Prozess-ID   <– optional

• Messpunkt-ID(s)

• Messpunkt-Status

• Zusätzliche Objekte

• …

Aus der Definition des Messpunktes wird dann ein TransferData Objekt erstellt und der „Queue“ des CCM Prozessmonitors übergeben. Sobald das Objekt in der Queue gespeichert wurde erfolgt die weitere Verarbeitung im CCM-Prozessmonitor.

Die Angabe der Prozess-ID (also z.B. BEGOFSUPPL für Lieferbeginn) ist dabei optional, da nicht für jeden Messpunkt über das Regelwerk der Prozesstyp bestimmt werden kann. Ein Beispiel hierfür wäre eine eingehende CONTRL Nachricht, aus deren Inhalt nicht zwangsläufig erkennbar ist, welchem Prozess sie zugeordnet werden muss. Stattdessen wird ein allgemeiner Messpunkt generiert und an den CCM Prozessmonitor geschickt, der dann versucht, anhand der Identifikationsmerkmale (z.B. Referenznummer der Originalnachricht) den ursprünglichen Vorgang auszumachen (z.B. eine UTILMD E01) und über diesen den Prozess zu bestimmen (Lieferbeginn).

Nachfolgend einige Beispiele für die Definition solcher Regeln:

RULE rule8 XML_CHG_DEV[
"$PROCTYPE$"=CHG_DEV,
"$PROCIDTYPE1$"=ISUPOD,
"$PROCID1$"="${edipath(LOC[1]+2+0)}",
"$PROCIDTYPE2$"=DEV\_OLD,
"$PROCID2$"="${edipath(RFF[2]+1+1)}",
"$PROCIDTYPE3$"=DEV\_DATE,
"$PROCID3$"="${edipath(DTM[2]+1+1)}",
"$CPID$"=050,
"$CPSTATUS$"="${template(&(this.B3P\_OBJ\_MESSAGE.state))}",
"$OBJTYPE$"=MSGID\_UTILMD,
"$OBJKEY$"="${template(&(this.B3P\_OBJ\_MESSAGE.messageId))}" ]
<=
equalsEdi("UNH+2+0", UTILMD) AND
execute("org.b2bbp.functions.rules.TemplateRule",
"${template(&(this.FORMAT.direction))}","1") AND
equalsEdi("BGM+1+0", "E03");

Der Ausdruck oben enthält einen Regel-Teil (alles rechts bzw. unterhalb des Zuweisungszeichens <= ) und einen Definitionsteil (alles links bzw. oberhalb des Zuweisungszeichen <= ).

Die erste Zeile öffnet den Ausdruck mit dem Stichwort RULE gefolgt von einer ID (rule8) für den nachfolgenden Ausdruck. Das nachfolgende Objekt XML_CHG_DEV verweist auf ein XML Dokument, welches die Struktur für den Messpunkt enhält. Dieses XML Dokument ist in der B2B als Extension hochgeladen und enthält Platzhalter, die über die nachfolgenden Konfigurationen im Definitionsteil gefüllt werden (z.B. $PROCTYPE$ oder $CPID$).

Wichtig ist, dass der Definitionsteil erst ausgewertet und ein TransferData Objekt erstellt wird, wenn die Regel(n) im nachfolgenden Regel-Teil erfüllt ist/sind. In diesem konkreten Fall gilt die Regel als getroffen, wenn es sich bei der verarbeiteten EDIFACT-Nachricht um eine UTILMD Nachricht handelt, diese ausgehend ist und im BGM Segment der Transaktionsgrund E03 angegeben ist. Die Regeln ließen sich noch beliebig erweitern, z.B. um Einschränkungen bzgl. des Absenders oder des Empfängers oder um weitere Edipath-Ausdrücke. Bei der Und-Verknüpfung (AND-Operator) gilt, dass die Regeln von links nach rechts validiert werden und eine negative Validierung zum Abbruch der weiteren Prüfung der restlichen Regeln führt (Kurzschluss-Operatoren).

Einzelne Verarbeitungsschritte als Messpunkte überwachen

Eine zusätzliche Anforderung ist die Extraktion mehrerer Messpunkte aus einer Nachrichtenverarbeitung. Falls eine solche differenzierte Messpunktbetrachtung gewünscht ist, muss der Aufruf einzelner Actions bzw. Services erfasst werden. Um dies zu erreichen, können zusätzliche Action- bzw. Service-Properties gesetzt werden, die beim Ausführen der Action bzw. des Services Objekte in den Messagekontext schreiben. Im EventSubscriber kann dann auf das Vorhandensein dieser Objekte im Messagekontext geprüft werden, um daraus Messpunkte zu generieren.