Skip to Content

Michal’s tips: Application Interface Framework (AIF) 2.0 – monitoring existing IDOCs

SAP Application Interface Framework (AIF) is a new tool for monitoring and error handling of all interface in one place. You can use it to monitor your IDOC and ABAP proxy scenarios in one place which was not possible in the past. For more features on AIF please have a look at AIF introduction on

In this article I’d like to show a simple example of AIF on how to monitor existing IDOC scenarios, that is without changing any of your IDOC configuration. We will be doing configuration of the AIF to be able to monitor one inbound IDOC – SYSTAT01 in order to be able to see it in the AIF’s Monitoring and Error Handling application.

Step 1

At first we need to create a new namespace in which we will be doing the configuration (it’s just a way of grouping for customizing objects). We can create it from transaction /AIF/CUST_IF – Interface Development – Define Namespace. Add a new namespace and save it as show in the Figure below.


Step 2

Then need to generate a new IDOC structure which will be used in AIF. We can do this in transaction – /AIF/IDOC_GEN.

Insert the following:


– the basic type of the IDOC which you want to monitor

– a prefix structure (any custom name – you can use name but I stick to Y/Z objects)

– a prefix interface definition (any custom name – use Y/Z objects)

– a namespace (created in step 1 of this article)

– an interface version – 1

– a variant ID = 01


Once you’re in the generation screen (after pressing F8 – Execute) you canΒ  generate it. If the generation was successful you can copy the Raw Data Structure’s name as we will be using that in the next steps.


Step 3

In the next step you need to define an interface which will be used in monitoring. Transaction – /AIF/CUST_IF – Interface Development – Define Interfaces.

– Insert the interface name

– Insert the interface version

– SAP data Structure = RAW data structure (from the IDOC generation step)

– make sure “move corresponding structures” check if selected


Step 4

As a next step you need to define which engine will be used to handle the interface. Transaction – /AIF/CUST_IF – Interface Development – Additional Interface Properties – Specify Interface Engines. The engine should also be defined by the variant ID selected in /AIF/IDOC_GEN.

Insert the following:

– Application Engine = IDOC

– Persistence Engine = IDOC

– Selection EngineΒ  = IDOC control record

– Logging Engine = IDOC status record


Step 5

As a last configuration step we need to assign the IDOC type to the newly created interface from Step 3. Transaction – /AIF/CUST_IF – Interface Development – Additional Interface Properties – Assign IDOC type. Select your interface from Step 3 and insert IDOC’s Message Type and IDOC’s Basic Type.



Now you can run your standard IDOC scenario one more time and this time apart from standard IDOC monitoring transactions (WE02/WE05) you will be able to see it the AIF’s Monitoring and Error Handling application. Transaction –Β  /AIF/ERR


You can also display the message payload and edit it.



This is just the first view of AIF – in the next articles I will try to show all AIF options for monitoring of IDOCs and ABAP Proxies, index tables, doing validations and mappings so please stay tuned.

You must be Logged on to comment or reply to a post.
  • Hi Michal,

    Thanks for sharing this. Can you shed some light on the licensing model? I know that AIF require separate license. How do you justify customers to use AIF over free options like FEH for ABAP proxy?


    Prateek Raj Srivastava

  • Hi Michal,

    Thanks for keeping the PI/PO community informed about these updates on the front.

    If I understand good AIF can be positioned as an alternative for PI in some specific cases, e.g. less complex integration sceanario's, no adapter needed etc.. Generally speaking AIF is a light version of PI. Do you agree on that?



    • hi Roberto,

      >>>Generally speaking AIF is a light version of PI. Do you agree on that?

      not at all πŸ™‚  

      AIF is only able to work with proxies, rfc, and IDOCs but cannot send/receive them from files or any other adapter - there needs to be the something like PI (or any other middleware which will be able to work with real adapters)

      so AIF is more like WE02/We05/SXI_monitor + a few features in one application

      but certainly not a light PI πŸ™‚   it's more like light version of Solman I'd say πŸ™‚


      Michal Krawczyk

      • Hi Michal,

        That was exactly what I was hoping for ;-).

        However, at AIF is described with a broader scope than only monitoring interfaces.

        How about that? πŸ™‚


        The SAP Application Interface Framework enables you to develop and monitor interfaces as well as execute error handling in a single framework residing in your SAP back end system.

        • Hi,

          >>>How about that? πŸ™‚

          so this the processing framework as shown in my second blog on AIF πŸ™‚

          still the same thing - generic monitoring tool for all SAP interfaces

          with some simple mapping functions, nothing related to adapters, scheduling, etc.

          so for me it's only way better WE02/SXMB_MONI with many new functions (index tables, alerting, etc.) just I said it's like FEH/ECH for all interfaces (not only proxies)

          but you know - I might be wrong πŸ™‚


          Michal Krawczyk

  • Dear Michal,

    Please provide some post for Outbound IDOC.

    Error Handling for Outbound IDOC and Recipients configuration for this.

    With Best Regards

    Sayantan Das

  • Hi Michal,

    thanks for the helpful summary.

    In Step 4 you have assigned your Namespace "TEST" to each engine except to the logging engine. Why?

    The standard IDoc processing doesn't know any namespaces, right?!. So which sense does it make assigning one here?

    Best regards


  • Hi Michal,

    Basically, AIF should implement on Application system like ERP etc.

    However is it possible to implement AIF on PI system just for a demo test?



  • Hi Maichal,

    Thank you for share this scenrio.

    When I generate Idoc it occured an erro. Could you please help to solve it.

    error msg:

    Number range /AIF/ISG failed

    Error during structure generation. Processing stopped.

    Thanks & Regards,


  • Thank you Michal for bringing up this topic & highlighting its benefits.

    Apart from above advantages, it can be used for,

    1) Moving the Business logic from PI to AIF[Add on to ECC].

        so far, we had restrictions of implementing Business Logic in IDOC scenario

        AIF helps a lot in implementing business logics before IDOC generation.

        Hence, we can use PI for structural mapping & ECC for busines logics.

    2)Moving Value mappings, RFC Lookup to ECC,  to AIF.

       If any customer is using Huge value mapping tables in PI for validation purposes. Those        tables & Logics can be re-implemented in AIF. This improves the performance on PI.

       if we are using RFC lookups to ECC system in an IDOC scenario, that would drain the        performance of the message. By moving the RFC lookup logic to AIF, it would drastically    improve message perfromance.