Konfiguration des CCM Index Update Backup Service

Einleitung

Der UpdateBackupIndexServiceCCM dient dazu, Probleme, die bei der Parallelverarbeitung von Nachrichten entstehen, zu kompensieren.

Normale Index Updates und Deferred Updates

Der Grundmechanismus zur Synchronisierung von Informationen zwischen B2B und CCM sind Index-Updates. Neu hereinkommende Nachrichten werden über ADD-Operationen und die B2BBP_CCM_INDEX_SYNC Datenbanktabelle in den CCM-Index geschrieben. Ändern sich Nachrichten in der B2B, wie z.B. durch eingehende CONTRLs oder durch die StatusSynchronisation mit einer IS-U, werden Update-Dokumente erzeugt, die in der Regel über UPD-Operationen und B2BBP_CCM_INDEX_SYNC in den CCM-Index geschrieben werden.

Jedes Update hat explizit oder implizit einen Suchterm, der ihm ermöglicht, die upzudatende Originalnachricht im Index zu finden. Für Updates in der B2BBP_CCM_INDEX_SYNC Tabelle gibt es einen Mechanismus für den Fall, dass ein Update seine Originalnachricht nicht im Index findet. Dabei werden die UPD-Objekte als UDD-Objekte (Deferred Updates) in eine Warteschleife in der B2BBP_CCM_INDEX_SYNC Tabelle geschickt und entweder irgendwann zugeordnet und ausgeführt oder nach einem definierten Zeitraum und mehreren fehlgeschlagenen Zuordnungsversuchen in der B2BBP_CCM_INDEX_SYNC_BU Tabelle archiviert.

Ein Sonderfall sind sogenannte zugehörige (“Related”) Updates. Sie entstehen bei der Indizierung von APERAK-Dokumenten (ADD-Operation). Wenn der IndexServiceCCM die APERAK-Objekte aus der Tabelle holt und verarbeitet, erzeugt er Related Updates, um das zugehörige Originaldokument (z. B. UTILMD) auf BS=APC zu setzen. Diese werden nicht in die B2BBP_CCM_INDEX_SYNC geschrieben, sondern direkt im Index umgesetzt.

Diese Related Updates (eins für jeden Vorgang) prüfen in der DB, ob bei ihrer Originalnachricht das Attribut B3P_PUBLISHED_TO_CCM gesetzt ist. Wenn nicht, werden sie in die B2BBP_CCM_UPDATE_BACKUP Tabelle geschrieben. Der UpdateBackupIndexServiceCCM läuft ca. alle 40 s (einstellbar) und holt sich Updates, bei deren Originalnachricht mittlerweile das B3P_PUBLISHED_TO_CCM Attribut gesetzt ist, aus der Tabelle und verschiebt (????) sie mit Operation UDD (????) in die B2BBP_CCM_INDEX_SYNC Tabelle.

ToDo

Zu klären: Was unterscheidet diese Related Updates von normalen UDDs (sie haben eine zusätzliche Vorgangs-ID); könnten die Updates in den Deferred Updates Prozess überführt werden?

Installation

Datenbanktabelle

Der UpdateBackupIndexServiceCCM benötigt die Datenbanktabelle B2BBP_CCM_UPDATE_BACKUP. Aktuelle CREATE-Skripte für verschiedene Datenbanken können beim Support angefordert werden.

CCM Update Backup Service definieren

Definieren Sie einen neuen Service Task unter “Administration -> Services” wie folgt:

Field Value
ID ccm_update (eindeutige ID)
Name CCM Update Backup Service
Typ INDEX
Klasse com.nextlevel.ccm.indexing.service.UpdateBackupIndexServiceCCM
Channel <keine Auswahl>
Richtung nach Welt
Status STP
Erstellt von b2bbp
Startup Yes (check box)

Wird der Service in einem Customizing über eine xml-Datei hochgeladen, ist defaultmäßig Startup=0 eingestellt. Der Service muss dann noch manuell gestartet werden (Startup=1).

Service-Attribute für den UpdateBackupIndexServiceCCM definieren

Eigenschaft Wert Beschreibung
B3P_POLL_INTERVAL 40 (positive Ganzzahl) Periode für Neustart des Service, in Sekunden
B3P_MAX_FILES 300 (positive Ganzzahl) Anzahl der Nachrichten, die bei Aufruf des Service “in einem Rutsch“ verarbeitet werden
B3P_MAX_DAYS 30 (positive Ganzzahl) maximales Alter der Updates, die noch verarbeitet werden sollen, in Tagen

Knotenzuordnung

Ordnen Sie den Service einem Knoten zu. Zur Zuordnung zu Knoten <N> hängen Sie an den Wert der GlobalProperty NODE_<N> mit Komma die ID des Service an, z.B.

NODE_12=ccm_index_pre,ccm_update

Der Service darf maximal auf einem Knoten laufen.

 

 

 

 

View Me   Edit Me