IndexSyncAnalyzer

Motivation

Die DB-Tabelle B2BBP_CCM_INDEX_SYNC stellt die Schnittstelle zwischen B2B und CCM dar. Wenn neue Nachrichten ins CCM übertragen werden, geschieht dies durch ADD-Operationen in dieser Tabelle. Werden Nachrichten in der B2B nachträglich verändert, werden die zugehörigen Informationen in Form von Index-Updates (UPD) übertragen. Kann ein Index-Update keiner Nachricht im CCM zugeordnet werden (verspätet, aus dem Index gelöscht etc.), wird das UPD als zeitverzögertes (“deferred”) Update (UDD) mit einer Ausführungszeit (“Added”) in der Zukunft wieder in die B2BBP_CCM_INDEX_SYNC gestellt. War eine Reihe von Zuordnungsversuchen nicht erfolgreich, werden die UDDs in die Tabelle B2BBP_CCM_INDEX_SYNC_BU verschoben. Das Update ist damit tot, wird aber zu Analysezwecken in der Tabelle aufbewahrt, um den Grund für den Fehler finden zu können.

Die Einträge in der B2BBP_CCM_INDEX_SYNC werden vom CCM-Index-Job (IndexServiceCCM) in Paketen abgeholt und verarbeitet. Bei hohem Datenaufkommen oder wenn die Updates sehr aufwendig sind, stauen sich die Einträge in der B2BBP_CCM_INDEX_SYNC. Bei Fehlern im Nachrichtenrouting können große Mengen an Nachrichten in der B2BBP_CCM_INDEX_SYNC_BU landen.

IndexSyncAnalyzer

Der IndexSyncAnalyzer ist ein Analysetool, mit dem große Mengen von Einträgen in den Datenbanktabellen B2BBP_CCM_INDEX_SYNC, B2BBP_CCM_INDEX_SYNC_BU menschenlesbar gemacht und ausgewertet werden können.

Es können sowohl der aktuelle Status in der B2B-DB online per Servlet analysiert und als Reports abgerufen, als auch aus der Datenbank exportierte Daten offline analysiert werden.

Installation

Servlet-Implementierung

Das Servlet wird ab der Stable Version 1.13.6_0.X automatisch in Form einer jar-Datei ausgeliefert und muss nicht per manuell eingespielt werden. Es befindet sich unter tomcat/webapps/b2bbp-engine/WEB_INF/lib. Das Servlet ist auf dem jeweiligem Knoten über den Aufruf

http://<server>[:<port>]/b2bbp-engine/indexsyncanalyzer

erreichbar.

Zur vollen Funktionsfähigkeit des Servlets muss eine Extension angelegt werden:

Extension INDEX_SYNC_ANALYZER_DOCTYPE_PROPERTIES

Eine aktuelle Version findet sich unter

NLI DirectSupport INDEX_SYNC_ANALYZER_DOCTYPE_PROPERTIES

In der Extension werden Typen von Index-Sync-Einträgen anhand der darin vorhandenen Lucene-Felder definiert (z.B BS=CTP) definiert und mit einem Namen versehen. Die Definitionen dienen dazu, jedem Index-Sync Eintrag einen Namen/Dokumenttyp zuzuordnen sowie evtl. einen Provider, der z.B. das Update erzeugt hat.

Jede Zeile ist eine Property mit dem Namen als Key und einer Beschreibung des Lucene-Dokuments als Value.

Beispiele:
CTP_UPDATE=BS:CTP;B3P.Updated;Contrl.Received;SEARCHTERM:B3P.MessageId;Publisher:<UNKNOWN> APERAK_Z19_UPDATE=BS:APC;APERAK_RECEIVED;APERAK_CODE:Z10|Z14|Z19|Z31;APERAK_MESSAGE;B3P.Updated;SEARCHTERM:Format.ReferenceId,Format.SenderCode,Format.PartnerCode,Format.Direction#1,BGM,TYPE#Header;Publisher:<UNKNOWN>

Die Syntax-Regeln im Einzelnen: Semikola (“;”), Doppelpunkte (“:”), Kommata (“,”) und Hashtags (“#”) sind Steuerzeichen.

Die Beschreibung des Lucene-Dokuments listet durch “;” getrennte Lucene-Felder auf. Für die Definition der Lucene-Felder gibt es mehrere Möglichkeiten:

• Das Feld muss nur vorhanden sein und kann mit einem beliebigen Wert gefüllt sein (Beispiel: Contrl.Received)
• Der Feldwert darf nur einen festen Wert annehmen. Dieser wird mit Doppelpunkt angeschlossen (Beispiel: BS:CTP)
• TODO Der Feldwert darf mehrere verschiedene Werte annehmen. Diese werden mit einem Doppelpunkt angeschlossen und mit “|” getrennt (Beispiel: APERAK_CODE:Z10|Z14|Z19|Z31)
• SEARCHTERM: Die im Searchterm vorhandenen Felder werden durch Kommata separiert angehängt (ohne die Werte, AND, OR und Klammern; sollen doch Werte vorgegeben werden, werden diese durch “#” an den Feldnamen angehängt Beispiel: SEARCHTERM:Format.ReferenceId,Format.SenderCode,Format.PartnerCode,Format.Direction#1,BGM,TYPE#Header)
• Publisher: Dies ist ein Freitextfeld. Hier kann eine erzeugende Klasse angegeben werden oder ein Service oder z.B. “DeltaSync”

Standalone Version (Eclipse)

Die derzeitige Standalone-Version funktioniert nur aus einer IDE (Eclipse, IntelliJ) heraus. Die Klasse IndexSyncAnalyserFileImpl enthält eine main-Methode. Bei Ausführung erscheint eine File-Select-Box, mit der ein csv-DB-Export der DB-Tabelle ausgewählt werden kann.

Derzeit können nur Exports aus ORACLE-DBs mit DB-Visualizer verarbeitet werden.

Dieser muss in folgendem Format vorliegen: TODO

Aufruf des Servlets mit Parametern

Beim Aufruf des Servlets können noch optionale Parameter als key=value Paare mitgegeben werden. Diese werden mit “?” an die Servlet-URL angehängt und durch & getrennt.

• maxdatasets=50000 [default=10000] legt die Anzahl der maximal auszuwertenden Tabellenzeilen fest.
• outformat=zip [default=html]; zip lädt die Analysereports als ZIP-Datei herunter; html gibt die Reports hintereinander auf dem Bildschirm aus.
• tablename=B2BBP_CCM_INDEX_SYNC_BU [default=B2BBP_CCM_INDEX_SYNC] bestimmt die auszuwertende Tabelle.

Beispiele:

Wenn man einen Stau in der B2BBP_CCM_IN DEX_SYNC Tabelle untersuchen möchte, kann man sich mit folgendem Aufruf die ersten 200 Datensätze auf dem Bildschirm anschauen, die pro Batch / Joblauf des IndexServiceCCM aus der Tabelle geholt werden (ServiceProperty B3P_MAX_FILES):

http://<server>[:<port>]/b2bbp-engine/indexsyncanalyzer?maxdatasets=200

Wenn man eine statistische Analyse machen will, welche Dateien wann in der B2BBP_CCM_INDEX_SYNC_BU gelandet sind, geht das z.B. mit dem Aufruf

http://<server>[:<port>]/b2bbp-engine/indexsyncanalyzer?maxdatasets=25000&outformat=zip&tablename=B2BBP_CCM_INDEX_SYNC_BU

ParameterErrorReport

Wenn für die Parameter nicht erlaubte Werte angegeben werden, wird ein ParameterErrorReport erzeugt. In HTML ist dies der erste angezeigte Report, in ZIP ist es eine eigene Datei ParameterErrorReport.txt. Im Fehlerfall wird das Servlet trotzdem ausgeführt. Für die fehlerhaften Parameter werden dabei die Default-Parameter verwendet.

DataAnalyzer

Die Analysen werden innerhalb des Tools von DataAnalyzer Klassen durchgeführt und die Ergebnisse in Form einzelner Reports ausgegeben (als html auf dem Bildschirm oder zum Download als zip-Archiv mit csv- oder Text-Dateien). Bei neuen Analyseanforderungen können einfach neue DataAnalyzer-Klassen geschrieben und eingebunden werden. Derzeit existieren folgende DataAnalyzer

POSSIBLE_PROBLEMS

Der Report ist noch in Entwicklung und soll bekannte Probleme bei vollaufenden CCM_INDEX_SYNC DB-Tabellen automatisch erkennen und melden. Bisherige Features:

• TS-Update-Erkennung
• Erkennung von ADD-Operationen mit vielen Dokumenten (z.B. UTILMD E05 Bestandslisten, MSCONS, APERAK)

EXTENDED_CSV LIST

Der Report enthält für jede Zeile der DB-Tabelle eine csv-Zeile mit den Werten der DB-Tabelle, aber ergänzt um Informationen aus dem in der DB nicht einsehbaren Binärobjekt (BLOB):

• Anzahl der Dokumente im BLOB
• Typen der Dokumente im BLOB, soweit sie mit Hilfe der Extension INDEX_SYNC_ANALYZER_DOCTYPE_PROPERTIES identifiziert werden können. Bei neu hinzugefügten Nachrichten wird vor dem dem Dokumenttyp HEADER_ADD/ROW_ADD das Nachrichtenformat angezeigt.
• Anzahl der Lucene-Felder im ersten Dokument
• Den Publisher , also den Herausgeber des Dokuments (Service, DeltaSync etc.), soweit dieser bereits identifiziert werden konnte.
• Den Suchterm, mit dem Updates nach ihren Originalnachrichten suchen. Die Komplexität des Suchterms kann auf längere Verarbeitungszeiten hindeuten.

UNKNOWN_DOCUMENTS_CONTENT

Der Report enthält Infos über bisher noch nicht identifizierte Dokument-Typen. Mit diesen Informationen können neue Typen in der Extension INDEX_SYNC_ANALYZER_DOCTYPE_PROPERTIES angelegt werden.

DOCUMENT_TYPES_FOUND

Der Report enthält Infos über die in den Einträgen identifizierten Dokumenttypen. Er besteht aus zwei Teilen:

• Statistik der Dokumenttypen: Eine Auflistung, wie oft die verschiedenen Dokumenttypen in den untersuchten CCM_INDEX_SYNC-Einträgen vorkommen. Dabei werden Header und Row Dokumente einzeln gezählt. Eine neu hinzugefügte UTILMD Nachricht mit 10 Vorgängen wird als 1 Eintrag vom Typ UTILMD HEADER_ADD und 10 Einträge vom Typ UTILMD ROW_ADD gezählt. Die Anzahl der HEADER_ADDs ist dabei immer identisch mit der Anzahl Nachrichtendateien.

• Definition der gefundenen Dokumenttypen: Hier kann man nachsehen, welche Felder mit welchen Werten ein Dokumenttyp enthalten muss, damit er vom System identifiziert wird. (Ausnahme: HEADER_ADD und ROW_ADD; diese enthalten unterschiedliche Anzahlen von Feldern). Wird als Wert <ANY> angegeben, bedeutet dies, dass das Feld einen beliebigen Wert annehmen kann, also einfach nur vorhanden sein muss.

Statistik MONAT / TAG / STUNDE / Minuten

Der Report enthält eine Aufschlüsselung, wieviele Einträge der verschiedenen Typen ADD (hinzugefügte Dokumente), UPD (Update), DFR (Deferred Update), TS (Timestamp-Update) in den entsprechenden Zeiträumen in die DB-Tabelle gekommen sind. Dies kann dazu genutzt werden, festzustellen, ob zu bestimmten Zeitpunkten (Uhrzeiten, Tagen) große Mengen Updates gleichzeitig ankommen, um dann herauszufinden, woher sie kommen.

ToDo

• Identifizierung der Provider

• SEARCHTERM auswerten

• DataAnalyzer automatische Problemerkennung erweitern
• DataAnalyzer für kompletten Output der BLOBs?