IDoc Processing with the Integration Server (SAP Library - SAP Exchange Infrastructure (BC-XI))

IDoc Processing with the Integration Server

Purpose

The IDoc adapter enables you to process and send IDocs (Intermediate Documents) using the Integration Engine. You can use all existing IDoc types that have been released. ALE Audit is supported.

Processing IDocs using the Integration Engine pipeline is an alternative to processing XML messages that are generated using the proxy interface. This alternative is considered for all SAP applications and external systems (subsystems) that have already defined IDocs, as well as for new applications of SAP components that do not yet have access to the proxy generation functions.

For more information on IDocs, see IDoc Interface/Electronic Data Interchange (BC-SRV-EDI).

Prerequisites

Integration Server

If the system on which the IDoc adapter is located is configured as the Integration Server, then inbound IDocs are processed using the IDoc adapter and not using the normal IDoc interface.

On an Integration Server you must therefore enter IDocs that are to be processed using the IDoc interface in an exception table using the report IDX_SELECT_IDOCTYP_WITHOUT_IS. You can only include IDoc types in this table that are already defined in the system. These IDoc types are not processed using the Integration Engine.

To load IDoc meta data you must establish an RFC connection to the connected system using the port maintenance in the IDoc adapter. This system is defined by the sender port and the client in the IDoc control record.

Application Components

Existing applications do not need to be changed.

In the sender system you merely need to change the target address of the RFC destination of a tRFC port for the Integration Server. If no tRFC port exists, you must create one for the Integration Server.

To change an existing tRFC port, proceed as follows:

In the SAP menu, choose Administration ® Business Communication ® IDoc Basis ® Administration ® RFC Destination.
Select the corresponding RFC destination by double-clicking it.
Enter the server address of the Integration Server as the Target Machine.

For more information see, displaying, maintaining and testing destinations.

To create a new tRFC port, proceed as follows from the SAP menu:

To create a connection type 3 RFC destination and to specify the server address of the Integration Server as the Target Machine, choose Administration ® Business Communication ® IDoc Basis ® Administration ® RFC Destination.

For more information see, displaying, maintaining and testing destinations.

To define a new port of type Transactional RFC (tRFC) with this destination, choose Administration ® Business Communication ® IDoc Basis ® Administration ® Port Description.

For more information about configuring ports, see configuring ports .

To change the partner profiles, choose Administration ® Business Communication ® IDoc Basis ® Administration ® Partner Profile. Enter the receiver system as the partner number, select the sender message type and basis type for the outbound parameters and enter the new port as the receiver port.

For more information, see creating outbound partner profiles.

You must also change the partner profiles in the receiver system.

To do so, from the SAP menu choose Administration ® Business Communication ® IDoc Basis ® Administration ® Partner Profiles and enter the sender system as the partner number.
Also specify the inbound message type and the basis type for the inbound parameters.

Process Flow

The connected systems generate the corresponding IDocs in the applications and send them to the new tRFC port; the RFC destination of this port addresses the Integration Server.

The IDoc adapter that generates IDoc XML from the native IDoc format is called on the Integration Server. This IDoc XML is transferred to the Integration Engine pipeline for the purposes of routing, mapping and sending.

Note

If the received IDoc is to be sent as an IDoc again without any changes to the data records, it is possible to deactivate the conversion to IDoc XML by using a corresponding configuration parameter.

Inbound IDoc Adapter

Once the IDoc has left the application through the RFC interface and has reached the inbound IDoc adapter, the system converts it from IDoc format to IDoc XML format. A message GUID is generated for each IDoc.

IDocs can also be transferred in packages. A package of IDocs is only accepted if all IDocs within the package can be converted to IDoc XML format. If one or more of the IDocs cannot be converted, the whole package is refused.

The conversion comprises a implicit 1:1 mapping of segments and fields to XML tags. The necessary meta data (IDoc structures for the corresponding IDoc types) is not located on the Integration Server, but in the connected SAP system (or in the SAP reference system in which the meta data is saved if the sender system is a subsystem).

You can either call this meta data directly at runtime or you can load it onto the Integration Server beforehand. To be able to do this you must have already created an RFC connection (a port) to the connected system.

To display already loaded meta data and connected systems, use the meta data display in the IDoc adapter. You can also reset and then reload meta data.

Integration Server: Inbound Channel

A message comprising a header and body with payload (IDoc XML) is sent to the Integration Server for each IDoc XML.

Among other things, the header contains the sender business system. This is identified from the values for the sender port and the client from the IDoc control record. The sender port comprises the prefix SAP and the system ID (for example, SAPBCE). These values are assigned to business systems in the System Landscape Directory.

In addition, the sender/receiver IDoc partners are made available to logical routing as context objects. For more information, see the description of the conditions editor for logical routing.

Note

The IDoc XML message must only contain one IDoc. Inbound IDocs are not persisted.

Logical Routing

The receiver can be determined either by using context objects from the IDoc control record or by using an XPath rule on the IDoc XML, depending on the sender business system in the IDoc XML message. To be able to identify the receiver successfully, the XPath rule must have the status true.

If context objects are not used and if no XPath rule is defined, then the business system that is assigned to the sender business system is selected as the receiver.

Technical Routing

In technical routing the logical receiver is assigned a physical target. For the message, the outbound IDoc adapter requires one IDoc end point (an RFC destination) from technical routing for each logical receiver.

This IDoc end point is analyzed and provides the technical information for the tRFC call. Note the following for the version of the technical IDoc interface: The function module

INBOUND_IDOC_PROCESS (Version 2) must be used for IDoc types with short names, for example eight characters

IDOC_INBOUND_ASYNCHRONOUS (Version 3) must be used for IDoc types with long names, for example thirty characters

Note

An IDoc end point that expects acknowledgment messages from an IDoc adapter is also required in the sender system.

Mapping

The IDoc adapter does not make any special demands on mapping. The outbound IDoc adapter must simply be provided with an IDoc XML structure. This either already exists or must be generated by using a mapping. The data in the IDoc control record does not necessarily need to be completed by the mapping here since any data will be overwritten by the outbound IDoc adapter at a later stage anyway.

Integration Server: Outbound Channel

Before the message leaves the Integration Server, the message header contains values that are exported and used later to complete the IDoc control record.

The system calls the outbound IDoc adapter and transfers the XML IDoc, IDoc end point data, and the control record data.

Outbound IDoc Adapter

The task of the outbound IDoc adapter is to convert XML IDocs to native IDoc format and to transfer the IDocs to the receiver system (an SAP component or subsystem) using the standard tRFC IDoc interface. The IDoc control record is completed by the outbound IDoc adapter.

The outbound IDoc also identifies the IDoc sender partner from the assigned sender business system and the IDoc receiver partner from the assigned receiver business system.

Sender and receiver business systems are assigned to IDoc partners in the System Landscape Directory. An IDoc partner of type LS (logical system) is assigned to each business system by using a logical system name.

Note

External systems can also be maintained in the System Landscape Directory as SAP systems.

To convert IDoc XML to IDoc format, the outbound IDoc adapter requires the meta data for the respective IDoc type. If this data is not available, you must load it from the receiver system (or from the corresponding SAP reference system, if the receiver system is a subsystem). The IDoc adapter requires the current release of the receiver system to obtain the meta data. This is located in the IDoc end point.

The conversion to IDoc format then takes places using the meta data.

Note

If the IDoc you want to send has already been received as an IDoc, and if the corresponding configuration parameters that deactivate the conversion of IDoc XML have been set, then conversion from IDoc XML to IDoc format does not occur at this point.

The system then calls a function module of the tRFC IDoc inbound channel using the destination (from the IDoc end point) and transfers the data in the corresponding format. The IDoc interface version from the IDoc end point determines which function module is called.

In the case of version 2, the function module INBOUND_IDOC_PROCESS is called that requires the native IDoc exchange format 3.x (for IDoc types with short names, for example eight characters).
In the case of version 3, the function module IDOC_INBOUND_ASYNCHONOUS is called (for IDoc types with long names, for example thirty characters).

Both function modules are called in the receiver system that is addressed using the RFC destination that is defined in the IDoc end point.

The function module call is placed in the tRFC queue and then the IDoc is finally sent to the receiver application. The Integration Server checks if the message was actually sent or not.

To enable you to select IDocs in the target system later on, the system transfers the message GUID and the IDoc number in the field ARCKEY of the IDoc control record.