Before you can send a message to a remote service, you must first address this remote service. To do this, use the APRO (Address PROgram) call.
In distributed processing you can use the functions of both remote services and, by using openUTM’s message queuing functionality, asynchronous services. You use APRO DM (Dialog Message) to address remote dialog services. and APRO AM (Asynchronous Message) to address asynchronous services.
If a remote service is addressed in a transaction with APRO AM/DM, then a message must also be sent to the remote service in the same transaction.
Under certain circumstances you can also use APRO AM to address a dialog service via OSI TP, i.e. to address an asynchronous job to a dialog service (see "Job receiver side").
The following APRO call parameters are of relevance when a remote service is addressed:
In the KCRN (Referenced Name) field, enter the LTAC name of the remote service. The LTAC name (Local TransAction Code) is the name under which the remote service is known in the configuration of the local application. The LTAC name is assigned at generation.
If this LTAC name is already associated with a fixed partner application in the configuration you only have to specify the name for the APRO call to unambiguously determine the remote service. This is called single-step addressing. Single-step addressing is always advisable in cases where there are no alternative partner applications, e.g. because the requested service is only available from one partner application.
In two-step addressing, the partner application is specified explicitly when calling APRO:
The KCPA (Partner Application) field is used to specify the (OSI-)LPAP name of the partner application in two-step addressing. The (OSI-)LPAP (Logical Partner APplication) name is the name by which the partner application is known in the configuration of the local application. The (OSI-)LPAP name is assigned at generation. The name of a MASTER-LU61-LPAP or a MASTER-OSI-LPAP can also be specified in the KCPA field.
Two-step addressing is always advisable in cases when the requested service is available from multiple partner applications. Which partner application is selected depends on the particular situation.
If you specify the (OSI-)LPAP name of a partner application in KCPA, although the LTAC name specified in KCRN is already assigned to a partner application in the configuration, then the specification in KCPA takes precedence over the configuration assignment.
In the KCPI (Partner Identification) field, you assign an identification to the remote service for the duration of the interaction. This identification, also called the service ID, is freely selectable. However, the first character must be ">". The scope of the validity of the service ID is the local service; in other words, if two services use the same service ID at the same time, they are thus addressing different remote services. You have to specify this identification in the KCRN field for all communication calls to the addressed service. When interaction with the remote service terminates, you can use the service ID in further APRO calls to identify the same service or other services.
For the following calls you have to specify the service ID in the KCRN field:
MPUT calls to send dialog messages to the remote service
FPUT/DPUT calls to send asynchronous messages to the remote service
MGET calls to read dialog messages or status information from the remote service
MCOM BC calls to start a job complex whose basic job is directed to the remote service
CTRL calls to control OSI TP dialogs