Introduction and Use Case

You might have already experienced a situation in which you have to make slight changes to the customizing of an existing interface in AIF. Examples for such situations are:

  • Your interfaces are defined globally. However, in certain scenarios the processing of a message needs to be slightly different. E.g. if data is coming from a certain plant.
  • You have an interface that is delivered by SAP. Interfaces delivered by SAP cannot be changed on a customer system. However, you would like to enhance the interface with some own logic, for example you would like to add an additional check or fix value.

How can you enhance the interface’s customizing without changing the original interface or without creating an additional interface? Or how can you even change the customizing of SAP-owned interfaces of other applications, which usually are protected for changes?

Since AIF 1.0 you can use the variant-feature to tackle this. E.g. you can simply add or change a fixed value without changing the original interface. The only thing that changes is the variant. From my experiences, interface variants are commonly unknown, but could be used in so many situations (just two mentioned at the beginning). For this reason I wrote this blog post, which explains the usage of interface variants in AIF by using a simple example with the FLBOOKING interface in namespace /AIF/. We are going to add a new fixed value and replace the create-booking-action by a different action.




To overwrite the existing action we need to have a different action. We will now create an action that always throws an error message.

To create a new action go to /AIF/CUST and expand Interface Development to select Define Actions. Enter one of your namespaces (to create a new namespace go to Define Namespace first / in our example we will use the namespace Z_FZ5). Create a new entry. Use ALWAYS_ERROR as the action’s name and use any description. Your customizing should look like the following:


Then click on Define Functions on the left and create a new entry. Use 10 as the function number and enter a ZALWAYS_ERROR as the function module name and confirm by pressing enter. Use the forward navigation to create the function module. You can use the following code snippet for the function module:

  " Error message
      msgty      = 'E'
      msgid      = '/AIF/MES'
      msgno      = '000'
      msgv1      = 'This error message gets thrown every time!'
      return_tab = return_tab.

Your customizing should look like in this screenshot:




How to enable interface to support variants

Interfaces have to be prepared to support variants. The preparation is basically the setup of the variant assigning table. This table describes which variants should be applied to an interface (and which keyfields should be used for the determination). To create a new variant assigning table, go to the se11 to copy the template called /AIF/VAR_AS_TMPL. Use ZVAR_AS_FLBOOKIN as name and use any description.


In our example we only want to use the variant if the carrier-field is set to a specific value. Therefore add an entry called CARRID with the type S_CARR_ID to the list. The table should look like the following:


Then go to tab Delivery and Maintenance and set the Data Browser/Table View Maint. field to Display/Maintenance Allowed (Alternatively you could create a dedicated maintenance view). Save and activate the newly created table. In general one assigning table could be used for multiple interfaces.

In addition the variant assigning table has to be connected to your interface. Therefore go to transaction /AIF/CUST and expand Interface Development, Interface Variants to select the node Define Assigning Tables. Then enter the namespace of your interface (in our example we will use the FLBOOKING interface (version 1) in the /AIF/ namespace) and you will see a maintenance view. Add the name of your newly created variant assigning table to your interface. Save your changes and you are done.




How to create a new variant

To create a new variant go to transaction /AIF/CUST and expand Interface Development, Interface Variants to select the node Define Interface Variants. Enter a namespace for your new variant (our example uses the namespace Z_FZ5). The used namespace can be different than the one used for the interface – this does make sense if you want to create a variant for a SAP-owned interface in a locked namespace (e.g. /AIF/ namespace). In the maintenance view create a new entry and insert the variant’s name (e.g. TESTVARIANT) and description. Save your changes and you are done.



Create a new fixed value

In the following we are going to add a new fixed value. In general the corresponding maintenance views give a good overview on what you can do with a variant. Therefore go to transaction /AIF/CUST and expand Interface Development, Interface Variants to select the node Define Variant Mappings. Enter your namespace and the name of your variant.

Select Select Interface on the left side and create a new entry. Enter /AIF/ as namespace, FLBOOKING as interface name and 1 as version.


Then click on Add/Select Structure Mapping and create a new entry. It is basically the same thing as the structure mapping of an interface. In our example leave the source structure field empty (meaning we are selecting the root of the raw structure) and enter 10 as number for this mapping. The number is the mapping’s identifier. If you choose a number that already exists in the structure mapping of the interface you can change or enhance the behavior of this specific mapping (we will see that in more detail when defining the action). Then click on Assign Fix Values on the left side and add a new entry. Enter 10 as fix value, choose CUSTOMER_DATA-LANGU as field name, enter EN as value and save your changes. This fixed value will fill the CUSTOMER_DATA-LANGU field of the SAP-structure with the value EN.




Overwrite an action

Now we are going to overwrite the standard create-booking-action. Therefore select Assign Action on the left side and create a new entry. Use 10 as the action number. Because the number 10 refers to an action, which already exists in the interface, this will override/replace the existing action in the interface’s customizing. Enter the namespace and the name of your action you created before.




How to apply a variant to an interface?

In order to enable the variant determination by a dedicated keyfield (in our example: CARRID), you have to define this keyfield. Therefore go to /AIF/CUST and expand Interface Development, Interface Variants and select the node Define Interface Key Fields. Then enter the namespace of your interface (in our example we will use the FLBOOKING interface (version 1) in the /AIF/ namespace) and you will see a maintenance view. Add a new row and use 10 as the key field number and CARRID as Interface Variant Key Field (refers to the column name in the variant assigning table) and Field Name (refers to the field in the raw structure). Save your changes. The customizing should now look like the following:


To apply the created variant to the FLBOOKING interface, we need an entry in the variant assignment table. This is the table you created before. Therefore go to se16, enter ZVAR_AS_FLBOOKIN as table name and create a new entry. Enter the interface you want to apply the variant to. In our example we want to use the FLBOOKING interface (version 1) in namespace /AIF/. Then enter the namespace and the name of your variant. In our example we only want to apply the variant if the CARRID keyfield is set to FZ. Therefore enter FZ in the CARRID field and save all changes. The table now should look like the following:




Test our example

To test our example we can use the test tool. Therefore go to transaction /AIF/IFTEST and press the Search-Button. Then create a new test file and choose the FLBOOKING-interface (version 1) in /AIF/ namespace. Enter any description and save the file. Next press the Read Data button to load the file. Enter FZ as CARRID and use any values for the remaining fields of the raw structure. Finally press Process in XML Runtime. This will send a new message to AIF.

Please note: The Transform-Button in the test tool won’t respect any variants. This feature only applies the interface’s customizing. Instead, the Process in XML Runtime button will really send a message to AIF and AIF performs all steps including the look up for variants.


To see this message, go to transaction /AIF/ERR and enter /AIF/ as namespace. You will find one message in status error. It should have one log message originated from the overwritten action.


To see the result of the fixed value mapping, switch to Technical Mode (button in the upper left corner), double click on the message and click the Transform button (lower left part of the screen). Then select the CUSTOMER_DATA substructure. The data content will contain the value EN in the LANGU field.





This blog post gave an introduction on how to use interface variants. It showed that variants can be used in many situations to gain flexibility and to modify the existing behavior of an interface for all or some messages.


PS: I am happy to receive your feedback to this blog post.

AIF Webcast.jpg

If you missed our Webcast on March 8 here's your chance to join us!  See the replay of how the SAP Application Interface Framework tool makes life easier for business users by empowering businesses to monitor and troubleshoot processing issues on their own.  The tool improves the visibility of business rules and validations, performs interface-related monitoring with minimal IT involvement, and helps to increase operational efficiency.


Click HERE to see a replay of the Webcast.


  • You would like to implement AIF interface with automatic reprocessing of messages.

I would like to show you how to set up an automatic reprocessing for your AIF-interface.

I will use simplified interface BP_IN for business partner with the same SAP and RAW structures ZBPSTRUC:


For automatic reprocessing, we have to use a runtime group, created for our interface.

Use Tcode /n/AIF/PERS_CGR to create a runtime group, say RT1:


Don't remember about checkboxs "Runtime Configuration Group Active" and "Run Scheduled".


Then I create an Action...



...that uses a Function Module



First, we just use a Break Point to make sure our interface is working



Then I create a simple report to call AIF Interface:




ls_input type ZBPSTRUC.   "our AIF structure


*Fill the structure with dummy data:

ls_input-BP-TITLE = 'Mr'.

ls_input-BP-NAME_FIRST = 'Mark'.

ls_input-BP-NAME_LAST = 'Levinson'.




     is_any_structure = ls_input

     IV_QUEUE_NS = 'BP'

     IV_QUEUE_NAME = 'RT1' ).


I don't use AIF test tool because of Runtime Group specification in call.

Now let's try to check if all is Ok and run our report. Then check /n/AIF/ERR:


Yoo-hoo! It works!


Now lets try to setup an automatic reprocessing.

First, we need to define reprocessing action, using Tcode /n/AIF/REP_AC_DEF


Take a look, that we need to use a function module /AIF/RESTART_MSG and our Runtime Group created above.


Than, we need to assign a reprocessing action in Tcode /n/AIF/REP_AC_ASGN:




  • You can select a special message class and message, so only messages with specified errors will be restarted
  • You can define in what time period your message will be restarted. As shown, this message will be restarted in 5 minutes.

Also, you can define an intermediate status, for exapmle "In process", "Application error" and others.

Now you can have some experiments with your AIF message, for example with changing time or Intermediate Status.


Hope this blog was useful for you.



The purpose of this document is to show the implementation steps in SAP ECC for the 'New WebService' engine in AIF 702.

Message for a outbound interface will be sent from SAP ECC via WebService using SOA to other system (for example: SAP PI). The messages can be monitored in SOAMANAGER via /AIF/ERR. (I have used SAP note 2010881 for reference)

1. Assign the 'New WebService' engine to the Interface (AIF IMG-> Interface Development -> Additional Interface Properties -> Specify Interface Engines)



2. In transaction SOAMANAGER, create a Logical Port for the Interface of new WS




3. In the ABAP program for sending the messages, use FM '/AIF/SEND_WITH_PROXY' and assign the Logical Port as an exporting parameter.

    (We copied /AIF/SEND_WITH_PROXY into our custom FM to cater to our requirement)



4. In /AIF/ERR, AIF message was logged,




and from /AIF/ERR we could navigate to Monitoring in SOAMANAGER


Most of the SAP delivered Enterprise Services use the Error and Conflict Handler (ECH) to handle messages which end up with errors. AIF seems to be integrated with ECH but there are many ways to enable this integration. We can either turn off ECH to monitor ECH completely in AIF (ECH will not be used at all) or we can make AIF use ECH error status messages. The second approach is much better in cases where the SAP delivered Enterprise Service used some other ECH functionalities which would stop working if ECH is completely turned off. The only difficulty is that you need two AIF interfaces to monitor a single interface:


a) one for monitoring ECH messages

b) one for monitoring successfull proxies


Let me demonstrate the idea of using the AIF for the second case.




OSS note  2094472 - Support of standard enterprise services



Step 1



As per OSS note you need to define two AIF interfaces for the same inbound proxy class: one for ECH and one for Proxy. The main difference will be the Interface engine configuration where for proxy interface you can use the default values but for ECH you need to use ECH for all engines:


Application Engine = ECH

Persistence Engine = ECH

Selection Engine = ECH

Logging Engine = ECH



Step 2



In step 2 you need to assign the correct ECH component to the ECH AIF interface - Interface Development -> Additional Interface Properties -> Assign ECH Component



Step 3



You also need to perform all of the manual steps from the OSS note: 


a) create the implementation for two enhancement spots /AIF/ERROR_HANDLING and /AIF/ENGINES


b) perform the manual post customizing which includes creating a custom function. This function will allow you to navigate between the AIF message of the proxy interface to the same AIF message in the ECH interface. This way you can not only work with specific functions of two monitors but also drill down to both of them (to proxy monitor from proxy interface  and to ECH monitor from the ECH interface). You can find the information on how to create the custom function on the screenshots below. 




Figure 1 - Custom function for ECH monitoring




Figure 2 - Parameters for custom function for ECH monitoring



How does it work



Now when you try to monitor your message AIF you only need to open the proxy version of your interface as it will always contain both types of messages (correctly processed and incorrectly processed). For the ones which failed you will see a status message saying that the error is in ECH and by using the arror you can drill down to the ECH version of the AIF interface from where you can perform all ECH related activities. 




Figure 3 - ECH drilldown from AIF Proxy interface





You can find some more info on ECH, proxy monitoring and AIF in my book - SAP SOA Integration - Enterprise Service Monitoring



Special thanks:


Verena Woerner for helping me with customizing of this functionality.

As of AIF 3.0 a new, fantastic feature has been introduced - AIF serialization. Together with my two colleagues from Int4 - Michal Michalski and Krzysztof Luka we've decided to describe how do different options of AIF serialization work as we believe it's usage can be a vital part of almost every AIF implementation due to it's unique benefits.


SAP Press has published our book with it's new format - E-bite. E-bites are supposed to be smaller books available only in electronic format and they need to concentrate on a single topic only - in our case serialization. Our book contains step-by-step instructions and screenshots that will enable you to explore your serialization options in SAP Application Integration Framework in no time, starting from the configuration up to monitoring and troubleshooting of the AIF serialization.




Where to buy:


SAP Press - Serializing Interfaces with SAP AIF




My first book on AIF topic for business users - SOA Integration - Enterprise Service Monitoring (LIE, FEH/ECH, AIF)

SAP AIF with release 3.0 has got many new features and one of them is a much tighter integration with SAP rule engine - BRFPlus/DSM. In this video presentation you can find out why it’s worth using AIF together with BRFPlus/DSM: SAP Application Interface Framework with SAP NetWeaver Decision Service Management


The main topic of this article will be to show how quickly and easily can a BRFPlus rule be used in the AIF value mapping from the development point of view. For a start we need to design a BRFPlus function which can later be used within AIF. There are however two important things to be considered here:


a) if you’re building a new BRFPlus function together with a new BRFPlus expression (for example a decision table) you can try building it according to the AIF requirements (for input parameters). This basically means that the BRFPlus function can be used in the „Functional mode” with just one top expression (for example - decision table) which has the same input/output parameters


b) if the BRFPlus expression is already developed you have to develop a BRFPlus function according to the AIF requirements (for input parameters) but you may need to go for a function with "Event mode” so you can map the AIF required input and output parameters to the existing expression within the BRFPlus Ruleset (assigned to the function)


In this article we will only concentrate on the first approach (so both the BRFPlus function and expression are new). The first step would be to create a BRFPlus function with required input parameters which need to can have names listed as per the figure below which would correspond to the fields (Field1…Field5) from the AIF structure mapping later on. The output value does not need to have any specific name.




Next we need to prepare the BRFPlus expression (for example decision table) which will be used in the scenario and assign it to the BRFPlus function. It would be wise to test the function from the BRFPlus workbench to see it working using the start simulation button.


The rest of the customizing steps can be done within AIF and we need to start by defining a new value mapping where we need to select which BRFPlus application and function we will be using as shown in the figure below.




In order to use the new value mapping you need to add it in the AIF structure mapping keeping in mind that selected source fields will be used by the BRFPlus function exactly as shown in figure below.





After all of the mentioned steps are done you can try and test the end to end scenario and if you did everything as explained the value from the AIF interface should get mapped using the BRFPlus.



BRFPlus can also be used in AIF structure mapping and AIF checks and not only with AIF value mapping.



Business Rules Framework Plus Integration from

Requirement: To map child level field in a nested structure in AIF.


Source field: StreetPostalCode   --> (/Supplier/AddressInformation/Address/PhysicalAddress/StreetPostalCode)

Target field:  RegionName          --> (/Supplier/AddressInformation/Address/PhysicalAddress/RegionName)




Step 1: Root level structure mapping.


Assign "Supplier" as the source and target structure.




The next segment in the target structure after Supplier is "AddressInformation".

So, select "AddressInformation" as the field in destination structure and assign it as a Sub-Table as well.




Step 2: First level structure mapping.

Assign "AddressInformation" as the source and target structure. This time "Indirect Mapping" checkbox is selected as well.


The next segment in the target structure after AddressInformation is "Address".

So, select "Address" as the field in destination structure and assign it as a Sub-Table as well.




Step 3: Second level structure mapping.

Assign "Address" as source and target structure. This time as well "Indirect Mapping" checkbox is selected.



The next segment in the target structure after Address is "PhysicalAddress".

So, select PhysicalAddress as the field in destination structure and assign it as a Sub-Table as well.




Step 4:  Third level structure mapping.

Assign "PhysicalAddress" as the source and target structure. This time as well "Indirect Mapping" checkbox is selected.


Map the target field "RegionName" with the source field "StreetPostalCode".



In SAP back-end system the newly created AIF custom interface fails to display log in transaction /AIF/ERR. This is because the application log sub object is not created in the system.


For example: In transaction /AIF/CUST -> Interface Development -> Define Interfaces, a newly created interface IC0029 belonging to namespace ZHR.




Step 1: Go to transaction SLG0.


Step 2: Select the entry "/AIF/LOG" and double-click on "Sub-objects".



Step 3: Go to edit mode and create a new entry for interface IC0029 along with its namespace and Save.



An entry for IC0029 gets created in SLG0.



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.





Filter Blog

By author: By date:
By tag: