Since AIF is not involved in processing, no index tables exist. Therefore, AIF selects the IDocs data to be displayed in the Data Messages view from the IDOC control records.

For a scenario 1 IDoc interface, you have to specify the interface engines as follows:

• Application Engine: IDoc
• Persistence Engine: IDoc
• Selection Engine: IDoc Control Records
• Logging Engine: IDoc Status Records

 

If the generation report is used to create the interface, the engines are already set accordingly for the interface.

 

Scenario 2: Process IDocs Using AIF

With scenario 2, the data from an IDoc is processed by AIF before the IDoc standard processing function is called from within an AIF action. In this scenario, you can use checks, value mappings, and alerting. Also, the Interface Monitor can be used.

 

 

To send an IDoc to AIF special Function Modules are delivered. One of them is /AIF/IDOC_INB_PROCESS_FUNC_0 which can be used for every Message Type.

 

The Coding of the Action is always the same:

CALL FUNCTION '/AIF/IDOC_ACTION_FUNCTION'
 EXPORTING
iv_idoc_function = ‘'
 TABLES
return_tab = return_tab
CHANGING
data = data.

 

As AIF does not know for which Message Types and Basic Types Scenario 2 shall be used at the customer site, no Customizing is delivered.

 

That means you have for every Message Type/ Basic Type combination you want to use to do the Customizing yourself. The Side above shows the example we use in the exercise. Now when a message Type FLCUSTOMER_CREATEFROMDATA is sent from the Logical System ZAIF_S001 it will be forwarded to AIF.

 

For a scenario 2 IDoc interface, you have to specify the interface engines as follows:

• Application Engine: IDoc
• Persistence Engine: IDoc
• Selection Engine: AIF Index Tables
• Logging Engine: AIF Application Log

 

If the generation report is used to create the interface, the engines are already set accordingly for the interface.

 

Step 4: Maintain IDoc Customizing

To use the AIF IDoc scenario 2 and 3, you need to change the standard IDoc Customizing.

The steps required to process an IDoc via the AIF processing function are:

• The AIF function module needs to be assigned to the basic type and message type used in the IDoc (transaction WE57)
• An inbound process code is required. The AIF processing function module needs to be assigned to the process code (transaction WE42)
• The process code in the partner profiles is changed to the process code maintained for the AIF processing function module (transaction WE20)

Scenario 3: IDoc/BAPI Implementation and Monitoring

With scenario 3, the data from an IDoc is processed by AIF before the IDoc processing is started from within an AIF action. The processing can be done in a function module, a BAPI, and so on. In this scenario, you can use checks, value mappings, and alerting. Also, the Interface Monitor can be used.

 

The main difference between scenario 2 and 3 is that a structure mapping is usually required for scenario 3. Since a BAPI or other function is called, the source structure differs from the destination structure, which makes a structure mapping necessary.

 

In scenario 2, the standard ALE function is called, therefore, the source and destination structure are identical and can be mapped with the Move Corresponding function in the easiest case.