Today, I`d like do some enhancements on another main AIF tool - 'Interface Monitor'.

The enhancement spots '/AIF/INTERFACE_MONITOR' is in same package with 'Error handling'.



1, To create an enhancement implementation and related implementing class, as below figures:



2, Write your code in method 'CHANGE_CAL_COLOR_TIP_BY_DATA'.

    Importing parameter 'IT_ALL_KEYS' holding all the interfaces which you are monitoring.

    Changing parameter 'CR_CALENDAR' is that Calendar`s instance. Example code as below:


     In this code snippet, I specified Feb.18&19&20 with yellow and tooltip 'Spring Festival'.


3, Result in 'Interface Monitor', run '/n/AIF/IFMON'.



NB. In my ABAP code, some grammar is news for Release 7.40, I just use it to practice.

You`d better use old grammar to avoid syntax error.




When an SAP backend system is being called from another SAP backend system with the use of tRFC currently we have no ways of monitoring errors in such integration scenarios. In case the tRFC call fails on the destination system in some cases the users on the calling system would like to:


a) know what kind of error occured in the destination system

b) restart the tRFC call without running the initial transaction


AIF 3.0 (new version available as of October 2014) offers a new functionality which can help to solve both of those issues. It’s now possible to create an AIF interface which will enable monitoring of tRFC calls which ended with an error on the destination system. Furthermore with AIF 3.0 it’s also possible to restart those errors and even debug the tRFC calls on the destination system directly from the calling system. Below you can find a list of steps required to customize such an integration scenario.



Step 1


Create an RFC enabled function module on the destination SAP backend system or use an existing one.






Step 2


Create the AIF interface on the SAP backend system which will be calling remotely the RFC created on the destination SAP backend system from the previous step. You can create this new AIF interface by running a new, special report: /AIF/RFC_FUNC_GEN with the following parameters:


  • RFC Type - select - tRFC status table

  • Original RFC Function Name - the name of the RFC enabled function module which exists only on the destination SAP backend system (from Step 1)


  • Prefix of New Objects - prefix for the new created objects


  • Playback Function Name - this module will be created in the calling SAP backend system with the same signature as the original one from the destination . We need this module for the data transformation.


  • Name of AIF Structure - which will be automatically generated on the basis of the structure of the RFC enabled function module


  • Destination for Original Func. - this is the RFC destination of the SAP backend system on which the RFC enabled function module will be executed (destination SAP backend system)


  • Namespace - namespace of your new AIF interface


  • Interface Name - interface name of your new AIF interface


  • Interface Version - interface version of your new AIF interface






Step 3


Execute the report/transaction on the calling SAP backend system which will send the data to the destination SAP backend system. Only if the tRFC call fails we will be able to monitor that call in AIF. In case the call is successfull we will not see any data in the AIF monitoring transactions. As you can see on the figure below the failed tRFC calls are visible in the AIF monitoring transaction and we can even monitor the data from the RFC structures (name, data, creator).





Once the call failes as shown in the figure above we will be able to restart the call from AIF using the restart button or even debug the tRFC call using the debug button. Debugging will take the user from the calling SAP backend system to the destination SAP backend system on which the RFC module is being executed as shown in the figure below.




Please keep in mind that once all tRFCs calls are successfully corrected all the entries from the AIF monitoring transaction will be gone and not marked as successfully completed as with other AIF scenarios.




tRFC and qRFC - SAP Application Interface Framework - SAP Library

Sometimes we need to post a transaction which locks a certain object and other transactions using the same or other interfaces cannot get posted at the same time. What happens in that case is that interfaces fail and only the first one gets posted as shown in the figure below.





Then the interfaces which failed need to get restarted, either manually or in some cases we can restart them automatically.


AIF 3.0 (new version available as of October 2014) offers a new functionality which can help to solve such issues without the necessity of restarting the interfaces which failed. The new function is called - Serialization - Paralell Processing and in this article I will try to describe the steps required to customize this new function.


The idea behind this functionality is that we can use a predefined locking object which can tell AIF if the transaction is currently being locked and if such a situation happens, we can wait for a predefined amount of time, before we try to process the message so it will not fail with the locking error. We can add this functionality to any of your existing AIF interfaces suffering from the locking issues using just the customizing.



Step 1


At first we need to define the fields of the interface which can be assigned to the locking objects. With AIF we can do that by defining the Key Fields. In order to do that we need to create a new AIF index table with all fields which will be used by the lock object as per the figure below. In this case I’m using a flight demo scenario and I will have two locking fields (AIRLINE_ID and BOOKING_NUMBER).





Step 2


Then we need to define both of the Key Fields in the /AIF/CUST/ - Error Handling - Define Interface-Specific Features





Step 3


In the next step we can define a serialization object /AIF/CUST/ - Interface Development - Additional Interface Properties - Define Serialization Settings, where we can select the locking object and most important parameters like: wait time (time the AIF runtime needs to wait before processing the interface which was locked) and Max. No of Retries (self explanatory). In case of the flight booking scenario we can use the ESBOOK lock object as shown in the figure below.




Step 4


Once the lock object is assigned we need to assign it to the AIF interface and we can do that in the same menu as Step 3.




Step 5


The last customizing step is to assign the locking fields to the AIF Key Fields (defined in Step 2). The assignment is done on the basis of the locking object fields and Key Field sequence number.






Once all the settings are done we can try testing the new scenario and if we send multiple messages with the same lock key at the same time this time they should not fail but stay in the processing mode (till the wait time from Step 3 is reached) as shown in figure below.





Once the lock is free and assuming the Max. No of Retries parameter from Step 3 is not reached all of the interfaces should get posted without any issues as shown in figure below.






I hope that gives you an idea on how this type of AIF serialization is working. In the next articles I will try to describe other features of AIF serialization (external, internal indexes).

In last blog,,

I wrote how to enhance toolbar on View3. Today, i`d like enhance the editability of cells on View3.

As you know, we could set cells editable or not by Customizing,

/AIF/CUST -> Error Handling  -> Define Interface-Specific Features/Define Namespace-Specific Features -> Define Changeable Fields.


Except this, we could do more by implement BADI '/AIF/V5_CHANGEABLE_FIELDS', like according record type to set editable,

or according a certain value of other cells to set current cell editable. Let`s do it.


1, Create BADI Implementation,  '/AIF/V5_CHANGEABLE_FIELDS'.



2, There are three methods, which is independence.


4,  The Method 'INIT', it is called before every displaying data. we could write code in it like below:


The result as below, 'ADD_DATA1' the whole column become editable. 'ADD_DATA_KEY' is editable, due to i set it in Customizing:


5, The method 'GET_FIELDS_PER_RECTYPE', will be called for record type under structure in View2.

    CR_DATA containing the whole data of current message which you double click.


   The result as below, 'ADD_DATA2' become editable:


6, The method 'GET_FIELDS_PER_LINE', will be called for each data in View3. CT_DATA is current data in View3.

    How many data rows in View3, this method will be called how many times. In my example, it will be called twice.


  The result as below, 'ADD_DATA3' column, only the cell which 'ADD_DATA1' equal 'CNN' become editable :



With this BADI, you could dynamical set cells editable, it make Error Handling more flexible.




As of October 2014 the new version of AIF (3.0) is available and with the new version lots of new functionalities are available. One of them is the new mapping Analyzer. With this new tool you can now trace single steps of a mapping execution and this way find the issues much more quickly then if the mapping program runs in a single run. This is a different approach if we compare the SAP Process Orchestration Message Mapping tool which cannot display the intermediate results of the mapping. Let's see how does it work.



Step 1



At first you need to create an interface and a mapping which can be used by this interface.



Step 2



Next you can test the interface in the "Interface test tool" - TCODE - /AIF/IFTEST/ and after you populate the data in the test structure use the new Analyze button to go open the new tool.





Step 3



In the Process Step section you can now open each of the nodes of the Structure mapping and on the right hand side you will see the result values. As you can see in the example before the RAW_ADD_DATA_T structure is being processed the values of DATA1 and DATA2 fields contain the "pre mapping" prefix and data4 field has a value - "STANDARD".





Step 4



After we click on the DATA2 structure in the Process Step section the mapping for DATA1 and DATA2 fields will be executed and on the right hand side we will get the intermediate result for this small part of mapping execution only (in this case we remove the "pre mapping" part).






Step 5



The next step is to see if the value mapping for DATA4 field is working correctly and in order to do that we need to select the DATA4 field in the Process Step section and then click on the Conversion element of the DATA4 field mapping (conversion from value "STANDARD" to value "P"). This will start the value mapping of the DATA4 field and we will be able to see if the conversion was executed as expected giving the correct result in the right hand side.






I hope this blog has explained the new - Analyzer - feature in a simple way. In the next blogs I will try to show some more new functions of the AIF 3.0.

I`d like to continue last blog

Today i will write something about toolbar enhancement on View3 and View5 in 'Monitoring and Error Handing', TCode: /AIF/ERR.

What is View3 and View5, Maybe some new developers to AIF will have this question, here it is:

View1 is Data message view.

View2 is Data structure view.

View3 is Data view.

View4 is a technical view, you need tick 'technical mode' check box on selection screen, then it will display.

View5 is log message view.


First, let`s enhance View3. In '/AIF/ERROR' package, enhancement spots '/AIF/ERROR_HANDLING'.

1, To create a BADI Implementation:



2, To create a Implementing Class:



  4,  Write your logic in this two method:

         'GET_FUNC_LIST' is used to set the function code,

         'DO_ACTION' is do action when you click button on toolbar.




5, Activate class and BADI, the result on View3:


Second, go to enhance View5.

1, To create BADI Implementation and Implementation class:


2,  Write your own code in below method, GET_ACT_LIST and DO_ACTION is same with View5, used to set  a button on toolbar and response it:



3, Activate Class and BADI, result like below, the new added button on toolbar of View5,


  When you double click the line item:



Actually, each BADI have it`s own example implementation,  it`s very easy if you take a look at it .

I will soon back for other enhancement. see u.




As of October 2014 the new version of AIF (3.0) is available and with the new version lots of new functionalities are available. One of them is the preprocessing function. This new functionality can be used in two cases:



- in case you'd like to use an SAP standard Enterprise Service but before it's execution you'd like to change some of the fields - perform a mapping (master data lookup for example)


- in case you have a custom Enteprise Service or a simple custom proxy message and you'd like to implement a mapping without changing the existing code


In both cases it would be possible to implement the mapping in the code of the Enterprise Service/proxy either in the BADI/enhancement spot or in the custom proxy's code but why it is better to use the AIF for doing the premapping:


- you don't need to modify the standard object - how can a standard Enterprise Service be still standard if you change it heavily in the BADI/enhancement ? With AIF you can still call the original Enterprise Service in a second interface without using the new mapping


- BADIs/Enhancements are very often implemented in multiple places of the Enterprise Services or custom proxies and if we want to be able to govern the interfaces easily we should put all mappings in the same place (AIF structure mapping step)


What are the required steps to use the new functionality:


Step 1



Select the preprecessing checkbox in the interface definition of your AIF interface: SPRO - Interface Development - Define Interfaces





Step 2



Next you need to create a mapping: SPRO - Interface Development - Define Structure Mappings.

Select the source and destination structures of your Enterprise Service - in this case it's going to be the same structure. As a next step you can implement a field mapping where you can use the AIF value mapping table to change the values of the fields from your interface.






Only those two steps are required to implement the new functionality, now when you send the new message with the use of this interface the mapping step will be performed as a first step before the standard Enterprise Service gets called.



In the next blogs I will try to show some more new functions of the AIF 3.0.

Value conversion in SAP interface communication – architectural thinking

This article discusses the SAP technologies and key points that need to be addressed when an SAP solution is needed for value conversion in business process integration scenarios across systems. The article is based on SAP recommendations which have been enriched with additional architectural key points. The first part of the article explains value conversion in general. The next chapter discusses SAP technologies for value conversion. The third chapter analyzes architectural key points of value conversion that need to be taken into consideration. In the last chapter, the SAP technologies are explained in different architecture scenarios which are based on SAP’s recommendations and the key points discussed in chapter three.


Value conversion basics

Many different types of IT systems can still be found in many organizations. Each system contains its own data and semantics, especially in enterprises that are spread across multiple companies and geographies. Problems are likely to occur when data is exchanged between these systems via interfaces.


A simple example of a value conversion issue could be the representation of country codes in different systems. One system could use the letter “D” for Germany and another uses the common notation “GER”. When data including country codes is exchanged between these systems, the operations will fail because the systems do not work with different representations except their own. A mechanism is needed to convert the sender value to the expected receiver value. This kind of value mapping is classified as a functional value conversion, because the content is critical for correct transactional processing inside each system.


Other value conversions, such as the conversion of system names, are needed only for technical reasons. This type of mapping can be technically necessary to enable communication between the sender and receiver system. The functional departments are not concerned about these types of technical details. They will also not feel responsible if errors occur in this type of mapping. The separation between technical and functional value mapping is important when we discuss different value mapping approaches later on.


The definition of one single representation of a value (e.g. unique customer numbers) in the whole company could be considered a solution from an architectural point of view which would make value conversion unnecessary. In practice, this is often not applicable, however, because each business unit is interested in keeping its own representation in its system. Making changes would also incur additional costs and the users would need to get used to the new representation. In a worst case scenario, it would be impossible to make any changes for certain terms as they are hard-coded by a third-party vendor. In such cases, another solution will be needed for value conversions.


This section briefly discussed what “value conversion” is about and why a concept is needed to handle it. The next chapter explains the technologies that SAP recommends.



SAP Technologies

In this section, we discuss the SAP Process Integration (PI) and SAP Application Interface Framework (AIF). Both are intended to connect interfaces with each other and both explicitly provide value conversion functionality. Other SAP middleware products, such as SAP gateway, are not discussed here because they do not focus mainly on interface integration and value mapping.


PI is the middleware which is able to deal with different technologies (like file, SOAP, RFC, etc.) and the mapping of different interfaces on message type level. The middleware seems to be designated for message transformation and value conversion. The source system sends data to the middleware, maps the values (e.g. from “D” to “GER”), and delivers the message to the receiver.

SAP PI provides different standard concepts that can be used to map values between interfaces. These concepts, which are “Fix values”, “Value Mapping”, “Value Mapping Mass Replication” and “RFC look-Up”, will be discussed briefly.


Figure 1 SAP PI as a middleware.png

Figure 1: SAP PI as a middleware


The most basic option in PI is “Fix Values”. The value pair is entered and used for the specific target field mapping only within the enterprise service repository (design time). The value pair cannot be re-used in other message mappings or target field mappings. Maintenance and look-up of the value pairs are done in PI because no mass upload of values is possible. You can only enter source and target values and there is a 1:1 relationship between them. This option is recommended if you only want to map very few values by hand and the mapping is not to be re-used in other message mappings. The following figure shows a “Fix Value” example in PI.


Figure 2 Fix Values.png


Figure 2: Fix value in SAP PI


“Value Mapping” is another more complex option in PI. The value pair is entered in the integration directory (configuration time) and not directly in the target field mapping, like fix values. It can be re-used in all message mappings. Maintenance and look-up of the value pairs are done in PI. The creation of value mapping pairs is done manually and you need to specify additional meta-data, such as scheme, agency, and a context, for each individual value, which requires a sophisticated naming convention. Inside the Enterprise Service Repository (ESR) in the target field mapping, you must enter the source scheme and source agency of the source value and the target scheme and target agency for the target value. You must also define the context.

All values that belong together are classified as a “Value Mapping group.” In this group, there is no predefined source and target value. You can convert values in both directions based on the semantics that you use for source and target scheme and agency in the target field mapping. Compared to fix values, you can have more than two values in one group.

The following table is an example of a representation of the same person, Mr. Smith, in different systems:







System A


Mr Smith


System B




System C



Table 1:  Entity representation with value mapping


Based on the determination for context, agency, scheme and source value, the looked-up target value may differ.


“Value Mapping Mass Replication” is an extension of “Value Mapping”. Mass upload of value pairs is done via java inbound interfaces on PI. This allows any back-end system to store and maintain value pairs which can then be replicated to PI.

It is impossible to replicate values from PI Cache to the back-end. Only back-end to PI replication is possible.

Caution: Back-end and PI Cache should always be in sync. If the conversion rule base is updated in the back-end, the information needs to be replicated to PI. In the meantime, the value mapping cache in PI will not be up-to-date. If interfaces are running during this timeframe, inconsistency and false mappings may occur.


When using “RFC Look-up”, the value mapping pairs are saved in a back-end system.

During run-time, the value mapping pairs are looked up dynamically in the back-end.

The look-up API supports RFC, SOAP und JDBC.

The inbound and outbound interfaces of the look-up need to be configured in the ESR.

The communication channels also need to be set up in the Integration Directory.


PI is one solution in which data conversion can be converted. SAP also introduced AIF as another technology which is an add-on that is to be installed on each SAP back-end system. It enables interface development, monitoring and error handling. The functionality of the framework is performed before the actual inbound or outbound interface is executed in the SAP back-end system during run-time.



Figure 3 AIF and PI.png

Figure 3: SAP AIF combined with SAP PI


This SAP framework provides functionality to implement value conversion in interfaces without or with very little coding effort via customizing transactions. These value mapping objects point to different SAP tables which are to be looked-up during run-time to retrieve the value needed. If a more complex mapping rule is needed, a custom function module can be developed and called by AIF to do the conversion. Another advantage is the re-use of value mapping objects in several interfaces. AIF even provides advanced error handling capabilities such as automated notifications and mass correction, which are also useful in correcting value conversion errors. The error notifications can be directed to different users based on their roles to speed up error correction and reduce coordination effort. That allows the functional end-user to do the correction directly. Mass correction of the same type of error in several messages can be done to make things easier. AIF can be combined with SAP PI, but it can also be used alone. Because AIF is only to be installed on each SAP back-end system, AIF cannot be used in pure non-SAP scenarios that only involve legacy systems. The AIF interface development, functional mapping and monitoring functionality complements the interface transformation, technical mapping and routing functionality of PI.



Requirements for a value mapping architecture

When developing a solution for value conversion, the following points need to be taken into consideration before choosing the appropriate SAP technology:


System landscape: Are SAP systems involved? AIF cannot be used in a scenario that involves only non-SAP systems. Nevertheless, PI can always be used as a middleware technology. If value conversion has already been implemented in PI for such scenarios, it might be appropriate to re-use it in scenarios where SAP systems are involved instead of re-implementing value mapping in AIF, if it is introduced afterwards. On the other hand, if there is at least one SAP system involved per scenario, you can consider moving functional value mapping to AIF.

SAP recommends that AIF be designed for functional value mapping, functional error correction and user notification. PI is designed for message transformation of different interfaces, message conversion of different protocols and routing of messages to different target systems. Technical interface monitoring is also to be done in PI.

This recommendation makes sense as both technologies have strengths and weaknesses and can be combined in an effective manner.


Maintenance: Who should maintain the value conversions? The technical team is responsible for IT-systems, like the middleware. Typically, IT teams do not update functional conversion rules. They expect the functional departments to maintain these values because it is their area of responsibility. However, the functional departments do not want to work with any other system besides their own. They consider another system, such as a middleware engine, to be an additional burden and double work. A solution is needed which is acceptable for both departments, functional and IT. This again emphasizes the split between technical and functional mapping rules for which each department is responsible. If AIF and PI are combined, then PI should attend to technical conversions and AIF functional.


Possession of data: As described, an easy solution would be to save the value conversions directly in the middleware. Other solutions would be to save the conversions rules in the sender or receiving system. It could also be possible to replicate conversion rules between several systems. In the end, the concept must take into consideration who the owner of the conversion rules is and who is responsible for updating them. A master system needs to be defined. The master system should be the system that is to be used over the long-term.


Interface dependencies: There can be situations in which dependencies between interfaces must be considered. Let’s say there are two interfaces between two ERP systems. One interface replicates vendor master data and the other vendor account payable bookings. Critical for the target system is that the vendor number of the sender is always converted to the vendor number of the receiver system, as they have different number ranges. If a booking is passed before the vendor master data was replicated, the booking might fail because the vendor number does not exist yet in the target system. Even if the vendor master data was replicated before, the conversion rule must be updated first, before the other interface is executed. This means that if PI contains the conversion rule, it needs to be updated with the new vendor master data by the receiving ERP system before it can process the interface.


Timeliness of data: The example involving the vendor master data demonstrates that the conversion rule base must always be up-to-date in order to be able to execute other interfaces successfully. On the other hand, country codes are rather static as they do not change very often. In this case, a solution might be sufficient by which the conversion rule base is not updated that often.


Performance: Performance is very important in cases where the end-user expects real-time processing. Other scenarios do not demand high performance, e. g. when data is replicated at night and the user expects the updates the next day. A middleware usually leads to more processing overhead and less performance. The performance drops even more when the middleware also needs to do look-ups in other systems, e.g. to find a conversion rule for country codes.


Re-usability: When the conversion rule base is replicated between several systems there is redundancy and always a risk in terms of obsolete data. Implementing a central conversion rule base eliminates redundancy and increases re-usability. However, it might lead to worse performance because each conversion request needs to be routed to the central conversion rule base. The non-functional requirements need to be taken into consideration here and the right trade-off between performance and redundancy needs to be evaluated.


Error handling: How errors are handled represents an important aspect. A distinction is made between functional errors (wrong values) and technical errors (incompatible message types). A decision must be made as to who is responsible for certain types of errors and how they should be corrected. Audit requirements, e.g. for financial bookings, demand transparency in this process which usually results in a copy of the original broken message. Especially when it comes to defining role-based error handling, one must distinguish between technical and functional errors.


Development effort: Different solutions for value conversions also mean different degrees of effort for implementation. This must be taken into consideration during evaluation to find a solution that is worthy of being implemented. The more SAP technologies are used and combined, the higher the costs for implementation, licenses and operations.


SAP architectures

When considering the architectures of several systems that communicate with each other, we must distinguish between a middleware and a point-to-point architecture.


In a point-to-point connection, the sender and the receiver systems communicate with each other directly, without PI. If the number of interfaces increases, point-to-point connections will be difficult to maintain. A middleware often reduces both the effort and the costs. Nevertheless, point-to-point connections still often exist because they do not generate additional overhead compared to a middleware. Point-to-point connections usually result in very good performance. In terms of conversion rules, either one or both systems may establish a conversion rule base. As for communication that involves SAP, the AIF is designated for such scenarios. It still allows for high performance and conversion for inbound and outbound interfaces. When communication between two SAP systems takes place, one system needs to be defined as the master and do the value mapping. The systems also remain autonomous and the users do not have to work with additional systems. To reduce redundancy, as few as possible systems should contain the conversion rule base.



Figure 4: Point-to-point connections


By using PI as a middleware, the central mapping instance is highly re-usable, but the performance is worse compared to point-to-point. The middleware needs to be maintained with the conversion rules, which can lead to more effort compared to local implementation with AIF, for example. When PI is used and SAP back-ends are involved, AIF can also be used, which is what SAP recommends. As both technologies enable interface development and operations, one needs to discuss whether tasks can be split usefully, especially because value mapping is available in both products. The technical IT is usually aware of technical mappings and they also maintain the technical system details. It makes sense to assign responsibility for the technical mapping to them and execute it in PI directly. On the other hand, functional mapping rules are usually defined in the back-end systems that the functional departments responsible use.



Figure 5: SAP PI as central middleware



Implementing a value mapping concept in SAP is a complex topic that needs to take several key points into consideration. Different scenarios are possible depending on the requirements and the usage of SAP PI and/or AIF. Ideally, SAP PI and AIF are combined to differentiate between technical and functional value conversion and to allow for role-based error handling. If only one of them is used, another approach will be needed. Also, different value mapping concepts can be applied within PI. Each one has strengths and weaknesses which need to be evaluated for the problem statement. The following table shows where specific types of mapping should take place.



PI only

AIF only


Functional mapping




Technical mapping




Table 2: Usage of SAP PI and AIF


The following table also shows the difference between PI and AIF in terms of value conversion as well as the advantages and disadvantages of each mapping concept in PI:




Mapping with AIF only

Fix Values in PI

Value Mapping in PI

Value Mapping Replication in PI

RFC Look-up in PI

SAP Standard




PI only

Back-end custom development

PI only

Back-end custom development







Development effort

Low - Middle

Very low




Re-usability of values in message mapping

Limited – non-central approach





Amount of pairs to be handled






Default exception handling when no matching value was found

No restrictions

  • Pass original source value to receiver
  • Set default value
  • Throw exception

Accuracy of data

Always up-to-date

Need to be updated by hand

Depending on replication interval, data can be outdated

Always up-to-date

Conversion rule







Table 3: Overall recommendation


  • You have some basic knowledge of AIF
  • You would like to implement your custom functionality in toolbar
  • You are a ABAPer.

There are two alternative approaches to achieve this:

Ⅰ. Through the custom configure,

      1, To copy the standard status '/AIF/ERROR_HANDLING_TRANS/0300' to your 'Z' status, add your custom function code.


      2, To copy the standard 'Action handler' class '/AIF/CL_AIF_ACTION_HANDLER' to your 'Z' class.

          Add a method, keep name with 'ON_[FunctionCode]_[Number]' format, number means the view number,

          you can find similar method in this class. For my example, the method name is 'ON_SIMU_0'.


      3, To open the 'Define Applications' in /n/AIF/CUST. To replace 'Action handler' with your 'Z' class, type your custom status here.


     4, When you click the button on toolbar in /n/AIF/ERR, Result will be like this:


Ⅱ. Through BADI.

     1, You can easily find there are some useful enhancement spots in '/AIF/ERROR' package,

         what we wanted is '/AIF/V1_ACT' BADI. Also you can implement other BADI which works for other view.

         To create a enhancement implementation,


     2, and create a BADI implementation under it.


     3, 'GET_FUNC_LIST' is used to set the function code,

         'DO_ACTION' is do action when you click button,




     4, When you click the button on toolbar in /n/AIF/ERR, Result will be like this:



You will find it is more flexible using BADI to achieve same functionality, due to you can according values in 'AIF KEYS'

to decide this interface whether have this toolbar button.

This is my first blog, hope it`s useful, Please feel free give me suggestion or comments.


Best regards,


SAP AIF provides robust error handling mechanism along with Alert Notification where Alerts can be triggered to specific Recipient in case of Application Error. However, sometimes it is required to distribute the alerts to different Recipients based on who sent the message (e.g. If Sender system is ‘SenderSys1’ then Alert should be triggered to “Recipient1”).


SAP AIF Provides key field based Recipient determination for this purpose. This document explains steps to configure key field based recipient determination.


Step1: Define Index table containing the field on which you need to raise alert: Copy /AIF/STD_IDX_TBL into interface specific index table (e.g. Y0001_IDX_TBL). Add required Key Field on which routing needs to be defined (e.g. Sender System)




Step is only required if field on which recipient is determined is not available in AIF’s standard index table /AIF/STD_IDX_TBL.


Step 2: Assign Index table to your interface





Step 3: Define Alert recipient table by copying /AIF/T_ALRT_DEF


This table will be used to identify routing conditions for determining Recipients.




Step 4: Define different Recipients (Error Handling ->Namespace Specific Features ->Define Recipients)




Step 5: Assign different users to Recipients (System Configuration ->Assign Recipeints)



Step 6: Populate the table with different Recipients based on Key Fields value:




Step 7: Use custom Alert recipient table in Error Handling -> Namespace Specific Features ->Configure Alerts. Recipients will be identified based on this table by supplying key fields from Source message.



Assign appropriate alert category to be used.

Step 8: Define key field and assign that as to be used in Alert Recipient Determination in Error Handling -> Interface Specific Features.




After this configuration, if you execute your message and if it fails , Alert will be triggered to specific recipient based on Sender System. This can be changed to any particular fields from Payload (e.g. Company code or Department).


Limitation: Key Field based Alert determination is not allowed when Multi. Selection Type is selected as “Multiple Selection” (i.e. the data messages are selected from the multiple index table)



In /AIF/IDOC_GEN, you work with IDoc Types which start with "/". 1.png

You might get error message like "Separator '/' for namespace not paired or in wrong position" below.


This is due to that "/" as a special character should only be in the first place if it is contained in a structure name. Don’t worry! /AIF/IDOC_GEN has provided you an option to solve this issue. You can proceed with the next step by clicking below Continue button.

2 - Copy.png


Then you will see below screen for your confirmation.


Try to replace all "/" with "_" in Raw Data Structure column and press F8 to continue, you will succeed in generating the objects.



  • You have Inbound synchronous ABAP-Proxy
  • You would like to implement AIF Interface for your Proxy.
  • You have a developer key

As example, we will use simple inbound interface for bank data:


First, we have to create RAW structure for our interface. I create RAW structure ZAIF_BANK_SAP_N in se11:


Screenshot 2014-04-10 18.31.jpeg


Screenshot 2014-04-10 18.32.jpeg4.png

We shouldn’t define SAP structure because this is our generated Proxy structure.

Now, go to /n/AIF/CUST_IF transaction and create an interface BANK_IN (you should use your predefined namespace):


Hint: when you enter Proxy class name and press enter, Raw Data Structure and Record Type In Raw Structure will filled automatically.


Then we have to define an action…


…and a function module for this action:


Note, that we should enter Associated Type name for parameter CURR_LINE:


Then we have to implement our FM. If you would like to insert some data from your SAP structure, you should use curr_line-request structure. To send your response (ext_id in our case)  to proxy response, we have to put it to curr_line-response structure.

I just fill curr_line-response-ext_id with value ‘0001’ :


Save and activate FM.

Then, we have to define Structure Mapping. Click New Entries and add IMPORT_PARAM as source structure:


Choose our source structure, click “Assign Destination Structure” and assign LINES as destination structure:


Save and click Define Field Mappings. You have to define field mappings as on the picture:


Then define created above Action as described and save.


I will not describe configuration steps like creating and assigning recipients, you can find it in other docs about AIF.

As the last step, we have to implement our Proxy class ZCL_BANK_IN with code like this:



DATA: lt_return     TYPE bapiret2_tab.


lv_message_id TYPE sxmsmguid,

ls_sap_data TYPE ZAIF_BANK_SAP_N,

ls_input TYPE ZMT_BANK.


ls_input = input.


cl_proxy_access=>get_inbound_message_key(     "getting message key


      message_id     = lv_message_id ).


call FUNCTION '/AIF/FILE_PROCESS_DATA'       "call FM to create an AIF message


      ns = 'MD'

      ifname = 'BANK_IN'

      ifversion = '1'

      transform_data = 'X'

ximsgguid              = lv_message_id

      xi_flag = 'X'



      return_tab = lt_return


      data = ls_sap_data

      raw_struct = ls_input-mt_bank "pass record type


      not_found = 1

      customizing_incomplete = 2

      max_errors_reached = 3

      cancel = 4

      err_log = 5

      OTHERS = 6.


output-MT_BANK_RESP-ext_id = ls_sap_data-lines-response-EXT_ID. "assign the ext_id to proxy response




So, lets try to test our interface using proxy test:


Yoo-hoo! We get back an answer to our proxy Now, go to /n/AIF/ERR, select our interface, click “Today” in Generic Selection and Select All in Status Selection and Execute:



Note, that you will not see a payload of your message when it sent from test tool in sproxy. To see a payload, you need two things:

1) Turn on logging for synchronous messages in tcode sxmb_adm: Integration Engine Configuration —> Category: RUNTIME —> add new parameter LOGGING_SYNC with value “1”.

2) Send message from your PI/PO system.


Hope this blog was helpful


p.s. Special thanks to George Gita

In this article I will try to present the main differencies between 3 SAP technologies which are used in SAP integration projects on the SAP backend systems (like ERP, SCM, etc.) for handling interface related errors:



a) SXMB_MONI - standard monitor for proxy messages



b) FEH/ECH - Forward error handling, Error and Conflict Handler - standard SAP tool for enterprise service error solving



c) AIF - Application Interface Framework - additional tool from SAP for interface monitoring



A similar comparision was already done in this article - POV: FEH or AIF or Custom Error Handling - but since then there have been some significant changes in some of those technologies so I believe it's worth to do the comparision once more.



Zrzut ekranu 2014-01-22 o 18.18.56.png






Works for inbound asynchronous services
Works for inbound asynchronous services
Works for inbound asynchronous services


Works for outbound asynchronous services

Works for outbound asynchronous services


Works for inbound synchronous services

Works for inbound synchronous services

Works for outbound synchronous servicesWorks for outbound synchronous services
SAP Standard services use ECHNeeds to be customized (no coding required)SAP Standard services use SXBM_MONI
Payload editorPayload editorPayload editor based on XML
Manual restartingManual restartingManual restarting
Automated error resolution based on error typeVery limited automated restartingVery limited automated restarting
Alerting, NotificationAlerting, Notification also based on content of the messageAlerting, Notification
SXMB_MONI - integration - linksSXMB_MONI - integrated
Data search on the basis of message attributesData search on the basis of message attributes from indexed tables
Usage of tips and hints Usage of tips and hints
Authorization concept with payload attributes usage
Framework for implementing error handling - only Framework for implementing all kinds interfaces (IDOC, WS, etc.)
IDOC monitoring in the same tool (look and feel)
Own runtime for processing other types of integrations (file, etc.)
Simple navigation from error to the field level
Value mapping tables are the AIF standard objects
Grouping of interface based on defined criteria
Message mapping tool for additional mapping
Versions of interfaces
Customizable application tabs (with own objects)
Does not link to the documents Customized links to documentsDoes not link to the documents
Licence cost - freeLicence cost - Seperate LicenceLicence cost - free


I hope some of you can use this information to determine what kind of error handling tool do you need in your projects.

AIF allows configuring multiple selection tables for indexing values which may appear in a single message more then once (for example material number in lines of a sales order). AIF cookbook however does not provide the info how to create such tables. In this short article I will quickly describe the procedure.


Step 1


Copy table - /AIF/STD_IDX_TBL to your custom table and insert one new field - Counter - after the field MESGUID. Make sure it has the same attributes as per screenshot below:


a) key field - checked


b) initial value  - checked


c) data type - int4




Now you can add your key fields to the table (this you can do in the same way as you'd when working with single index tables)


Step 2


Once you save and activate your multiple index table you can use for your AIF interface. To do this you need to go to - /AIF/CUST - Error Handling - Interface Specific Features, select the Key field name, Data element, Parameter, Field-name and you need to select "Multiple selection type" field as - Multiple selection.







Make sure you don't put the multiple index table in transaction /AIF/CUST - Error Handling - Interface Specific Features as there you can only put single index tablels.



With the previous versions of AIF 2.0 if you wanted to monitor your standard proxies you had to call the AIF enabler (method - /aif/cl_enabler_proxy=>process_message) in a proxy's BADI, ehnancement or modification. However a few months ago a new functionality was added which calls the AIF on the basis layer so it's no longer necessary to make any changes to the standard proxy implementation in case you want to use AIF. You only need to do the standard AIF configuration for the interface if you implement - Note 1799544 - Support of Enterprise Services and existing proxy interfaces.There's only prerequisite - Error and Conflict Handler (ECH) cannot be activated in client specific customizing (please have a look inside the OSS note for more details).




With IDOCs the story was a bit different than with proxies. It was possible to use AIF with IDOCs without any additional development but we had to use IDOC engine in all entries in the Interface engines configuration. That had a negative functionality impact that we couldn't use index tables for example. The old configuration is described in my blog: Michal's tips: Application Interface Framework (AIF) 2.0 - monitoring existing IDOCs

If we wanted to use index tables we had to call the AIF enabler function (/AIF/IDOC_INBOUND_PROCESS_FUNC) as described in my other blog:

Michal's tips: Application Interface Framework (AIF) - IDOC processing with AIF actions Currenly with OSS note Note 1844352 - Support of Generic IDOC Monitoring we don't need to do that to call AIF enabler for IDOC scenarios. Again as with proxy interfaces AIF is being called in the basis layer so we can turn on AIF monitoring by simply doing the AIF customizing.


Limitations for both cases


Calling AIF from the basis layer in both cases (IDOC and proxy) means that we can use:


- Interface Monitor


- Index Tables


- Key Fields


- Authorizations


But the current limitation is that the the runtime features (like value mappings, checks) don't work so if you want to use those functions you still need to use the old way of explicitly calling the AIF enabler class/function.


Filter Blog

By author: By date:
By tag: