Konzept Nachrichtenindizierung im CCM-Index
Zum Verständnis der Arbeitsvorräte und zur Fehlersuche ist es nützlich zu wissen, auf welchem Weg Nachrichten in den CCM-Index gelangen und welche Programmteile, Extensions und Services daran beteiligt sind.
Überblick
Extension B3P_CCM_CHANNELS
Jeder Nachrichht, die über den Workflow in die B2B kommt, wird durch die ChannelDistributions ein Channel zugewiesen. Im Workflow wird dann geprüft, oib dieser Channel in der Extension B3P_CCM_CHANNELS vorhanden ist. Wenn ja, wird die Nachricht zur Indizierung ins CCM weitergeleitet. Dabei wird ein fachliches Attribut angelegt: “Nachricht wurde dem CCM zum Indexieren übergeben” = true.
Die Extension B3P_CCM_CHANNELS (“ChannelWhiteList”) ist das Eingangstor zum CCM-Index. Hier kann man die CCM-Indizierung dadurch abschalten, dass alle Channels auskommentiert werden. In der B2B ankommende Nachrichten werden dann nicht mehr indiziert, gelangen auch nicht in die DB-Tabelle B2BBP_CCM_INDEX_SYNC. Diese Nachrichten können später nachindiziert werden.
EventSubscriber
Nachrichten und Updates, die in den CCM-Index sollen, werden über den EventPublisher an die EventSubscriber übermittelt. Dies sind derzeit der PMEventSubscriber (CCM-Index), der BPTEdiSubscriber (Indexe des Prozessmonitors) und der DeltaSyncUpdateHandler (DeltaSync/StatusSynchronisation).
“Event” kommt von dem asynchronem EventBus, der früher zwischen EventPublisher und EventSubscriber eingeschaltet war. Jetzt werden die Nachrichten und Updates direkt an die jeweiligen EventSubscriber übertragen.
PMEventSubscriber
Für die Aufbereitung der Nachrichten für die CCM-Indizierung ist der PMEventSubscriber zuständig. (PM kommt daher, dass die Arbeitsvorräte früher als ProzessMonitor bezeichnet wurden, so heißt auch noch die zentrale Klasse der AV; heute heißen die Arbeitsvorräte eher “Prozessschrittmonitor”).
Der PMEventSubscriber (TODO: Warum WhiteListPrüfung hier?) macht eine Menge komplexer Dinge. Im Wesentlichen erzeugt er mit Hilfe des FlexibleIndexers aus den Nachrichten und Updates SearchDocuments, die dann in Form von IndexSync-Objekten in die DB-Tabelle B2BBP_CCM_INDEX_SYNC geschrieben werden. Ein IndexSync-Objekt enthält immer alle SearchDocuments, die zu einer Nachricht gehören. Dies ist immer ein “Header”-Dokument, das zu der gesamten NachrichtenDatei gehört und ein oder mehrere “Row”-Dokumente, eins für jeden Geschäftsvorfall / Vorgang / Einzelnachricht. Unter den technischen Details wird an eine der letzten ausgeführten Actions das Attribut B3P_PUBLISHED_TO_CCM gesetzt. Es gibt Gründe (reasons) warum dies oder das Setzen des fachlichen Attributs manchmal nicht passiert und die Nachricht trotzdem im CCM ist.
FlexibleIndexer und Extension FLEXIBLE_INDEX
Der FlexibleIndexer erhält seine Informationen aus der Extension FLEXIBLE_INDEX. Diese enthält für jede Nachrichtenversion (z.b: UTILMD 5.1G, UTILMD 5.1F, MSCONS 2.2H etc.) einen Block mit Anweisungen, welche Informationen aus der EDIFACT-Nachricht unter welchem Variablennamen / Feldnamen im CCM-Index abgelegt und damit suchbar gemacht werden sollen.
Jeder dieser Blöcke bestaht aus einem Kopfteil, der die Informationen für die Generierung des Header-SearchDocuments enthält, und einen iterativen Teil, der die Informationen für die Generierung der Row-SearchDocuments enthält.
Jedes SearchDocument ist am Ende eine Map von Key-Value-Paaren. Bei Nachrichten werden diese Maps als Liste von SearchDocuments verpackt und in ein IndexSync-Objekt gehängt, bei Updates wird nur ein einzelnes SearchDocumnent aingehängt. Das IndexSync-Objekt enthält noch Informationen wie die MessageID, den Index-Namen, die Operation (ADD, UPD, UDD, TS) etc. sowie das Datum der Hinzufügung zum CCM-Index.
Die fertigen IndexSync-Objekte werden dann in die DB-Tabelle B2B2BBP_CCM_INDEX_SYNC geschrieben.
IndexServiceCCM
Die B2B2BBP_CCM_INDEX_SYNC Tabelle ist so etwas wie die Queue des CCM-Index. Und entsprechend den QueueServices in der B2B gibt es hier einen IndexServiceCCM, der die IndexSync-Objekte in Paketen von 100-400 Stück aus der Tabelle holt und weiterverarbeitet.
Der IndexServieCCM packt die IndexSync-Objekte aus, sortiert die SearchDocuments nach Inserts, also neuen Dokumenten, Updates, Deferred Updates und TimeStampUpdates und führt dann die eigentliche Indizierung im CCM-Index aus.
Indizierung bedeutet dabei, dass eine Art Wörterbuch angelegt wird, wo zu jedem Wert, den ein Feld annehmen kann, die Dokumentnummern abgelegt werden, die in diesem Feld genau diesen Wert haben. Bei einer Suche fragt man also nach dieser Feld/Wert-Kombination und bekommt eine Liste von Dokumentnummern geliefert.
Updates enthalten neben den zu erneuernden Feldwerten noch einen Suchterm, der ihnen ermöglicht, das upzudatende Dokument zu finden. Das Originaldokument wird dann gelöscht und ein neues Dokument mit den geänderten sowie den unveränderten Feldwerten angelegt.
View Me Edit Me