Kurzbeschreibung
Der Service nimmt alle Messages aus den gegeben Channels, welche in den letzten 24 Stunden angekommen sind und startet diese neu. Sollte B3B_TARGET_CHANNEL nicht gesetzt sein wird der Service alle Nachrichten neu starten deren Channel nicht null oder „UNKNOWN“ ist. Falls erforderlich können nur Nachrichten mit einem vorgegebenen VS Status neugestartet werden.
Einrichtung
Um einen neuen Service der B2BBP hinzuzufügen, muss ein neuer Scheduler Service erstellt werden. Siehe dazu die Seite Einrichtung von Scheduler Services.
Eigenschaften (Context nicht überschreiben):
| Eigenschaft | Beschreibung | Default |
|---|---|---|
| B3P_SCHEDULER_REGISTER_CLASSNAME | org.b2bbp.service.inbound.scheduled.RestartMessageJob | |
| B3P_TARGET_CHANNEL | Komma separierte Liste von ChannelIDs der Channels, die überwacht werden sollen | |
| B3P_VS_STATE | VS Status der Nachrichten z.B. ERR; SUC, die neu gestartet werden sollen. Entweder B3P_VS_STATE oder B3P_GROUP_FORMAT muss gesetzt sein. | |
| B3P_GROUP_FORMAT | falls “true”, werden Nachrichten nach Format gruppiert neu gestartet. In diesem Fall muss die Property B3P_FORMATS gesetzt sein. Bei “false” muss die Property B3P_VS_STATE gesetzt sein. | false |
| B3P_FORMATS | Nachrichtenformate, die neu gestartet werden sollen, z.B. MSCONS;UTILMD | |
| B3P_KEEP_CHANNEL | Falls “true”, wird der aktuelle Channel explizit gesetzt. | false |
| B3P_SKIP_CHANNEL_DISTRIBUTION | Falls “true”, wird ChannelDistribution übersprungen. Falls nicht gesetzt, wird der Wert von B3P_KEEP_CHANNEL übernommen! | false |
| B3P_CHECK_DAYS | Anzahl der zu prüfenden Tage. | 1 |
| B3P_SERVICE_FETCH_MESSAGE_MAX | Maximal zu prüfende Anzahl an Nachrichten pro Lauf. | 10000 |
| B3P_RETRY_COUNT | Maximale Anzahl der durchgeführten Restarts. Unendlich wenn nicht angegeben oder 0!!! Max: 9 | [unendlich] |
| DEFAULT_PRIO | Queuepriorität die genutzt wird, wenn sie nicht im MessageContext hinterlegt ist. Beispiele: ultra, low | |
| MESSAGES_MINIMUM_AGE_IN_HOURS | So alt müssen Nachrichten mindestens sein damit Sie für den Neustart berücksichtigt werden. z.B. 3.75 | |
| B3P_DELAYS_PER_FORMAT | Mindestalter der Nachrichten in Milisekunden pro Format. z.B. 3000;1000 | |
| B3P_WAITS_PER_FORMAT | Zeit in Milisekunden, die gewartet wird, nachdem alle Nachrichten eines Formates neu gestartet wurden. z.B.10000;5000 | |
| EXECUTE_ALL_SERVICES | Wenn true: Führt für die neuzustartende Nachrichten bereits erfolgreich ausgeführte Services erneut aus. | false |
| INCLUDE_BS_STATES | In dieser Property können Bestätigungsstatus semikolonsepariert angegeben werden. (Beispiel: CTP;SSU) Es werden dann nur Nachrichten neugestartet, die den passenden Bestätigungsstatus aus dieser Liste besitzen. Ist diese Property gesetzt, wird B3P_EXCLUDE_BS_STATES ignoriert.” | |
| B3P_EXCLUDE_BS_STATES | Mit dieser Property kann man Nachrichten mit einem bestimmten Bestätigungsstatus vom Neustart ausschließen. Hierbei kann auch eine Liste von Statuskategorien angegeben werden (also z.B. CTP;SSU). | |
| B3P_CS_STATES_TO_MATCH | Mit dieser Property kann man konfigurieren, dass ausschließlich Nachrichten mit einem bestimmten Clearingstatus (CS) neugestartet werden. Hierbei kann auch eine Liste mehrerer CS angegeben werden (also z. B.: 001;800;900). | |
| B3P_EXCLUDE_CS_STATES | Nachrichten mit folgendem CS Status werden für den Neustart ignoriert. |
Es können verschiedene VS Status und CS Status angeben werden, diese sind durch ; zu trennen.
Restliche Eigenschaften müssen analog zum CRON oder DELAY Service gesetzt werden. (Beschreibung in Schulungsunterlagen)
B3P_KEEP_CHANNEL ist ein optionaler Parameter und wird normalerweise nicht gesetzt. Er sorgt dafür, dass beim Neustart der Channel immer noch der Alte ist. Dadurch ist es möglich eine Nachricht nach dem Neustarten anders auszusteuern, als im ersten Durchlauf.
Der ClearingCode neu gestarteter Nachrichten ist entweder „ARS“, falls kein B3P_RETRY_COUNT angegeben wurde oder „MRx“ wobei x die Anzahl der Startversuche sind (MR1 bedeutet also die nachricht wurde einmal vom MessageRestartService neu gestartet)
Die Priorität, mit der die Nachricht neu gestartet wird, wird aus dem MessageContext bezogen. Ist die Priorität nicht im MessageContext hinterlegt, wird der Wert aus DEFAULT_PRIO genutzt. Ist auch dieser nicht gesetzt, wird die Priorität auf „low“ gesetzt.
Um die Priorität korrekt in den MessageContext zu laden sind folgende Schritte notwendig:
- In allen Channels, in denen die Priorität wichtig ist muss eine
Action hinzugefügt werden, um die Prio aus dem MessageContext in die DB
zu persistieren (Falls im Channel bereits eine Action dieser Klasse
existiert, kann man die Property PERSIST_TECHNICAL entsprechend
anpassen):
- Name: PersistQueuePriority
- Klasse: org.b2bbp.runtime.actions.internal. PersistMessageContextAttributes
- Attribute: PERSIST_TECHNICAL=B3P_MESSAGE_PRIO (messageContext nicht überschreiben)
- Damit die Prio beim Neustart auch wieder in den MessageContext
geladen wird muss folgende GloablProperty gesetzt (bzw. erweitert)
werden:
- B3P_DYNAMIC_POPULATE=B3P_MESSAGE_PRIO
Um Nachrichten gruppiert nach BDEW Typ neu zu starten muss der Parameter B3P_GROUP_FORMAT auf true gesetzt werden. Dadurch werden die Parameter MESSAGES_MINIMUM_AGE_IN_HOURS und B3P_VS_STATE ignoriert.
Nun müssen die Parameter B3P_FORMATS, B3P_DELAYS_PER_FORMAT und B3P_WAITS_PER_FORMAT gesetzt werden. Es sind Semikolon-separierte Listen anzugeben und alle drei Listen müssen gleich viele Parameter enthalten.
Das Verhalten des Jobs ist dann wie folgt:
- Suche alle Nachrichten mit Format B3P_FORMATS[i](im obigen Beispiel MSCONS) mit Mindestalter B3P_DELAYS_PER_FORMAT[i](im obigen Beispiel 3000).
- Starte diese Nachrichten neu.
- Nachdem alle Nachrichten neu gestartet wurden, warte B3P_WAITS_PER_FORMAT[i](im obigen Beispiel 10000) Milisekunden.
- Führe die Schritte 1-3 für das nächste Format aus der Liste aus(i=i+1)(im obigen Beispiel UTILMD).
Ein spezieller Anwendungsfall dieses Service ergibt sich im Routing “REMADV Buffern”. Hier dient der Service dazu, die REMADV neuzustarten, sobald das Buffern endet.
Bekannte Bugs
Beim Einsatz des FSS-Regelwerks werden oft Clearing Codes wie “W51” gesetzt. Das konfliktiert mit den Clearing Codes, die der RestartMessageJob benutzt. Dadurch kann RestartMessageJob nicht mehr genau feststellen, wie oft die Nachricht neu gestartet wurde. Es kann dazu führen, dass Nachrichten mit solchen Clearing Codes durch den Job gar nicht neu gestartet werden.
View Me Edit Me