Show TOC Anfang des Inhaltsbereichs

Hintergrunddokumentation Queues zur asynchronen Message-Verarbeitung  Dokument im Navigationsbaum lokalisieren

Bei asynchroner Message-Verarbeitung unterscheiden sich die technischen Namen der Eingangs- und Ausgangswarteschlangen (Queues) je nach Rolle der Integration Engine als

      zentraler Integration Server

Die Integration Engine besitzt Eingangs- und Ausgangs-Queues.

      lokale Integration Engine ohne Integrationslogik

Die Integration Engine besitzt Sender- und Empfänger-Queues.

Zusätzlich werden weitere Queues für die Verarbeitung von Acknowledgment-Messages benötigt, sowie Queues für die Verarbeitung von besonders großen Messages. Letztere werden nur für die Exactly-Once-Verarbeitung benötigt (siehe Konfigurationsparameter EO_MSG_SIZE_LIMIT und EO_MSG_SIZE_LIMIT_PARALLEL der Kategorie Tuning).

Damit alle XML-Messages einschließlich Acknowledgment-Messages automatisch verarbeitet werden können, müssen Sie die von der Integration Engine benutzten Queues mit der Transaktion SMQR registrieren. Verwenden Sie hierzu die Funktion Administration Queues verwalten aus dem Menü Integration Engine.

Hinweis

Diese Funktion bietet auch einen Absprung in den Monitor für verarbeitete Messages. Springen Sie hierzu in den qRFC-Monitor (QIN-Scheduler), selektieren Sie die gewünschten generischen Queue-Namen, wählen Sie QRFC-Monitor (SMQ2), wählen Sie die gewünschten Queues zur Anzeige aus, machen Sie einen Doppelklick auf den gewünschten spezifischen Queue-Namen, und wählen Sie dann einen Queue-Eintrag (LUW) zur Anzeige aus.

Verarbeitet die LUW einzelne Messages (Funktionsbaustein SXMS_ASYNC_EXEC), werden die Messages im Monitor angezeigt.

Verarbeitet die LUW ein Message-Paket (Funktionsbaustein SXMS_ASYNC_EXEC_PACK), gelangen Sie zunächst in den Monitor für Message-Pakete. Dort werden Ihnen die in dem Paket enthaltenen Messages aufgelistet. Per Doppelklick auf eine der angezeigten Messages gelangen Sie dann in den Monitor für verarbeitete Messages.

Verarbeitet die LUW einen Integrationsprozess (Funktionsbaustein SWF_XI_MSG_RAISE_EVENT), gelangen Sie in ein Bild mit Informationen zur Prozessdefinition, zur Laufzeit, und zu Einstellungen der Eingangsverarbeitung des Prozesses.

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)

 

Sender

Eingangs

Ausgangs

Empfänger

Acknowledgment

Large Message

EO

XBTSx

XBT1x

XBT9x

XBTIx

XBT1x

XBT9x

XBTOx

XBTAx

XBTZx

XBTRx

XBTAx

XBTZx

XBTBx

XBTXx

XBTYx

XBTLx

XBTMx

EOIO

XBQSx

XBQ1x

XBQ9x

XBQIx

XBQ1x

XBQ9x

XBQOx

XBQAx

XBQZx

XBQRx

XBQAx

XBQZx

XBQBx

XBQXx

XBQYx

 

Ermittlung des Suffix

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.

Beispiel

Ermittelte Zufallszahl: 38

Queue-Name: XBTI0038

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.

Beispiel

Name des Empfängers: KUNDE_XYZ

Name verschlüsselt: 3___

Queue-Name: XBTO3___

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.

Beispiel

Name des Empfängers: KUNDE_XYZ

Name verschlüsselt: 3___

Ermittelte Zufallszahl: 17

Queue-Name: XBTO3___0017

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 (/).

Beispiel

Name der Queue aus der Anwendung: APPQUEUENAME (maximal 16 Stellen)

Name der Eingangs-Queue: XBQIAPPQUEUENAME

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.

Beispiel

Name des Empfängers: KUNDE_XYZ

Name verschlüsselt: 3___

Name der Ausgangs-Queue: XBQO3___APPQUEUENAME (maximal 24 Stellen)

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.

 

Ende des Inhaltsbereichs