Konfiguration des CCM Index Service

Einleitung

Der IndexServiceCCM ist für die Befüllung und Aktualisierung des CCM-Index zuständig. Er wird regelmäßig ausgeführt und liest bei jedem Aufruf ein Paket von Zeilen aus der Datenbanktabelle B2BBP_CCM_INDEX_SYNC aus. Die Datensätze werden dem CCM-Index als neue Index-Dokumente hinzugefügt (ADD) oder aktualisieren/updaten vorhandene Index-Dokumente (UPD). Deferred Updates (UDD) mit Zeitstempeln in der Zukunft sind Updates, die darauf warten, dass die Dokumente, die sie aktualisieren sollen, im Index auftauchen. Sie werden solange ignoriert, bis ihr Zeitstempel in der Vergangenheit angekommen ist, und dann wie normale Updates verarbeitet.

Installation

CCM Index Service definieren

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

IndexServiceCcm1

IndexServiceCcm2

Field Value
ID ccm_index_pre (eindeutige ID)
Name CCM Index Service
Typ INDEX
Klasse com.nextlevel.ccm.indexing.service.IndexServiceCCM
Channel
Richtung Engine nach Business Partner
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 IndexServiceCCM

Fügen Sie die folgenden Service-Attribute hinzu:

IndexServiceCcm3

Eigenschaft Wert Beschreibung
B3P_POLL_INTERVAL Positive Ganzzahl Wartezeit für Neustart des Service nach Beendigung des letzten Laufs, in Sekunden
B3P_MAX_FILES 100 (Positive Ganzzahl) Anzahl der Nachrichten, die bei Aufruf des Service “in einem Rutsch“ verarbeitet werden. 100 ist empfohlen. Bei zu großen Werten steigt der Speicherverbrauch stark an.
B3P_ENABLE_SERVICE_PAUSE_STATE true / false Einstellung zur Pausierung des IndexService für Sicherung. Siehe unten den Abschnitt “Extension zum Pausieren des CCM Index Service”
DEFER_UPDATE_SECONDS 600 [=default, wenn nicht vorhanden] Zeitverzögerung für erstes deferred Update; Kann ein Index-Update keiner Originalnachricht zugeordnet werden, wird für den nächsten Zuordnungsversuch ein verzögertes Update mit einer MessageId, die mit DFR0, DFR1 etc. beginnt, in die DB-Tabelle B2BBP_CCM_INDEX_SYNC geschrieben. DEFER_UPDATE_SECONDS ist die Verzögerung beim ersten Versuch. Bei jedem weiteren Versuch (insgesamt 8) wird die Verzögerungszeit verdoppelt. Nach dem letzten Versuch wird das Update in die DB-Tabelle B2BBP_CCM_INDEX_SYNC_BU verschoben; Die ServiceProperty wird ignoriert, wenn CCM_DEFERRED_UPDATES_INTERVALS_MINUTES vorhanden und korrekt befüllt ist
CCM_DEFERRED_UPDATES_INTERVALS_MINUTES 10,60,2500 Minutenintervalle für die Ausführung von Deferred Updates; Die Service Property bestimmt, wie oft das Update verschoben wird (Anzahl der durch die Trenner “,”, “;” oder “|” getrennten Einträge) und um wieviele Minuten jeweils. Die ServiceProperty überschreibt DEFER_UPDATE_SECONDS; Default, wenn die Service Property nicht vorhanden ist: DEFER_UPDATES_SECONDS/60 * (1, 2, 4, 8, 16, 32, 64, 128) Minuten
B3P_MAX_DAYS 3 Maximaler Alter der Deferred Updates in Tagen. Ältere Einträge werden nicht mehr defferred sondern gelöscht. Wenn die Eigenschaft fehlt, wird nicht nach Alter geprüft (das ist auch das Default). Diese Eigenschaft macht nur in Kombination mit DEFER_UPDATE_SECONDS Sinn.
TIMESTAMP_UPDATE_RANGE_HOURS Positive Ganzzahl (default: 48) Bei einem Timestamp-Update werden im CCM-Index Nachrichten mit Status BS=CTW (Warten auf CONTRL), bei denen die CONTRL-Frist (Feld Contrl.expected) abgelaufen ist, auf CTN (Nicht fristgerechte CONTRL) gesetzt. Um z.B. in Testsystemen zu verhindern, dass die Anzahl der zu bearbeitenden Nachrichten zu groß wird, kann mit dieser Eigenschaft eingestellt werden, wieviele Stunden rückwirkend die CTW Nachrichten upgedated werden sollen. Default: 48 h.
B3P_OPT_TIMESTAMP_UPDATE true / false TS-Updates (Bestätigungsstatus “Contrl nicht fristgerecht”) werden schneller verarbeitet. “false” sollte nicht mehr benutzt werden
TIMESTAMP_UPDATE_ONLY_HEADERS true / false Nur bei B3P_OPT_TIMESTAMP_UPDATE = true Nur Header-Einträge werden im Index aktualisiert. Bei den Row-Einträgen (für Vorgänge) bleibt Bestätigungsstatus auf “CTW”. Dadurch wird die Indizierung schneller.

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_update,ccm_index_pre

Der Service darf maximal auf einem Knoten laufen.

Timestamp-Updates abschalten

Wenn Nachrichten durch den ContrlDeadlineJob auf den Bestätigungsstatus “Contrl nicht fristgerecht” (CTN) gesetzt werden, wird dieser Status auch im CCM-Index gesetzt. Diese Operation nennt man den Timestate-Update. Bei vielen Vorgängen in Nachrichten kann sie sehr lange dauern.

Die Verarbeitung der Timestamp-Updates kann abgeschaltet werden. Dafür muss die Global Property B3P_CCM_PROCESS_CTRL_DEADLINE_TIMESTAMPS = false gesetzt werden.

Extension zum Pausieren des CCM Index Service

Definieren Sie eine Extension service_pause_interval_ccm_index_pre (der Extensionname muss auf die ID des Service enden).

Feld Wert
Typ service_pause_interval_ccm_index_pre
Provider <leer>
Version <leer>
Inhalt Für eine Pause zwei mal in der Woche
daysOfWeek Wednesday;Sunday
startTime 20:30
endTime 21:30

Oder für eine Pause jeden Tag
repeatInterval Daily
startTime 20:30
endTime 21:30

Der angegebene Inhalt der Extension verursacht eine Pausierung des CCM Index Service am Mittwoch und Sonntag zwischen 20:30h und 21:30h (oder alternativ täglich). Innerhalb dieses Zeitraums wird nichts in den Index geschrieben, und der Index kann gesichert werden.

Verarbeitungsstatistik / Operation Statistics

Es ist möglich eine Statistik über die verarbeiteten CCMIndexSync Einträge in den Logfiles ausgeben zu lassen. Dazu muss in der Extension LOG_LEVELS ein Eintrag

com.nextlevel.ccm.indexing.service.IndexServiceCCM=INFO

gesetzt und der Knoten, auf dem der IndexServiceCCM läuft, neu gestartet werden. In dem Fall wird nach jeder Ausführung des Service ein Block “OperationStatistics for current IndexServiceCCM run:” im B2B-Log ausgegeben, der Informationen über die verarbeiteten Daten enthält.

Zeile 1: Statistik über CCMIndexSync-Einträge

Die erste Datenzeile wertet die Einträge der DB-Tabelle B2BBP_CCM_INDEX_SYNC aus, die während des Service Laufs verarbeitet wurden.

CcmIndexSync entries (processed): Total:8(6)   ADD:3(3) UPD:2(2) UDD:1(1) TS:2(0)   Deleted(del.UDD->new UDD DFR):8(2->5)

Dabei bedeuten die Zahlen Folgendes:

Ausdruck Bedeutung
Total: x(y) Insgesamt wurden x Einträge / (= Nachrichtendateien) aus der B2BBP_CCM_INDEX_SYNC DB-Tabelle gelesen (ServiceProperty B3P_MAX_FILES). Davon wurden y verarbeitet.
ADD: x(y) x Einträge waren vom Typ ADD (neu hinzugefügte Nachrichten), davon wurden y zu Index-Insert-Dokumenten verarbeitet und dem Index hinzugefügt. APERAK ADDs können zusätzlich “related” Updates erzeugen. Dies sind BS=APC Updates auf den Header und die Rows der Originaldokumente, die mit der APERAK abgelehnt wurden
UPD x(y) x Einträge waren vom Type UPD (Updates für im Index vorhandene Nachrichten), davon wurden y zu Index-Update-Dokumenten verarbeitet und die zugehörigen Dokumente im Index upgedated.
UDD x(y) x Einträge waren vom Typ UDD (“deferred” Updates, die vor einiger Zeit UPDs waren, damals ihre zugeordneten Dokumente im Index nicht gefunden hatten und mit einem Zeitstempel (“Added”) in der Zukunft wieder in die CCM_INDEX_SYNC Tabelle eingestellt wurden), davon wurde bei y der Update-Versuch wiederholt, weil ihr Zeitstempel gerade wieder in der Vergangenheit angekommen ist.
TS x(y) x Einträge waren vom Typ TS (Timestamp-Update), davon wurden y zu Index-TS-Update-Dokumenten verarbeitet, weil die GlobalProperty B3P_CCM_PROCESS_CTRL_DEADLINE_TIMESTAMPS=true gesetzt ist.
Deleted: x(y->z) Bei Beendigung des Service wurden x Einträge gelöscht, weil korrekt verarbeitet (einschließlich UDDs, für die eine neue Zuordnung versucht wurde), y Deferred Updates (UDDs) mit MessageId-Prefix DFRX wurden gelöscht, nachdem sie ganz oder teilweise zu neuen UDDs (Anzahl: z) mit einem Dokument pro Eintrag und hochgezähltem DFRX+1 Prefix verarbeitet wurden.

Zeile 2: Statistik der erzeugten SearchDocuments (Inserts, Updates, TimestampUpdates)

Die zweite Datenzeile gibt an, wieviele Index-Dokumente durch welche Typen von Einträgen erzeugt worden sind.

Docs created: Total:1037   Inserts/ADD:1031 Upd/ADD:1 Upd/UPD:2 Upd/UDD:1(1) Upd/total:4 Ts/TS:1, TS/BU:1
Ausdruck Bedeutung
Total Gesamtanzahl der in diesem Lauf des IndexServiceCCM erzeugten Index-Dokumente
Inserts/ADD Anzahl der Insert-Dokumente, die durch ADD-Einträge erzeugt wurden (1 Header Dokument + 1 Row Dokument pro Vorgang/Einzelnachricht)
Upd/ADD Anzahl der Update-Dokumente, die als “related” Updates durch ADD Einträge von CONTRL (1 Dokument pro CONTRL) oder APERAK (1 Header Update Dokument + ein Row Update Dockument pro abgelehnten Vorgang) Nachrichten erzeugt wurden
Upd/UPD Anzahl der Update-Dokumente, die von UPD Einträgen erzeugt wurden
Upd/UDD x(y) Anzahl x der Update-Dokumente, die von UDD-Einträgen erzeugt wurden, für die ein erneuter Zuordnungsversuch unternommen wurde; Anzahl y der Update-Dokumente, für die der Zuordnungsversuch erfolgreich war
Upd/total Gesamtanzahl der erzeugten Update-Dokumente
TS/TS Anzahl der aus TS Einträgen erzeugten Timestamp-Update Dokumente
TS/BU Anzahl der nicht ausgeführten Timestamp-Updates, bei denen der TS-Eintrag in die B2BBP_CCM_INDEX_SYNC_BU Tabelle verschoben wurde

Zeile 3: Statistik über Deferred Updates (UDD CCMIndexSync-Einträge)

Die dritte Datenzeile (nur vorhanden, wenn Deferred Updates erzeugt oder verschoben wurden) gibt Informationen über neu erzeugte oder verschobene Deferred Updates. Dies sind neue CcmIndexSync-Einträge, die erstellt werden, wenn ein Update-Dokument das upzudatende Originaldokument nicht findet. Ein neues Deferred Update bekommt die Operation UDD und eine neue MessageId, die mit DFR0_ beginnt. Der Timestamp “Added” wird eine gewisse Zeit in die Zukunft datiert. Ist diese Zeit abgelaufen, “Added” also wieder in der Vergangenheit angekommen, wird eine neue Zuordnung versucht. Bei jedem erfolglosen Zuordnungsversuch wird der Prefix DFRn hochgezählt. Ist ein Maximalwert erreicht, wird das Deferred Update in die DB-Tabelle B2BBP_CCM_INDEX_SYNC_BU entsorgt.

Deferred updates: New entries (DFR0:1). Renamed Entries (DFR1:1 DFR4:1)  Entries moved to B2BBP_CCM_INDEX_SYNC_BU: 1
Ausdruck Bedeutung
New Entries (DFR0:x) Anzahl x der neu erzeugten Deferred Updates
Renamed Entries (DFRn:x) Anzahl x der zum n-ten Mal umbenannten Deferred Updates
Entries moved to B2BBP_CCM_INDEX_SYNC_BU: x Anzahl x der endgültig nicht zugeordneten, in die Backup-Tabelle verschobenen Deferred Updates
View Me   Edit Me