Port type for direct access to an R/2 System via the CPI-C protocol.
Since here the R/2 System is always the external system, the following exceptions and restrictions apply when compared with other port types:
· The SAP 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 SAP 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 SAP system (the ALE server concept): For this purpose, the R/2 IDoc must be sent first to an SAP system and then distributed from there to the recipients via an SAP ALE server.
· IDocs are always exchanged in record types from SAP 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 .
The SAP system retrieves IDocs from or sends them to R/2 in accordance with the R/2 IDoc interface protocol, that is, the SAP system is always the active system. When retrieving IDocs, the SAP 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.
The R/2 IDoc interface expects a status confirmation for the IDocs which have been sent (that is, retrieved by the SAP system). You can configure the CPI-C port on the SAP system 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 SAP system”). Confirmation of further processing stages in the SAP system cannot be sent to the R/2 System via status records. This can be achieved using response messages modeled in process chains.
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 SAP database table TXCOM. In this way, the SAP system recognizes the R/2 System to be called (see the following graphic, where the gateway is located on the SAP system 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.