Ein Service der Dateien aus der Nachrichten Queue verarbeitet

Übersicht

Der QueueService3 ist ein aktiver Service, welcher die Aufgabe hat, Nachrichten aus der Queue der B2B auszulesen und zu verarbeiten. Hierbei können mehrere QueueServices parallel arbeiten. Dies ermöglicht es, verschiedene spezialisierte QueueServices für verschiedene Nachichtengrößen zu verwenden. Nachfolgend werden einige Eigenschaften erläutert, über die der Administrator Einfluss auf das Verhalten des Services nehmen kann.

Technische Beschreibung

Klassenpfad: org.b2bbp.service.inbound.queue.QueueService3

Konfiguration

Aufteilung nach Nachrichtengrößen und die Reihenfolge der Nachrichtenverarbeitung

Nachrichten werden aufgrund ihrer Größe in 4 Gruppen eingeteilt: S (SMALL), M (MEDIUM), L (LARGE) und E (EXCLUSIVE). Die Grenzen werden über die GlobalProperty EDI_SIZES für Edifact Nachrichtung und XML_SIZES für IDOC Nachichten definiert. Dabei werden die 3 Grenzen mit einem Komma getrennt in diese Property geschrieben. Jeder Wert darf nicht größer als 2147483647 sein.

Beispiel: “100,1000,5000” => Nachrichten mit 1-99 Bytes sind SMALL, Nachrichten it 100-999 Bytes sind MEDIUM, Nachrichten mit 1000-4999 Bytes sind LARGE und Nachrichten mit 5000 und mehr Bytes sind EXCLUSIVE

Default

  • Für EDI_SIZES: 10000,500000,2500000
  • Für XML_SIZES: 100000,2000000,10000000

Bei eingehenden Nachrichten, die über AS4 empfangen werden, muss die Konfiguration der Größengruppen im B2B Message Service vorgenommen werden. Dies ist hier dokumentiert: B2B Message Service - Aufteilung nach Nachrichtengrößen

Innerhalb jeder Gruppe werden die Nachrichten nach ihrer Priorität abgearbeitet. Für Nachrichten in der Größengruppe EXCLUSIVE gilt zusätzlich, dass sie nur bearbeitet werden, wenn die Queue keine Nachrichten aus anderen Größengruppen enthält. Dies kann dazu führen, dass die E-Nachrichten sehr lange in der Queue verbleiben. Um dies zu vermeiden, kann die Grenze für die E-Gruppe so konfiguriert werden, dass keine Nachrichten dieser Gruppe zugeordnet werden, z. B. 100000,2000000,2000000000.

Verteilung der Nachrichten auf verschiedene QueueServices

Über die ServiceProperties B3P_QUEUE_SIZE_GROUP_SMALL_MAX, B3P_QUEUE_SIZE_GROUP_MEDIUM_MAX und B3P_QUEUE_SIZE_GROUP_LARGE_MAX wird die jeweilige maximale Anzahl von Nachrichten einer bestimmten Größenklasse festgelegt, die dieser QueueService pro Durchlauf verarbeitet. Hier werden ganzzahlige Eingaben erwartet. Ob ein QueueService Nachrichten der Größenklasse EXCLUSIVE verarbeitet wird über die ServiceProperty B3P_QUEUE_SIZE_GROUP_EXECUTE_EXCLUSIV gesteuert. Anders als bei den anderen Gruppen werden hier die Angaben true oder false erwartet.

Default Werte:

  • QueueSizes: 0
  • Exclusiv-Verarbeitung false

Wartezeit zwischen den Durchläufen des Service

Die Wartezeit zwischen dem Ende des vorherigen Laufs und dem Start des nächsten Laufs des QueueService lässt sich durch die ServiceProperty B3P_SERVICE_SCHEDULING_DELAY steuern. Die Angabe der Verzögerung erfolgt in Millisekunden.

Default: 1000 Millisekunden

Parallele Verarbeitung innerhalb eines QueueService

Ein QueueService kann Nachrichten in der Queue, die er verarbeitet entweder sequentiell oder parallel verarbeiten. Dies wird über die ServiceProperty B3P_SYNC_EXECUTION gesteuert.

Mögliche Werte sind:

  • true => sequentielle Verarbeitung
  • false => parallele Verarbeitung

Default: false

Handling doppelter Messages

Wird die ServiceProperty LAST_REFERENCE_ID_MAX_SIZE gesetzt, überprüft der QueueService eingehende Edifact Nachrichten auf Dopplungen. Dabei wird ein Puffer mit der konfigurierten Größe der letzten verarbeiteten Messages vorgehalten. Dafür werden die Referenznummer sowie die Ids des Absenders und des Empfängers geprüft. Sollte diese Prüfung eine Dopplung ergeben, wird die Verabreitung des Nachricht für eine in der ServiceProperty BUFFER_TIME konfigurierte Anzahl von Millisekunden pausiert. In der sequetiellen Verabreitung pausiert der QueueService für diese Zeit.

Defaults:

  • Puffern doppelter Messages: aus
  • Puffer Zeit bei eingeschaltetem Puffer: 2 Sekunden

Queue-spezifische Fehler als Systemfehler melden

Durch das Setzen der ServiceProperty LOG_QUEUE_SPECIFIC_ERRORS_IN_SYSTEM_ERRORS auf true oder false kann gesteuert werden, ob Fehler innerhalb dieses QueueService als Systemfehler gemeldet werden.

Default: true

View Me   Edit Me