The following section deals with the technical aspects of communication and data flow between SAP-R/3 and a non-SAP system (sub-system).

The following overview shows the procedure for transmitting outputs from R/3 to a sub-system.

The planning requirement for planning deliveries can be created with the functions described in the Outbound Delivery section. The procedure can be carried out either as an online transaction or a background job using output control.

Within the same process (Logical Unit of Work or LUW) the data is formatted in the form of repository (data dictionary) structures by the Application Link Enabling (ALE) level function module. These structures are called Intermediate Documents (IDocs). The IDocs that were created are saved in the database.

Transmission of the IDoc is carried out asynchronously to its creation, that is, ALE transmits the IDoc after it is created. 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). The system starts a remote shell in the subsystem and calls up the C program 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. A library of C development programs are available for program development.

For further information on creating C programs 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 in the sub-system. There is a sample program to this effect. 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 out separately in the sub-system.

Also, the subsystem should have status management for the data it received. Status management can prevent duplicate processing. You should also note that the sub-system must be able to recognize if an IDoc has already been transmitted once by the R/3 system. This is made possible through a unique transaction ID for each communication activity. (See also the technical documentation of the RFC.)

In addition to the transaction ID, the IDoc number can also be used to signify 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.

The following problems may occur during transmission:

In this case, the error is not critical for communication, because IDocs cannot be created without a planning requirement. Both postings are carried out in the same LUW and are therefore posted synchronously.

1. The data that was formatted in the LUW (which creates the IDoc) and which was sent to ALE is syntactically incorrect. The IDoc is copied and saved by ALE but cannot be transmitted. For more information about this error, see the SAP System Settings and Modifications section.
2. The partner profile for outbound processing is not defined for the receiver and the IDoc’s message type in ALE. The IDoc is saved but cannot be transmitted. For more information about this error, see the SAP System Settings and Modifications section.

If an IDoc is created but the connection cannot be made, then a report running in the background ensures that communication attempts are made from time to time. If the connection is restored, then the IDocs are transmitted automatically.

The following overview illustrates receipt of shipping documents that have been generated from planning requests by the subsystem.

The primary task of the subsystem is to optimize shipment planning 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:

You also need the RFC library for programming support for the transfer program. The central function module is part of the ALE layer.

Several IDocs can be transferred in one communication procedure - that is, when an R/3 function module is called up once, multiple IDocs can be transferred.

During transmission, the sub-system must provide status administration for the transmitted data. If the IDoc is transmitted unsuccessfully, then it must be retransmitted later.

Duplicate transfer of IDocs must be avoided on the SAP side of things. This is where the transaction ID, which is assigned by SAP for each communication procedure, comes into play. The data that is transferred by the sub-system must always be transmitted with this transaction ID (see also the technical documentation about the RFC). The same transaction ID must be entered for subsequent retransmissions.

The SAP System does not use the IDoc number to check for duplicate transfers.

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 as far as receipt is concerned), where processing occurs.

The application in R/3 that creates, changes and deletes shipment documents sends a status back to ALE for each IDoc. This IDoc status is the basis for processing any possible errors.

An IDoc was created, but processing was not started.

This error occurs (as in transmission from R/3), if the IDoc that is 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 about this error, see the SAP System Settings and Modifications section.

This is a question of logical errors in the application. A message is issued to a position with the IDoc status mentioned above. Several users can be assigned to a 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.

This section provides you with an overview of the technical details involved in the connection of a sub-system to the R/3 System. You can find detailed documentation of the Remote Function Call 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 consult the above-mentioned documentation as well if you want to make the connection yourself.

IDocs are transmitted from the SAP system by calling up the function module INBOUND_IDOC_PROCESS with a destination. The destination uses a table in the R/3 system to determine destination computer and the target program.

A C program with target program name must exist in the sub-system. The program contains a function with the name of the function module call.

In the R/3 system, the application data is transferred in the internal table of structure EDI_DD. In addition, a control record from structure EDI_DC that contains administration data is also transferred for each IDoc. In the example, this data is transferred in the form of internal tables.

For further information, please see the documentation mentioned above.

You can have a C program core from function module display SE37 generated from the R/3 system. You can use this as the basis for your receiving/transmitting program. In order to interpret the 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.

Please see also the RFC documentation mentioned above for more information on the settings.

When you log on to the SAP R/3 system, the server name of the SAP target system, SAP logon, user, password etc. must be defined in the C program. The actual logon is supported by the RFC function RfcOpen (...). You can find details about this in the comprehensive RFC documentation.

The data needs to be processed into IDoc format and placed in an internal table with 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.

To ensure the security of the data to be transferred, a unique ID must be used for the 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 transmit the data again in order to ensure that the entry is posted by the SAP System. If the data was successfully received and processed on the first attempt, however, the system must be able to recognize this. It should not process the data a second time.

This example would cause the following process flow between the transmitting system and the receiving system.