RSS Feed (xml)
THE CPI-C COMMUNICATION INTERFACE :
The SAP CPI-C interface allows ABAP programs in an R/3 or an R/2 System and external C programs to communicate with each other and exchange data.
Communication via CPI-C is necessary if RFC is not available.
CPI-C (Common Programming Interface for Communications) is a standardized program-to-program communication interface that originated at IBM. It consists of a set of calls with which two programs can communicate with each other.
SAP supports the CPI-C interface for ABAP and C programs.
REMOTE DESTINATIONS:
To start communication with a partner using CPI-C, the active program has to have an entry in the side information table (sideinfo entry). This entry contains all of the necessary communication parameters.
For each remote partner you want to call you must have a corresponding sideinfo entry. These sideinfo entries are also known as 'symbolic destinations'.
The sideinfo table in the SAP R/3 System is called TXCOM. You maintain it using Transaction SM54.
To start a communication between two R/3 Systems, you need an entry in the side info table TXCOM in the active (source) system.
Contents:
Dest : Any logical name (name of the sideinfo entry)
Prot: ' I ' (protocol type for R/3-R/3 connection)
GW host: Host on which the requisite gateway is running
GW Service : TCP/IP service for gateway to be used
(If the two fields GW host and GW service are not set with values, the default gateway of the current application server is used when making the connection.)
LU : Application server of the passive R/3 System (target system)
TP: TCP/IP service of the dispatcher of the passive R/3 System (target system)
To communicate between an R/3 System and an IBM R/2 System, you need an SNA gateway (SAP Gateway with SNA functions), on which an LU6.2 product is running as well as TCP/IP. We recommend installing the SNA gateway as a dedicated standalone gateway that can be used by various R/3 application servers to communicate with SNA LU6.2 systems.
To connect to an IBM R/2 System from an R/3 System, you need an entry in the sideinfo table TXCOM in the R/3 System, and an entry in the sideinfo table of the SNA Gateway.
TXCOM entry:
Dest : Name of sideinfo entry (must match with name of corresponding gateway sideinfo
entry)
Prot : ' C ' (Protocol type for R/3-R/2 connection)
GW host / GW service : Host and TCP/IP service of the SNA gateway
LU / TP: No meaning
Sideinfo entry on the gateway (see diagram): Contains the entry name (must match the corresponding TXCOM entry), and SNA entries about Logical Unit (LU) for the R/2 host (remotely called), and the R/2 task handler (TP = X1SA) (For information on maintaining the gateway sideinfo table, see the online documentation)
You can also install the SNA gateway on the host side. The advantage of running the SNA gateway on the IBM host is that you can use existing TCP/IP and LU6.2 software for the gateway on the host side.
To communicate between an R/3 System and a Siemens R/2 System, you need an SAP gateway running on the Siemens host that can be addressed using TCP/IP.
(TCP/IP functions on the host side are available from BS2000 version 10, DCAM version 11.)
You can operate the host gateway with or without sideinfo.
(Setting in host file SAPGW.RSPARAM , parameter bs2/use_sideinfo [0,1] )
You may have to maintain a corresponding sideinfo entry for the host gateway.
Refer to the documentation for maintaining the gateway sideinfo table.
To connection an R/3 System to a Siemens R/2 System, you need an entry in the sideinfo table TXCOM in the R/3 System.
TXCOM entry:
Dest : Name of the DCAM or UTM application (SAP System) to be called by the gateway or name of the gateway side info entry.
Prot: ' C ' (Protocol type for R/3-R/2 connection)
GW host / GW service : Host name / TCP/IP service of the host gateway
LU / TP : No meaning
UNIX: Calling an external program over the SAP gateway occurs with the user that started the gateway (for example, t79adm). This user must have the correct start authorization.
If the SAP gateway does not run on the same host as the external program, it is started by remote shell from the gateway. The user who started the SAP gateway must also exist on the host of the external program. (The program is called in its name). The .rhost (remote shell authorization) on the remote machine must also have a corresponding entry.
OS/2 : As with UNIX, but without user ID.
NT : Like OS/2, the SAP gateway must run on the same host as the external program because the remote shell function with Windows NT.
LU6.2 systems:
You can also reach external LU6.2 systems using the SAP SNA gateway. For example, you can call a Cobol program running in CICS using CPI-C from an R/3 System. The sideinfo table is maintained in the same way as the R/3 -->R/2 (IBM) communication scenario which you see in the online documentation.
Windows 3.1 , WfW :
- No CPI-C
- RFC only for the current front end
USING CPI-C IN COMMUNIATIONS :
The program that initiates the connection is called the active program, or client.
The program that is called is known as the passive program, or server.
To start a CPI-C connection, the active program must initialize it, that is, use a CPI-C call to read the necessary communication parameters from the corresponding sideinfo entry.
These parameters are then stored under a conversation ID (output of the CPI-C call) and are used when the connection is made. After being accepted by the target program the connection is available for data exchange.
CPI-C is a half-duplex communication method, that is, only one side may send data at a time.
Once the passive program has accepted the communication, the active program may send data first, while the passive program has to wait for data using a receive call.
CPI-C transmission is asynchronous. The send buffer is transmitted, along with permission to send, when the sending side submits its next receive command.
The connection may only be closed by the program that is currently permitted to send data (otherwise data may be lost). The partner program waiting with the receive command then receives the corresponding return code (18).
The term 'ping pong' describes the communication method described above, in which an acknowledgement is sent after each data record.
In contrast to the 'ping pong' method, 'multisend' sends a series of data records before receiving a single acknowledgement at the end.
Comparison of the two communication methods:
The ping pong method involves more work because you are dealing with single records and individual acknowledgements, whereas multisend uses a single asynchronous send, and only has to wait for one overall acknowledgement.
However, ping pong provides you with better control of your data. If the communication is broken (communication error, or the receiving program crashes - return code 17), you always know, if you are using ping pong, which records have arrived in the target system, which have been processed, and where you need to resume processing.
The multisend method, on the other hand, also returns the code 17, but does not know which records have been received, and if they have been fully or partially processed, or not processed at all.
Therefore use the ping pong method where each data record contains, for example, the data for one transaction.
You use the following ABAP statements to run a CPI-C (ABAP) connection:
COMMUNICATION INIT Initialize connection
COMMUNICATION ALLOCATE Make (allocate) connection
COMMUNICATION ACCEPT Accept connection
COMMUNICATION SEND Send data
COMMUNICATION RECEIVE Receive data
COMMUNICATION DEALLOCATE Close connection
External C programs use the same calls to communicate with ABAP programs using CPI-C.
Although the syntax of the calls is different in C (CMINIT, CMALLC, CMACCP, CMSEND, CMRCV, CMDEAL), their functions are the same as the corresponding ABAP calls.
The return code of a CPI-C call in ABAP is always placed in the field SY-SUBRC. However, it can also be placed in the RETURNCODE parameter of the CPI-C call itself.
As well as the return code, some CPI-C calls also return special parameters containing extra information about, for example, data transfer and which side is entitled to send data.
The return codes and return parameters of CPI-C calls are stored as hexadecimal codes. When you query the codes, you should use meaningful constants instead of the hex codes.
Use IF RC = CM_DEALLOCATED_NORMAL instead of if RC = 18 to close the connection from the partner side.
The CPI-C constants are contained in the standard ABAP include RSCPICDF.
The most important return codes are:
'0000'( CM_OK ) :Connection OK
'0011'( CM_DEALLOCATED_ABEND ) :Connection terminated
'0012'( CM_DEALLOCATED_NORMAL ) :Connection from partner terminated normally
'0013'( CM_PARAMETER_ERROR ) :Invalid conversation ID in CPI-C call
'0014'( CM_PRODUCT_SPECIFIC_ERROR ) :Invalid sideinfo entry in CMINIT call
'0019'( CM_PROGRAM_STATE_CHECK ) :Send command rejected due to missing send authorization
COMMUNICATION INIT This is used to initialize the CPI-C connection.
(Preparing the connection)
Entry:
DESTINATION Name of sideinfo entry
Output:
ID Conversation ID This indicates the communication partners for the specified sideinfo entry.
It is used until the next connection is made and is at the same time the name of the connection.
RETURNCODE Return code of the call is always stored in SY-SUBRC; can be used in additional fields.
This parameter is optional.
The fields listed in the INIT call must have the following types:
dest C8
convid C8
rc X2
Legend: lowercase + cursive --> ABAP field
underlined --> Entry variable
[ ... --> optional entry
COMMUNICATION ALLOCATE builds the CPI-C connection and the corresponding partner program is started. You must specify the conversation ID returned by the INIT call.
For a valid connection to be established, the called program must accept the connection using the COMMUNICATION ACCEPT statement. The ACCEPT call returns the conversation ID of the connection and a return code. This must be the first statement in the passive program.
After the ACCEPT call from the side that was called, the active program has the send permission. The passive program must first receive.
In the send command, you can send a data packet of up to 30000 bytes.
Parameters:
ID Conversation ID
BUFFER Send buffer (max 30000 bytes)
LENGTH Length of the packet you want to send (optional; if entries are missing, the entire send buffer is sent) The field must have type P.
Output:
RETURNCODE
If a program sends without having permission, the return code is 25 (Hex 19).
FOR RELATED POSTS SEE BELOW.
abap communication interface 1
Interface programming part two
Interface programming for abap part three
communication interface part four
Interface programming part five
communication interface part six
The SAP CPI-C interface allows ABAP programs in an R/3 or an R/2 System and external C programs to communicate with each other and exchange data.
Communication via CPI-C is necessary if RFC is not available.
CPI-C (Common Programming Interface for Communications) is a standardized program-to-program communication interface that originated at IBM. It consists of a set of calls with which two programs can communicate with each other.
SAP supports the CPI-C interface for ABAP and C programs.
REMOTE DESTINATIONS:
To start communication with a partner using CPI-C, the active program has to have an entry in the side information table (sideinfo entry). This entry contains all of the necessary communication parameters.
For each remote partner you want to call you must have a corresponding sideinfo entry. These sideinfo entries are also known as 'symbolic destinations'.
The sideinfo table in the SAP R/3 System is called TXCOM. You maintain it using Transaction SM54.
To start a communication between two R/3 Systems, you need an entry in the side info table TXCOM in the active (source) system.
Contents:
Dest : Any logical name (name of the sideinfo entry)
Prot: ' I ' (protocol type for R/3-R/3 connection)
GW host: Host on which the requisite gateway is running
GW Service : TCP/IP service for gateway to be used
(If the two fields GW host and GW service are not set with values, the default gateway of the current application server is used when making the connection.)
LU : Application server of the passive R/3 System (target system)
TP: TCP/IP service of the dispatcher of the passive R/3 System (target system)
To communicate between an R/3 System and an IBM R/2 System, you need an SNA gateway (SAP Gateway with SNA functions), on which an LU6.2 product is running as well as TCP/IP. We recommend installing the SNA gateway as a dedicated standalone gateway that can be used by various R/3 application servers to communicate with SNA LU6.2 systems.
To connect to an IBM R/2 System from an R/3 System, you need an entry in the sideinfo table TXCOM in the R/3 System, and an entry in the sideinfo table of the SNA Gateway.
TXCOM entry:
Dest : Name of sideinfo entry (must match with name of corresponding gateway sideinfo
entry)
Prot : ' C ' (Protocol type for R/3-R/2 connection)
GW host / GW service : Host and TCP/IP service of the SNA gateway
LU / TP: No meaning
Sideinfo entry on the gateway (see diagram): Contains the entry name (must match the corresponding TXCOM entry), and SNA entries about Logical Unit (LU) for the R/2 host (remotely called), and the R/2 task handler (TP = X1SA) (For information on maintaining the gateway sideinfo table, see the online documentation)
You can also install the SNA gateway on the host side. The advantage of running the SNA gateway on the IBM host is that you can use existing TCP/IP and LU6.2 software for the gateway on the host side.
To communicate between an R/3 System and a Siemens R/2 System, you need an SAP gateway running on the Siemens host that can be addressed using TCP/IP.
(TCP/IP functions on the host side are available from BS2000 version 10, DCAM version 11.)
You can operate the host gateway with or without sideinfo.
(Setting in host file SAPGW.RSPARAM , parameter bs2/use_sideinfo [0,1] )
You may have to maintain a corresponding sideinfo entry for the host gateway.
Refer to the documentation for maintaining the gateway sideinfo table.
To connection an R/3 System to a Siemens R/2 System, you need an entry in the sideinfo table TXCOM in the R/3 System.
TXCOM entry:
Dest : Name of the DCAM or UTM application (SAP System) to be called by the gateway or name of the gateway side info entry.
Prot: ' C ' (Protocol type for R/3-R/2 connection)
GW host / GW service : Host name / TCP/IP service of the host gateway
LU / TP : No meaning
UNIX: Calling an external program over the SAP gateway occurs with the user that started the gateway (for example, t79adm). This user must have the correct start authorization.
If the SAP gateway does not run on the same host as the external program, it is started by remote shell from the gateway. The user who started the SAP gateway must also exist on the host of the external program. (The program is called in its name). The .rhost (remote shell authorization) on the remote machine must also have a corresponding entry.
OS/2 : As with UNIX, but without user ID.
NT : Like OS/2, the SAP gateway must run on the same host as the external program because the remote shell function with Windows NT.
LU6.2 systems:
You can also reach external LU6.2 systems using the SAP SNA gateway. For example, you can call a Cobol program running in CICS using CPI-C from an R/3 System. The sideinfo table is maintained in the same way as the R/3 -->R/2 (IBM) communication scenario which you see in the online documentation.
Windows 3.1 , WfW :
- No CPI-C
- RFC only for the current front end
USING CPI-C IN COMMUNIATIONS :
The program that initiates the connection is called the active program, or client.
The program that is called is known as the passive program, or server.
To start a CPI-C connection, the active program must initialize it, that is, use a CPI-C call to read the necessary communication parameters from the corresponding sideinfo entry.
These parameters are then stored under a conversation ID (output of the CPI-C call) and are used when the connection is made. After being accepted by the target program the connection is available for data exchange.
CPI-C is a half-duplex communication method, that is, only one side may send data at a time.
Once the passive program has accepted the communication, the active program may send data first, while the passive program has to wait for data using a receive call.
CPI-C transmission is asynchronous. The send buffer is transmitted, along with permission to send, when the sending side submits its next receive command.
The connection may only be closed by the program that is currently permitted to send data (otherwise data may be lost). The partner program waiting with the receive command then receives the corresponding return code (18).
The term 'ping pong' describes the communication method described above, in which an acknowledgement is sent after each data record.
In contrast to the 'ping pong' method, 'multisend' sends a series of data records before receiving a single acknowledgement at the end.
Comparison of the two communication methods:
The ping pong method involves more work because you are dealing with single records and individual acknowledgements, whereas multisend uses a single asynchronous send, and only has to wait for one overall acknowledgement.
However, ping pong provides you with better control of your data. If the communication is broken (communication error, or the receiving program crashes - return code 17), you always know, if you are using ping pong, which records have arrived in the target system, which have been processed, and where you need to resume processing.
The multisend method, on the other hand, also returns the code 17, but does not know which records have been received, and if they have been fully or partially processed, or not processed at all.
Therefore use the ping pong method where each data record contains, for example, the data for one transaction.
You use the following ABAP statements to run a CPI-C (ABAP) connection:
COMMUNICATION INIT Initialize connection
COMMUNICATION ALLOCATE Make (allocate) connection
COMMUNICATION ACCEPT Accept connection
COMMUNICATION SEND Send data
COMMUNICATION RECEIVE Receive data
COMMUNICATION DEALLOCATE Close connection
External C programs use the same calls to communicate with ABAP programs using CPI-C.
Although the syntax of the calls is different in C (CMINIT, CMALLC, CMACCP, CMSEND, CMRCV, CMDEAL), their functions are the same as the corresponding ABAP calls.
The return code of a CPI-C call in ABAP is always placed in the field SY-SUBRC. However, it can also be placed in the RETURNCODE parameter of the CPI-C call itself.
As well as the return code, some CPI-C calls also return special parameters containing extra information about, for example, data transfer and which side is entitled to send data.
The return codes and return parameters of CPI-C calls are stored as hexadecimal codes. When you query the codes, you should use meaningful constants instead of the hex codes.
Use IF RC = CM_DEALLOCATED_NORMAL instead of if RC = 18 to close the connection from the partner side.
The CPI-C constants are contained in the standard ABAP include RSCPICDF.
The most important return codes are:
'0000'( CM_OK ) :Connection OK
'0011'( CM_DEALLOCATED_ABEND ) :Connection terminated
'0012'( CM_DEALLOCATED_NORMAL ) :Connection from partner terminated normally
'0013'( CM_PARAMETER_ERROR ) :Invalid conversation ID in CPI-C call
'0014'( CM_PRODUCT_SPECIFIC_ERROR ) :Invalid sideinfo entry in CMINIT call
'0019'( CM_PROGRAM_STATE_CHECK ) :Send command rejected due to missing send authorization
COMMUNICATION INIT This is used to initialize the CPI-C connection.
(Preparing the connection)
Entry:
DESTINATION Name of sideinfo entry
Output:
ID Conversation ID This indicates the communication partners for the specified sideinfo entry.
It is used until the next connection is made and is at the same time the name of the connection.
RETURNCODE Return code of the call is always stored in SY-SUBRC; can be used in additional fields.
This parameter is optional.
The fields listed in the INIT call must have the following types:
dest C8
convid C8
rc X2
Legend: lowercase + cursive --> ABAP field
underlined --> Entry variable
[ ... --> optional entry
COMMUNICATION ALLOCATE builds the CPI-C connection and the corresponding partner program is started. You must specify the conversation ID returned by the INIT call.
For a valid connection to be established, the called program must accept the connection using the COMMUNICATION ACCEPT statement. The ACCEPT call returns the conversation ID of the connection and a return code. This must be the first statement in the passive program.
After the ACCEPT call from the side that was called, the active program has the send permission. The passive program must first receive.
In the send command, you can send a data packet of up to 30000 bytes.
Parameters:
ID Conversation ID
BUFFER Send buffer (max 30000 bytes)
LENGTH Length of the packet you want to send (optional; if entries are missing, the entire send buffer is sent) The field must have type P.
Output:
RETURNCODE
If a program sends without having permission, the return code is 25 (Hex 19).
FOR RELATED POSTS SEE BELOW.
abap communication interface 1
Interface programming part two
Interface programming for abap part three
communication interface part four
Interface programming part five
communication interface part six
No comments:
Post a Comment