OSI-LPAP bundles

OSI-LPAP bundles allow automatic distribution of messages over multiple OSI-LPAP partners. If a UTM application exchanges a large number of messages with a partner application, it may make sense in terms of the load balancing to start several instances of the partner application and distribute the messages among the separate instances. In a OSI-LPAP bundle, openUTM takes care of distributing the messages to the instances of the partner application.To achieve this, the program units in the APRO call must address the MASTER-OSI-LPAP.

One case of an application with this type of message distribution when a UTM application communicates via BeanConnect with a JEE conform application server. If the application server is run as a cluster application, then the messages sent to the application server should be distributed among the separate instances of the cluster (see also the "BeanConnect for openUTM" manual).

A further application scenario is communication from a standalone UTM application to a UTM cluster application. This allows messages to the UTM cluster application to be distributed across the individual node applications.

Connecting a standalone UTM application to a UTM cluster application via an OSI-LPAP bundle works in the same way as communication between two standalone UTM applications with OSI-LPAP bundles. No special issues related to clusters need to be observed.

An OSI-LPAP bundle consists of one master LPAP and several slave LPAPs. The slave LPAPs are assigned to the master LPAP during generation. In this case, OSI-CONs that belong to different slave LPAPs address the various partner applications.

Figure 9: Example of a OSI-LPAP bundle

Generating OSI-LPAP bundles

MASTER-OSI-LPAP statement in section "MASTER-OSI-LPAP - Defining the master LPAP of an OSI-LPAP bundle" Defines the name and properties of the master LPAP in a OSI-LPAP bundle:

• master-lpap-name

  Name for the master LPAP.

• APPLICATION-CONTEXT=

  Application context to be used for the communication with the remote partner.

• STATUS=

  Specifies whether messages can be sent to this LPAP bundle.

OSI-LPAP statement in section "OSI-LPAP - define an OSI-LPAP partner for distributed processing based on OSI TP" The following properties must be specified for the generation of a slave LPAP:

• lpap-name

  Name of the slave LPAP.

• BUNDLE=master-lpap-name

  Name of the master LPAP. The master LPAP specified here must be defined in a MASTER-OSI-LPAP statement. If you specify BUNDLE, this OSI-LPAP becomes a slave LPAP of the specified master LPAP.

  MASTER-OSI-LPAP master , ...
OSI-LPAP slave-lpap , BUNDLE= master , ...

• APPLICATION-CONTEXT=

  Application context to be used for the communication with the remote partner.

  All slave LPAPs of a LPAP bundle must be assigned to the same application context as the master LPAP.

OSI-CONs of LPAPs in an OSI-LPAP bundle

• Physical connections (OSI-CONs) must not be assigned to master LPAP. This means it may not be specified as an OSI-LPAP in a OSI-CON statement. The master LPAP always uses the connections assigned to the slave LPAPs.

• All OSI-CONs of all slave LPAPs of a LPAP bundle must be assigned to the same local ACCESS-POINT.

Distributing messages

The following information on distributing messages applies equally to LU6.1 and OSI TP.

Program units can address a slave LPAP as well as a master LPAP with the APRO call. APRO calls to a slave LPAP are not distributed by openUTM. APRO calls to a master LPAP are distributed as follows by openUTM:

• openUTM addresses the slave LPAPs in sequence using APRO calls sent to a master LPAP.

  • openUTM always attempts in this case to find a slave LPAP to which a connection has already been established and, if a queued message is to be sent to the partner (APRO AM), whose queue level has not been reached yet.

  • If the first APRO call to a master LPAP in a transaction is APRO DM, then openUTM only returns the return code 40Z/KD10 when there is no connection to any slave LPAP.

  • If the first APRO call to a master LPAP in a transaction is APRO AM, then openUTM only selects a slave LPAP with a cleared connection when there is no connection yet to any of the slave LPAPs. In this case the connection is initiated for the slave LPAP.

  • When searching for a slave LPAP with an established connection, a connection is initiated for every slave LPAP found that does not have a connection yet.

• All APRO calls sent to the MASTER-LPAP in a single transaction address the same slave LPAP.
  For this reason, an APRO call for a second message to a partner application may be rejected if, for example, the queue level for the slave LPAP has been exceed or the connection has been lost in the meantime.

• Messages that have already been assigned to a slave LPAP are not reassigned in sequence to another slave LPAP any more. Single exception:Asynchronous messages if MAX MOVE-BUNDLE-MSGS=YES was generated. (default is NO).

  If the connection for dialog messages is lost after the APRO call, then the dialog message is rejected just like for "normal" LPAPs and the transaction is rolled back, if necessary.

Information displayed in the KB header

The following information on the display in the KB header applies equally to LU6.1 and OSI TP.

In services started for received messages, openUTM always displays the name of the LTERM or (OSI-)LPAP through which the message was received in the KB header.

The following therefore applies for LPAP bundles:
In services started for messages received through a slave LPAP, the name of this slave LPAP is displayed in the KB header and not the name of the master LPAP.

With INIT PU you can obtain information on whether the (OSI-)LPAP in the KB header is the slave LPAP of an LPAP bundle as well as the name of the master LPAP.