IDoc Processing with the IDoc Adapter 

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 SAP applications that do not yet have access to the proxy generation functions.

For more information about IDocs, see IDoc Interface/Electronic Data Interchange.

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 the exception table IDXIDOCINB 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 metadata, 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:

...

       1.      Call the transaction Display and Maintain RFC Destinations (SM59).

       2.      Select the corresponding RFC destination by double-clicking it.

       3.      Enter the server address of the Integration Server as the Target host.

For more information, see Displaying, Maintaining, and Testing Destinations.

To create a new tRFC port, proceed as follows:

...

       1.      Call the transaction Display and Maintain RFC Destinations (SM59) to create a connection type 3 RFC destination and then specify the server address of the Integration Server as the Target host.

For more information, see Displaying, Maintaining, and Testing Destinations.

       2.      Call the transaction Ports in IDoc Processing (WE21) and use this destination to define a new port of type Transactional RFC (tRFC).

For more information about configuring ports, see Configuring Ports.

       3.      Call the transaction Partner Profiles (WE20) to change the partner profiles. Enter the receiver system as the partner number, select the type of message to be sent and the basic type in the outbound parameters, and enter the new port as the receiver port.

For more information, see Creating Outbound Partner Profile.

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

...

       1.      To do this, call the transaction Partner Profiles (WE20) and create an inbound partner profile for the sender party.

       2.      Also specify the inbound message type and the basic type in 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.

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.

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.

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 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 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 metadata and connected systems, use the metadata display in the IDoc adapter. You can also reset and then reload metadata.

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 service.

Adapter-specific identifiers must be assigned to each service 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 service in the message header. The receiver service in the inbound channel remains empty.

·        If the sender system is an SAP system, the sender service 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 service is identified from the logical system name of the sender port.

Besides the sender service, the message header also contains the sender and receiver party (comprising the party name, identification scheme, and issuing agency).

·        If an IDoc partner is defined as a logical system (partner type LS), the party remains empty in the message header. The service is defined under Service Without Party.

·        If an IDoc partner 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 partner number

¡        The identification scheme, which comprises the IDoc partner type and, optionally, the IDoc partner role (thus, ALE#<partner_type> or, optionally, ALE#<partner_type>#<partner_role>)

¡        The issuing agency, which comprises the sender service (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.

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. For more information, see the description of the condition editor for logical routing.

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 must also create a communication channel with adapter type IDoc for sender systems that expect acknowledgment messages from an IDoc adapter.

You also specify the technical IDoc interface version in the receiver IDoc adapter.

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 deleted 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

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 is 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 partner of type LS (logical system) is identified with the service as the logical system name.

·        If the party in the message header is 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 service 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.

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 (Interface Version and Queue Processing parameters in the receiver IDoc adapter) of the RFC IDoc inbound channel using the RFC destination and transfers the data in the corresponding 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.