BS2000 R/2 Host: UTM-UTM Connection 
BS2000 R/2 Host: UTM-UTM Connection
Purpose
No CPI-C interface is available in BS2000. Alternatively, you can use program-to-program communication between ABAP programs and UTM subprograms based on UTM-VTV. This means that two R/2 Systems under UTM are connected.
Implementation considerations
Communication can be initiated by both sides. As UTM does not support calls equivalent to the CPI-C calls Initalize, Allocate, Accept and Deallocate, these calls need not be used or must be simulated as follows:
CPI-C call in ABAP |
UTM call |
COMMUNICATION ALLOCATE |
APRO |
COMMUNICATION SEND |
MPUT |
COMMUNICATION RECEIVE |
MGET |
To create UTM-D subprograms, you will require the corresponding UTM guides.
The rules for distributed transaction processing must be adhered to.
The following examples are discussed:
Initiator: R/2 System Initiator: Non-SAP SystemFeatures
Both the sending and the receiving program can be run for test purposes in the same SAP system. For the test, you do not need a second application (see the generation notes).
A special feature contained only in UTM implementation is the possibility of asynchronous communication. Unlike synchronous communication, which always involves sending a message (CMSEND) and then waiting for a reply (CMRECEIVE), asynchronous communication only involves sending.
This offers a series of advantages:
Up to now, the asynchronous procedure has been used predominantly for sending messages to the SAP system. The procedure is based on a special feature of UTM-D, that is asynchronous partial messages from the sender can be presented to the receiver as individual messages. Asynchronous communication from the external system to the SAP system is operated as follows:
You send a logon message (in which you specify the receiving report), and can then send as many data messages as required up to the maximum number of partial messages possible (around 32000 Bytes). The requirements here are simply large enough page pools in the KDCFILEs of sender and receiver.
Constraints
ABAP programs, which contain the COMMUNICATION statements, cannot run in debugging mode.
Possible intermediate dialogs in this mode violate the rules for distributed transaction processing with UTM-D. Violation results in a PEND ER and task termination.
Free communication is restricted in that no message can begin with the string FREE because this is used for the DEALLOCATE simulation.
As the statement DEALLOCATE is not supported in UTM, it must be simulated. From the point of view of the SAP system on the host, there are two synchronous processing scenarios:
If the PLU performs a DEALLOCATE statement, which follows a RECEIVE, this must be made known to the SLU. A FREE message is created in the service routine Deallocate and sent to the SLU. At the same time, terminal output from the PLU is delayed until the response required by the UTM protocol is received from the SLU.
If, for example, an SLU encounters an error situation, in which it is preferable to continue communication, the SLU must end communication using DEALLOCATE.
The SLU has two possible courses of action:
If DEALLOCATE is called, the FREE message is generated automatically. You cannot send a message and then perform a DEALLOCATE call.
If the SLU is not an SAP System, a process termination by PEND FI of the SLU is interpreted as DEALLOCATE by the SAP System.
A PLU can only close itself (PEND FI) after all its SLUs are closed. Otherwise, this would cause a UTM task termination with 87Z and KS01 (see bottom-up strategy in the UTM documentation).