Queues zur asynchronen Message-Verarbeitung

Bei der Namensgebung dieser Queues gelten die nachfolgenden Konventionen für das Präfix. Hierbei steht EO für Quality-of-Service Exactly Once und EOIO für Quality-of-Service Exactly Once In Order.

Name der Queues (maximal 24 Stellen lang)

Wenn Sie das Switch-Verfahren zur Überserialisierung der EOIO-Queues verwenden, wird ein neues Set von EOIO-Queues erzeugt mit dem Präfix XB2 (statt XBQ). Zusätzlich werden die Fehlerqueues XBQE, XBQF und XBQG angelegt.

Weitere Informationen: Anzahl der EOIO-Queues ändern .

Das Suffix x des Queue-Namens wird je nach Zustellungsart unterschiedlich ermittelt, wobei das Suffix bei den Sender-, Empfänger- und Eingangs--Queues jeweils auf die gleiche Art und Weise ermittelt wird.

Zustellungsart EO

Bei der Zustellungsart EO wird zur Ermittlung des Suffix der Sender-, Empfänger- und Eingangs-Queues mit einem Zufallsalgorithmus eine vierstellige Zahl zur Ergänzung des Queue-Namens generiert. Somit können mehrere Messages parallel in verschiedenen Queues verarbeitet werden.

Den für den Zufallsalgorithmus gültigen Bereich können Sie über den Konfigurationsparameter EO_INBOUND_PARALLEL der Kategorie Tuning bestimmen. Mit Hilfe der Subparameter SENDER, CENTRAL und RECEIVER können Sie separate Bereiche für die Sender-Queue, die Eingangs-Queue und die Empfänger-Queue festlegen.

Auf dem zentralen Integration Server werden die Messages nach der Eingangsverarbeitung erneut persistiert und zum Versenden an die ermittelten Empfänger eingeplant. Um ein Blockieren von Messages zu vermeiden, werden diese nach Empfängern gebündelt und in die den jeweiligen Empfängern zugeordneten Ausgangs-Queues gestellt. Die jeweilige Queue wird über eine vierstellige Verschlüsselung des Empfängernamens ermittelt.

Tritt bei der Verarbeitung ein Fehler auf, der einen manuellen Restart verlangt, wird die entsprechende Message aus der Queue entfernt und die nachfolgenden Messages werden weiter verarbeitet. Tritt ein Fehler auf, bei dem die Message automatisch neu gestartet wird (zum Beispiel bei Verbindungsproblemen zum Empfänger), blockiert die Message nach dem letzten (erfolglosen) Versuch die Queue, um zu verhindern, dass die nachfolgenden Messages auf den gleichen Fehler laufen.

Gehen viele Messages an den gleichen Empfänger, können Sie mit dem Konfigurationsparameter EO_OUTBOUND_PARALLEL der Kategorie Tuning einstellen, ob Sie die Messages parallel in verschiedenen Queues verarbeiten möchten. Auch hier wird über einen Zufallsalgorithmus eine vierstellige Zahl zur Ergänzung des Queue-Namens generiert. Hierzu müssen Sie in der Spalte Subparameter den Empfänger sowie in der Spalte Wert den für den Zufallsalgorithmus gültigen Bereich eingeben.

Sollen prinzipiell alle Messages in parallelen Ausgangs-Queues verarbeitet werden, geben Sie mit dem Konfigurationsparameter nur den Bereich für den Zufallsalgorithmus an, ohne einen speziellen Empfänger einzugeben.

Nach erfolgreichem Versenden wird eine Message erneut persistiert. Im Zielsystem führt die Integration Engine nach erfolgreicher Verarbeitung ein implizites Datenbank-Commit aus. Tritt während der Verarbeitung ein Fehler auf, führt sie ein implizites Datenbank-Rollback durch.

Zustellungsart EOIO

Zur Ermittlung des Suffix der Sender-, Empfänger- und Eingangs-Queues wird der von der Anwendung mitgelieferte Queue-Namen herangezogen. Dieser Name darf höchstens 16 Stellen lang sein und wird an das Präfix des Queue-Namens angehängt. Erlaubte Zeichen sind Ziffern (0 bis 9), Großbuchstaben (A bis Z), sowie Unterstrich (_) und Schrägstrich (/).

Zum Bündeln von Messages nach Empfänger wird auf dem zentralen Integration Server der Name der entsprechenden Ausgangs-Queue ermittelt. Dies geschieht über den Namen des ermittelten Empfängers . Der Name der Anwendungsqueue wird in diesem Fall mit übernommen.

Eingehende Messages mit gleichem Empfänger werden in der gleichen Reihenfolge verarbeitet wie sie eingegangen sind. In dieser Reihenfolge werden sie auch an ihre jeweiligen Empfänger verschickt, da sie aufgrund des gleichen, aus der Anwendung mitgelieferten Queue-Namens in die gleiche Ausgangs-Queue gestellt werden.

Tritt ein Fehler in der Verarbeitung auf, blockiert die fehlerhafte Message die Queue, um die Reihenfolge der Verarbeitung zu garantieren.

Bei unterschiedlichen Empfängern kann die Reihenfolge jedoch abweichen.

Nach erfolgreichem Versenden wird eine Message erneut persistiert. Im Zielsystem führt die Integration Engine nach erfolgreicher Verarbeitung ein implizites Datenbank-Commit durch; andernfalls ein implizites Datenbank-Rollback.