Mit Hilfe der RemadvBufferBeforePaydayAction kann eine ausgehende REMADV Edifact in der B2B gebuffert werden. Diese wird dann erst kurz vor ihrer Frist verschickt. Hierfür muss ein zugehöriger RestartMessageJob laufen.
Eine REMADV referenziert über ihr Dokumentnummer DOC+2+0 eine INVOIC Rechnung BGM+2+0. Diese enthält ein Fälligkeitsdatum DTM[1+0=”265”]+1+1. Bis zu diesem muss die REMADV verschickt worden sein. Eine REMADV kann im Allgemeinen mit mehreren DOC-Segmenten mehrere INVOICs referenzieren. Falls mehrere Fälligkeitsdaten ermittelt werden, wird im weiteren Verlauf das frühestmögliche Datum benutzt.
Im Folgenden wird die Konfiguration innerhalb der B2B beschrieben.
Datenbank
Für dieses Feature muss die Tabelle B2BBP_DATA_SCHEDULEMESSAGE angelegt werden. (vgl Anhang)
org.b2bbp.runtime.actions.internal.RemadvBufferBeforePaydayAction
Zum Buffern ist die REMADV in einen Channel zu steuern, in dem die RemadvBufferBeforePaydayAction ausgeführt wird, bevor die Nachricht verschickt wurde. Die Action wirft gezielt eine ActionException um die Verarbeitung anzuhalten. Die Action erstellt einen Datenbankeintrag mit dem Zeitpunkt, an dem das Buffern enden soll (im Folgenden Schedulepunkt genannt). Je nach Konfiguration ändert sie den Verarbeitungsstatus der Nachricht und setzt einen ClearingCode.
Konfiguration der Action
- HOURS_BEFORE_PAYDAY hier wird die Anzahl der Stunden vor dem Fälligkeitsdatum angegeben. In Kombination mit einem konkreten Fälligkeitsdatum ergibt dies den Schedulepunkt. Ab diesem Zeitpunkt kann die Nachricht automatisch mit dem MessageRestartJob neugestartet werden.
- PAYDAY_SEGMENT hier wird konfiguriert, über welches Segment das Fälligkeitsdatum ermittelt wird. Mögliche Werte sind: INVOIC_DTM_265 (default), REMADV_DTM_137.
- Die weitere Konfiguration der Action erfolgt analog zur
MessageBufferActionFirstTime.
- B3P_FORMAT_VALUES darf nicht gesetzt werden. Sie wird automatisch als REMADV interpretiert.
- B3P_FORMAT_VALUE muss das Format der verarbeiteten Nachricht enthalten. Hier kann z.B. folgender Ausdruck eingetragen werden: ${template(&(this.FORMAT.type))}
- B3P_VS_STATE Hier sollte ein Buffer-Status gesetzt sein, der vom zugehörigen RestartMessageJob aufgegriffen werden sollte.
- B3P_CLEARING_STATUS Es sollte ein Clearingstatus konfiguriert werden, sodass die Nachricht bei einem Neustart nicht wieder in die RemadvBufferBeforePaydayAction läuft.
- EXPECTED_CLEARING_STATE Die Nachricht wird nicht gebuffert, wenn sie den hier angegebenen Clearingstatus hat.
org.b2bbp.service.inbound.scheduled.RestartMessageJob
Dieser SchedulerRegisterService wird in regelmäßigen Abständen (z.B. jede Stunde) ausgeführt. Wenn zur Ausführung der Schedulepunkt einer REMADV überschritten wurde, wird diese neugestartet. Mit einem geeigneten Clearingcode erfolgt der Neustart in einem Channel, von dem aus die Nachricht verschickt werden kann.
Konfiguration des Jobs
- SCHEDULE_POLICY Hiermit wird das Verhalten in Bezug auf den
Schedulepunkt konfiguriert. Mögliche Werte sind:
- ALL: (default, hier ungeeignet) Beachtet die Tabelle beim Restart nicht. Alle ermittelten Nachrichten werden neugestartet, unabhängig vom Schedulepunkt.
- EXCLUDE_WAITING: (empfohlen) startet alle ermittelten Nachrichten neu, deren Schedulepunkt überschritten wurde sowie alle ermittelten Nachrichten, die NICHT in der ScheduleMessage Tabelle hinterlegt sind. Es werden also nur die Nachrichten ausgeschlossen, die in der Tabelle hinterlegt sind, ihren Schedule-Punkt aber noch nicht überschritten haben.
- ONLY_READY: startet nur die ermittelten Nachrichten neu, deren Schedulepunkt überschritten wurde. Nachrichten, die keinen SchedulePunkt besitzen, werden nicht neugestartet.
- B3P_VS_STATE Hier ist der Bufferstatus anzugeben.
- Zur weiteren Konfiguration des Jobs vergleiche die Job-Doku.
org.b2bbp.service.inbound.scheduled.FreeTableScheduleMessageService
Mit diesem SchedulerRegisterService kann der Inhalt der Tabelle
B2BBP_DATA_SCHEDULEMESSAGE gelöscht werden, sobald er nicht mehr von
Nutzen ist.
Das bedeutet alle Einträge, die ihren Schedulepunkt überschritten haben
und nicht im Bufferstatus sind (weil sie automatisch oder manuell
neugestartet wurden), werden gelöscht.
Konfiguration des Jobs
- Es gelten die üblichen Regeln zur Konfiguration eines SchedulerRegisterServices.
- SCHEDULE_VS Hier ist der Bufferstatus anzugeben.
Anhang
SQL-Script zum Anlegen der Tabelle:
CREATE TABLE
B2BBP_DATA_SCHEDULEMESSAGE (
messageId VARCHAR (100) NOT NULL
,wait TIMESTAMP
,state VARCHAR (100)
,PRIMARY KEY (messageId)
,FOREIGN KEY (messageId) REFERENCES B2BBP_DATA_MESSAGE (messageId)
ON DELETE CASCADE
);
CREATE INDEX state_wait ON b2bbp_data_schedulemessage (state,wait);