OSI-LPAP-Bündel ermöglichen eine automatische Verteilung von Nachrichten auf mehrere OSI-LPAP-Partner. Soll eine UTM-Anwendung sehr viele Nachrichten mit einer Partner-Anwendung austauschen, kann es für die Lastverteilung sinnvoll sein, mehrere Instanzen der Partner-Anwendung zu starten und die Nachrichten auf die einzelnen Instanzen zu verteilen. In einem OSI-LPAP-Bündel übernimmt openUTM die Verteilung der Nachrichten an die Instanzen der Partner-Anwendung. Dazu müssen die Teilprogramme im APRO-Aufruf das MASTER-OSI-LPAP adressieren.
Ein Anwendungsfall für eine solche Verteilung der Nachrichten ist z.B. die Kommunikation einer UTM-Anwendung über BeanConnect mit einem JEE konformen Application Server. Wird der Application Server als Cluster-Anwendung betrieben, sollten die Nachrichten an den Application Server auf die einzelnen Instanzen des Clusters verteilt werden (siehe auch Handbuch „BeanConnect for openUTM“).
Ein weiterer Anwendungsfall ist die Kommunikation einer stand-alone UTM-Anwendung mit einer UTM-Cluster-Anwendung. Die Nachrichten an die UTM-Cluster-Anwendung können somit auf die einzelnen Knoten-Anwendungen verteilt werden.
Ein OSI-LPAP-Bündel besteht aus einem Master-LPAP und mehreren Slave-LPAPs. Die Slave-LPAPs werden dem Master-LPAP bei der Generierung zugeordnet. Die OSI-CONs von verschiedenen Slave-LPAPs adressieren dabei die verschiedenen Partner-Anwendungen.
Bild 9: Beispiel OSI-LPAP-Bündel
OSI-LPAP-Bündel generieren
 | MASTER-OSI-LPAP-Anweisung im Abschnitt "MASTER-OSI-LPAP - Master-LPAP eines OSI-LPAP-Bündels definieren" |
master-lpap-name
Name für das Master-LPAP.
APPLICATION-CONTEXT=
Application Context, der für die Kommunikation mit dem entfernten Partner genutzt werden soll.
STATUS=
gibt an, ob Nachrichten an dieses LPAP-Bündel gesendet werden können.
| OSI-LPAP-Anweisung im Abschnitt "OSI-LPAP - OSI-LPAP-Partner für verteilte Verarbeitung über OSI TP definieren" |
lpap-name
Name des Slave-LPAP.
BUNDLE=master-lpap-name
Name des Master-LPAP. Das Master-LPAP, das hier angegeben wird, muss in einer Anweisung MASTER-OSI-LPAP definiert sein. Durch Angabe von BUNDLE wird dieses OSI-LPAP zum Slave-LPAP des angegebenen Master-LPAP.
MASTER-OSI-LPAPmaster, ...
OSI-LPAPslave-lpap, BUNDLE=master, ...APPLICATION-CONTEXT=
Application Context, der für die Kommunikation mit dem entfernten Partner genutzt werden soll.
Allen Slave-LPAPs eines LPAP-Bündels muss der gleiche Application Context wie dem Master-LPAP zugeordnet sein.
OSI-CONs von LPAPs eines OSI-LPAP-Bündels
Einem Master-LPAP dürfen keine physikalischen Verbindungen (OSI-CONs) zugeordnet werden. Es darf also nicht als OSI-LPAP in einer OSI-CON-Anweisung angegeben werden. Das Master-LPAP nutzt immer die Verbindungen, die den Slave-LPAPs zugeordnet sind.
Alle OSI-CONs aller Slave-LPAPs eines LPAP-Bündels müssen dem gleichen lokalen ACCESS-POINT zugeordnet sein.
Verteilung von Nachrichten
Teilprogramme können mit dem APRO-Aufruf sowohl ein Slave-LPAP als auch ein Master-LPAP adressieren. APRO-Aufrufe an ein Slave-LPAP werden von openUTM nicht weiter verteilt. APRO-Aufrufe an ein Master-LPAP verteilt openUTM wie folgt:
Über APRO-Aufrufe, die an ein Master-LPAP gerichtet wurden, adressiert openUTM reihum die Slave-LPAPs.
openUTM versucht dabei immer, ein Slave-LPAP zu finden, zu dem bereits eine Verbindung aufgebaut ist und, wenn eine Asynchron-Nachricht an den Partner gesendet werden soll (APRO AM), dessen Queue-Level noch nicht erreicht ist.
Ist der erste APRO-Aufruf an ein Master-LPAP in einer Transaktion ein APRO DM, liefert openUTM nur dann den Returncode 40Z/KD10, wenn zu keinem Slave-LPAP eine Verbindung besteht.
Ist der erste APRO-Aufruf an ein Master-LPAP in einer Transaktion ein APRO AM, wählt openUTM nur dann ein Slave-LPAP mit nicht aufgebauter Verbindung, wenn zu keinem der Slave-LPAPs bereits eine Verbindung besteht. In diesem Fall wird für das Slave-LPAP der Verbindungsaufbau angestoßen.
Bei der Suche nach einem Slave-LPAP mit aufgebauter Verbindung wird für jedes Slave-LPAP, zu dem keine Verbindung aufgebaut ist, ein Verbindungsaufbau initiiert.
Alle APRO-Aufrufe, die innerhalb einer Transaktion an das MASTER-LPAP gerichtet werden, adressieren das gleiche Slave-LPAP.
Deswegen kann ggf. ein APRO-Aufruf für eine zweite Nachricht an eine Partner-Anwendung abgelehnt werden, wenn z.B. in der Zwischenzeit der Queue-Level für das Slave-LPAP überschritten wurde oder die Verbindung verloren gegangen ist.Nachrichten, die bereits einem Slave-LPAP zugeordnet wurden, werden in der Folge nicht mehr an ein anderes Slave-LPAP umgehängt.
Einzige Ausnahme:
Asynchron-Nachrichten, sofern MAX MOVE-BUNDLE-MSGS=YES generiert wurde (Standard ist NO).Geht für Dialog-Nachrichten die Verbindung nach dem APRO-Aufruf verloren, wird die Dialog-Nachricht wie bei „normalen“ LPAPs verworfen und die Transaktion ggf. zurückgesetzt.
Anzeige im KB-Kopf
In Vorgängen, die für empfangene Nachrichten gestartet werden, zeigt openUTM im KB-Kopf immer den Namen des LTERM bzw. (OSI-)LPAP an, über das die Nachricht empfangen wurde.
Für LPAP-Bündel gilt also:
In Vorgängen, die für Nachrichten gestartet werden, die über einen Slave-LPAP empfangen wurden, wird im KB-Kopf der Name dieses Slave-LPAPs angezeigt und nicht der Name des Master-LPAPs.
Sie können sich mit INIT PU darüber informieren, ob das (OSI-)LPAP im KB-KOPF Slave-LPAP eines LPAP-Bündels ist und wie das Master-LPAP heißt.