📚 SAP AIF Configuration Series - Guide #5

We are configuring default values on top of the iDoc interface we developed in our previous guides.

If you are new here and would like to see the previous articles, check out the following guides.

1. How to Configure your First IDoc Monitoring Interface in AIF.

2. How to Configure Fixed Values in SAP AIF

3. Implement a Single Value Mapping in AIF

4. Develop an SAP AIF Multi-Value Mapping

Default Value in SAP AIF Value Mapping

Introduction

In the previous chapter, we configured a multi-value mapping that determines a customer discount based on the ISO country code (E1SCU_CRE-E1BPSCUNEW-COUNTR_ISO) and customer type (E1SCU_CRE-E1BPSCUNEW-CUSTTYPE) of the incoming iDoc. That works perfectly as long as the incoming combination exists in the mapping table. But what happens when a customer arrives from a country that hasn’t been mapped yet?

By default, AIF will raise an error and the IDoc will not be processed. That’s the safe option, but it’s not always what the business wants. Sometimes you’d rather the customer gets created with a sensible fallback discount rather than failing completely.

This is exactly what a default value in SAP AIF is for. When a value mapping lookup fails to find a match, AIF can fall back to a predefined default value and continue processing the message successfully.

Get the full ebook!

Scenario

We are building on top of the II_FL_CUST interface in namespace ZDEMO and the multi-value mapping VM_DISCOUNT from the previous chapter.

The new requirement is simple: if an incoming customer’s country and type combination is not found in the VM_DISCOUNT mapping table, AIF should not raise an error. Instead, it should assign a default discount of 2 to the E1SCU_CRE-E1BPSCUNEW-DISCOUNT field and continue creating the customer.

This gives us a safe fallback that keeps the interface running even when new country codes appear in the data that haven’t been mapped yet.

Prerequisite

The multi-value mapping VM_DISCOUNT must already be configured as described in the previous chapter. The field mapping for E1SCU_CRE-E1BPSCUNEW-DISCOUNT referencing VM_DISCOUNT must be in place under Define Field Mappings for interface II_FL_CUST.

What Is a Default Value in AIF?

A default value in SAP AIF is a fallback that is applied to a destination field when the associated value mapping cannot find a matching entry for the incoming data. Instead of putting the message into error status, AIF uses the default value and marks the message as successful.

It is configured directly on the field mapping entry.

💡 Tip

Default values are particularly useful in interfaces where data quality from the source system is inconsistent. Rather than blocking every message with a missing mapping entry, you can apply a safe default and let the interface team clean up the mapping table without causing a backlog of errors.

Step 1 - Add the Default Value to the Field Mapping

Transaction: /AIF/CUST → SAP Application Interface Framework → Interface Development → Define Value Mappings

Navigate to Define Field Mappings for interface II_FL_CUST, namespace ZDEMO, version 1. Find the existing field mapping entry for the destination field E1SCU_CRE-E1BPSCUNEW-DISCOUNT - this is the entry we created in the previous chapter that references value mapping VM_DISCOUNT.

Alternatively, you can go to Interface Development → Define Value Mapping to access the value mapping directly.

Select the value mapping VM_DISCOUNT. Open the entry and set the Default Value field to 2.

Save your changes.

💡 Tip

The default value must be a valid internal value for the destination field; the same type and format as the values in the Internal Value column of your mapping table. For the DISCOUNT field, this is a numeric value, so entering 2 tells AIF to assign a discount of 2 whenever no matching mapping entry is found.

Step 2 - Test the Interface

Let’s create a customer from the country of France (FR). In our value mapping table, we do not have any entries maintained for country FR.

Step 3 - Verify the Customer Master Record

Notice that the default discount value of 2 is applied to the customer created.

📚 SAP AIF Configuration Series - Guide #4

We are configuring value mappings on top of the iDoc interface we developed in our previous guides.

If you are new here and would like to see the previous articles, check out the following guides.

1. How to Configure your First IDoc Monitoring Interface in AIF.

2. How to Configure Fixed Values in SAP AIF

3. Implement a Single Value Mapping in AIF

In the last article, we built a single value mapping in SAP AIF that translates a salutation code from an external system into the internal SAP value. That works fine when you only have one incoming field to look up. But sooner or later you’ll hit a requirement where the result depends on a combination of fields, and a single mapping can’t handle that.

That’s exactly the situation we’re solving here. The scenario is that the airline customer interface receives customer data from an external system via IDoc.

The business wants a discount assigned to each new customer automatically, based on the country of the customer and the customer type.

Here are the two fields in the incoming message,

• ISO country code (COUNTR_ISO) - full path E1SCU_CRE-E1BPSCUNEW-COUNTR_ISO)

• Customer type (CUSTTYPE) - full path E1SCU_CRE-E1BPSCUNEW-CUSTTYPE)

The discount determined for the customer gets written into the DISCOUNT field (E1SCU_CRE-E1BPSCUNEW-DISCOUNT).

The discount rules look like this:

Single Value Mapping vs. Multi-Value Mapping

A single value mapping has exactly one external source field. AIF looks up the incoming value in the mapping table, finds a match, and writes the corresponding target value to the destination field. The salutation mapping from the previous chapter is a good example of this: one external field (FORM) maps to one internal value.

A multi-value mapping has two or more external source fields, and AIF evaluates all of them together as a single combined key. The combination is what determines the result or the target value.

💡 Tip: "when field A equals X, the result is Y," a single mapping can handle. When the rule becomes "when field A equals X and field B equals Z, the result is Y," you need to use multi-mapping in AIF.

Configuration Steps for Multi-Value Mapping in AIF

🛑 This configuration builds on the II_FL_CUST interface from the base AIF IDoc interface chapter. The structure mapping and field mapping for that interface need to already be in place before you start.

Step 1: Define the Multi-Value Mapping

Transaction: /AIF/CUST -> Interface Development -> Define Structure Mappings -> Define Field Mappings

💡 Tip: The order of the source fields matters. AIF builds the lookup table by combining the values in exactly this order. When you maintain the mapping data later in /AIF/VMAP, the external value columns will appear in the same sequence —COUNTR_ISO first, CUSTTYPE second.

Since VM_DISCOUNT does not yet exist, AIF will prompt you to create it. If it does not, double-click the value mapping name to create it.

Step 2: Configure the Details of the Value Mapping

• Number of External Values - 2

• Single or Multiple Value Mapping - Multiple

• Customizing or Master Data - Master Data

Setting Number of External Values = 2 tells AIF to expect two source fields as the combined lookup key

💡 Customizing or Master Data?

This controls how and where the mapping values are maintained.

• Master Data - values are maintained at runtime directly in transaction /AIF/VMAP. They’re client-dependent, meaning each client manages has its own copy of mapping values.

• Customizing - values are maintained in the IMG and transported like any other Customizing entry. Use this when the mapping is stable and needs to be consistent across all clients through the landscape.

Save your entries.

Optional Step: Remove Any Conflicting Fixed Value

If a fixed value was previously configured for the DISCOUNT target field, you should remove it.

In the previous example, we defined a Fixed Value in AIF for the Discount field. In that case, fixed values take priority over value mappings, so the discount field would receive the fixed value instead of the target value from Value Mapping.

Step 3: Maintain the Multi-Value Mapping Data

Open transaction /AIF/VMAP, select namespace ZDEMO and value mapping VM_DISCOUNT.

You will see two external value columns, one for COUNTR_ISO and one for CUSTTYPE, in the order defined in Step 1. Create new data rows for each combination of incoming value and target.

⚠️ Warning: Both external values must match exactly for AIF to find a result. They are case-sensitive. If the IDoc sends COUNTR_ISO = US but CUSTTYPE arrives as lowercase p instead of uppercase P, the lookup will fail and the message will go into error.

Step 4: Test the Interface

Use transaction WE19 to create a test IDoc based on basic type FLCUSTOMER_CREATEFROMDATA01. In segment E1BPSCUNEW, populate the following fields and leave the DISCOUNT field empty. AIF will fill it in during preprocessing.

Test case - US Passenger customer (COUNTR_ISO = US, CUSTTYPE = P)

Verify that the discount was correctly determined by checking the message in /AIF/IFMON or /AIF/ERR and inspecting the customer record in table SCUSTOM.

There are resources out there that explain what AIF is and what it can do, but when you actually start implementing AIF in a project, we noticed that resources on SAP AIF are scarce.

And perhaps one of the biggest challenges we faced during our projects was how do you explain to IT manager, SAP implmentation teams why AIF should be used and how it should fit into the overall integration architecture?

“We faced many of these challenges ourselves while working on different SAP implementation projects.”

So we decided to put what we have learned along the way into one place.

Introducing the SAP AIF Configuration Guide for SAP Consultants

This is a complete guide for SAP consultants who are already working with AIF, want to learn AIF, or are looking to newly implement AIF in their organizations.

We didn’t want to create another guide that only explains the theory.

Our goal was to create something practical that you can actually use when working on an SAP project.

There are currently more than 75 lessons covering different parts of SAP AIF.

And this is not the final version.

This Is a Living Guide

We will be regularly adding new AIF lessons and new topics to the guide.

So if there are areas of AIF that are not covered yet, there is more content coming.

And the important part is that all future lessons will be included for you when you get access now.

Our intention is to keep improving this guide and make it a most useful resource for SAP consultants working with AIF.

Get the eBook!

Who Is This For?

If you are an SAP technical and functional consultant who:

• Is currently working with SAP AIF

• Wants to learn SAP AIF

• Is involved in SAP S/4HANA implementation projects

• Needs to understand how AIF is configured and implemented

• Wants to implment SAP AIF for the first time

• Or is trying to understand where AIF fits into your overall integration architecture

Then this guide is for you.

We have tried to bring together the theory, configuration, implementation steps, practical examples, and lessons we have learned from working with AIF in real projects.

Get life time access!

The SAP AIF Configuration Guide is now available.

If you want to start learning SAP AIF or improve your understanding of how to implement it, you can get access using the link below.

And remember, as we add new lessons to the guide, you will get access to those future lessons as well.

👉 Get access to the SAP AIF Configuration Guide here.

Get the eBook!

📚 SAP AIF Configuration Series - Guide #3

We are configuring value mappings on top of the iDoc interface we developed in our previous guides.

If you are new here and would like to see the previous articles, check out the following guides.

1. How to configure your first IDoc monitoring interface in AIF.

2. How to Configure Fixed Values in SAP AIF

Value mapping in SAP Application Interface Framework (AIF) is a mechanism used to translate incoming external values into internal SAP-compliant values during message processing. Or vise-versa from internal SAP values to external values.

It’s needed because different source systems often use different coding or naming conventions than SAP. Value mapping ensures that these external representations are converted into the correct internal values, so the data can be processed without errors and remains standardized across interfaces.

Scenario

In this example, let’s assume the external system sends us the passenger (customer) master information with the title as MISTER or MISTRESS.

However, when we create the customer master data, we don’t want to use these external values in the title; instead, we want to save them as Mr. and Mrs.

We’ll create a value mapping for the FORM field in the iDoc.

The external values are converted into standard internal SAP values as follows:

• MISTER → Mr.

• MISTRESS → Mrs.

This ensures that incoming data is normalized during processing, regardless of how the external system represents the salutation.

Step 1 - Define Value Mapping

Transaction: /AIF/CUST -> Interface Development -> Define Structure Mappings -> Define Field Mappings

In Define Structure Mappings -> Define Field Mappings, create a new entry.

Make sure the destination structure is mapped correctly. We created this mapping in the previous example for Fixed Values.

⚠️ Warning

Make sure the interface II_FL_CUST in namespace ZDEMO is already working before you start this step.

The value mapping you’re about to create sits on top of the structure mapping from the Fixed Values chapter, so that needs to be in place first.

Maintain the following values under Define Field Mapping:

• Field in Destination Structure: E1SCU_CRE-E1BPSCUNEW-FORM — the field you’d like to transform

• Field Name 1: E1SCU_CRE-E1BPSCUNEW-FORM — the field you’d like to transform

• Namespace: ZDEMO Value Mapping: VM_FORM — the name of the new value mapping table

💡 Tip

You can select the field from the drop-down.

Since the value mapping doesn’t yet exist, you’ll be prompted to create it.

Confirm the dialog.

Then define the value mapping with the following settings:

• Value Mapping Description: Map customer form (salutation)

• Data Element for INT: S_FORM

• Number of External Values: 1

• Single or Multiple Value Mapping: Single

• Customizing or Master Data: Master Data

💡 Customizing or Master Data?

This controls how and where the mapping values are maintained.

• Master Data - values are maintained at runtime directly in transaction /AIF/VMAP. They’re client-dependent, meaning each client manages its own set of mapping values. Use this when the mapping is likely to change over time or differs between clients (e.g. sandbox vs production).

• Customizing - values are maintained in the IMG and transported like any other Customizing entry. Use this when the mapping is stable and needs to be consistent across all clients through the transport landscape.

For most real-world interfaces, Master Data is the more practical choice because business users or support teams can update the values directly in /AIF/VMAP without needing a transport.

Our AIF eBook with a full collection of these guides is coming soon!

Read more

📚 SAP AIF Configuration Series - Guide #2

We are configuring the fixed values on top of the iDoc interface we developed in AIF previously. If you are new here and like to learn how to configure the namespaces and the iDoc Monitoring basic steps in AIF, check out the linked article first.

Introduction to Fixed Values in SAP AIF

Fixed values in SAP Application Interface Framework (AIF) allow you to assign predefined values to interface fields during message processing. This is particularly useful when a field must always contain a specific value, or when the incoming message doesn’t provide all the mandatory information required by the target application.

Scenario

In this example, we’ll use a fixed value mapping to populate the CUSTTYPE field during inbound IDoc processing. The CUSTTYPE field is mandatory and cannot be left empty. It also only accepts two valid values:

• P - Passenger

• B - Business

In our requirement, all customers created through this interface should initially be classified as passengers. We’ll configure a fixed value in SAP AIF that automatically assigns the value P to the CUSTTYPE field. This ensures that every IDoc processed through the interface contains a valid customer type and can be processed successfully, without requiring the sender system to provide this information. The sender system may send a blank value.

Sample IDoc segment showing the CUSTTYPE field left blank by the sender

In the following steps, you’ll learn how to configure a fixed value mapping in SAP AIF so that all customer master records created through the II_FL_CUST interface automatically receive the customer type P (Passenger) during preprocessing.

Step 1 - Configure the Interface for Preprocessing

Transaction: /AIF/CUST -> SAP Application Interface Framework -> Interface Development -> Define Interfaces

Go to Customizing for SAP Application Interface Framework (transaction code /AIF/CUST) and navigate to Interface Development -> Define Interfaces.

💡 Tip Pre-Processing must be enabled on the interface before AIF can apply any field mappings - including fixed values and value mappings at runtime. Without this flag set, the structure mapping configuration in the following steps will have no effect.

/AIF/CUST - Define Interfaces menu path

In the selection screen, enter your namespace (for example, ZDEMO) and choose Continue.

/AIF/CUST - namespace selection screen

Switch to Change Mode and open the existing interface II_FL_CUST.

/AIF/CUST - opening interface II_FL_CUST in change mode

Configure the following settings:

• Deselect Move Corresponding Structures

• Select Pre-Processing

• Maintain the source and destination structures

/AIF/CUST - interface settings with Pre-Processing enabled

Save your changes.

Step 2 - Define Structure Mappings

Transaction: /AIF/CUST -> SAP Application Interface Framework -> Interface Development -> Define Structure Mappings

While still in Customizing, navigate to Interface Development -> Define Structure Mappings.

/AIF/CUST - Define Structure Mappings menu path

Enter the following values:

• Namespace: ZDEMO

• Interface Name: II_FL_CUST

• Interface Version: 1

/AIF/CUST - structure mapping selection screen with namespace/interface/version fields

Choose Continue.

💡 Tip

Notice that in this example, the fixed value is created under the combination Namespace / Interface / Version (ZDEMO / II_FL_CUST / 1). As a result, this fixed value is specific to this interface version and cannot be reused by other interfaces within the same namespace. This approach is useful when the fixed value is only relevant to a particular interface and should not be available elsewhere. SAP AIF also allows you to create fixed values at the namespace level. Namespace-level fixed values aren’t tied to a specific interface and can therefore be reused across multiple interfaces within the same namespace. For example, if several interfaces in namespace ZDEMO require the same customer type, status code, company code, or any other constant value, it’s more efficient to create the fixed value directly under the namespace.

Select New Entries and create a mapping for the root node of your interface structure.

/AIF/CUST - New Entries for structure mapping

Select the root structure that was generated for your interface.

Save the entry.

💡 Tip

The source structure you select here should be the root-level DDIC structure that was generated for your IDoc basic type in the DDIC generation step. If you’re unsure of the name, you can look it up in SE11 or check the objects created during the /AIF/IDOC_GEN run.

Step 2.1 - Assign Destination Structure

Select the newly created source structure and double-click Assign Destination Structure.

/AIF/CUST - Assign Destination Structure option

⚠️ Warning

Make sure to first select the source structure and then the destination structure; otherwise, the configuration cannot be created properly.

Create a new entry with the following values:

• Number of Structure Mapping: 10 Destination Structure: Root structure of the interface

• Move Corresponding Fields: Selected

Save your changes.

Step 3 - Create a Fixed Value for Customer Type

Read more

Scenario Detail

In this scenario, we will set up an SAP AIF interface to process customer data received through an IDoc. The interface will be capable of creating and updating customer (passenger) master records.

We will use the following IDoc:

Message Type: FLCUSTOMER_CREATEFROMDATA

Basic Type: FLCUSTOMER_CREATEFROMDATA01

Step 1 - Define the Namespace

Transaction: /n/AIF/CUST -> SAP Application Interface Framework -> Define Namespaces

Navigate to transaction /n/AIF/CUST and create a new namespace. Alternatively, you can use an existing namespace. In this example, we will use the existing namespace ZDEMO.

💡 Tip

The namespace is the top-level container for all your AIF objects - interfaces, recipients, and value mappings all sit inside it. Using a consistent naming convention (e.g. Z + project abbreviation) makes it much easier to manage objects across a large system.

Step 2 - Generate DDIC Structure

Transaction: /n/AIF/IDOC_GEN

SAP AIF works with SAP Data Dictionary (DDIC) structures. However, IDoc basic types, which define the structure of an IDoc, do not have corresponding DDIC structures delivered by default. Therefore, before an IDoc can be monitored and processed through SAP AIF, a DDIC structure must be generated for the IDoc basic type.

Open the IDoc Structure Generator using transaction /n/AIF/IDOC_GEN and enter the details of the IDoc you want to monitor.

💡 Tip

This step only needs to be done once per IDoc basic type. If a DDIC structure has already been generated for your basic type by a previous project, you can skip to Step 2.1 and create the interface directly in /n/AIF/CUST without re-running the generator.

Step 2.1 - Create the Interface

You can create the interface directly during this step. Alternatively, you can create the interface later using transaction /n/AIF/CUST.

To create the interface as part of the IDoc Structure Generator process, select the Create Interface option and maintain the interface details as shown below.

💡 Tip

The IDoc Processing Scenario field controls how AIF hooks into the IDoc processing. The option “ALE runtime; AIF enabler writing application log” is the most common choice for inbound IDocs - it means AIF runs as part of the standard ALE inbound processing and writes errors to the application log so they appear in the AIF monitor.

Namespace: ZDEMO or the namespace created in Step 1

Interface Name: II_FL_CUSTOMER

Interface Version: 1

Interface Description: Customer Master IDoc Interface

IDoc Processing Scenario: ALE runtime; AIF enabler writing application log

Customizing Request: Your customizing request

After maintaining the required information, execute the generation process.

If the generation is successful, SAP AIF creates all required objects, including the DDIC structures and interface definitions. A confirmation popup is displayed showing the details of the generated objects.

If the objects are created successfully, you will have a log with all the objects like this.

Step 3 - Create Interface-Specific Single Index Table

Transaction: SE11

Go to transaction SE11 to create the index table. SAP provides a standard index table template that can be used as a reference. Copy the template table and create a new custom index table based on it. Make sure the new table follows the required naming conventions for your namespace and interface.

💡 Tip

To leverage the full capabilities of SAP AIF and to customize interface error handling and monitoring as required, an index table is typically needed. Therefore, it is recommended to always create an index table for your interfaces.

This index table is used by SAP AIF to enable message indexing and monitoring for the interface.

⚠️ Warning

You can switch the single index table later; however, messages stored in the old index table will no longer be visible in the Interface Monitor. Only new messages will be written to the newly assigned table.

You can use the AIF index template table /AIF/STD_IDX_TBL and select Copy. Then, enter the name ZIDX_IXIFL_CUSTO for the new table and select Continue. When prompted, enter the package name you created earlier.

🛑 Required

Make sure to activate the table in SE11 before moving on. Without activation the index table does not exist in the database and AIF will not be able to write messages to it. You will get a runtime error the first time an IDoc is processed.

Step 4 - Define Namespace-Specific Features

Transaction: /n/AIF/CUST -> SAP Application Interface Framework -> Error Handling -> Define Namespace-Specific Features -> Define Interface-Specific Features

Next, assign the index table to the interface. Go to transaction /n/AIF/CUST and navigate to SAP Application Interface Framework -> Error Handling -> Define Namespace-Specific Features.

Enter namespace ZDEMO and continue.

In Define Interface-Specific Features, choose New Entries and maintain the interface II_FL_CUST with version 1. In the Message Index Table field, enter the newly created index table ZAIF_IDOC_CUST and save your changes.

Step 5 - Create Recipient for Alerts

One of the main purposes of SAP AIF is to enable users to monitor interfaces through AIF monitoring tools. However, not all users should have access to all interfaces in the system. Therefore, users must be grouped into different categories so that access can be controlled based on business requirements.

In SAP AIF, these user groups are defined as Recipient for Alerts. Based on your organization’s requirements, you should create appropriate recipient groups.

For example, you can create one recipient group for users who should monitor all IDoc-related interfaces, and another group for users responsible for OData services.

💡 Tip

In a real-world scenario, access is typically restricted by functional areas. For instance, the Material Master team (PLM) may be given access to material-related interfaces, while the OTC team may be granted access to all sales-related interfaces.

Go to Customizing (transaction /AIF/CUST) and navigate to SAP Application Interface Framework > Error Handling > Define Namespace-Specific Features.

Enter or select your namespace ZDEMO and select Continue.

Navigate to Define Recipients by double-clicking it.

Select New Entries, enter a meaningful name for your new recipient.

Step 6 - Assign the Recipient to the Interface

Transaction: /AIF/CUST -> SAP Application Interface Framework -> Error Handling -> Define Namespace-Specific Features -> Define Interface-Specific Features -> Assign Recipients Without Key Fields

Now assign the recipient to the interface. Go to transaction /AIF/CUST and navigate to SAP Application Interface Framework -> Error Handling -> Define Interface-Specific Features.

💡 Tip

Use Assign Recipients Without Key Fields when all messages for this interface should be visible to the recipient group, regardless of any business key values (e.g. customer number or company code). If you want to restrict visibility to only certain key values, use Assign Recipients with Key Fields instead.

Enter namespace DEMO_1, interface FCUSTOMER, and version 1, then choose Continue.

Read more