The source structure for an outbound interface is the internal structure. Usually, you have to create the structure in the ABAP dictionary. How the structure should look depends on the data you have to pass to AIF in order to be able to derive all the necessary information required by the receiver. For example, you have a report that triggers the sending of data. The user can fill some fields on a selection screen. These fields have to be passed to AIF then and your source structure has to contain those fields.

 

Inbound Interface

For an inbound interface, the destination structure is usually pre-defined, since it has to fit to the data received from the external system. For example, for an ABAP proxy, the source structure is the type of INPUT parameter of the proxy class method.

 

Target Structure

The target Structure is sent from AIF to the final destination. In an Inbound Interface it is the SAP structure in an outbound Interface it is the RAW Structure.

 

Outbound Interface

For an outbound interface, the destination structure is usually pre-defined, since it has to fit to the data required by the external system. For example, for an outbound proxy interface, the structure is defined by the proxy class method's OUTPUT parameter. The raw data structure is the destination structure.

 

Inbound Interface

For an inbound interface, you usually have to create the destination structure in the ABAP dictionary. How the structure should look, depends on the functions you want to call in your actions. The SAP data structure is the destination structure. In our example, we will create customers and flight bookings by calling the corresponding BAPIs. Therefore, the destination structure has to contain the BAPIs' structures.

 

Engines

How an interface is processed and monitored in AIF is driven by the enginges. AIF knows 4 different engine types as shown in the figure. For all this engines at least one AIF own engine is provided. Also for a lot of interface technologies like IDoc or Proxy engines are delivered which use the origin interface technology inside of AIF.

The Application Engine determines how the received messages should be handled in Monitoring and Error Handling. Which application engine handles the requests depends on the technology used to process the data messages.

 

AIF delivers some standard engines:

• Proxy - Handles messages received via proxy form SAP NetWeaver PI or via a web service
• IDoc - Handles IDocs that are processed with ALE Runtime
• XML - Handles messages processed with AIF's XML runtime
• Test File - Handles test files that have been created with the AIF test tool
• ECH - Handles asynchronous data messages received via a proxy from SAP PI but processed by the Error and Conflict Handler application. Each message will have a corresponding postprocessing order (only available with AIFX and NetWeaver 7.31)
• BDC - Handles BDC messages
• CIF - Handles CIF messages
• qRFC - Handles qRFC messages
• tRFC - Handles tRFC messages

 

The persistence engine determines which persistence engine class is used to retrieve or update the data messages on their corresponding persistence layer. Which persistence engine should be used depends on where the interface persists the processed message content.

 

AIF delivers the following standard persistence engines:

• Proxy - Handles the data content of data messages processed by the local integration engine.
• IDoc - Handles the data content of data messages processed by the ALE Runtime.
• XML - Handles the data content of data messages stored in AIF's own persistence layer.
• Test File - Handles the data content of files processed with the AIF test tool.
• ECH - Handles the data content of messages processed with the Error and Conflict Handler application. Includes load data and save data as new version (only available in AIFX and NetWeaver 7.31).
• BDC - Handles the data content of BDC messages.
• CIF - Handles the data content of CIF messages.
• • 1
  • 2
  • 3
  • 4
  • 5