CPI-C Connection to the R/2 System 

Definition

Port type for direct access to an R/2 System via the CPI-C protocol.

Use

Since here the R/2 System is always the external system, the following exceptions and restrictions apply when compared with other port types:

·        The R/3 System is always "active”: It either retrieves IDocs from the R/2 System, or it sends IDocs to the R/2 System. Therefore in the port definition for outbound processing almost the same parameters are required as in inbound processing.

·        The R/3 System can return at most one status record for each inbound IDoc. The IDoc type SYSTAT01 cannot be used because the IDoc type is not available in the R/2 System.

·        An R/2 IDoc can only be retrieved once. Consequently, ALE distribution models (IDocs sent to several addressees) can only be implemented indirectly across an R/3 System (the ALE server concept): For this purpose, the R/2 IDoc must be sent first to an R/3 System and then distributed from there to the recipients via an R/3 ALE server.

·        IDocs are always exchanged in record types from R/3 Releases 3.0/3.1. This means that port version 2 is always entered by default and cannot be changed in the port definition.

·        The R/2 System does not support extensions or the long names used in Release 4.0. You can find out more about the possible problems from the following section: Communication with Older Releases/Subsystems or R/2 Systems .

Structure

Exchanging IDocs between R/2 and R/3

The R/3 System retrieves IDocs from or sends them to R/2 in accordance with the R/2 IDoc interface protocol, that is, R/3 is always the active system. When retrieving IDocs, the R/3 System can define which of the IDocs which are ready for dispatch are actually transferred during the connection. The main obligatory selection criterion is the port in the R/2 System. The port is a lock object in the R/2 IDoc interface. You should configure a separate port in the R/2 System for each logical system.

Sending IDoc status records from R/3 to R/2

The R/2 IDoc interface expects a status confirmation for the IDocs which have been sent (that is, retrieved by R/3). You can configure the CPI-C port on the R/3 side in such a way that status records are returned to the R/2 System for the IDocs which are received. You can choose any of the following alternatives for sending status records to the R/2 System:

·        do not send status records

·        send status records immediately when an IDoc is received

·        send the status records asynchronously via a scheduled report

Only one status record can be returned per IDoc (status “12” = “dispatch OK” = “IDoc successfully retrieved by R/3 System”). Confirmation of further processing stages in the R/3 System cannot be sent to the R/2 System via status records. This can be achieved using response messages modeled in process chains.

Communication technique

The SNA protocol LU 6.2 (SNA = System Network Architecture, on the R/2 side; LU = Logical Unit, identifies programs or devices in the SNA) forms the basis for communication. The CPI-C protocol combines the LU 6.2 commands to form a limited number of commands that can be easily used in programming (hence the name CPI-C = Common User Programming Interface - Communication). Communication takes place via a gateway which recognizes the SNA architecture and assigns the symbolic name of the target system to a logical unit in a sideinfo file. The name of the gateway and the symbolic name of the target system are located in the R/3 database table TXCOM. In this way, the R/3 System recognizes the R/2 System to be called (see the following graphic, where the gateway is located on the R/3 side).

SNA, LU 6.2 and CPI-C were developed by IBM. The CPI-C protocol used by SAP is a modification of the original IBM CPI-C.

You will find a detailed description of communication with the R/2 IDoc interface in the R/2 manual, S53.2, Chapter 8.