DeleteJobDBAndArchived

Kurzbeschreibung

Der Löschjob löscht Nachrichten aus der Datenbank. Die Nachrichten müssen älter als eine angegebene Zeitgrenze sein. Für nicht archivierte Nachrichten kann konfiguriert werden, welche Elemente dieser Nachrichten gelöscht werden sollen. Archivierte Nachrichten werden vollständig gelöscht.

Der Löschjob protokolliert zur Laufzeit im Monitoring-Action-Eintrag auf welcher Tabelle er zuletzt gearbeitet hat, wie viele Einträge gelöscht wurden und aus welcher Nachrichtenzeitraum in der B2BBP_DATA_MESSAGE-Tabelle gelöscht wurde.

Beim Löschen aus den B2BBP_DATA_MESSAGE und B2BBP_DATA_ACTION Tabellen werden automatisch alle abhängigen Daten gelöscht.

Der Joblauf endet spätestens nach einer konfigurierten maximalen Laufzeit.

Anlegen des SCHEDULER-Jobs

Zunächst wird gemäß der Dokumentation zu Scheduler Services ein Scheduler eingerichtet. Der Service wird im Bereich “Administration” unter dem Reiter “Service” angelegt. Tip: Man kann einen bestehenden SCHEDULER-Job kopieren und die Service ID abändern.

* Typ: SCHEDULER
* Klasse: org.b2bbp.service.inbound.scheduled.SchedulerRegisterService
* Startup: ja

Konfiguration der ServiceProperties

Scheduler Properties

Vergleiche hierzu auch die Dokumentation zum SchedulerRegisterService. Um den Job jede Nacht um 2:30 auszuführen, sind folgende Properties zu setzen:

B3P_SCHEDULER_TYPE = CRON

B3P_CRON_HOURS = 2

B3P_CRON_MINUTES = 30

B3P_SCHEDULER_REGISTER_CLASSNAME = org.b2bbp.service.inbound.scheduled.DeleteJobDBAndArchived

Zeitgrenze & Löschkategorien

Es gibt mehrere Löschstrategien. Diese werden nacheinander ausgeführt. Für jede Strategie gibt es eine Property, die die zugehörige Zeitgrenze definiert. Nur Nachrichten, die älter als diese Grenze sind, werden beim Löschen berücksichtigt. Falls zu einer Strategie keine Property konfiguriert ist, wird die Strategie nicht angewendet.

Die Strategien basieren auf den Strukturen in der Datenbank. Es gelten folgende Fremdschlüsselbeziehungen: Einer Nachricht können mehrere Actions zugeordnet sein. Einer Action können mehrere Attribute und Errors zugeordnet sein. Es ist performanter, wenn zunächst Attribute & Errors, dann Actions und dann Nachrichten gelöscht werden. Entsprechend ergibt sich die Reihenfolge der Strategien.

• B3P_DEL_ARCHIVED_DATE_BEFORE - Archivierte Nachrichten werden vollständig gelöscht. (Zuerst Attribute, dann Errors, dann Actions, dann Nachrichten.)
• B3P_DEL_ATTRIBUTE_DATE_BEFORE - Nur Attribute der (archivierten & unarchivierten) Nachrichten werden gelöscht.
• B3P_DEL_ERROR_DATE_BEFORE - Nur Errors der (archivierten & unarchivierten) Nachrichten werden gelöscht.
• B3P_DEL_ACTION_DATE_BEFORE - Actions der (archivierten & unarchivierten) Nachrichten werden gelöscht. Hierdurch werden auch Attribute und Errors gelöscht.
• B3P_DEL_MESSAGE_DATE_BEFORE - (Archivierte & unarchivierte) Nachrichten werden vollständig gelöscht.

Als Wert zu jeder dieser Properties ist jeweils eine Zeitgrenze anzugeben. Die Angabe erfolgt als CRON Ausdruck im Format Y M D H M S (Jahre, Monate, Tage, Stunden, Minuten, Sekunden). Beispiel: 1 2 5 2 0 0 – alle passenden Einträge deren Nachrichten älter als 1 Jahr, 2 Monate, 5 Tage, 2 Stunden, 0 Minuten und 0 Sekunden sind, werden gelöscht.

Die Zeitgrenze muss so gewählt werden, dass die Archivierung bis dahin abgeschlossen ist. Falls das nicht möglich ist, muss der Administrator der B2B den Löschjob deaktivieren.

Maximale Laufzeit

Mit der folgenden Property wird die maximale Laufzeit des Jobs in Stunden angegeben.

B3P_MAX_RUNTIME_HOURS

Hier ist eine ganze Zahl zwischen 1 und 23 einzutragen. Der Standardwert ist 5.

Die tatsächliche Laufzeit kann geringfügig länger sein.

Reihenfolge, letzte Ausführung & Nebenläufigkeit

Der DeleteJob löscht alte Nachrichten zuerst. Er speichert in den GlobalProperties das Datum bis wohin gelöscht wurde. Die Speicherung erfolgt pro Strategie. Der nächste Joblauf startet bei diesem Datum. Mit Hilfe der folgenden Property wird dieses Datum ignoriert und die Suche nach zu löschenden Nachrichten beginnt von vorne (1.1.1990):

B3P_DELETE_FROM = START

Falls mehrere Löschjobs (auch unterschiedliche) konfiguriert sind, schreiben sie alle die gleichen GlobalProperties. In diesem Fall muss diese Property deshalb zwingend für jeden Löschjob konfiguriert werden.

Alternativ kann der Startzeitpunkt mit der Property selbst bestimmt werden. Hierfür ist in der Property statt dem fixen Wert START ein Zeitpunkt in der Form yyyy.MM.dd HH:mm:ss einzutragen. Dies kann die Performance verbessern.

Filter nach Channel

Es können gezielt Nachrichten aus bestimmten Channeln gelöscht werden. Hierfür ist folgende Property zu konfigurieren:

B3P_CHANNELID = ;;...

Die Channelnamen sind Semikolon-separiert anzugeben. Falls diese Property gesetzt ist, werden nur Nachrichten gelöscht, die in den hier konfigurierten Channeln verarbeitet wurden.

Optimierungen

Deletion Span

Der Löschjob arbeitet auf einem fortlaufenden Zeitfenster, der Deletion Span. Sobald die Arbeit innerhalb des Zeitfensters abgeschlossen ist, wird das Fenster weiter geschoben.

B3P_DELETION_SPAN

Die Angabe erfolgt in Tagen, der Default ist 7 Tage. Zu große wie auch zu kleine Werte können sich negativ auswirken.

SQL Optimierung

Das Löschen erfolgt per SQL. Standardmäßig werden die MessageIds in der where-clause als Disjunktion aufgelistet. Mit der folgenden Property werden die MessageIds stattdessen per where-in Syntax aufgelistet:

B3P_USE_IN_STATEMENT = true

Hierdurch wird die Performance verbessert. Da im Code gewährleistet ist, dass die where-clause eine bestimmte Größe nicht überschreitet, hat das setzen dieser Property keine Nachteile.

Jobläufe pro Wochentag konfigurieren

Der Job kann so konfiguriert werden, dass er nur an bestimmten Wochentagen läuft. Hierfür ist mindestens eine der folgenden Properties zu konfigurieren.

• B3P_RUNTIME_MONDAY
• B3P_RUNTIME_TUESDAY
• B3P_RUNTIME_WEDNESDAY
• B3P_RUNTIME_THURSDAY
• B3P_RUNTIME_FRIDAY
• B3P_RUNTIME_SATURDAY
• B3P_RUNTIME_SUNDAY

Der Job läuft dann nur an Tagen, die per Property aufgeführt sind. Als Wert wird die maximale Laufzeit des Job am jeweiligen Tag in Stunden (0-23) angegeben.

Performance durch Datenbank Index

Damit das Löschen von Errors, Actions oder Messages performant ist, muss auf der Tabelle B2BBP_DATA_ERROR folgender Index existieren:

CREATE INDEX IDX_ERROR_MESSAGE_ID ON B2BBP_DATA_ERROR ( MESSAGEID ASC );