The following chapter deals with the technical aspects of communication and data flow between SAP-R/3 and a non-SAP system (subsystem).
Transmitting Planning Requests
The following overview shows the procedure for transmitting message from R/3 to a subsystem.
Creating a Planning Requirement in Transportation
The planning requirement for planning deliveries can be created with the functions described in section Outbound Delivery. The procedure can be carried out either as an online transaction, or as a background job, using message control.
Saving the Data in the ALE Layer
Within the same process (LUW, Logical Unit of Work) the data is formatted in the form of repository (data dictionary) structures by the ALE level function module. These structures are called IDocs (Intermediate Document). The IDocs created are saved in the database.
You can find exact information on the structure and definition of an IDoc underIDoc Description and Description of the IDoc Segments, Fields and Domain Values.
Communication Structure and Transmission of the IDocs
Transmission of the IDoc is carried out asynchronously to the creation of the IDoc, that is, after the IDoc is created, transmission is carried out by ALE. An IDoc can be transmitted directly, or combined first and then sent as part of a package of several IDocs.
During IDoc transmission the ALE uses transactional Remote Function Call (tRFC). A remote shell is started in the subsystem and a C program is called to which the function to be called is transferred within the program. The underlying technique that allows transmission to be carried out correctly according to the log, is described above as an RFC layer. From the program side, a library of C development programs are provided.
For further information on the creation of the C-Program and further system settings, see the following sections and the documentation in the RFC libraries.
The C program for receiving the data must be provided on the subsystem. There is also a sample program. This is supported by the RFC library that you receive from SAP as a certification partner (RFC SDK, Remote Function Call Software Development Kit).
The program must save the data after receiving it before the receipt confirmation is sent back to the R/3 system. Then, data processing can start in the subsystem. SAP recommends this intermediate saving procedure, which allows communication of processing logic to be carried separately on the subsystem.
Also, the subsystem provides status administration for the data that is received. This prevents duplicated processing. You should also note that the subsystem must be able to recognize if an IDoc has already been transmitted once by the R/3 system. This is made possible by the unique transaction ID for each communication procedure (see also technical documentation for the RFC).
As well as the transaction ID, the IDoc number can also be used to recognize that an IDoc has already been transferred. The IDoc number is only unique within a given client of an SAP system. If communication is carried out with several clients and/or several SAP systems, then the IDoc can not be identified using only the IDoc number.
Error Processing in Communication
During transmission, the following problems usually occur:
Posting termination in the application (e.g. when creating a planning requirement)
In this case, the error is not critical for communication, because no IDoc can be created without a planning requirement. Both postings are carried out in the same LUW and are therefore posted synchronously.
Error in the ALE layer
If an IDoc is created but the connection can not be made, then a report running in the background ensures that communication occurs from time to time. If the connection is restored, then the IDocs are transmitted automatically.
Receiving Planned Shipping Documents
The following overview displays the receipt of shipping documents that have been generated from planning requests by the subsystem.
Formatting and Transmitting Shipment Data
The primary task of the subsystem is to optimize planning of shipments from the planning requests that have been transmitted from the R/3 system. Fully planned shipments must be transmitted back to the R/3 system using the communication path provided (transactional RFC). The subsystem carries out the following tasks within the framework of communication with the SAP R/3 system:
Intermediate Storage of Data and Formatting for IDoc
The subsystem shipment data must be saved in an IDoc-specific data structure. For information on the definition and structure of the different IDocs, see sectionsIDoc Description and Description of the IDoc Segments, Fields and Domain Values.
Calling a Central Function Module in R/3 using the Transfer Program
You need the RFC library for programming support for the transfer program too. The central function module belongs to the ALE layer.
Several IDocs can be transferred in one communication procedure - that is, when an R/3 function module is called once.
Updating After IDoc Transmission
During transmission, the subsystem must provided status administration for the transmitted data. If the IDoc is transmitted unsuccessfully, then it must be transmitted again later.
On the SAP side, duplicated transfer of IDocs must be avoided. This is where the transaction ID is used. This is defined by SAP for each communication procedure. The data that are transferred by the subsystem must always be transmitted with this transaction ID (see also technical documentation on the RFC). The same transaction ID must be entered for subsequent retransmissions.
The IDoc number is not used by the SAP system to check duplicated transfer.
Receipt and Posting of Data
ALE receives the IDoc and writes it into the database. After this intermediate saving procedure, a confirmation of receipt is sent back to the subsystem. The IDoc is then forwarded to the application (asynchronously with regards to receipt) where processing is carried out.
The application in R/3, that carries out the creation, changing and deletion of a shipment document, sends a status back to ALE for each IDoc. This IDoc status is the basis for processing any possible errors.
The following errors may occur:
Connection can not be made at present.
The subsystem should use status administration to ensure that subsequent posting can be carried out.
Error in the ALE layer
An IDoc was created, but processing has not commenced
This error occurs (as in transmission from R/3), if the IDoc received is syntactically incorrect or if the partner profile for inbound processing is missing for the sender and the message type of this IDoc. For more information on this error see section SAP System Settings and Modifications.
Error in the Application (e.g. when posting the transfer request)
This is a question of a logical error in the application. A message is issued to a planning position with the IDoc status mentioned above. Several users can be assigned to a planning position. Each user receives the error message in their own SAP-OFFICE-Inbox. As soon as a user enters and processes the error message, it disappears from the other inboxes.
Technical Programming for the Subsystem Connection
This section provides you with an overview of the technical details involved in the connection of a subsystem to the R/3 system. Detailed documentation of the Remote Function Call exists in RFC SDK and in the R/3 system online documentation. This section is intended to give you an overview of the programming techniques. It is not comprehensive. Please see the other documentation as well if you want to carry out connection yourself.
Transmission from SAP to a Subsystem
IDocs are transmitted from the SAP system by calling function module ‘INBOUND_IDOC_PROCESS’ with a destination. The destination uses a table in the R/3 system to determine destination machine and the target program.
A C program with target program name must exist in the subsystem. The program contains a function with the name of the function module call.
In the R/3 system, the application data are transferred in the internal table of structure EDI_DD. In addition, a control record from structure EDI_DC is also transferred for each IDoc, containing the administration data for each IDoc. In the example, these data are transferred in the form internal tables.
For further information, please see the documentation mentioned above.
You can create a C program from function module display SE37 from the R/3 system. You can use this as the basis from your receiving/transmitting program. In order to interpret the user data in the IDoc, you also need the data structures of the IDocs at C Program level. If an R/3 system is available, you can generate an .h - IDoc header file directly from repository transaction SE11.
Notes on TCP / IP settings
Please see also the RFC documentation mentioned above for more information on the settings
Transmitting from a Subsystem to SAP
Logging on to the SAP R/3 system including the server name of the SAP target system, SAP logon, user, password etc. must be defined in the C program. Logging on itself is supported by the RFC function RfcOpen (...). You can find details on this in the comprehensive RFC documentation.
The user data needs to be processed into IDoc format and placed in an internal table for structure EDI_DD. A control record must also be created for each IDoc and placed in an internal table for structure EDI_DC. The form of data transfer is also described in detail in the documentation.
Transactions ID Administration
To guarantee the security of the data to be transferred, a unique ID must be used for a communication procedure. This ID allows the receiving system to recognize whether this data has already been received and processed.
For example, communication could be terminated suddenly during the transmission of data for mobile entry of goods receipts. The user would have to transmit the data again in order to ensure that posting is carried out by SAP. If some of the data was successfully received and processed on the first attempt, however, the system must be able to recognize this. It is not allowed to process the data again.
This example would cause the following process flow between the transmitting system and the receiving system.