Interface Variants with AIF

[Former Member]

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.

Preparation

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
  CALL FUNCTION '/AIF/UTIL_ADD_MSG'
    EXPORTING
      msgty      = 'E'
      msgid      = '/AIF/MES'
      msgno      = '000'
      msgv1      = 'This error message gets thrown every time!'
    TABLES
      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.

Summary

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.