IDoc Processing with the IDoc Adapter

You use the IDoc adapter to process and send IDocs (intermediate documents) by using the Integration Engine. You can use all existing released IDoc types for this. ALE audit is supported.

Processing IDocs using the Integration Engine pipeline is an alternative means for you to process 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 SAP applications that do not yet have access to the proxy generation functions.

More information: Integration Engine , ALE Audit , Pipeline , IDoc Interface/Electronic Data Interchange .

The IDoc adapter is part of the Integration Server. Essentially, the IDoc adapter comprises two parts: an adapter at the Integration Server inbound channel, and an adapter at the Integration Server outbound channel. The metadata for the IDoc types involved is shared.

The adapter at the inbound channel is located before the Integration Server pipeline and calls this pipeline. The adapter at the outbound channel, however, is called by the pipeline, and can therefore be regarded as part of the pipeline.

The connected systems transfer or receive IDocs through their IDoc RFC interface.

IDoc Processing Procedure

The connected systems generate the corresponding IDocs in the applications and send them to the 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.

IDoc Adapter at the Integration Server Inbound Channel

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

You can make IDocs available as a file. More information: File Interface

IDocs can 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 an implicit 1:1 mapping of segments and fields to XML tags. The necessary metadata (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 metadata is stored if the sender system is a subsystem).

You can either call this metadata directly at runtime or you can upload it to 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 metadata and connected systems, use the metadata display in the IDoc adapter. You can reset metadata, load it again and then compare the loaded metadata with the metadata in the reference system.

More information: Loading, Displaying, and Deleting Metadata , Managing Ports for IDoc Metadata , Comparing Metadata  with the Reference System

IDoc Packaging, Integration Server Inbound Channel, and Partner Conversion

The following function modules are available in the Integration Server inbound channel:

• IDOC_INBOUND_ASYNCHRONOUS

  This module uses segment names as input parameters.

• IDOC_INBOUND_IN_QUEUE

  This module uses segment types. You can also enter the queue name for quality of service Exactly Once in Order.

If IDoc packaging is activated in the sender IDoc adapter, IDoc packages sent using tRFC are put into a message. You can ensure the packages do not get too large by setting the package size.

If IDoc packaging is not activated, then a message consisting of a header and a body with payload (IDoc XML) is sent to the Integration Server for each IDoc XML. Among other things, the header contains the sender communication component.

Adapter-specific identifiers must be assigned to each communication component for the IDoc adapter in the Integration Directory. The specific identifiers for the IDoc adapter are values from the IDoc control record. The IDoc adapter uses these specifications to specify the sender communication component in the message header. The receiver communication component in the inbound channel remains empty.

• If the sender system is an SAP system, the sender communication component is identified from the system ID (for example, BCE) of the sender port (for example, SAPBCE), and the client.
• If the sender system is a non-SAP system, the sender communication component is identified from the logical system name of the sender port.

Besides the sender communication component, the message header also contains the sender and receiver party (comprising the party name, identification scheme, and assigning agency).

• If an IDoc partner is defined as a logical system (partner type LS), the party remains empty in the message header.
• If an IDoc party is not defined as a logical system, an alternative party is generated in the message header. This party consists of the following alternative identifiers:
  • The communication party (party name), which comprises the IDoc party number
  • The identification scheme, which comprises the partner type and, optionally, the IDoc partner role (thus, ALE#<partner_type> or, optionally, ALE#<partner_type>#<partner_role>).
  • The assigning agency, which comprises the sender communication component (identified from the system ID and client)

  You have the option of normalizing the alternative sender party, that is, replacing it with the internal XI party.

  Note

  You can omit the normalization of the alternative party for reasons of compatibility.

In addition, the sender/receiver IDoc partners are made available to logical routing as context objects.

Logical Routing

Logical routing determines the logical receiver. 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

Technical routing assigns a physical target to the logical receiver. The IDoc adapter needs an RFC destination from the technical routing for each logical receiver. This is specified as a parameter (RFC Destination) in the receiver IDoc adapter.

You also define the version of the technical IDoc interface in the receiver IDoc adapter.

More information: Configuring the Receiver IDoc Adapter , Processing Acknowledgment Messages

Mapping

The IDoc adapter does not make any special demands on mapping. The IDoc adapter must simply be provided with an IDoc XML structure at the Integration Server outbound channel. This either already exists or must be generated by using a mapping. If the IDoc XML structure contains a control record, it is rejected and created again by the IDoc adapter.

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 IDoc adapter and transfers the IDoc XML, the parameters from the communication channel, and the control record data.

IDoc Adapter at the Integration Server Outbound Channel, Partner Conversion

The task of the IDoc adapter at the Integration Server outbound channel is to convert IDoc XMLs to native IDoc format and to transfer the IDocs to the receiver system (an SAP system or subsystem) using the standard tRFC IDoc interface. The IDoc control record has been completed by the IDoc adapter.

In addition, the IDoc adapter identifies the corresponding IDoc partners from the sender and receiver in the message header.

• If the party in the message header is empty, an IDoc party of type LS (logical system) is identified with the communication component as the logical system name.
• If the party in the message header has been completed, the IDoc partner is identified using the alternative party.

  If the party has been normalized, a communication channel must be used to assign the following identifiers:

  • The partner type and, optionally, the IDoc partner role (thus, ALE#<partner_type> or, optionally, ALE#<partner_type>#<partner_role>) as the identification scheme
  • The communication component as the issuing agency

To convert IDoc XML to IDoc format, the IDoc adapter requires the metadata 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 conversion to IDoc format then takes place using the metadata.

Then, using the RFC destination, a function module (parameter Interface Version and Queue Processing in the receiver IDoc adapter) is called from the RFC IDoc inbound channel and the data is transferred in the relevant format.

The IDoc is then 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 ARCKEY field of the IDoc control record.

Conversion of Acknowledgment Status to IDoc Status and the Other Way Around

Rules for Converting an IDoc Status to an Acknowledgment Status

Rules for Converting an Acknowledgment Status to an IDoc