Ein Auftraggeber-Vorgang kann per FPUT- oder DPUT-Aufruf einen Asynchron-Auftrag an einen fernen Asynchron-Vorgang richten (Remote Queuing). Der Auftraggeber-Vorgang kann dabei Dialog- oder Asynchron-Vorgang sein.
openUTM arbeitet bei Asynchron-Aufträgen an ferne Anwendungen mit zwei jeweils lokalen Queues: eine Queue liegt dabei in der Sender-Anwendung, die andere Queue beim Empfänger. Durch dieses Deferred Delivery-Prinzip ist das rechnerübergreifende Message Queuing mit openUTM vollständig unabhängig davon, ob gerade eine Verbindung besteht oder nicht: Falls keine Verbindung aufgebaut werden kann, bleibt der Auftrag solange in der lokalen Sender-Queue, bis eine Verbindung hergestellt ist. Nach Verbindungsaufbau gilt:
Bei LU6.1 werden die Aufträge umgehend an den Partner übertragen.
Bei OSI TP kann es noch eine bestimmte Zeit dauern, bis die Aufträge übertragen werden. Diese Zeit ist durch den in MAX CONRTIME generierten Wert beschränkt. Beachten Sie, dass bei CONRTIME=0 die Zeit auf 10 Minuten gesetzt wird.
Kommt es beim Senden eines Auftrags – also bei bestehender Verbindung - zu einem dauerhaften Fehler, so wird der Auftrag aus der lokalen Sender-Queue gelöscht, aber nicht in die entsprechende Message Queue der Partner-Anwendung eingetragen. In diesem Fall wird in der lokalen Anwendung eine Meldung K239 ausgegeben.
Zu einem dauerhaften Fehler, der zum Verlust des Auftrags führt, kommt es unter anderem, wenn der Auftrag an einen TAC gerichtet ist, der in der Partner-Anwendung gesperrt ist. Die genaue Ursache finden Sie in der Meldung K086 (LU6.1) oder K119 (OSI TP), die in der Partner-Anwendung ausgegeben wird.
Der Verlust des Auftrags kann verhindert werden, in dem für den LPAP- bzw. OSI-LPAP-Partner der lokalen Anwendung die Sicherung von Nachrichten in der lokalen Dead Letter Queue aktiviert wird, siehe Abschnitt „Dead Letter Queue".
Bild: Remote Queuing mit openUTM