Using the Intermediate Document (IDoc) Adapter in the Advanced Adapter Engine (AAE)

After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • List the benefits of the IDOC_AAE

Benefit of IDoc AAE

An important benefit of the Intermediate Document (IDoc) Advanced Adapter Engine (AAE) is that you can leverage the high performance capabilities of the advanced adapter for the same IDoc scenarios as scenarios through the Integration Server (ABAP).

The following are steps for using the IDoc:

  • Design-IDoc types

    The IDoc interface must be imported into the Enterprise Services Repository (ESR). Mapping is usually required; when it is, use the IDoc type as the sender or receiver structure.

  • Configuration-Logical system names

    The communication components involved must have a logical system name assigned to them in the System Landscape Directory (SLD) or in the Integration Directory (ID).

  • Runtime-IDoc structures

    Access must be provided at runtime to the IDoc structure for conversions between IDoc and XML displays. In NetWeaver Administrator, the inboundRA Resource Adapter needs to be configured for IDoc , especially the destination name, which is usually XI_IDOC_DEFAULT_DESTINATION. Normally, this destination points to the system that knows most of the sender IDocs (Enterprise Resource Planning (ERP)). The destination XI_IDOC_DEFAULT_DESTINATION needs to be created in NWAConfigurationInfrastructureDestinations. With the above mentioned default settings, it's only possible to connect one IDoc Sender system with the AEX. If you want to connect different IDoc Sender Systems with the AEX, you have to clone the inboundRA. For each cloned inboundRA, you have to create a XI_IDOC_DEFAULT_DESTINATION_<SID> connection.

  • Configuration-IDoc communication channel

    A destination in SAP NetWeaver Administrator (NWA) can be created to define where the IDocs are going to be delivered to. For the metadata, you can use the Default destination or choose Use Alternative Source of Metadata and enter another destination.

Importing an IDoc Type in the ESR

During IDoc processing, the scenario is determined by the message type and the document structure by the IDoc type. You can find details about IDoc types in transaction code WE60.

To include an IDoc interface of an SAP software component in an integration scenario or to use it for mapping, import the software component and the IDoc type of the software component into the ESR. Name the XML IDoc type using the naming convention <MessageType>.<IDocType>.<Enhancement>. For SAP standard IDoc types, the element <Enhancement> can be omitted. The IDoc type is then saved as an XML schema.

If an IDoc type is not yet in the ESR, you can import it from an SAP system. Importing SAP interfaces (IDoc or RFC) is allowed at the Software Component Version (SWCV) level in the ESR. To do this, the technical connection data for RFC access to an SAP system must be saved in the SWCV so that it can be used to read the IDoc types.

Using IDoc Types in Mapping

In contrast to a service interface, the IDoc type in the ESR does not contain any listed attributes, such as synchronous or asynchronous, outbound or inbound. IDoc types are always used asynchronously and can be used as both outbound and inbound.

During mapping, the IDoc type is used directly in the operation mapping as a service interface and in message mapping (or external mapping program) as a message type.

The requirements for defining a message mapping from a message type to an IDoc type are as follows:

  • An optional segment is constructed if a mapping exists from a source field to the segment.

  • Each segment must be assigned an attribute segment that has a value of 1. You can achieve this by assigning a constant to the segment.

  • You are permitted to use only string-type fields in an IDoc type. If the source structure contains other types, convert them.

Importing an IDoc

The prerequisites for importing an IDoc are as follows:

  • Maintain the software component and the version containing the IDoc type in the SLD and assign the software component and the version to a product version.

  • Assign the product to the technical system and select the SWCV as the installed software component.

  • Select the product as the installed product in the corresponding business system.

  • Import the SWCV from the SLD into the ESR.

To import an IDoc type, perform the following steps:

  1. Choose the software component for which you want to import an IDoc type. Check the settings of the SWCV. Make sure that the technical connection data for importing from the SAP system is maintained.

  2. From the context menu of Imported Objects, choose Import of SAP Objects.

  3. Enter a valid user and password and choose Continue.

  4. Expand the IDoc node and select one or more IDocs. Choose Continue.

  5. Check your selection and import the IDoc types by choosing Complete.

Sender and Receiver in IDoc Processing

IDoc processing uses the following fields to define sender and receiver:

  • Partner type

  • Partner role

  • Partner number

In the case of pure A2A scenarios, where the sender and receiver systems are known, the partner type is a logical system. In SAP systems, the logical system name is an attribute in every client.

At runtime, the sender system adds information about the sender and receiver to the IDoc control record.

IDoc processing also handles B2B scenarios, where the sender or receiver are identified with an alternative partner type, for example, KU for customer or LI for vendor. This can be mapped using a communication party.

Conversion Between a Business System Name and a Logical System Name

The figure illustrates the relation between a logical system name and a business system.

If no logical system name is assigned to the sender system, you can enter a communication component in the receiver agreement that has a logical system assigned to it.

To check the logical system name, perform the following steps:

  1. Log on to the ABAP stack of the SAP back-end system. To determine the logical system name of the client, execute transaction SCC4. This displays a list of the clients installed on the system. Choose your client and choose Details. The assigned logical system name appears in the Logical System field.

    You do not have permission to change the logical system name later on during client maintenance, as inconsistencies can arise.
  2. Log on to the SLD. Go to Technical System. Choose the technical system of the SAP back-end system and choose the Clients tab page in the lower area of the screen. Choose the client number from the SAP back-end system. Enter the assigned logical system name that you chose in step one and enter it in the Logical System Name field.

  3. Log on to the ID. Navigate to the business system. On the Objects tab page, choose Communication ComponentBusiness System and double-click the business system (SAP_BACKEND). From the Object menu, choose Communication ComponentAdapter-Specific Identifiers. You can display the current logical system name under IDoc Adapter in the ID.

Availability of IDoc Metadata

The current metadata of the IDoc type must be made available to the Advanced Adapter Engine. This metadata also contains information that is relevant to the ESR. For example, the segment types and their exact lengths are needed. For this reason, there is a special cache on the Advanced Adapter Engine that saves the IDoc metadata.

Once the IDoc Metadata were loaded, you can find the IDoc Metadata in the IDOC Adapter Monitor. Open PiMon and navigate to MonitoringAdapter EngineIDOC Adapter MonitorMetadata Monitor.

How to Import an IDoc into the Enterprise Services Repository (ESR)

How to Clone the InboundRA

Examine Prerequisites to Receive IDocs

Log in to track your progress & complete quizzes