BIT750

SAP Application Interface

Framework

.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 03
Course Duration: 5 Day(s)
Material Number: 50151172
SAP Copyrights, Trademarks and
Disclaimers

© 2022 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see https://www.sap.com/corporate/en/legal/copyright.html for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials may have been machine translated and may contain grammatical errors or
inaccuracies.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate
company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any
reason without notice. The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking statements are subject to
various risks and uncertainties that could cause actual results to differ materially from expectations.
Readers are cautioned not to place undue reliance on these forward-looking statements, which speak
only as of their dates, and they should not be relied upon in making purchasing decisions.

© Copyright. All rights reserved. iii

Typographic Conventions

American English is the standard used in this handbook.

The following typographic conventions are also used.

This information is displayed in the instructor’s presentation

Demonstration

Procedure

Warning or Caution

Hint

Related or Additional Information

Facilitated Discussion

User interface control Example text

Window title Example text

iv © Copyright. All rights reserved.

Contents

vii Course Overview

1 Unit 1: Introduction to SAP Application Interface Framework (AIF)

3 Lesson: Explaining Error Handling with and Without AIF

19 Unit 2: General Functionality

21 Lesson: Explaining General Functionality

35 Lesson: Explaining the Scenario of the Exercises

47 Unit 3: Basic Interface Development

49 Lesson: Exploring Basic Interface Development

67 Unit 4: Advanced Structure and Field Mapping

69 Lesson: Explaining Advanced Structure and Field Mapping

87 Unit 5: Actions

89 Lesson: Using Actions

103 Unit 6: Additional Monitoring Features

105 Lesson: Defining Additional Monitoring Features

119 Unit 7: AIF XML Runtime

121 Lesson: Explaining the AIF XML Runtime

127 Unit 8: Processing and Monitoring IDocs with AIF

129 Lesson: Processing and Monitoring IDocs with AIF

145 Lesson: Processing and Monitoring Outbound iDocs with AIF

149 Unit 9: Proxy Interfaces

151 Lesson: Using Proxy Interfaces

157 Unit 10: File Adapter

159 Lesson: Explaining the File Adapter

167 Unit 11: Additional Features for Simplified Monitoring

169 Lesson: Using Additinal Features for Simplified Monitoring

177 Unit 12: Interface Variants

179 Lesson: Explaining Interface Variants

© Copyright. All rights reserved. v

185 Unit 13: Analyzer

187 Lesson: Using the Analyzer

195 Unit 14: Additional Information

197 Lesson: Exploring Additional Topics

203 Lesson: Determining Interfaces

vi © Copyright. All rights reserved.

Course Overview

TARGET AUDIENCE
This course is intended for the following audiences:
● Application Consultant
● Development Consultant
● Technology Consultant
● Developer
● System Architect

© Copyright. All rights reserved. vii

viii © Copyright. All rights reserved.
 UNIT 1 Introduction to SAP Application
Interface Framework (AIF)

Lesson 1
Explaining Error Handling with and Without AIF 3

UNIT OBJECTIVES

● Explain error handling with and without AIF

© Copyright. All rights reserved. 1

Unit 1: Introduction to SAP Application Interface Framework (AIF)

2 © Copyright. All rights reserved.

 Unit 1
Lesson 1
Explaining Error Handling with and Without AIF

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain error handling with and without AIF

Introduction to SAP Application Interface Framework

Figure 1: Data Processing via Different Interfaces

The basic idea of interfaces is the automatic posting of data that was created from another
system. The steps for this are always the same. You need the possibility to bring data inside of
the system (IDoc, File,…) . Then a document is created in the system ( for example a sales
order ) and then people can work with this document.
Of course, sometimes the process does not work as desired and an error occurs. As the
sender of the interface trusts in getting for example the ordered items you always have to
repair such errors. Different error types will need different people in the company to be
solved.

© Copyright. All rights reserved. 3

Unit 1: Introduction to SAP Application Interface Framework (AIF)

Figure 2: Responsible People

Errors in interfaces are often handled by IT staff. Since typical error situations are often
business-related, why not have the business (power) user enabled to do monitoring and error
handling? This would clarify responsibilities and eliminate unnecessary communication
overhead. It would lead to an overall faster issue resolving process, higher data quality, and a
reduced interface TCO.
This is where the SAP Application Interface Framework (AIF) can support you. With AIF,
business users are able to do the monitoring for the business-related errors of interfaces.

Typical Error Situation

Figure 3: Typical Error Situation

During the processing of an interface, different errors can occur.

Here are some examples of errors that can occur:
● Low quality of data received.
● Typos at initial data creation.

4 © Copyright. All rights reserved.

 Lesson: Explaining Error Handling with and Without AIF

● Invalid identification information (e.g., credit card number or IBAN).

● Missing information (e.g., address data).
● Format conversion errors:
- Unexpected date format: MM/DD/YYYY vs. DD.MM.YYYY
- Unexpected floating point separator: 100.00 vs. 100,00
- Unexpected indication of negative numbers: (100) vs. -100 vs. 100-
● Missing mapping information:
- Customer master record for a given customer number not available
- Missing entries in value mappings
● Technical issues:
- Data record inaccessible (locked, moved, removed)
- Out of system memory

It is necessary to solve these errors but who is responsible and what is the best way to solve
them?

Figure 4: An Error Occurs, what are the Next Steps?

An error occurs during the processing of an interface.

There are two possible kinds of errors:
● Technical errors and
● Business errors.

When technical users monitor queues and see erroneous messages, they can try to solve the
problem.
In the best case scenario, the error is an technical error. A technical user can solve the
problem and restart the processing.

© Copyright. All rights reserved. 5

Unit 1: Introduction to SAP Application Interface Framework (AIF)

In the worst case scenario, a technical user ignores the error and waits for it to solve itself,
e.g., when the data is resent automatically every week.

Figure 5: Solve Errors Without AIF

An error occurs during the processing of an interface.

A technical user sees the erroneous message. The root cause is a business error. The
technical user has to find the business user responsible. If he does not know the business user
responsible (maybe the error occurs irregularly), he has to search for the business user who
can help him to solve the error. Depending on the interface's complexity, the departments
involved, and the technical user's business knowledge, this can be a long and cumbersome
process. Several people and a lot of communication overhead can be involved before the
error can be resolved. This can cost a lot of time and money.

Figure 6: Solve Errors with AIF

6 © Copyright. All rights reserved.

 Lesson: Explaining Error Handling with and Without AIF

An error occurs during the processing of an interface.

The root cause is a business error. The business user responsible sees the error message in
Monitoring and Error Handling in AIF. The business user can start to work directly on the
problem. The technical user is not required to solve the problem and does not need to
dispatch the messages to the corresponding business users. The technical user can continue
working on IT tasks.

SAP Application Interface Framework

Figure 7: SAP Application Interface Framework

One of the main parts of AIF is to ensure the user who has to solve the problem is informed
about the problem and get help from the system, for example, directions on how to proceed.

Figure 8: Interface Implementation, Monitoring and Error Handling

The figure shows the two main capabilities of AIF:

© Copyright. All rights reserved. 7

Unit 1: Introduction to SAP Application Interface Framework (AIF)

● Error Monitoring and

● Interface Development.

Interface Implementation (Design Time):

● Interface implementation mainly through Customizing menus.
● Easy access to relevant data or functions of underlying SAP application.
● Re-use of interface components (for example checks, mappings, and actions).
● Supports variants of interfaces (exceptions or additional steps).
● Independent implementation and testing of interface components and interface variants.

Monitoring and Error Handling (Runtime & Operations):

● Business user monitoring (power user).
● Customizable authorizations for interface access.
● Overview of interface status.

AIF focuses on the monitoring of errors with special help for business users. The right people
can be informed depending on the content of the interface. For example, it is possible that the
errors of one sales organization are sent to one user and those of another sales organization
to another user. The monitoring can be done for existing interfaces as well as for interfaces
developed in AIF.
Another focus of AIF is the development of interfaces. AIF makes it possible to create all
necessary steps to post an interface with an existing business function as well as create a new
business function.

Figure 9: Benefits

The AIF tools for developers and business users will reduce workload for both IT and
Business, resulting in daily work being carried out faster and reducing costs company-wide.

8 © Copyright. All rights reserved.

 Lesson: Explaining Error Handling with and Without AIF

AIF Architecture Overview

Figure 10: Architecture Overview

Data is sent in different formats (for example IDoc, Proxy, BDoc, and files) from different
systems (for example via a middleware system like PI) to the SAP Application System.
The incoming data is passed to AIF. AIF executes the checks, field mappings, and value
mappings that are defined for the interface. In addition, the actions are executed from within
the actions BAPIs, standard functions, or customer-specific functions are called. These
functions post the data in the application system.
The development of an AIF interface is done by a technical user. This user performs the
necessary steps in Customizing for the SAP Application Interface Framework.
When data is processed in AIF, an application log is written. The messages stored in the
application log or standard logs (for example, an IDoc's status records) are displayed in
Monitoring and Error Handling. These messages help the users doing monitoring and error
handling to solve the error. Monitoring and error handling is done by business users in the
SAP Application System.
If the interface has been enabled for alert management, the business user(s) assigned to the
interface is alerted when an error occurs.
You can assign different authorizations to different users to meet security and authorization
requirements.

© Copyright. All rights reserved. 9

Unit 1: Introduction to SAP Application Interface Framework (AIF)

Usage Scenarios

Figure 11: Usage Scenario 1 - Runtime and Monitoring

Scenario 1 - Runtime and Monitoring

This is the "classic" AIF scenario. Interfaces are built - mainly based on Customizing - with the
SAP Application Interface Framework. Monitoring of the interfaces is done in AIF. Due to the
very high integration and synergy between interface development and ongoing monitoring
inside one single tool, this scenario provides excellent benefits.
This scenario can be used based on top of multiple interface technologies (for example, web
service, IDOC, qRFC, bgRFC, and customer-specific technologies).

Figure 12: Usage Scenarios 2 and 3

10 © Copyright. All rights reserved.

 Lesson: Explaining Error Handling with and Without AIF

Scenario 2 - Monitoring
In scenario 2, AIF is only used for monitoring. This scenario provides very quick wins and
benefits for customers who want to have a very efficient and business-centric monitoring tool
but who have existing interfaces or who have specific reasons to use another interface
technology instead of AIF. This scenario can be used to monitor existing interfaces and
requires very few changes or adaptions.
To monitor existing interfaces, a surrounding AIF interface is required to tell the framework
what to monitor.
Scenario 3 - Runtime
This scenario can be used in cases where functions from AIF runtime should be re-used, (for
example checks, mappings, and actions), without the need for monitoring, (for example,
synchronous call where error handling is done in the calling application).
This enables you to call logic from the framework for multiple use cases while having an
excellent governance through a structured and central view and handling of interface logic
instead of doing it locally in multiple different tools and technologies.

Underlying Basis Technologies

Figure 13: Coverage of Underlying Basis Technologies

The SAP Application Interface Framework allows you to implement and monitor interfaces of
different interface technologies. The support of several technologies is delivered with AIF:
● Proxy XI Runtime
● AIF Runtime XML
● Files
● ALE / IDoc
● Web Service
● Enterprise Service, and
● BDoc.

© Copyright. All rights reserved. 11

Unit 1: Introduction to SAP Application Interface Framework (AIF)

Furthermore, the monitoring and error handling of AIF can be extended to also support other
technologies. This can be done with custom code without having to modify the monitoring
and error handling. In this way, it is possible to support, for example:
● CIF
● qRFC
● bgRFC
● MWB
● or any other customer-specific technology.

Figure 14: Interface Monitor, Display

The figure shows the main screen of the interface monitor.

12 © Copyright. All rights reserved.

 Lesson: Explaining Error Handling with and Without AIF

Figure 15: Interface Monitor, Details

The Interface Monitor provides an overview of the different interfaces a user is responsible
for. It is available with a SAP GUI and a web-based user interface.
The Interface Monitor consists of two main parts:
● Message Overview: Provides a personalized overview of the interfaces the user is
responsible for. Displays the overall status (Okay, Caution, Errors, and Undefined) of an
interface. Also, the number of messages for each status (Warnings, Application Errors,
Successfully Processed, Technical Error, and In Process) is displayed. As well as the
number of messages for each status, the sum of all messages is displayed. If the interface
uses key fields for recipient determination, the key fields are also displayed.
● Calendar: With the calendar, you can restrict the data range for the information shown in
the message overview. This can be done by selecting dates in the calendar control. Days
where messages are found in the system are highlighted as follows depending on the
highest error status:
- Red: There are error message for this day (successful, canceled and warning messages
may also have occurred).
- Yellow: There are warning messages (successful or canceled messages may also have
occurred; there are no error messages).
- Green: There are only successful or canceled messages.

If the calendar is not displayed, press the Without Date Restriction button .
Possible Activities in the Calendar:

Restrict Date Range

You can restrict the selected messages by using with date restriction and by specifying a
date range or by marking a date range in the calendar.
Set Timer
You can specify the seconds before the content of the Interface Monitor is refreshed
automatically.

© Copyright. All rights reserved. 13

Unit 1: Introduction to SAP Application Interface Framework (AIF)

Message Summary
You can access the Message Summary from the Interface Monitor; select a namespace
or an interface and choose Message Summary.
Error Handling
You can navigate directly to Monitoring and Error Handling by clicking on one of the
status icons.

Message Summary

Figure 16: Message Summary

The figure shows a screenshot of the message summary screen.

Facts About the Message Summary:

● The Message Summary provides an overview of how often a certain log message was
written to the application log and how many data messages used a certain log message:
- Groups messages by namespace, interface name, and version.
- Allows users to get an overview of how frequently an error occurs.
- Provides mass reprocess and cancel functions.
- Navigate to Monitoring and Error Handling.
● Only users with the correct authorizations can use the mass restart and cancel
functionalities for an interface.

You can navigate to Monitoring and Error Handling from the Message Summary by double
clicking on one line of the Message Summary. In Monitoring and Error Handling, all messages
with the same message are displayed. For example, a user can jump to Monitoring and Error
Handling and display all messages with one specific error. The user has a clear overview of the
affected messages and can easily fix the issue for all messages.
You can use mass restart and cancel functionality in the Message Summary. For example, if a
user sees an error message that belongs to a logging problem, the user can select the
message and restart the corresponding messages without needing to navigate to Monitoring
and Error Handling, select the corresponding messages, and restart them.

14 © Copyright. All rights reserved.

 Lesson: Explaining Error Handling with and Without AIF

Monitoring and Error Handling

Figure 17: Monitoring and Error Handling

The Monitoring and Error Handling transaction enables the user to analyze errors, correct
errors, and restart or cancel messages.
Access to interface data can be restricted using authorizations.
The transaction can be accessed from the Interface Monitor or via transaction code /AIF/
ERR.

Figure 18: Monitoring and Error Handling - Views

The figure illustrates the main views of the monitoring and error handling.

© Copyright. All rights reserved. 15

Unit 1: Introduction to SAP Application Interface Framework (AIF)

LESSON SUMMARY
You should now be able to:
● Explain error handling with and without AIF

16 © Copyright. All rights reserved.

 Unit 1

Learning Assessment

1. With AIF business users can be connected to different Interfaces so everyone sees only
those Interfaces he or she is responsible for.
Determine whether this statement is true or false.

X True

X False

2. Which are the two main components of AIF.

Choose the correct answer.

X A Interface monitoring and user monitoring

X B Interface monitoring and Interface implementation

X C User management and Interface implementation

X D User management and authorization management

3. Which are the three usage scenarios of AIF?

Choose the correct answers.

X A Runtime and monitoring

X B Monitoring of existing Interfaces

X C Monitoring of user activities

X D Use runtime only

X E Convert synchronous Interfaces to asynchronous

© Copyright. All rights reserved. 17

 Unit 1

Learning Assessment - Answers

1. With AIF business users can be connected to different Interfaces so everyone sees only
those Interfaces he or she is responsible for.
Determine whether this statement is true or false.

X True

X False

This is correct. With AIF business users can be connected to different Interfaces so
everyone sees only those Interfaces he or she is responsible for. See BIT750, Unit 1,
Lesson 1.

2. Which are the two main components of AIF.

Choose the correct answer.

X A Interface monitoring and user monitoring

X B Interface monitoring and Interface implementation

X C User management and Interface implementation

X D User management and authorization management

This is correct. The two main components are Interface monitoring and Interface
implementation. See BIT750, Unit 1, Lesson 1.

3. Which are the three usage scenarios of AIF?

Choose the correct answers.

X A Runtime and monitoring

X B Monitoring of existing Interfaces

X C Monitoring of user activities

X D Use runtime only

X E Convert synchronous Interfaces to asynchronous

This is correct. Usage scenarios are: Runtime and monitoring, monitoring of existing
Interfaces, and the use of the runtime only. See BIT750, Unit 1, Lesson 1.

18 © Copyright. All rights reserved.

 UNIT 2 General Functionality

Lesson 1
Explaining General Functionality 21

Lesson 2
Explaining the Scenario of the Exercises 35

UNIT OBJECTIVES

● Explain general functionality

● Explain the scenario of the exercises

© Copyright. All rights reserved. 19

Unit 2: General Functionality

20 © Copyright. All rights reserved.

 Unit 2
Lesson 1
Explaining General Functionality

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain general functionality

General Functionality

Figure 19: How to Develop an Interface - Required Steps

The figure, How to Develop an Interface - Required Steps, shows the main components in AIF.
This is just an overview. The single components will be explained in detail during this lesson.

© Copyright. All rights reserved. 21

Unit 2: General Functionality

Figure 20: How to Develop an Interface - Optional Steps

AIF also provides optional steps. These are not necessary to run an interface but they can
make life easier. The recipient is very important for the business users and is explained in
detail during this training.

Namespace

Figure 21: Namespace

A namespace is used for the logical structuring of objects and configurations in the SAP
Application Interface Framework. All interfaces, value mappings, fix values, checks, and
actions have to be assigned to a namespace. Customizing activities like Define Interface,
Define Value Mappings, Define Fix Values, Define Checks, and Define Actions are locked at
namespace level. If one user edits the objects and configurations of a specific namespace,
these are locked for other users.
You can set authorizations for Customizing and error handling based on the namespace.
AIF delivers one example namespace: /AIF/. This namespace cannot be used to develop
interfaces. It is a read only namespace.
To create a new namespace go to AIF Customizing. The AIF Customizing can be found in the
SAP menu under Cross-Application Components → SAP Application Interface
Framework → Administration → Configuration → Customizing. You can go directly to

22 © Copyright. All rights reserved.

 Lesson: Explaining General Functionality

Customizing via transaction /AIF/CUST. You can create a new namespace in the activity
Define Namespace, which you can find in Customizing under the Interface Development topic.
Create a new namespace via the New Entries button. Assign a name to the namespace and
provide a short description.

Figure 22: Objects Belonging to a Namespace

A namespace can contain:

● Several defined interfaces
● Several defined checks
● Several defined value mappings
● Several defined actions

Example How To Structure Namespaces:

● Create your own namespace for generic and reusable objects.

● Objects that are explicit to an interface should be placed into the same namespace.
● Example 1: Group by Project Name and Application Component:
- XY_FIN (Financials)
- XY_CRM (Customer Relationship Management)
- XY (Reusable objects for project XY)
● Example 2: Group Interfaces by the Type of Data:
- Inbound Interfaces are assigned to namespace INB001, INB002,…
- Outbound Interfaces are assigned to namespace OUT001, OUT002,…

The namespace is a 6 digit CHAR field. You are free to name your namespaces in the way you
require them. There are no naming restrictions from the AIF side.

© Copyright. All rights reserved. 23

Unit 2: General Functionality

Example 1: You could create the namespaces with a unique abbreviation for the project
together with a grouping by application component or business object:
● <ProjectName>_<ApplicationComponent>
● <ProjectName>_<BusinessObjet>

Interface

Figure 23: Interface

For every interface that should be monitored or processed by AIF, a corresponding AIF
interface is required. It is necessary to set up the interface according to the communication
technology used. After the interface is defined, you can maintain mappings and assign actions
to this interface.
To create an interface, a namespace is required. The new interface will be assigned to this
namespace. You require a RAW data structure and an SAP data structure for this interface.
You require the authorization to maintain interfaces for the given namespace.
AIF delivers no standard interfaces, and, by default, the interface list is empty.
To create a new interface, go to the AIF Customizing and start the Define Interfaces activity,
which can be found under the Interface Development node. As stated before, interfaces are
namespace dependent and, therefore, you have to enter the namespace.
An interface requires a name and a version. The interface name is a 10 digit CHAR field. You
can create different versions of an AIF interface. Every AIF interface also requires a version
number. The purpose of the interface should be described in the Description field. In addition
to the interface name, version, and description, you have to define at least the raw data
structure and the SAP data structure for the interface.

Facts About the Interface Version:

● An interface can have several versions. The unique identifier for an interface is the
combination of namespace, interface name, and version.
● When is it useful to create a new version of an interface?
- If the processing of an interface requires some changes but the purpose of the interface
is unchanged.

24 © Copyright. All rights reserved.

 Lesson: Explaining General Functionality

- If changes to an interface are required for a defined target date and changes to the
general Customizing of the interface are not possible.
● In AIF processing, the highest interface version is selected by default.

To use the latest version of an interface is the default provided by AIF. It is also possible to do
an Interface determination and find the version to use from rules. This rules can also be
dependant from the content of an interface.

Figure 24: What Happens in an Interface?

The figure What Happens in an Interface? shows how interfaces can be used by AIF.
Data is sent to an interface. The incoming data is transferred to the source structure used in
the AIF interface. In the next step, the structure mappings, checks, and value mappings
defined for the interface are executed. After the data has been successfully mapped into the
defined destination structure, the actions are executed. Within an action, the processing of
the data via standard processing functions, BAPIs, or customer functions is started.

© Copyright. All rights reserved. 25

Unit 2: General Functionality

Source and Destination Structure

Figure 25: RAW / SAP Structure

Whether the RAW or the SAP structure is the source or destination structure depends on the
interface's direction. The following are further explanations:

RAW Structure
Defines the name of the raw data structure for an interface in the SAP Application
Interface Framework.
For inbound interfaces, the components of the structure are defined by the format of the
data sent by the sending system. The raw data structure is the source structure for
inbound interfaces. During runtime, the data of the raw data structure is mapped to the
destination structure (SAP structure).
For outbound interfaces, the components of the structure are defined by the data
required by the external system. The raw data structure is the destination structure for
outbound interfaces. During runtime, the data of the source structure is mapped to the
raw data structure (destination structure).
SAP Structure
Defines the name of the SAP data structure for an interface in the SAP Application
Interface Framework.
For inbound interfaces, the components of the structure are usually defined by the
class's methods or function modules to be executed in the system. For inbound
interfaces, the SAP data structure is the destination structure. During runtime, the data
of the source structure is mapped to the SAP data structure.
For outbound interfaces, the components of the structure are usually defined by the
format of the data stored in the system or by the data available in the function, report,
etc., that triggers the processing. For outbound interfaces, the SAP data structure is the
source structure. During runtime, the data of the SAP data structure is mapped to the
destination structure.
The raw and the SAP structure used must exist in the ABAP dictionary.

26 © Copyright. All rights reserved.

 Lesson: Explaining General Functionality

Source Structure
The source structure is the structure send to AIF. In an Inbound interface it is the RAW
Structure in an outbound Interface the SAP Structure.
Outbound Interface
The source structure for an outbound interface is the internal structure. Usually, you
have to create the structure in the ABAP dictionary. How the structure should look
depends on the data you have to pass to AIF in order to be able to derive all the necessary
information required by the receiver. For example, you have a report that triggers the
sending of data. The user can fill some fields on a selection screen. These fields have to
be passed to AIF then and your source structure has to contain those fields.
Inbound Interface
For an inbound interface, the destination structure is usually pre-defined, since it has to
fit to the data received from the external system. For example, for an ABAP proxy, the
source structure is the type of INPUT parameter of the proxy class method.
Target Structure
The target Structure is sent from AIF to the final destination. In an Inbound Interface it is
the SAP structure in an outbound Interface it is the RAW Structure.
Outbound Interface
For an outbound interface, the destination structure is usually pre-defined, since it has to
fit to the data required by the external system. For example, for an outbound proxy
interface, the structure is defined by the proxy class method's OUTPUT parameter. The
raw data structure is the destination structure.
Inbound Interface
For an inbound interface, you usually have to create the destination structure in the
ABAP dictionary. How the structure should look, depends on the functions you want to
call in your actions. The SAP data structure is the destination structure. In our example,
we will create customers and flight bookings by calling the corresponding BAPIs.
Therefore, the destination structure has to contain the BAPIs' structures.

Engines

Figure 26: Engines Used in AIF

How an interface is processed and monitored in AIF is driven by the enginges. AIF knows 4
different engine types as shown in the figure. For all this engines at least one AIF own engine is

© Copyright. All rights reserved. 27

Unit 2: General Functionality

provided. Also for a lot of interface technologies like IDoc or Proxy engines are delivered which
use the origin interface technology inside of AIF.

Figure 27: Application Engine

The Application Engine determines how the received messages should be handled in
Monitoring and Error Handling. Which application engine handles the requests depends on
the technology used to process the data messages.
AIF delivers some standard engines:
● Proxy - Handles messages received via proxy form SAP NetWeaver PI or via a web service
● IDoc - Handles IDocs that are processed with ALE Runtime
● XML - Handles messages processed with AIF's XML runtime
● Test File - Handles test files that have been created with the AIF test tool
● ECH - Handles asynchronous data messages received via a proxy from SAP PI but
processed by the Error and Conflict Handler application. Each message will have a
corresponding postprocessing order (only available with AIFX and NetWeaver 7.31)
● BDC - Handles BDC messages
● CIF - Handles CIF messages
● qRFC - Handles qRFC messages
● tRFC - Handles tRFC messages

28 © Copyright. All rights reserved.

 Lesson: Explaining General Functionality

Figure 28: Persistence Engine

The persistence engine determines which persistence engine class is used to retrieve or
update the data messages on their corresponding persistence layer. Which persistence
engine should be used depends on where the interface persists the processed message
content.
AIF delivers the following standard persistence engines:
● Proxy - Handles the data content of data messages processed by the local integration
engine.
● IDoc - Handles the data content of data messages processed by the ALE Runtime.
● XML - Handles the data content of data messages stored in AIF's own persistence layer.
● Test File - Handles the data content of files processed with the AIF test tool.
● ECH - Handles the data content of messages processed with the Error and Conflict
Handler application. Includes load data and save data as new version (only available in
AIFX and NetWeaver 7.31).
● BDC - Handles the data content of BDC messages.
● CIF - Handles the data content of CIF messages.
● qRFC - Handles the data content of qRFC messages.
● tRFC - Handles the data content of tRFC messages.

© Copyright. All rights reserved. 29

Unit 2: General Functionality

Figure 29: Selection Engine

The selection engine determines which data messages are to be displayed in Monitoring and
Error Handling. In order to select the data messages, it evaluates the data from the selection
screen. Furthermore, it prepares the data messages header data so that it can be displayed in
the Data Messages view of the Monitoring and Error Handling screen.
AIF delivers the following standard selection engines:

AIF Index Tables

Handles data messages where entries were written into AIF index tables during message
processing.
IDoc Control Records
Handles IDocs that have been processed without AIF. Data is selected from the IDoc
control records.
ECH
Handles messages that have been processed by the Error and Conflict Handler
application instead of AIF. The data is selected from postprocessing order related tables
(only available in AIFX and NetWeaver 7.31).
tRFC Status Tables
Handles tRFC messages that have been processed without AIF. Data is selected from the
tRFC status tables.

30 © Copyright. All rights reserved.

 Lesson: Explaining General Functionality

Figure 30: Logging Engine

The Logging Engine defines, from where the log messages, which are displayed in the
Monitoring and Error Handling, are retrieved. These log messages are written during the
processing of a data message.
The Logging Engine is also used to write log messages for the AIF enabler. Which logging
engine should be chosen depends on how the log entries are written when processing a data
message of an interface.
The following logging engines are delivered with AIF:

AIF Application Log

Handles log messages that are written to the application log. If the Proxy or XML enabler
is used, the AIF application log engine should be chosen.
IDoc Status Records
If AIF is not involved in the processing of an IDoc, the IDoc status records can be
displayed as log messages in Monitoring and Error Handling. When using the enabler for
IDocs, the enabler will not write any application log entries if the IDoc status records
logging engine is used.
ECH
Handles messages for a postprocessing order raised during Error and Conflict Handler
application processing (only available with AIFX and NetWeaver 7.31).
tRFC
If AIF is not involved in the processing of an tRFC message, the tRFC status table can be
used to display log messages in Monitoring and Error Handling.

© Copyright. All rights reserved. 31

Unit 2: General Functionality

AIF's XML Persistence and Runtime

Figure 31: AIF's XML Persistence and Runtime

For interfaces that use the XML runtime and persistence the application and persistence
engines have to be set to XML. We will use the runtime and persistence for the interface that
we create during the first exercises.

Recipients

Figure 32: Recipients

Recipients define for which interfaces the (business) users are responsible. Recipients also
define which interfaces a user should see in the Interface Monitor. The user has to be
assigned to a recipient and the Include in Overview checkbox has to be selected.

32 © Copyright. All rights reserved.

 Lesson: Explaining General Functionality

Instead of assigning single users, you can assign roles to the recipients.
You can assign different interfaces to one recipient. You can also assign a user to multiple
recipients.
With recipients, you can also notify the users in the case of errors. AIF uses SAP Alert
Management. Therefore, the users can receive emails or see the alerts in their alert inbox. An
email is only sent for the first erroneous message of an interface. A new alert is only sent out if
the old alert was confirmed or has expired.

Figure 33: How to Set Up a Recipient in General

Before you start to set up recipients, you should think about who should be responsible for
which interface, who needs to be informed in case an error occurs, and who needs to do
something to correct the error. For example, users from an FI department are not responsible
for interfaces related to HR and, therefore, the FI users should not see any interface belonging
to HR in the Interface Monitor.
The first step in the setup of recipients is to define the recipient itself. You can do this in AIF
Customizing in Error Handling → Namespace-Specific Features → Define Recipients. Give the
recipient a meaningful name and description.
Next, you have to assign the recipient to the interface(s) that should be monitored with it. You
can either assign the recipient to a specific interface(s), you can assign the recipient to a
complete namespace, or you can assign the recipient as key field dependent (Unit 6). If you
assign the recipient to the complete namespace, you can monitor all interfaces of the
namespace.
If you want to assign the recipient to specific interfaces, you can do this via the Interface-
Specific Features in the AIF Customizing in Error Handling → Interface-Specific
Features → Assign Recipients without Key Fields.

© Copyright. All rights reserved. 33

Unit 2: General Functionality

Figure 34: How to Set Up an Interface-Specific Recipient

After you have created the recipient and assigned the interfaces, the users have to be
assigned. In Customizing for AIF, go to System Configuration → Assign Recipients.
You can assign users or roles. If the users should be able to see the messages in the Interface
Monitor, the Include in Overview Screen checkbox has to be selected. If the Technical User
checkbox is selected, the user will also see messages that are in process or messages with
the status "technical error" in the Interface Monitor.
Furthermore, you can assign external addresses, for example, an email address or a mobile
number for SMS notification.

LESSON SUMMARY
You should now be able to:
● Explain general functionality

34 © Copyright. All rights reserved.

 Unit 2
Lesson 2
Explaining the Scenario of the Exercises

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain the scenario of the exercises

Exercise Scenario

Figure 35: Scenario for Exercises, 1/4

During the training, we will create an AIF interface step-by-step. In this process, we will have a
look at different AIF objects like structure mappings, value mappings, and checks. The goal of
the exercises is to have an AIF interface that will create customers and book flights for those
newly created customers.
While AIF is able to handle messages from different interfaces (see Unit 1), we will use AIF's
XML runtime and persistence for our interface.

© Copyright. All rights reserved. 35

Unit 2: General Functionality

Figure 36: Scenario for Exercises, 2/4

The figure shows the next step in our scenario: customer information.

Figure 37: Scenario for Exercises, 3/4

The figure shows the next steps in our scenario: posting and checking bookings.

36 © Copyright. All rights reserved.

 Lesson: Explaining the Scenario of the Exercises

Figure 38: Scenario for Exercises, 4/4

The figure shows the last step in our scenario: monitoring.

Scenario Description
During the exercises of this training, you build a scenario to automatically create new
customers in the system and book flights for those customers.
Required Structures
To be able to process the examples described below, the following structures are required:

Figure 39: Source Structure

This structure contains the following components:

Table 1: Structure: ZAIF_T100_TRAVEL_AGENCY

Component Component Type

AGENCYNUM S_AGENCYNUM
NAME S_AGENCYNAME

© Copyright. All rights reserved. 37

Unit 2: General Functionality

Table 2: Structure: ZAIF_ T100_CUSTOMER

Component Component Type

ID S_CUSTOMER

NAME S_CUSTNAME

STREET S_STREET

POSTCODE POSTCODE

CITY CITY

COUNTRY STRING

TELEPHONE S_PHONENO

CUSTTYPE STRING

EMAIL S_EMAIL

CLASS STRING

CREDITCARD CCNUM

Table 3: Structure: ZAIF_ T100_FLIGHT_BOOKING

Component Component Type

FLDATE STRING

CLASS S_CLASS

AIRPORT_FROM S_FROMAIRP

AIRPORT_TO S_TOAIRP

Table 4: Table Type: ZAIF_ T100_FLIGHT_BOOKINGS

Component Component Type

Line Type ZAIF_S###_FLIGHT_BOOKING

Table 5: Structure: ZAIF_ T100_CUSTOMER_BOOKING

Component Component Type

CUSTOMER_DETAILS ZAIF_S###_CUSTOMER

FLIGHT_BOOKINGS ZAIF_S###_FLIGHT_BOOKINGS

38 © Copyright. All rights reserved.

 Lesson: Explaining the Scenario of the Exercises

Table 6: Table Type: ZAIF_ T100_CUSTOMERS

Component Component Type

Line Type ZAIF_S###_CUSTOMER_BOOKING

Table 7: Structure: ZAIF_ T100_SALES_AGENT

Component Component Type

SALES_AGENT_ID CHAR20

NAME STRING

PHONE S_PHONENO

EMAIL S_EMAIL

AGENGY_NUMBER S_AGENCYNUM

Table 8: Structure: ZAIF_S###_RAW_FLIGHT

Component Component Type

TRAVEL_AGENCY ZAIF_S###_TRAVEL_AGENCY

CUSTOMER_DATA ZAIF_S###_CUSTOMERS

SALES_AGENT ZAIF_S###_SALES_AGENT

Figure 40: Destination Structure

This structure contains the following components:

© Copyright. All rights reserved. 39

Unit 2: General Functionality

Table 9: Structure: ZAIF_ T100_SALES_AGENT

Component Component Type

SALES_AGENT_ID CHAR20

NAME STRING

PHONE S_PHONENO

EMAIL S_EMAIL

AGENCY_NUMBER S_AGENCYNUM

Table 10: Structure: ZAIF_ T100_CUSTOMER_DETAIL

Component Component Type

ID S_CUSTOMER

CUSTOMER_DATA BAPISCUNEW

CREDITCARD CCNUM

Table 11: Table Type: ZAIF_ T100_CUSTOMER_DETAILS

Component Component Type

Line Type ZAIF_S###_CUSTOMER_DETAIL

Table 12: Structure: ZAIF_ T100_BOOKING_DETAIL

Component Component Type

LINE_ID INT1

RESERVE_ONLY S_RESERV

BOOKING_DATA BAPISBONEW

AIRLINEID S_CARR_ID

BOOKINGNUMBER S_BOOK_ID

TICKET_PRCE BAPISBOPRI

Table 13: Table Type: ZAIF_ T100_BOOKING_DETAILS

Component Component Type

Line Type ZAIF_S###_BOOKING_DETAIL

40 © Copyright. All rights reserved.

 Lesson: Explaining the Scenario of the Exercises

Table 14: Structure: ZAIF_ T100_SAP_FLIGHT

Component Component Type

SALES_AGENT ZAIF_S###_SALES_AGENT

CUSTOMERS ZAIF_S###_CUSTOMER_DETAILS

FLIGHT_BOOKINGS ZAIF_S###_BOOKING_DETAILS

LESSON SUMMARY
You should now be able to:
● Explain the scenario of the exercises

© Copyright. All rights reserved. 41

Unit 2: General Functionality

42 © Copyright. All rights reserved.

 Unit 2

Learning Assessment

1. Which are the 4 engines of AIF?

Choose the correct answers.

X A Logging engine

X B Adapter engine

X C Persistence engine

X D Selection engine

X E Monitoring engine

X F Application engine

X G Process engine

X H Integration engine

2. To create an Interface you need a namespace first.

Determine whether this statement is true or false.

X True

X False

© Copyright. All rights reserved. 43

Unit 2: Learning Assessment

3. What is true about the RAW and the SAP structure of an interface?
Choose the correct answers.

X A Every Interface needs a RAW and a SAP structure, they are mandatory fields.

X B Both structures have to be defined in the data dictionary.

X C The RAW structure is always sent to AIF and the SAP structure is always sent from
AIF

X D Which structure is passed over to AIF and which one is sent from AIF depends on
the direction of the interface. Inbound and Outbound Interfaces are handled
differently.

X E The RAW structure looks like the partner data the SAP structure looks like the SAP
data.

X F The RAW structure and the SAP structure are always the same.

44 © Copyright. All rights reserved.

 Unit 2

Learning Assessment - Answers

1. Which are the 4 engines of AIF?

Choose the correct answers.

X A Logging engine

X B Adapter engine

X C Persistence engine

X D Selection engine

X E Monitoring engine

X F Application engine

X G Process engine

X H Integration engine

This is correct. Engines are: logging, persistence, selection and application. See BIT750,
Unit 2, Lesson 1.

2. To create an Interface you need a namespace first.

Determine whether this statement is true or false.

X True

X False

This is correct. You need a namespace first. See BIT750, Unit 2, Lesson 1.

© Copyright. All rights reserved. 45

Unit 2: Learning Assessment - Answers

3. What is true about the RAW and the SAP structure of an interface?
Choose the correct answers.

X A Every Interface needs a RAW and a SAP structure, they are mandatory fields.

X B Both structures have to be defined in the data dictionary.

X C The RAW structure is always sent to AIF and the SAP structure is always sent from
AIF

X D Which structure is passed over to AIF and which one is sent from AIF depends on
the direction of the interface. Inbound and Outbound Interfaces are handled
differently.

X E The RAW structure looks like the partner data the SAP structure looks like the SAP
data.

X F The RAW structure and the SAP structure are always the same.

This is correct. The RAW structure is not always sent to AIF and the RAW structure and
the SAP structure are not always the same. See BIT750, Unit 2, Lesson 1.

46 © Copyright. All rights reserved.

 UNIT 3 Basic Interface Development

Lesson 1
Exploring Basic Interface Development 49

UNIT OBJECTIVES

● Explore basic interface development

© Copyright. All rights reserved. 47

Unit 3: Basic Interface Development

48 © Copyright. All rights reserved.

 Unit 3
Lesson 1
Exploring Basic Interface Development

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explore basic interface development

Basic Interface Development

Figure 41: Structure Mapping

The source and destination structure of an interface usually differ. Therefore, structure
mapping is needed. The structure mapping defines how the data from the source structure
should be passed to the destination structure. To achieve this, some other AIF objects (for
example, checks, value mappings, or fix values) are needed for structure mapping.

© Copyright. All rights reserved. 49

Unit 3: Basic Interface Development

Figure 42: Structure Mapping Sub-Process

Mapping is one of the central parts of AIF. It happens quite seldom that a partner can deliver
data in the way the SAP system needs, or SAP can deliver it in a way the partner needs it. So
we will have very often mappings.
The first step always is to tell which field in the source structure shall be used for which target
field. This is called the structure mapping.
If the relevant field is found it might be usable directly. But it is also possible that we have to
convert it for example $ to USD or 10.05.2019 to 20191005. This conversion is called value
mapping. If a source structure can not provide a field at all we might have to set fixed values.
Additionally, AIF gives us the possibility to use conditions and have different mappings
depending on those conditions. This makes it possible to use a special field if a fit exists, and
use a more global field if not.

Figure 43: Source Structure

Depending on whether the processed interface is inbound or outbound, the source structure
is:

50 © Copyright. All rights reserved.

 Lesson: Exploring Basic Interface Development

● The raw data structure or a sub-structure/-table of it if the interface is an inbound

interface
● The SAP data structure or a sub-structure/-table of it if the interface is an outbound
interface

If the root structure should be selected, instead of entering the name of the root structure in
the Source Structure field, you need to insert a space character (the field stays empty besides
the <blank>).

Figure 44: Destination Structure

The destination structure is the counterpart to the selected source structure.

If you select the root structure as source structure, the destination structure can be left
empty.
If the source and destination structure are identical, you can map the fields of the structures
via the Move Corresponding Fields functionality. The Move Corresponding Fields functionality
maps the entries from a source field to its counterpart in the destination structure. In this
case, you do not need additional field mappings.
If you select the Move Corresponding Fields checkbox, the complete structure including the
sub-structure and sub-tables are mapped.
If you select the Copy Fields only checkbox, in addition to the Move Corresponding Fields
checkbox, only the fields are mapped.

© Copyright. All rights reserved. 51

Unit 3: Basic Interface Development

Figure 45: Field Mapping

You have to map the fields of the source structure to the fields of the destination structure.
You do this via field mappings.
To create a field mapping, at least the field in the destination structure and the field name of
the source field is required. All other options are not mandatory.
In a field mapping, you can maintain the following information:

Field in Destination Structure

Defines a field in the destination structure to where the data is mapped.
Source Fields
You can insert up to five fields as source fields in the Field Name 1 to 5 fields. The fields
contain the name of a field in the source structure. These field can also contain the field
names of a destination structure field. In case a destination structure field was selected,
an '@' sign must prepend the field name. The defined fields are available as parameters
and can be used in value mappings or checks. An offset and a length can be defined, as
well as a separator string. The contents of the Field Name fields are split by this character
or symbol in the destination structure. If multiple field names are maintained and no
further settings are made, the values of the fields are concatenated into the destination
field.
Offset and Field Length
Specify the offset and field length of the data that should be passed into the destination
field.
Field Name for Data Link
If multiple fields are maintained in Field Name 1 to Field Name 5, this field indicates to
which field an error should be linked in Monitoring and Error Handling if an error occurs
during field mapping. If only Field Name 1 is maintained, this field is used automatically to
create the link.
Value Mapping Function

52 © Copyright. All rights reserved.

 Lesson: Exploring Basic Interface Development

Maintain a function module for a value mapping.

Value Mapping
The fields defined in Field Names 1 to 5 are available as parameters for the value
mapping. To make use of the parameter, you have to insert '$<Fieldname number>'
in an appropriate field in the value mapping. At runtime, '$<Fieldname number>' is
replaced by the current value of the field. They can be used in a "where" condition or in a
value mapping function defined in this value mapping. If an error message was defined in
the value mapping, the fields can be used to replace placeholders in the error message as
well. Furthermore, they can be used as external values for a single or multiple value
mapping table. If you enter a name of a value mapping that does not exist, the system
offers you the opportunity to create the value mapping.
Data Element for Conversion/Conversion Routine/Direction of Conversion Exit
Enter the conversion routine (for example, ALPHA) in the Conversion Routine field.
Maintain the direction of the conversion in the Direction of Conversion field. Instead of
entering a conversion routine, you can also insert a Data Element for Conversion (for
example DATS).
Namespace / Check
ou can enter the namespace and name of a check here. The check is executed during
field mapping. If the check fails, the field mapping will also fail. Per default, the data in
Field in Destination Structure will be checked. Select the Check Before Mapping
checkbox to check the source data.

You can enter a fix value directly in the Field Name field. If a fix value should be entered in one
of the source fields, you require a % followed by the value. for example, if the fix value for the
field is 5, the field input has to be %5.

Figure 46: How to Test an Interface

To test the mapping of an interface, you have two options: create data messages and try to
process them or you can use the AIF test tool.
If you can create data messages, you can see the result in Monitoring and Error Handling.
However, in some cases it might not be so easy to create new messages. Therefore, you can
use the AIF test tool to test the mapping of your interface.

© Copyright. All rights reserved. 53

Unit 3: Basic Interface Development

Figure 47: AIF Test Tool

With the AIF test tool, you can create a test file for an AIF interface.
If the report is started, you can search for a test file. If it is necessary to create a new file, just
choose Search on the first screen. You can also create a new file when the search result
displays.
A list containing all existing files that meet the selection criteria is displayed. You can select an
existing file from the list, or you can create a new file via the New Data button. A pop-up is
displayed that enables you to select the interface that the file will be created for.
After selecting a file, you can open it via the Read Data button. The file is displayed on a new
screen. The top half of the screen displays the structure of the data to be processed. You can
insert data into the structure. You can add or delete new lines by choosing the Add/Delete
buttons.
You can test the mapping of your interface. Choose the Transform button to execute the
mapping. The bottom half of the screen displays data in the SAP structure. After the
transformation is complete, you can check here if the mapping returns the expected results.
If the transformation is successful, the Process button is made available for use. Actions
assigned to the interface will then also be executed and the test file will also be visible in
Monitoring and Error Handling.

Note:
If you choose the Process button multiple times, a new entry will not be created in
Monitoring and Error Handling, since it is regarded as a reprocessing of the same
message/file.

The log messages of the transformation are displayed in the bottom half of the screen. If the
selected interface is an outbound proxy interface, the Send to PI pushbutton is made
available.

54 © Copyright. All rights reserved.

 Lesson: Exploring Basic Interface Development

Furthermore, if the interfaces use the AIF's XML runtime and persistence, a Process in XML
Runtime button is available. This allows you to create a "real" message that is processed in
AIF.

Checks

Figure 48: Checks

The purpose of a check is to identify if a specified condition is true or false for the given input
values. With checks, you can conditionally influence the processing in AIF.
You can assign checks in different places, for example, to conditionally skip a specific
mapping step, to conditionally execute a specific function of an action, or to identify
application error situations in which the processing should be stopped immediately.

© Copyright. All rights reserved. 55

Unit 3: Basic Interface Development

Figure 49: Reusability of Checks

In the SAP Application Interface Framework, a check has a well-defined input (up to five field
values) and a well-defined output (a success checkbox indicating the result of the check), and
they remain independent of the context in which they are used. As a result, checks can easily
be reused by several interfaces in the SAP Application Interface Framework.

Figure 50: Define a Reusable Check

You can create a reusable check in the AIF Customizing via the Define Checks Customizing
activity.
There are some simple field checks that are already predefined, for example:
● Check if the field has only numeric values, is not empty, contains only capitals, etc.

56 © Copyright. All rights reserved.

 Lesson: Exploring Basic Interface Development

● Check for allowed characters

● Define an operator together with an pattern for the field check

To check the data from a database table, you have to fill the Table Name and Where Condition
for Select Statement fields. In the case of a database check, you have two options:
● Verify the existence of an entry in the database
● Verify that a field in the entry found on the database has a specific value

If a function module should be used to check the data, it must have the same signature as
the /AIF/FILE_TEMPL_CHECK template function module provided.
One reusable check can consist of multiple single checks. These single checks are
concatenated with "OR", which means that if one of the single checks is successful, the
complete check is regarded as successful.

Figure 51: Notify User about Check Results

If a check cannot be processed successfully, AIF adds a default error message to the
application log. However, as these error messages are generic, they might not give the
business user a hint about the error. Therefore, it is possible to define a check-specific error
message.
The error message belonging to a check is defined during the first step of check creation. The
error message is defined together with the check description. You can enter an error message
(message class and number) and define up to 4 variables. This can be a constant value
(%value) or a placeholder, which will be dynamically exchanged with the actual data at
runtime.
The success message is defined in the single check. You can enter a success message class, a
success message number, and define up to 4 variables.

Note:
Depending on the trace level, the success message might not be added to the
application log.

© Copyright. All rights reserved. 57

Unit 3: Basic Interface Development

Figure 52: A Check can be Used on Two Levels

Explanations about the level, on which a check can be used:

Check on structure level

You can assign a check on structure level in AIF Customizing in the Define Structure
Mapping activity via Assign Checks.
You are required to specify which data structure should be checked. This can be the raw
or SAP structure. You also need to define the behavior of the check in case of an error.
There are two options:
● Ignore data if check is not successful
● Treat as error if check is not successful

You can use a check that already exists. Then, you have to select the corresponding
check and namespace in the namespace and check field. As well as using an existing
check, you can define a check directly.
Check on field level
You define a check on field level inside the Define Field Mappings Customizing activity in
the Define Structure Mapping activity. You cannot define the check directly; you can only
use existing checks or create a new one. The final step for using a check on field level is to
define if the check should be executed before or after mapping.
You can define a constant value for the check in the field(s) passed to the check. The
value has to be entered with %<value>. This makes sense, for example, in the case of a
database check, where the same set of data is always relevant.

58 © Copyright. All rights reserved.

 Lesson: Exploring Basic Interface Development

Figure 53: How to React In Case Of an Error on Structure Level

There are two possibilities:

● Ignore data if check is not successful
● Treat as error if check is not successful

Ignore data if check is not successful

If the check fails, the current line is ignored and processing continues. An information
message is added to the application log (depends on the trace level).
Treat as error if check is not successful
If the check fails, processing is stopped at the current line. An error message is posted to
the application log.

Fixing of Values

Figure 54: Fixed Value 1/2

© Copyright. All rights reserved. 59

Unit 3: Basic Interface Development

In AIF, fix values are used in structure and value mappings to assign a constant value to a field
in the destination structure. Additionally, they can also be used in checks to refer to a
constant value.

Figure 55: Fixed Value 2/2

You can specify a fixed value via AIF Customizing in the Define Fix Values activity. You have to
define a name, description, and the value.

Figure 56: Assign a Fixed Value

Use a reusable fix value on namespace level and assign it to the structure mapping. This has
the advantage that, once the value has to be changed, there is only one place that has to be
adapted.
Example
You have several interfaces where customer data (orders, flight bookings, and so on) is
processed. Currently, every customer gets a discount of 10%. Therefore, a corresponding
reusable fix value is assigned to the interfaces. The discount is then changed so that the

60 © Copyright. All rights reserved.

 Lesson: Exploring Basic Interface Development

customers only get 5% discount. Since you have defined the fix value as a reusable fix value,
you can simply change this fix value in one place and all your interfaces use the correct
discount.

LESSON SUMMARY
You should now be able to:
● Explore basic interface development

© Copyright. All rights reserved. 61

Unit 3: Basic Interface Development

62 © Copyright. All rights reserved.

 Unit 3

Learning Assessment

1. In AIF you can perform the mapping between the source and the target interface. Which of
the following statements are true:
Choose the correct answers.

X A AIF can use structure and field mappings to find the right field for the target
structure.

X B The mapping engine of AIF creates the mapping rules automatically.

X C All fields of the target structure have to be part of the source structure as well.

X D AIF can use a move-corresponding for structures that contain the same fields.

X E The target structure is always the SAP structure.

2. In AIF you can perform the mapping between the source and the target interface. Which of
the following statements are true:
Choose the correct answers.

X A Only one field of the source structure can be used to find the field for the target
structure.

X B In case of mapping errors the monitoring shows the field that has the error.

X C A mapping can be tested with the AIF Testtool.

X D Checks and fix value mappings can be used from different namespaces.

3. What is true about checks?

Choose the correct answer.

X A A check always belongs to a structure.

X B A check can not be reused.

X C A failed check always generates an error.

X D Checks can happen on field or on structure level.

© Copyright. All rights reserved. 63

Unit 3: Learning Assessment

4. If a local and a reusable fix value exist for the same target field always the local check is
done.
Determine whether this statement is true or false.

X True

X False

64 © Copyright. All rights reserved.

 Unit 3

Learning Assessment - Answers

1. In AIF you can perform the mapping between the source and the target interface. Which of
the following statements are true:
Choose the correct answers.

X A AIF can use structure and field mappings to find the right field for the target
structure.

X B The mapping engine of AIF creates the mapping rules automatically.

X C All fields of the target structure have to be part of the source structure as well.

X D AIF can use a move-corresponding for structures that contain the same fields.

X E The target structure is always the SAP structure.

This is correct. There is no mapping engine, and fix values or value mappings can be used
to find target fields that are no part of the source structure. See BIT750, Unit 3, Lesson 1.

2. In AIF you can perform the mapping between the source and the target interface. Which of
the following statements are true:
Choose the correct answers.

X A Only one field of the source structure can be used to find the field for the target
structure.

X B In case of mapping errors the monitoring shows the field that has the error.

X C A mapping can be tested with the AIF Testtool.

X D Checks and fix value mappings can be used from different namespaces.

This is correct. You can use up to 5 fields. See BIT750, Unit 3, Lesson 1.

© Copyright. All rights reserved. 65

Unit 3: Learning Assessment - Answers

3. What is true about checks?

Choose the correct answer.

X A A check always belongs to a structure.

X B A check can not be reused.

X C A failed check always generates an error.

X D Checks can happen on field or on structure level.

This is correct. Checks can be performed on field or on structure level. See BIT750, Unit 3,
Lesson 1.

4. If a local and a reusable fix value exist for the same target field always the local check is
done.
Determine whether this statement is true or false.

X True

X False

This is correct. AIF takes the global value if both exist. See BIT750, Unit 3, Lesson 1.

66 © Copyright. All rights reserved.

 UNIT 4 Advanced Structure and Field
Mapping

Lesson 1
Explaining Advanced Structure and Field Mapping 69

UNIT OBJECTIVES

● Explain advanced structure and field mapping

© Copyright. All rights reserved. 67

Unit 4: Advanced Structure and Field Mapping

68 © Copyright. All rights reserved.

 Unit 4
Lesson 1
Explaining Advanced Structure and Field
Mapping

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain advanced structure and field mapping

Structure and Field Mapping

Figure 57: Advanced Structure Mapping, Source and Destination Structure

Direct Mapping is possible, when the structures are on the root level or the first level and if
they are on the same level on both sides. All the examples we discussed till now were like this.
More often, structures differ more. Then, AIF needs to know how a structure in the message
can be reached. This will be our next step in structure mapping.

© Copyright. All rights reserved. 69

Unit 4: Advanced Structure and Field Mapping

Figure 58: Mapping of Structures

You cannot map structures directly when they are on the second level or deeper in a
structure.
You cannot map structures directly when the items are on a level under the header items in
the source structure but the header and items are on the same level in the destination
structure.
You cannot map structures directly when the header and items are on the same level in the
source structure but the items are on a level under the header items in the destination
structure.

70 © Copyright. All rights reserved.

 Lesson: Explaining Advanced Structure and Field Mapping

Indirect Mapping

Figure 59: Indirect Mapping

Only the root and the first level structures can be mapped directly. Therefore, all the following
structures require an indirect mapping. All steps have to be repeated until the root or the first
level structure is reached (they also have to be mapped).
The first step in creating an indirect mapping is to map the parent structures.
The second step is to create a field mapping and map the child structures. If a structure
mapping for the child structures is created, the child destination structure is selected as Field
in Destination Structure. The child source structure is selected in the Sub-Table field.
The final step is to create a structure mapping for the child structures and select the Indirect
Mapping checkbox. In AIF Customizing, in the Define Structure Mappings activity, create a
new entry for the child source structure in Select Source Structure. Go to Assign Destination
Structure and enter the child destination structure. Furthermore, you have to select the
Indirect Mapping checkbox for this structure mapping.
After you have created the structure mapping, you can do the field mappings for the
structures as usual.

© Copyright. All rights reserved. 71

Unit 4: Advanced Structure and Field Mapping

Indirect Mapping - Example 1

Figure 60: Indirect Mapping - Example 1 1/2

The source structure contains the customer data as a child structure. The customer data
contains the flight bookings as child structure. Both structures are tables that can have
several entries.
The destination structure contains the customer data and the flight bookings data on the
same level.

Figure 61: Indirect Mapping - Example 1 2/2

To map all structures, an indirect mapping for the flight bookings is required:

1. Map the parent structure. In this case, the customer data is the parent structure.

2. Create the field mappings for the customer data. Map the required fields. Create the
mapping for the flight bookings child structure.

3. Create the structure mapping for the flight booking structure. Select the Indirect Mapping
checkbox. Create all required field mappings.

After all mappings are done, the data is mapped from the source to the destination structure.

72 © Copyright. All rights reserved.

 Lesson: Explaining Advanced Structure and Field Mapping

Indirect Mapping - Example 2

Figure 62: Indirect Mapping - Example 2 1/3

The source structure contains the customer data and the flight bookings on the first level.
Both structures are tables that can have several entries.
The destination structure contains the customer data on the first level and the flight bookings
data on the second level.

Figure 63: Indirect Mapping - Example 2 2/3

To map all structures, an indirect mapping for the flight bookings is required:

1. Map the parent structure. In this case, the customer data is the parent structure.

2. Create the field mappings for the customer data. Map the required fields. Create the
mapping for the flight bookings child structure. In addition to the sub-table mapping of the
flight bookings structure, a selection field is required to be able to determine the correct
flight bookings belonging to the different customer detail entries.

© Copyright. All rights reserved. 73

Unit 4: Advanced Structure and Field Mapping

3. Create the structure mapping for the flight booking structure. Select the Indirect Mapping
checkbox. Create all required field mappings.

After all mappings are done, the data is mapped from the source to the destination structure.

Figure 64: Indirect Mapping - Example 2 3/3

Further Explanations about objects, displayed in the figure:

Selection Field
Defines a field of the sub-table that is used for filtering the table rows for the hierarchical
mapping. The field is part of the selected sub-structure of the raw structure.
Operator
Defines the comparison operator for comparison between the input value of the
Selection Field and the Comparison Field.
Comparison Field
Defines a field from the source structure. The value of this field is compared using the
operator defined in the Operator field and the field defined in the Selection Field.

Example
Flights belonging to a specific customer are identified by the customer ID. On the destinations
side, you need the flight bookings belonging to the current customer. Therefore, you have to
specify the Comparison Field and the Selection Field. At runtime, the customer with ID = 7411
is mapped. AIF then checks which flight bookings on the source side belong to customer 7411
and map those flights to the customer's flight bookings on the destination side.

74 © Copyright. All rights reserved.

 Lesson: Explaining Advanced Structure and Field Mapping

Value Conversion

Figure 65: Value Conversion

Data Element for Conversion: Defines the data element for conversion. In addition to the Data
Element for Conversion, the Direction of Conversion Exit also needs to be maintained. If the
direction is not maintained, the conversion is ignored.
Example: The source field is defined as STRING containing a date. The destination field is
defined as DATS. The conversion element in this case would be DATS.
Conversion Routine: Converts data from display format to internal format and vice versa. If a
standard conversion is not suitable, it can be overridden by a conversion routine in the
underlying domain.
A conversion routine is identified by its five-place name and is stored as a group of two
function modules. The function modules have a fixed naming convention. The following
function modules are assigned to conversion routine xxxxx:
● CONVERSION_EXIT_xxxxx_INPUT
● CONVERSION_EXIT_xxxxx_OUTPUT

The input module performs the conversion from display format to internal format. The output
module performs the conversion from internal format to display format.
Example for Conversion Routine: ALPHA, MATN1
Direction of Conversion Exit: Defines the conversion direction for the input data defined in the
Conversion Exit field. Direction can be External to Internal or Internal to External. The
Conversion Exit and the Direction of Conversion fields are required to be used in combination.

© Copyright. All rights reserved. 75

Unit 4: Advanced Structure and Field Mapping

Value Mapping

Figure 66: Value Mapping, Introduction

A value mapping can be used to derive one or multiple values of a source structure to the
corresponding values in the destination structure.
Value mappings are assigned to field mappings.

Figure 67: Value Mapping, Usage in Interfaces

A value mapping is created in the AIF Customizing in the Define Value Mappings activity.
A value mapping has a well-defined input (up to five field values) and a well-defined output
(one field value) and remains independent of the context in which they are called. Therefore,
value mappings can be reused by several interfaces in several namespaces.

76 © Copyright. All rights reserved.

 Lesson: Explaining Advanced Structure and Field Mapping

Value Mapping Creation

Figure 68: Creating a Value Mapping

A value mapping is created in the AIF Customizing in the Define Value Mappings activity.
Within a value mapping, you have different options for creating a value mapping:
● Mapping Table (with /AIF/VMAP): You can create a value mapping that uses
transaction /AIF/VMAP to maintain the values. You can decide if the value mapping
contains master or Customizing data. Depending on this setting, the entries will either be
transported to the productive system (Customizing) or they have to be maintained in the
productive system (master). If you select master, the business users are able to maintain
missing values. You can decide how many external values are passed into the value
mapping. The maintenance transaction /AIF/VMAP displays a generic table. If you
maintain the data elements of your external and internal fields, users will have an F4 help
(if value range exists) in /AIF/VMAP. Furthermore, users can navigate to /AIF/VMAP
directly from Monitoring and Error Handling.
● Database select: You can derive values directly from an existing database table. You have
to specify the database table, the field you want to select, and a where condition.
● If your requirements cannot be met with the Customizing options, you can also create a
function module for the value mapping.

There are some more features:

● Maintain an error message to overwrite the generic AIF message with an error message
that is more specific to the value mapping
● Maintain an Alternative Transaction that is called instead of transaction /AIF/VMAP
● Maintain View/Table Name to navigate to a table/maintenance view from Monitoring and
Error Handling

© Copyright. All rights reserved. 77

Unit 4: Advanced Structure and Field Mapping

Missing Values

Figure 69: Missing Values in Value Mapping

You can maintain in a value mapping if a missing value shall be used or if an error shall occur.
If you decide to have an error message you can maintain the missing fields and then restart
the message.

Figure 70: Maintaining Missing Values in Value Mapping

The Maintenance of missing values can be done in the value mapping as you have seen
before. But it's also possible to add new values directly out of the monitoring and error
overview. This makes it also possible for the business user can add the missing fields.

78 © Copyright. All rights reserved.

 Lesson: Explaining Advanced Structure and Field Mapping

Figure 71: Maintaining Missing Values in Value Mapping, Insertion of Missing Values

Forward navigation will lead the user to the value mapping directly with all fields prefilled, so
the user only has to use the insert values button and add the missing fields.

Error Message And Data Content Linkage

Figure 72: Link Error Message and Data Content

A data link is used to link an error message to a specific field in the Data Structure view in the
Monitoring and Error Handling transaction. AIF uses the current structure and the customized
source field. If more source fields than one is used, the link cannot be determined
automatically at field level. In this case, you need to specify a specific link field in case of an
error.

© Copyright. All rights reserved. 79

Unit 4: Advanced Structure and Field Mapping

Figure 73: Link Error Message and Data Content, ID not found

If you know that from all the fields that are used to do the mapping for one field one field has
the highest plausibility to cause the error, you can customize the system to color only this
field red.

Data Link

Figure 74: Data Link

A data link can be created in Field Mappings and Checks.

80 © Copyright. All rights reserved.

 Lesson: Explaining Advanced Structure and Field Mapping

Conditional Mapping

Figure 75: Conditional Mapping

A conditional mapping is created for a specific field mapping. After defining the field mapping
for the field, you can create one or more conditions for the field. The mapping of the field is
changed accordingly if one of the conditions is executed. If you have to set the value of a field
to a specific value, depending on the result of the check, you can enter the value directly in
Customizing in the Alternative Field Name field with %value.
To define if a condition should be executed, a check is needed. If the check is successful, the
condition is used to fill the destination field. If the check fails, the normal field mapping is
executed.

Condition Types

Figure 76: Condition Types

© Copyright. All rights reserved. 81

Unit 4: Advanced Structure and Field Mapping

Different condition types exist and have be set in the condition accordingly:
● Empty Value: An empty value is passed to the destination field
● Alternative Value Mapping/ Field Name: Depending on the Customizing settings, several
things can be done with this condition type:
- If only alternative field names are defined, the alternative field name(s) is used to fill the
destination field.
- If a value mapping is defined for the normal field mapping, the alternative field name(s)
is used for the value mapping of the normal field mapping.
- If only an alternative value mapping is defined in the condition, the fields from the
normal field mapping are passed to the alternative value mapping.
- If alternative value mapping and alternative field name(s) are defined, the alternative
value mapping is used with the alternative field names.
● Ignore Value Mapping/Use Alternative Field Name: Value mapping in the normal field
mapping is ignored. Instead, the value of alternative field name(s) is passed to the
destination field.

LESSON SUMMARY
You should now be able to:
● Explain advanced structure and field mapping

82 © Copyright. All rights reserved.

 Unit 4

Learning Assessment

1. AIF needs an indirect mapping if structures from source structure or target structure are
on a deeper level than 2 or if they are on different levels.
Determine whether this statement is true or false.

X True

X False

2. What is true about indirect mappings? The structures on level 3 or deeper than level 2 are
linked together in the field mapping of the next higher structure as a subtable.
Determine whether this statement is true or false.

X True

X False

3. Missing entries in a value mapping table can be added from the business user inside the
monitoring transaction.
Determine whether this statement is true or false.

X True

X False

4. If you use more than one field as input for a mapping, which one is marked red in case of
an error?
Choose the correct answers.

X A The one you defined as field for datalink.

X B The first one.

X C None if no datalink is defined.

X D All of them.

© Copyright. All rights reserved. 83

 Unit 4

Learning Assessment - Answers

1. AIF needs an indirect mapping if structures from source structure or target structure are
on a deeper level than 2 or if they are on different levels.
Determine whether this statement is true or false.

X True

X False

This is correct. Only the same structure on root or second level can be used directly. See
BIT750, Unit 4, Lesson 1.

2. What is true about indirect mappings? The structures on level 3 or deeper than level 2 are
linked together in the field mapping of the next higher structure as a subtable.
Determine whether this statement is true or false.

X True

X False

This is correct. The Structures on level 3 or deeper than level 2 are linked together in the
field mapping of the next higher structure as a subtable. See BIT750, Unit 4, Lesson 1.

3. Missing entries in a value mapping table can be added from the business user inside the
monitoring transaction.
Determine whether this statement is true or false.

X True

X False

This is correct. Missing entries in a value mapping table can be added from the business
user inside the monitoring transaction. See BIT750, Unit 4, Lesson 1.

84 © Copyright. All rights reserved.

 Unit 4: Learning Assessment - Answers

4. If you use more than one field as input for a mapping, which one is marked red in case of
an error?
Choose the correct answers.

X A The one you defined as field for datalink.

X B The first one.

X C None if no datalink is defined.

X D All of them.

This is correct. Red marked are the one you defined as field for datalink, or, none, if no
datalink is defined. See BIT750, Unit 4, Lesson 1.

© Copyright. All rights reserved. 85

Unit 4: Learning Assessment - Answers

86 © Copyright. All rights reserved.

 UNIT 5 Actions

Lesson 1
Using Actions 89

UNIT OBJECTIVES

● Use actions

© Copyright. All rights reserved. 87

Unit 5: Actions

88 © Copyright. All rights reserved.

 Unit 5
Lesson 1
Using Actions

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Use actions

Actions

Figure 77: Actions

An action is an interface building block that contains the business logic of an SAP Application
Interface Framework interface. It consists of at least one action function module that can, for
example, call BAPIs or function modules to process data.
An action is defined by its name and the namespace it is assigned to. The action's main
component type defines which data type the action handles. An action can be assigned to
different interfaces across different namespaces.
Since actions in the SAP Application Interface Framework have a well-defined input (a data
structure with the type defined as the action's main component type), they remain
independent of the context in which they are called. As a result, actions can be reused easily
by several interfaces in the SAP Application Interface Framework.

To Define an Action:

● In the first step of creating an action, you maintain general information:

© Copyright. All rights reserved. 89

Unit 5: Actions

- Name and description.

- Commit mode and commit level.
- (Optional) init function before processing.
- Main component type.
● In the second step, the function module containing the business logic is defined. You can
define multiple function modules for one action. For every function module, you must
maintain the following information:
- Function number and function module name.
- Stop processing on error.
- Restart always.

Figure 78: Commit Mode/Level

Commit Mode: The commit mode controls if AIF should perform a:

● Commit Work
● Commit Work and Wait
● No Commit Work

Commit Level: Defines when AIF commits the changes to the database:
● After each function: A commit is done after each separate function call of the action.
● After each action for all datasets: Leads to a commit after the action was executed for all
datasets of a table the action was called with.
● After each action for each dataset: Leads to a commit after all functions of the action have
been executed for a dataset (dataset = a line of a table).
● No commit (but maybe after all actions): Does not lead to a commit at the action level.
However, at the interface level, there could be a commit (if it is customized accordingly).

Which commit level should be chosen depends on your requirements. You should also
consider that AIF will perform a rollback in case of an error. If a message is restarted and a

90 © Copyright. All rights reserved.

 Lesson: Using Actions

function was executed successfully before, AIF will not execute it again if AIF already
performed a commit for this function.
Example
You have a table that contains customer data and an action that creates those customers.
The commit level for the action is set to After each function. Your table contains two
customers. The creation of the first customer is successful but the creation of the second
customer fails. A user corrects the error and restarts the message. AIF will only try to create
the second customer. For the first customer, the function module will not be executed again.

Figure 79: Init Function Before Processing

Defines a function module that is called by AIF at the beginning of the processing of the
current action.

Figure 80: Action Function

An action can have different function modules to be executed during the processing of the
action. The function number defines in which sequence the function modules are processed.

© Copyright. All rights reserved. 91

Unit 5: Actions

Figure 81: Action Function - Stop Processing on Error

The Stop Processing on Error checkbox specifies if the message processing should be
stopped if an error occurs.
Stop Processing on Error in Define Functions
An action has function numbers 5, 10, 20, and 30. For function number 10, the Stop
Processing on Error checkbox is selected. If an error occurs while function number 10 is being
executed, function numbers 20 and 30 are not executed for the current line.
Stop Processing on Error in Assign Actions
In addition to the Stop Processing on Error checkbox on action function level, a Stop
Processing on Error checkbox can also be selected in the Assign Actions activity of the Define
Structure Mappings in AIF Customizing. Here, the checkbox behaves a bit differently.
An action number 10 and an action number 20 are assigned to an interface. For action
number 10, the Stop Processing on Error checkbox is selected in Assign Actions. If an error
occurs during the processing of action number 10, action number 20 is not executed anymore
for the current line.

92 © Copyright. All rights reserved.

 Lesson: Using Actions

Figure 82: Action Function - Restart Always

For every defined action function, you can set the behavior in case of a restart. If you select
the Restart Always checkbox for a function module of an action, this function module is
executed when the processing of the data message is restarted. The function module is also
executed if it was executed successfully in the previous run.

Note:
Only for lines where errors occurred, the function is executed again if it has a
Restart Always checkbox selected.

Figure 83: Action Function - Check

If the check fails, there are two options that you can set:

© Copyright. All rights reserved. 93

Unit 5: Actions

● Treat as error if check is not successful: The action function is not executed. Instead, an
error message is added to the application log.
● Ignore data if check is not successful: No error message is added to the application log.
Instead, the function is ignored.

Action Functions - Examples

Figure 84: Action Functions - Example 1

The combination of the Restart Always and the Stop on Error flag are responsible for the
behavior in case of an error. To make your decision about Restart Always keep in mind, that a
function that works with internal numbering normally only should be processed once.

Figure 85: Action Functions - Example 2

94 © Copyright. All rights reserved.

 Lesson: Using Actions

Also if you need the data from the first function to process the second it might be senseless to
go on after an error in the first function.

Fields to Restore

Figure 86: Fields to Restore 1/3

The figure shows an example: The first action function creates a customer. For this new
customer, you should create an invoice. In order to create the invoice, you need the customer
number.

Figure 87: Fields to Restore 2/3

The figure shows an example: The first function creating the customer is executed
successfully. The second action function creating the invoice fails because the payment terms
are not correct. This error is corrected and the message is restarted. The function that
created the customer is not executed again, since it was already processed successfully.
Therefore, the customer number cannot be passed to the second function

© Copyright. All rights reserved. 95

Unit 5: Actions

Figure 88: Fields to Restore 3/3

The figure shows an example: The customer number determined by the first function is
defined as Field to Restore. If the message is reprocessed, instead of executing the first
function, the customer number is retrieved. Then, the customer number is passed to the
function, which creates the invoice.

Changeable Fields

Figure 89: Changeable Fields

96 © Copyright. All rights reserved.

 Lesson: Using Actions

Changeable fields can be defined for a specific interface in AIF Customizing under SAP
Application Interface Framework → Error Handling → Define Interface-Specific Features. New
entries can be created under Define Changeable Fields.

Note:
In Define Namespace-Specific Features you have to define an interface-specific
entry for your interface. Without this entry you cannot display the Define Interface-
Specific Features dialog for your interface.

If a field is defined as changeable, the users still need to have the corresponding authorization
to change the content of a data message. Thus, users that are only authorized to display the
data will not be allowed to edit the data even if the field is set to changeable. If a user changes
the data it will be logged by AIF. AIF will log the old and the new value as well as the date and
time when the message was edited. These entries can be displayed in transaction /AIF/
EDCHANGES.
In addition, you can set fields as changeable on namespace level. To specify the changeable
field in AIF Customizing on namespace level, go to SAP Application Interface
Framework → Error Handling → Define Namespace-Specific Features. New entries can be
created under Define Changeable Fields. These entries will be evaluated once the user selects
data messages of different interfaces within one namespace that have the same source
structure, and displays the data content of those messages.

LESSON SUMMARY
You should now be able to:
● Use actions

© Copyright. All rights reserved. 97

Unit 5: Actions

98 © Copyright. All rights reserved.

 Unit 5

Learning Assessment

1. To define an action, you must define the business logic first.

Determine whether this statement is true or false.

X True

X False

2. The commit mode controls if AIF should perform a:

Choose the correct answers.

X A Commit work

X B Commit work and wait

X C Commit clerk

X D No commit work

3. What is correct about changeable fields?

Choose the correct answer.

X A If a field is set to changeable no authorization is required to change it.

X B You can globally define changeable fields for any interface in AIF customizing

X C There are no changeable fields in AIF.

X D Users need to have the required authorization to change fields.

4. Which commit level is not possible for Actions?

Choose the correct answers.

X A In the middle of a function.

X B After each function.

X C No Commit.

X D After each Action for all data sets.

X E After each Action for each dataset.

© Copyright. All rights reserved. 99

Unit 5: Learning Assessment

5. What is the purpose of an init function?

6. Actions can be used for other namespaces. If you want to do that the structures that are
needed from the action have to be available from both interfaces that use the action but
they can have different names in the structures.
Determine whether this statement is true or false.

X True

X False

7. What is the purpose of a field to restore?

100 © Copyright. All rights reserved.

 Unit 5

Learning Assessment - Answers

1. To define an action, you must define the business logic first.

Determine whether this statement is true or false.

X True

X False

This is correct. You have to maintain general information first. See BIT750, Unit 5, Lesson
1.

2. The commit mode controls if AIF should perform a:

Choose the correct answers.

X A Commit work

X B Commit work and wait

X C Commit clerk

X D No commit work

This is correct. The commit mode controls, if AIF should perform a commit work, a
commit work and wait and a no commit work. See BIT750, Unit 5, Lesson 1.

3. What is correct about changeable fields?

Choose the correct answer.

X A If a field is set to changeable no authorization is required to change it.

X B You can globally define changeable fields for any interface in AIF customizing

X C There are no changeable fields in AIF.

X D Users need to have the required authorization to change fields.

This is correct. Users still need the corresponding authorization. See BIT750, Unit 5,
Lesson 1.

© Copyright. All rights reserved. 101

Unit 5: Learning Assessment - Answers

4. Which commit level is not possible for Actions?

Choose the correct answers.

X A In the middle of a function.

X B After each function.

X C No Commit.

X D After each Action for all data sets.

X E After each Action for each dataset.

This is correct. The commit level in the middle of a function is not possible. See BIT750,
Unit 5, Lesson 1.

5. What is the purpose of an init function?

It can precalculate data before the action is called to provide information that is not known
in the source structure. Also, it is possible to add data that was created in an action
before.
This is correct. See BIT750, Unit 5, Lesson 1.

6. Actions can be used for other namespaces. If you want to do that the structures that are
needed from the action have to be available from both interfaces that use the action but
they can have different names in the structures.
Determine whether this statement is true or false.

X True

X False

This is correct. An action uses a particular DDID Structure and every interface that is able
to provide a value with this structure can use an action. See BIT750, Unit 5, Lesson 1.

7. What is the purpose of a field to restore?

If an action creates data with internal numbering, the new number can be stored in a field
to restore. If the next action fails and the message is restarted the action can read this
data from the field to restore.
This is correct. See BIT750, Unit 5, Lesson 1.

102 © Copyright. All rights reserved.

 UNIT 6 Additional Monitoring Features

Lesson 1
Defining Additional Monitoring Features 105

UNIT OBJECTIVES

● Define additional monitoring features

© Copyright. All rights reserved. 103

Unit 6: Additional Monitoring Features

104 © Copyright. All rights reserved.

 Unit 6
Lesson 1
Defining Additional Monitoring Features

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Define additional monitoring features

Additional Monitoring Features

Note:
This chapter is only valid for selection engine AIF index tables.

Figure 90: Standard Single Index Table

Messages processed in AIF are recorded in a single index table. By default, the messages are
stored in the standard single index table.
In Monitoring and Error Handling, by default, you can select messages by namespace,
interface name, interface version, time, status, and so on.
The data displayed in Monitoring and Error Handling is selected from the index tables.

© Copyright. All rights reserved. 105

Unit 6: Additional Monitoring Features

Figure 91: Index Tables

The standard selection fields are not enough for every interface. In some cases, it is required
to search for specific fields.
This can be enabled with the use of an interface-specific single or multi index table. In this
table, you can specify key fields that are then available for selection in Monitoring and Error
Handling.

Figure 92: Single Index Table

All messages processed by the SAP Application Interface Framework are recorded in a single
index table. Each message can be identified by its message GUID or by a file number.
The values of key fields are saved into the single index table during runtime of the SAP
Application Interface Framework. If you want to use key fields, you need to define them in
your own single index table.
To use a self-defined single index table in an interface, it needs to be connected to the
interface. You do this in the Namespace-Specific Features activity in AIF Customizing. Under
Define Namespace-Specific Features, enter the name of the single index table in the Message
Index Table Name field.

106 © Copyright. All rights reserved.

 Lesson: Defining Additional Monitoring Features

A single index table can be used for multiple interfaces that have the same single key fields.
However, especially if many messages are processed by an interface, it makes sense to
create your own index table for every interface for performance reasons.

Figure 93: Multi Index Table

A multi index table is required if the defined key field is part of a table. The key fields defined in
a multi index table are not used for grouping in Monitoring and Error Handling.
To use the self-defined multi index table in an interface, it needs to be connected to the
interface. You to do this in the Interface-Specific Features activity in AIF Customizing. Under
Define Key Fields for Multi. Search, you need to create an entry for the key field. The Multi.
Selection Type has to be Multiple selection. You can enter the name of the multi index table in
the Message Index Table Name field after the selection type is changed to multiple.

Figure 94: Single or Multi Index Table?

© Copyright. All rights reserved. 107

Unit 6: Additional Monitoring Features

In SAP Systems the Plant is a field, that quite often has a key status for searching messages
as well as for finding the right person for the error handling. If it exists only once in an
interface it is a good example for a single index field.

Figure 95: Display Additional Key Fields - Selection Screen

The selection screen has to be added to the interface. You can do this in the Define
Namespace-Specific Features activity in AIF Customizing . You have to enter the selection
screen in the Program Name field; you also have to fill the Screen Number field.

Figure 96: Interface-Specific Index Tables and Selection Screen

The program you create for the additional selection screen has to be of type Module-Pool and
the screen has to be programmed with the selection-screen commands instead of the screen
painter. As the screen is added to the standard Error Handling Screen you have to create it as
a sub-screen.

108 © Copyright. All rights reserved.

 Lesson: Defining Additional Monitoring Features

Recipients and Alerting

Figure 97: Recipients and Alerting 1/2

Every field of the single index table can also be used to make sure the right business user
finds the interfaces in the monitoring transaction. Also, this key field can be part of the
message an alert gives if you use your own alert and not the AIF default alert that goes
together with the AIF Standard Single Index Table.

Figure 98: Recipients and Alerting 2/2

At the beginning of the workshop, we created a recipient that is responsible for a complete
namespace. However, business users are not usually responsible for all the interfaces of a
namespace. Therefore, recipients are usually assigned directly to interfaces. The recipient
then monitors only those interfaces.
You can assign a recipient to an interface in AIF Customizing in Error Handling → Interface-
Specific Features → Assign Recipients without Key Fields.

© Copyright. All rights reserved. 109

Unit 6: Additional Monitoring Features

The /AIF/ALERT_CAT_DEF alert category is delivered with AIF. This category is used by
default for sending notifications. In order to give the business users some more hints about
the errors and how to handle them, you can create your own alert category (transaction
ALRTCATDEF). If you define the container elements with the same names as in /AIF/
ALERT_CAT_DEF, AIF passes those values to your own alert category as well. In this way,
information, for example, the error messages and interface name, can also be passed to the
users.
You can assign the alert category to an interface in AIF Customizing in Error
Handling → Namespace-Specific Features → Configure Alerts.
Furthermore, you can pass the value of a single key field to your alert category. If the name of
the container element differs from the name of the field in the single index table, you have to
specify the name of the container element in Error Handling → Interface-Specific Features →
Define Key Fields for Multi Search.

Figure 99: Key Field Dependent Recipients 1/2

In some cases, users are only responsible for messages with specific content. In this case,
they are notified only for messages that have the content they are responsible for. For
example, for an interface for invoices, the users are only responsible for messages that belong
to their company code. Then, they see only the messages of their company code in Interface
Monitor and receive only notifications for errors in their company code. This can be achieved
by defining key field dependent recipients.
A prerequisite is that the field is defined as a single key field. You have to set this single key
field as Relevant for Recipient Determination in AIF Customizing in Error
Handling → Interface-Specific Features → Define Key Fields for Multi Search. Furthermore, a
recipient assignment table is required. The easiest way to create the table is to copy /AIF/
T_ALRT_DEF and then add the field(s) that should be used for recipient determination.
You have to insert the namespace, interface name, and version of your interface as well as the
recipient and the key field's value the recipient is responsible for.
For example, you have two company codes 1000 and 2000. RECIPIENT_1 is responsible for
company code 1000 and RECIPIENT_2 is responsible for company code 2000. Then, you
have to maintain an entry for both recipients in your table.

110 © Copyright. All rights reserved.

 Lesson: Defining Additional Monitoring Features

Furthermore, you have to assign the recipient assignment table to your interface. In AIF
Customizing, go to Error Handling → Namespace-Specific Features → Configure Alerts and
enter the name of your recipient assignment table

Figure 100: Key Field Dependent Recipient 2/2

To use a field in the single index table you created to find the right recipient for a message, it is
necessary to customize this field as relevant for recipient determination and to create the link
between one special field content and the user who shall be informed. Because these fields
are always different AIF needs one special recipient assignment table per interface.

Figure 101: Interface Mail Notification

The user has the three alternatives for interface email notifications:

Mail for next alert

© Copyright. All rights reserved. 111

Unit 6: Additional Monitoring Features

The user will receive one email when an error occurs. Now, the user is informed that there
has been an error in his interface. He will not receive a new email when another error
occurs until the alert is confirmed or timed out.
An alert can be confirmed in the Interface Monitor on recipient level by clicking on the
switched-on light bulb icon in the Alert column.
No Mail
The user will receive no email when an error occurs even if there was no unconfirmed
alert before.
Mail for every single error
The user will receive an email each and every time an error occurs. Confirming or not
confirming an alert does not influence this behaviour.

The user can change the settings for the interface mail notification in the interface monitor in
column mail. The notification settings are done per recipient.

Note:
An interface can be assigned to multiple recipients. If you are assigned to several
recipients of this interface you may receive notifications even if you deactivated
notifications for one specific recipient. Example: For the FLBOOKING interface,
you are assigned to Recipient AGENCY_120 and AGENCY_130. If you switch to No
Mail for recipient AGENCY_120, you can still receive emails for recipient
AGENCY_130.

Note:
Even if you have selected the No Mail icon, the Click to Confirm icon (light bulb
that is switched on) can be displayed if another user receives e-mails for this
interface/recipient combination and an alert exists as a consequence.

Hide Confidential Data

Figure 102: Hide Confidential Data

Hidden fields will be not shown in the structure and hidden structures are not shown at all. For
the user this might look like this fields have not been in the message at all.

112 © Copyright. All rights reserved.

 Lesson: Defining Additional Monitoring Features

Some data is not to be seen by any user. Some business users must not see confidential parts
of data messages they are working on in Monitoring and Error Handling. They should only see
the data that is relevant for their work. AIF allows you to hide specific parts of the structure.
This can be complete structures or certain fields of a structure.

Figure 103: Hide Structures

AIF allows you to hide structures. This can be done on interface or on namespace level.
Hide Structures on Interface Level
If a structure is defined to be hidden for a specific interface, the structures are not displayed
in the Monitoring and Error Handling transaction if this interface is selected. In the Data
Structure and the Data Content view of Monitoring and Error Handling, the structures and
their corresponding data are not displayed.
Where to customize: AIF Customizing → Error Handling → Interface-Specific Features → Hide
Structures.
Hide Structures on Namespace Level
If different interfaces are using the same root structure within one namespace you can select
messages of these different interfaces at the same time in Monitoring and Error Handling. The
data structure and data content of the different interfaces can be displayed together. To
ensure that even then the structures are hidden, you can hide structures on namespace level.
In the Data Structure and the Data Content views of the Monitoring and Error Handling, the
structures and the corresponding data are not displayed when the user selects the messages
from different interfaces.
Where to customize: AIF Customizing → Error Handling → Namespace-Specific
Features → Hide Structures.

© Copyright. All rights reserved. 113

Unit 6: Additional Monitoring Features

Figure 104: Hide Fields

AIF allows you to hide the fields of a structure. This can be done on interface or on namespace
level.
Define Hide Fields on Interface Level
If a field is defined to be hidden for a specific interface, that field is not displayed in the
Monitoring and Error Handling transaction if this interface is selected. In the Data Content
view of the Monitoring and Error Handling, the field and its data are not displayed.
Where to customize: AIF Customizing → Error Handling → Interface-Specific Features→ Hide
Fields
Define Hide Fields on Namespace Level
If different interfaces are using the same root structure within one namespace you can select
messages of these different interfaces at the same time in Monitoring and Error Handling. The
data structure and data content of those different interfaces can be displayed together. To
ensure that even then the fields are hidden, you can hide fields on namespace level. In the
Data Content view of the Monitoring and Error Handling, the corresponding fields are not
displayed when the user selects the messages from different interfaces.
Where to customize: AIF Customizing → Error Handling → Namespace-Specific Features→
Hide Fields.

LESSON SUMMARY
You should now be able to:
● Define additional monitoring features

114 © Copyright. All rights reserved.

 Unit 6

Learning Assessment

1. What is true about single index tables?

Choose the correct answers.

X A AIF delivers a so called standard single index table that can be used for all
interfaces even for customer defined interfaces.

X B The standard single index table has a field to obtain plant data.

X C You can use your own single index table for an interface.

X D You can have as many single index tables for one interface as you like.

X E You can define additional multi single index tables for an interface.

X F You can have interfaces without an index table at all.

2. If you want to search for fields of your own index tables in Transaction /AIF/ERR you have
to provide a report with the definition of a selection screen of the type subscreen.
Determine whether this statement is true or false.

X True

X False

3. You can define the selection screen for your own index tables with the screen painter.
Determine whether this statement is true or false.

X True

X False

4. You can define your own alerts in transaction ALRTCATDEF.

Determine whether this statement is true or false.

X True

X False

© Copyright. All rights reserved. 115

Unit 6: Learning Assessment

5. You can use the fields of the multi index table to assign recipients to messages.
Determine whether this statement is true or false.

X True

X False

116 © Copyright. All rights reserved.

 Unit 6

Learning Assessment - Answers

1. What is true about single index tables?

Choose the correct answers.

X A AIF delivers a so called standard single index table that can be used for all
interfaces even for customer defined interfaces.

X B The standard single index table has a field to obtain plant data.

X C You can use your own single index table for an interface.

X D You can have as many single index tables for one interface as you like.

X E You can define additional multi single index tables for an interface.

X F You can have interfaces without an index table at all.

This is correct. Correct is, that AIF delivers a so called standard single index table that can
be used for all interfaces even for customer defined interfaces, you can use your own
single index table for an interface, and that you can define additional multi single index
tables for an interface. See BIT750, Unit 6, Lesson 1.

2. If you want to search for fields of your own index tables in Transaction /AIF/ERR you have
to provide a report with the definition of a selection screen of the type subscreen.
Determine whether this statement is true or false.

X True

X False

This is correct. You have to provide a report with the definition of a selection screen of the
type subscreen. See BIT750, Unit 6, Lesson 1.

3. You can define the selection screen for your own index tables with the screen painter.
Determine whether this statement is true or false.

X True

X False

This is correct. You have to code it with the selection_Screen commands. See BIT750, Unit
6, Lesson 1.

© Copyright. All rights reserved. 117

Unit 6: Learning Assessment - Answers

4. You can define your own alerts in transaction ALRTCATDEF.

Determine whether this statement is true or false.

X True

X False

This is correct. You can define your own alerts in transaction ALRTCATDEF. See BIT750,
Unit 6, Lesson 1.

5. You can use the fields of the multi index table to assign recipients to messages.
Determine whether this statement is true or false.

X True

X False

This is correct. Only fields of the single index table can be used to identify recipients for a
message. See BIT750, Unit 6, Lesson 1.

118 © Copyright. All rights reserved.

 UNIT 7 AIF XML Runtime

Lesson 1
Explaining the AIF XML Runtime 121

UNIT OBJECTIVES

● Explain the AIF XML runtime

© Copyright. All rights reserved. 119

Unit 7: AIF XML Runtime

120 © Copyright. All rights reserved.

 Unit 7
Lesson 1
Explaining the AIF XML Runtime

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain the AIF XML runtime

AIF XML Runtime

Figure 105: Process Data Using AIF XML Runtime

What are the steps required for processing data in the AIF runtime?

1. Create source and destination structure.

2. Define an interface.

3. Maintain XML application and persistence engines.

4. Define a structure mapping for the interface.

5. Trigger AIF processing by calling one of the following function modules:

● /AIF/CL_ENABLER_XML=>TRANSFER_TO_AIF for single messages

● /AIF/CL_ENABLER_XML=>TRANSFER_TO_AIF_MULT for multiple messages

© Copyright. All rights reserved. 121

Unit 7: AIF XML Runtime

Figure 106: Pass Single Message to AIF

To use the method /AIF/CL_ENABLER_XML=>TRANSFER_TO_AIF or

TRANSFER_TO_AIF_MULT the Application Engine for that Interface has to be set to XML.

Figure 107: Pass Multiple Messages to AIF

Even if you use the method TRANSFER_TO_AIF_MULT the messages in the table that is
handed over to AIF are handled one by one. They will be seen as single messages in the
monitoring and it is possible to have successful and faulty messages in one call.

Facts about the Runtime Configuration Group:

● To process XML messages using AIF, a runtime configuration group is required.

● A runtime configuration group is identified by:
- The namespace
- A three-digit identifier
● The runtime configuration group specifies:

122 © Copyright. All rights reserved.

 Lesson: Explaining the AIF XML Runtime

- The number of messages the be executed per packet

- The number of messages to be executed per run
- If a run/packet is processed synchronously or asynchronously
- The created runs are executed automatically (Active checkbox)
● If no specific runtime configuration group is defined AIF uses the default, where one run
contains 100 messages and each packet in the run contains 20 messages.
● To use your own the runtime configuration group, use parameters IV_QUEUE_NS and
IV_QUEUE_NAME in TRANSFER_TO_AIF and TRANSFER_TO_AIF_MULT.

The AIF runtime environment creates persistence runs. Within the runs, the messages will be
processed by run packets. The number of runs and the number of run packets created
depends on the Runtime Configuration Group.
More details about the Runtime Configuration Group
AIF is shipped with a default configuration for the Runtime Configuration Group. By default, a
run contains 100 messages and each packet contains 20 messages. You can define a
customer-specific Runtime Configuration Group using transaction /AIF/PERS_CGR.
A runtime configuration group is identified by a namespace and a three-digit identifier. The
number of messages executed per packet and the number of messages to be executed per
run can be defined. The current user (SY-UNAME) is used to release and execute the jobs.
The user needs to have the authorizations to process messages in AIF. To have the runs
executed asynchronously, select the Run Scheduled checkbox. In that case a job is created to
execute a run. If the Run Scheduled checkbox is not selected, the jobs are executed
synchronously. If they are executed asynchronously (Schedule Packages checkbox selected),
the packets are scheduled in a second job. If the Schedule Packages checkbox is not set, the
packets are executed in the same job as the run.
You can activate or deactivate the runtime configuration group. If the runtime configuration
group is deactivated, the messages are stored in the message queue and are assigned to a
run. But the messages and runs are not processed automatically. The processing of runs can
be triggered using the /AIF/PERS_RUN_EXECUTE report. This report can be scheduled as a
job. By default the runs will only be triggered once they are full.

© Copyright. All rights reserved. 123

Unit 7: AIF XML Runtime

Runtime Configuration Group Example

Figure 108: Runtime Configuration Group Example

The figure illustrates an example. In this example, the default Runtime Configuration Group is
used:
● A run contains 100 messages
● Each packet contains 20 messages

In the example, 250 messages are to be processed. Accordingly, 3 runs are created:
● 1st run contains 100 messages:
- 5 packets are created, each containing 20 messages
● 2nd run contains 100 messages:
- 5 packets are created, each containing 20 messages
● 3rd run contains 50 messages:
- 2 packets are created, each containing 20 messages
- 1 packet is created that contains 10 messages

LESSON SUMMARY
You should now be able to:
● Explain the AIF XML runtime

124 © Copyright. All rights reserved.

 Unit 7

Learning Assessment

1. The class /AIF/CL_ENABLER_XML allows you to hand one or more messages over to the
AIF runtime from a report or function module.
Determine whether this statement is true or false.

X True

X False

2. The AIF test tool can use the AIF own XML runtime.
Determine whether this statement is true or false.

X True

X False

© Copyright. All rights reserved. 125

 Unit 7

Learning Assessment - Answers

1. The class /AIF/CL_ENABLER_XML allows you to hand one or more messages over to the
AIF runtime from a report or function module.
Determine whether this statement is true or false.

X True

X False

This is correct. The class /AIF/CL_ENABLER_XML allows you to hand one or more
messages over to the AIF runtime from a report or function module. See BIT750, Unit 7,
Lesson 1.

2. The AIF test tool can use the AIF own XML runtime.
Determine whether this statement is true or false.

X True

X False

This is correct. The AIF test tool can use the AIF own XML runtime. See BIT750, Unit 7,
Lesson 1.

126 © Copyright. All rights reserved.

 UNIT 8 Processing and Monitoring
IDocs with AIF

Lesson 1
Processing and Monitoring IDocs with AIF 129

Lesson 2
Processing and Monitoring Outbound iDocs with AIF 145

UNIT OBJECTIVES

● Process and monitor IDocs with AIF

● Process and monitor outbound IDocs with AIF

© Copyright. All rights reserved. 127

Unit 8: Processing and Monitoring IDocs with AIF

128 © Copyright. All rights reserved.

 Unit 8
Lesson 1
Processing and Monitoring IDocs with AIF

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Process and monitor IDocs with AIF

iDoc Processing and Monitoring with AIF

Processing Inbound IDocs without AIF
Before we look at the processing of IDocs within AIF we need to know the standard IDoc
functionality.

Figure 109: Processing Inbound IDocs without AIF 1

IDocs can be sent with different protocols, but normally the Remote Function Module (RFM)
IDOC_INBOUND_ASYNCHRONOUS is called. It saves the Data delivered from the IDoc
directly on the database as Characters.
At this point it does not make a difference which kind of Data (Materials, Orders etc. ) are
sent.

© Copyright. All rights reserved. 129

Unit 8: Processing and Monitoring IDocs with AIF

Figure 110: Processing Inbound IDocs without AIF 2

To Split between a technical part of the IDoc transmission that is the same for all Message
Types and a Business Part that does the Posting of the IDoc and is different per Object that
shall be created, brings the benefit of handling errors at the receiving side.
For each combination of Partner and Message Type the partner inbound profile gives a
process code. This process code tells the system how to post the IDoc.

Figure 111: Processing Inbound IDocs without AIF Prerequesites

To use a Function Module to process an inbound IDoc the system has to be told which one to
use in Transaction WE20 the Partner Profile. But it is not possible to use any Function Module.
The System needs to have a connection between the Function Module the Message Type and
the Basis type. This is done in transaction WE57. If an Function Module is connected to a
Message Type / Basic type combination it can be used inside a Process Code in transaction
WE42.
Only those Process Codes can be used in the Partner Profile .

130 © Copyright. All rights reserved.

 Lesson: Processing and Monitoring IDocs with AIF

IDoc Scenarios

Figure 112: IDoc Scenarios

AIF can monitor IDocs that are already in the system. This helps you to find errors and to use
the AIF Mass Changing function if you have the same error very often.
Also IDocs can be processed by AIF. Then you can also use the mappings Checks and other
AIF functions.

Prerequisites to Process IDocs in AIF

Figure 113: Prerequisites to Process IDocs in AIF

The IDoc Segments are single structures in the DDIC and we have special transactions that
tell the system how these structures form a special IDoc Message Type. Unfortunately that

© Copyright. All rights reserved. 131

Unit 8: Processing and Monitoring IDocs with AIF

means the IDOc structures already in the system cannot be used for AIF Interfaces. An AIF
Interface needs one root structure for the RAW Structure and one Structure for the SAP
Structure. AIF helps you to create these structures from IDoc Types.

Generation Report

Figure 114: Generation Report

An IDoc basic type can be very large. Creating a DDIC structure that corresponds to the basic
type can be very difficult especially if extensions have to be considered for the IDoc. The AIF
generation report creates or updates the required structure for a basic type.
You can open the generation report via transaction code /AIF/IDOC_GEN.

Figure 115: The IDoc Generation Report

132 © Copyright. All rights reserved.

 Lesson: Processing and Monitoring IDocs with AIF

The IDoc Structures are already defined inside SAP with Data structures that can be shown
and used in Transaction SE11. Different line Types socalled segments are used for each
different line.
As AIF needs ONE Data Structure for the whole message those segments can not be used
directly. The IDoc Generation Report can create the needed root structure for every IDoc you
want to use.
It also already creates the Interface using the correct engines for the IDoc Processing
Scenario you want to use.

Scenario 1 - Monitoring IDocs with AIF

Figure 116: Scenario 1 - Monitoring IDocs with AIF

With IDoc scenario 1, you can monitor existing IDocs in the Monitoring and Error Handling
transaction. The processing of the IDocs is not influenced by AIF. The scenario uses only the
monitoring capabilities of Monitoring and Error Handling.
Since AIF is not involved in processing, no index tables exist. Therefore, AIF selects the IDocs
data to be displayed in the Data Messages view from the IDOC control records.

© Copyright. All rights reserved. 133

Unit 8: Processing and Monitoring IDocs with AIF

Figure 117: Scenario 1: Steps Required to Use Scenario 1

For a scenario 1 IDoc interface, you have to specify the interface engines as follows:
● Application Engine: IDoc
● Persistence Engine: IDoc
● Selection Engine: IDoc Control Records
● Logging Engine: IDoc Status Records

If the generation report is used to create the interface, the engines are already set accordingly
for the interface.

134 © Copyright. All rights reserved.

 Lesson: Processing and Monitoring IDocs with AIF

Scenario 2: Process IDocs Using AIF

Figure 118: Scenario 2: Process IDocs Using AIF

With scenario 2, the data from an IDoc is processed by AIF before the IDoc standard
processing function is called from within an AIF action. In this scenario, you can use checks,
value mappings, and alerting. Also, the Interface Monitor can be used.

Figure 119: Processing Inbound IDocs with AIF, IDoc Scenario 2

To send an IDoc to AIF special Function Modules are delivered. One of them is /AIF/
IDOC_INB_PROCESS_FUNC_0 which can be used for every Message Type.
The Coding of the Action is always the same:
CALL FUNCTION '/AIF/IDOC_ACTION_FUNCTION'
EXPORTING

© Copyright. All rights reserved. 135

Unit 8: Processing and Monitoring IDocs with AIF

iv_idoc_function = ‘<NAME_OF_ORIGINAL_IDOC_FUNCTION>'
TABLES
return_tab = return_tab
CHANGING
data = data.

Figure 120: Processing Inbound IDocs with AIF Scenario 2 or 3 Prerequesites

As AIF does not know for which Message Types and Basic Types Scenario 2 shall be used at
the customer site, no Customizing is delivered.
That means you have for every Message Type/ Basic Type combination you want to use to do
the Customizing yourself. The Side above shows the example we use in the exercise. Now
when a message Type FLCUSTOMER_CREATEFROMDATA is sent from the Logical System
ZAIF_S001 it will be forwarded to AIF.

136 © Copyright. All rights reserved.

 Lesson: Processing and Monitoring IDocs with AIF

Figure 121: Scenario 2: Steps Required to Use Scenario 2

For a scenario 2 IDoc interface, you have to specify the interface engines as follows:
● Application Engine: IDoc
● Persistence Engine: IDoc
● Selection Engine: AIF Index Tables
● Logging Engine: AIF Application Log

If the generation report is used to create the interface, the engines are already set accordingly
for the interface.
Step 4: Maintain IDoc Customizing
To use the AIF IDoc scenario 2 and 3, you need to change the standard IDoc Customizing.
The steps required to process an IDoc via the AIF processing function are:
● The AIF function module needs to be assigned to the basic type and message type used in
the IDoc (transaction WE57)
● An inbound process code is required. The AIF processing function module needs to be
assigned to the process code (transaction WE42)
● The process code in the partner profiles is changed to the process code maintained for the
AIF processing function module (transaction WE20)

© Copyright. All rights reserved. 137

Unit 8: Processing and Monitoring IDocs with AIF

Scenario 3: IDoc/BAPI Implementation and Monitoring

Figure 122: Scenario 3: IDoc/BAPI Implementation and Monitoring

With scenario 3, the data from an IDoc is processed by AIF before the IDoc processing is
started from within an AIF action. The processing can be done in a function module, a BAPI,
and so on. In this scenario, you can use checks, value mappings, and alerting. Also, the
Interface Monitor can be used.
The main difference between scenario 2 and 3 is that a structure mapping is usually required
for scenario 3. Since a BAPI or other function is called, the source structure differs from the
destination structure, which makes a structure mapping necessary.
In scenario 2, the standard ALE function is called, therefore, the source and destination
structure are identical and can be mapped with the Move Corresponding function in the
easiest case.

138 © Copyright. All rights reserved.

 Lesson: Processing and Monitoring IDocs with AIF

Figure 123: Processing Inbound IDocs with AIF IDoc Scenario 3

The first Step in this Scenario is the same as in Scenario 2. Again you use the AIF function
Module /AIF/IDOC_INB_PROCESS_FUNC_0 to hand over the IDoc to AIF.
That means again you have to create entries for WE57, WE42 and WE20 as described for
Scenario2 above.
But the next step is different. You have to create an action as well, but this time you can
program the action however you want to.

Figure 124: Scenario 3: Steps Required to Use Scenario 3

For a scenario 3 IDoc interface, you have to specify the interface engines as follows:
● Application Engine: IDoc
● Persistence Engine: IDoc

© Copyright. All rights reserved. 139

Unit 8: Processing and Monitoring IDocs with AIF

● Selection Engine: AIF Index Tables

● Logging Engine: AIF Application Log

If the generation report is used to create the interface, the engines are already set accordingly
for the interface.

Figure 125: Difference between IDoc Scenario 2 and Scenario 3

If scenario 3 is used, you need to maintain the SAP data structure. The structure of the SAP
data structure depends on the function modules called in the action. The SAP data structure
has to be created manually. Since the SAP and raw data structure differ, a structure mapping
is required. This scenario is usually applicable if you have your own custom-specific basic type
and want to call, for example, a BAPI.

140 © Copyright. All rights reserved.

 Lesson: Processing and Monitoring IDocs with AIF

Scenario 4: IDoc Monitoring with Additional Enabler Call

Figure 126: Scenario 4: IDoc Monitoring with Additional Enabler Call

Scenario 4 is, like scenario 1, a pure monitoring scenario. In comparison to IDoc scenario 1,
you can use some advanced features of AIF. You can use alerting, interface-specific index
tables, and interface-specific selection screens. If a recipient was specified, the IDocs can also
be displayed in the Interface Monitor.
The AIF enabler for IDocs is called every time an IDoc status is updated. The IDoc enabler
determines the interface based on the settings in interface determination. If a corresponding
AIF interface is found, index table entries can be written and alerts are created. If a
corresponding AIF interface is not found, the ALE processing continues as usual. The
processing of IDocs that do not have an AIF interface assigned is not interrupted.

Figure 127: Implicit Call of AIF Enabler for IDocs

© Copyright. All rights reserved. 141

Unit 8: Processing and Monitoring IDocs with AIF

The AIF Enabler writes the status changes of the IDoc into the Standard Single Index table or
your Single Index Table or Multi Index Tables. This enables you to use all Index Table relevant
features like recipient assignment.

Figure 128: What Happens When the AIF Enabler is Installed?

The figure isslustrates the steps, when the AIF Enabler is installed and working.
An AIF Interface with the generated AIF IDoc Structure as RAW and SAP Structure is a
prerequisite.

Figure 129: Scenario 4: Steps Required to Use Scenario 4

For a scenario 4 IDoc interface, you have to specify the interface engines as follows:

142 © Copyright. All rights reserved.

 Lesson: Processing and Monitoring IDocs with AIF

● Application Engine: IDoc

● Persistence Engine: IDoc
● Selection Engine: AIF Index Tables
● Logging Engine: IDoc Status Records (it is also possible to select the AIF Application Log
Engine)

If the generation report is used to create the interface, the engines are already set accordingly
for the interface.

Figure 130: Import Existing IDocs into AIF Tables

Importing IDocs into the system and processing them to the Index tables help you find IDocs
that posted with an error for different recipients. This makes monitoring easier than in the
IDoc Transactions.

LESSON SUMMARY
You should now be able to:
● Process and monitor IDocs with AIF

© Copyright. All rights reserved. 143

Unit 8: Processing and Monitoring IDocs with AIF

144 © Copyright. All rights reserved.

 Unit 8
Lesson 2
Processing and Monitoring Outbound iDocs
with AIF

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Process and monitor outbound IDocs with AIF

Outbound iDoc Processing and Monitoring with AIF

Figure 131: Outbound IDoc Scenarios

The figure names the two different ways to monitor outbound IDocs:

1. Monitor existing IDocs in the Monitoring and Error Handling of AIF.

2. Process IDocs using AIF.

Figure 132: Scenario 1 - Monitor IDocs in AIF

© Copyright. All rights reserved. 145

Unit 8: Processing and Monitoring IDocs with AIF

With the IDoc scenario 1 you can monitor existing IDocs in the Monitoring and Error Handling
transaction. The processing of the IDocs is not influenced by AIF. The scenario uses only the
monitoring capabilities of the Monitoring and Error Handling.
Since AIF is not involved in processing, no index tables are created. Thus, AIF retrieves the
data to be displayed in the data message view, from the IDOC control records.

Figure 133: Scenario 2 - Processing Outbound IDocs

The required structure and the first interface can be created using the AIF IDoc generation
report. In the generation report, select scenario 4 to create the interface.
You can run the report a second time to generate the second interface (do not forget to
change the IDoc name).

LESSON SUMMARY
You should now be able to:
● Process and monitor outbound IDocs with AIF

146 © Copyright. All rights reserved.

 Unit 8

Learning Assessment

1. AIF can only be used for inbound IDocs.

Determine whether this statement is true or false.

X True

X False

2. Which of the following IDoc scenarios are possible with AIF?

Choose the correct answers.

X A Split an IDoc in 2 Messages.

X B Change fields in IDocs that have errors when the IDoc was already in the system
before the AIF Interface was created.

X C Address faulty IDocs to a recipient depending on IDoc content.

X D Do some mapping and then use the original IDoc function module.

© Copyright. All rights reserved. 147

 Unit 8

Learning Assessment - Answers

1. AIF can only be used for inbound IDocs.

Determine whether this statement is true or false.

X True

X False

This is correct. Both directions are possible. See BIT750, Unit 8, Lesson 1.

2. Which of the following IDoc scenarios are possible with AIF?

Choose the correct answers.

X A Split an IDoc in 2 Messages.

X B Change fields in IDocs that have errors when the IDoc was already in the system
before the AIF Interface was created.

X C Address faulty IDocs to a recipient depending on IDoc content.

X D Do some mapping and then use the original IDoc function module.

This is correct. Splitting an IDoc in 2 Messages is not an AIF scenario. See BIT750, Unit 8,
Lesson 1.

148 © Copyright. All rights reserved.

 UNIT 9 Proxy Interfaces

Lesson 1
Using Proxy Interfaces 151

UNIT OBJECTIVES

● Use proxy interfaces

© Copyright. All rights reserved. 149

Unit 9: Proxy Interfaces

150 © Copyright. All rights reserved.

 Unit 9
Lesson 1
Using Proxy Interfaces

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Use proxy interfaces

Proxy Interfaces

Figure 134: Customer-Specific ABAP Proxies - Inbound Interface

As a prerequisite to creating an AIF interface for an inbound proxy, you need a service
interface. The service interface is created in the ESR or MDR and is usually not the task of the
AIF interface developer.
For this service interface, an inbound proxy class has to be generated in the back end system.
Another prerequisite is the destination structure. You have to create this structure. What the
structure should look like depends on the BAPIs, function modules, and so on that should be
called in the AIF action.
After the generation of the proxy, you have to implement it. You have to implement the
proxy's method. Since you use AIF, the only thing you have to do is call AIF by calling /AIF/
CL_ENABLER_PROXY=>PROCESS_MESSAGE. You have to pass the proxy method's input
structure as well as the exception class' name.
An AIF interface has to be created. You have to specify the name of your inbound proxy class;
the raw structure and the record type should then be inserted automatically. Furthermore,

© Copyright. All rights reserved. 151

Unit 9: Proxy Interfaces

you have to specify the SAP structure (destination structure). The engines used for inbound
proxy messages are the default ones, therefore, you do not have to change anything here.

Note:
In case you have NetWeaver 7.40 and you do not use SAP PI for communication,
you have to set the application and persistence engines to New Web Services.

The rest of the implementation can then be done in AIF Customizing. You can create structure
mappings, value mappings, actions, and so on as for any other AIF interface.

Note:
If you catch the exception given rise to by PROCESS_MESSAGE in your proxy
method, or if your proxy method does not have an exception class at all, errors
that occurred during AIF processing cannot be passed to the proxy framework.
The proxy framework is not able to set the message to an error state, therefore, it
displays as processed successfully and restarting or editing data is not correct.

Figure 135: Customer-Specific ABAP Proxies - Outbound Interface

As a prerequisite to creating an AIF interface for an outbound proxy, you need a service
interface. The service interface is created in the ESR or MDR and is usually not the task of the
AIF interface developer.
For this service interface, an outbound proxy class has to be generated in the back end
system.
Another prerequisite is the source structure. You have to create this structure. What the
structure should look like depends on the data that is available at the triggering place and that
needs to be passed to AIF. You should consider that you do not have to pass all data that you
want to be sent out to AIF; instead, you can derive the data from other fields within mapping in
AIF.

152 © Copyright. All rights reserved.

 Lesson: Using Proxy Interfaces

Create an AIF interface. You have to specify the name of the outbound proxy class and the
record type should then be inserted automatically. Furthermore, you have to specify the SAP
structure (source structure).
AIF always displays the source data in Monitoring and Error Handling. However, this data is
not usually stored anywhere for outbound proxy interfaces. Therefore, we use AIF's own
persistence and runtime in order to enable the display of data and reprocessing and canceling
of messages. Set the application and persistence engines to XML.
The rest of the implementation can then be done in AIF Customizing. You can create structure
mappings, value mappings, actions, and so on as for any other AIF interface.
Furthermore, you have to create a report, function module, and so on, which trigger the
sending of the message. Pass the necessary data to the interfaces source structure and call
the /AIF/SEND_WITH_PROXY function module. Make sure to pass the correct namespace,
interface name, and version to the function module. Furthermore, you have to pass the
source data.
If you process a message, you are able to see the source structure content in Monitoring and
Error Handling. Furthermore, you can do error handling, restart or cancel a message if it ran
into an error in AIF.

Figure 136: Monitor Existing Inbound Proxies/Standard Enterprise Services

The monitoring of inbound proxies that are synchronous makes it possible for you to see if
proxies were called. The standard proxy runtime does not keep track of synchronous calls.

LESSON SUMMARY
You should now be able to:
● Use proxy interfaces

© Copyright. All rights reserved. 153

Unit 9: Proxy Interfaces

154 © Copyright. All rights reserved.

 Unit 9

Learning Assessment

1. AIF can work with inbound and outbound proxy interfaces.

Determine whether this statement is true or false.

X True

X False

2. Which AIF function module can be used to send an outbound proxy?

Choose the correct answer.

X A /AIF/BROADCAST_WITH_PROXY

X B /AIF/SEND_WITH_PROXY

X C /AIF/TRANSMIT_WITH_PROXY

3. Which AIF method has to be called inside the inbound proxy interface to send it to AIF?
Choose the correct answer.

X A /AIF/CL_PROCESS_PROXY=>PROCESS_MESSAGE

X B /AIF/CL_PROCESS_PROXY=>ENABLE_MESSAGE

X C /AIF/CL_ENABLER_PROXY=>PROCESS_MESSAGE

© Copyright. All rights reserved. 155

 Unit 9

Learning Assessment - Answers

1. AIF can work with inbound and outbound proxy interfaces.

Determine whether this statement is true or false.

X True

X False

This is correct. Both directions are possible. See BIT750, Unit 9, Lesson 1.

2. Which AIF function module can be used to send an outbound proxy?

Choose the correct answer.

X A /AIF/BROADCAST_WITH_PROXY

X B /AIF/SEND_WITH_PROXY

X C /AIF/TRANSMIT_WITH_PROXY

This is correct. You use: /AIF/SEND_WITH_PROXY. See BIT750, Unit 9, Lesson 1.

3. Which AIF method has to be called inside the inbound proxy interface to send it to AIF?
Choose the correct answer.

X A /AIF/CL_PROCESS_PROXY=>PROCESS_MESSAGE

X B /AIF/CL_PROCESS_PROXY=>ENABLE_MESSAGE

X C /AIF/CL_ENABLER_PROXY=>PROCESS_MESSAGE

This is correct. You use: /AIF/CL_ENABLER_PROXY=>PROCESS_MESSAGE. See BIT750,

Unit 9, Lesson 1.

156 © Copyright. All rights reserved.

 UNIT 10 File Adapter

Lesson 1
Explaining the File Adapter 159

UNIT OBJECTIVES

● Explain the file adapter

© Copyright. All rights reserved. 157

Unit 10: File Adapter

158 © Copyright. All rights reserved.

 Unit 10
Lesson 1
Explaining the File Adapter

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain the file adapter

File Adapter

Figure 137: File Adapter

Files can be uploaded to AIF. The figure explains the basic requirements.
In more detail, to upload files, the following is required:

1. Create a DDIC structure representing the structure of the file. The structure must contain
a structure matching the fields of the file. If the file contains a table of entries, the DDIC
structure must contain a table with the structure containing the fields of the file as line
type. This structure will be used as the raw structure in the AIF interface.

2. Create or reuse an SAP structure. The SAP structure is defined by the follow-up
processing inside AIF.

3. Create an AIF interface.

4. Set interface engines. The Application and Persistence Engines must be set to XML. The
Selection Engine should be set to AIF Index Tables and the Logging Engine should use the
AIF Application Log.

5. Define structure mappings and actions. Map the raw to the SAP structure and trigger the
follow-up processing in an action assigned to the interface.

© Copyright. All rights reserved. 159

Unit 10: File Adapter

6. Create the file adapter configuration. There are no default settings for uploading a file. To
read a file from the system, the minimum information required is the file type, file content,
and text type. To map the file to the interface, the structure name and the field name,
where the file content is moved to during the upload, is required.

The imported file will result in one or more AIF messages. If the content of the file is mapped
to one or multiple AIF messages depends on the configuration of the file adapter and the
interface/structure of the interface.

Figure 138: Options for File Upload

The following are required transactions:

File Upload
This transaction allows you to upload single files from either the application server or
from a local PC. It is targeted at users that need to upload files manually. The report
provides the option to display the file after upload so that the user can have a look at its
content. Furthermore, if you have a flat structure, you can display the result structure
before the data is transferred to AIF. This way, you can see how the data was mapped
from the file to the structure specified in the file adapter configuration.
Transaction: /AIF/LFA_UPLOAD_FILE
Mass File Upload from Server: This transaction allows you to upload multiple files from
the application server. The report can be scheduled as a regular job to read data from a
predefined path and pass it to AIF. Once a file has been read, it is moved to a new folder
on the application server to avoid having the same files read again. This folder can also be
specified.
Transaction: /AIF/LFA_CHECK_SEND
The transaction for the single file upload.

160 © Copyright. All rights reserved.

 Lesson: Explaining the File Adapter

Figure 139: Upload Files with the File Adapter

File Adapter Configuration: The file adapter configuration defines which settings are used for
uploading files to the SAP Application Interface Framework. For example, it defines the file
type and the structure the uploaded file is moved to.
Block Size in Lines: If your file contains multiple data sets, you can specify how many lines are
passed to one message. If you do not specify a block size, the entire file content is sent as one
message.
For example, you have a file with 1000 data sets.
● You do not maintain a block size: All data sets are passed at once to AIF. This results in one
single message in AIF.
● You maintain a block size of 100: 100 data sets are passed to AIF and a message is created
for those 100 data sets. Afterwards, the next 100 data sets are passed to AIF. This results
in 10 messages that are processed in AIF, each message containing 100 data sets.

Note:
A block size can only be maintained if you have a flat structure. In case of a
complex structure, the complete file has to be transferred at once.

If you have multiple data sets in your file and your structure is only able to handle one data set
at a time, the file upload uses an implicit block size of one. In that case, each data set results
in one message.
Runtime Configuration Group
As the XML runtime of AIF is used to process the data sets, a runtime configuration group can
be specified. This allows you to define whether the messages are processed in the same
session or background jobs are created. Furthermore, this defines how many messages are
processed within one run or package.

© Copyright. All rights reserved. 161

Unit 10: File Adapter

Figure 140: File Adapter Configuration

There are no default settings for uploading a file. To upload a file, the minimum information
required is the file type, file content, and text type. To map the file to the interface, the
structure name and the field name, to where the file content is moved during the upload, is
required:
● File Type defines whether the file should be read in binary mode or in text mode.
● File Content defines what the content of the file looks like. There are following file content
types:
- Flat Structure
- Complex Structure: The file content can be mapped into a complex structure, which
may contain header, substructures, and sub tables. In this case, you have to maintain a
substructure determination in Customizing for the SAP Application Interface
Framework under Configure File Adapter.
- User Defined: Customer-specific mapping can be done using a customer-specific
function module, the name of which has to be stored in the Mapping Function field.
- XML: Mapping is done via Extensible Stylesheet Language Transformation (XSLT) or
Simple Transformation (ST). The transformation name must be stored in the
Transformation field.
- Depending on the selection done in the File Content field, different fields are displayed
in the Customizing of the field adapter configuration.
● Text Type: defines where the file content should be separated into individual fields during
the file upload. The following options are possible:

162 © Copyright. All rights reserved.

 Lesson: Explaining the File Adapter

- Special Character as Separator: The individual fields are separated by a special

character in the file (e.g., in case of CSV files). The separator needs to be maintained in
the Field Separator field.
- Fixed Field Lengths: The length of the individual fields is correctly represented in the file
and no special field separator is used.
- One Field per Line: Each field has exactly one line in the file.
● Structure Name: Name of the raw structure used in the AIF interface.
● Field Name: defines the component of the structure, maintained in the Structure Name
field, to where the file content is moved during upload. This component can also be a table
type. In this case, the line type of this table type has to fit to the data that you upload with
the file.

Source Structure

Figure 141: Creating a Source Structure

To be able to process files in AIF, you need a DDIC structure that matches the file. How do you
create this structure?

1. Check the file and the content.

In which form is the data contained in the file? Does the file contain a data table or only a
single record? How long are the different fields?

2. Create a corresponding DDIC structure.

If the file contains a data table, the DDIC structure requires a table to store the different
entries from the file. The line type is defined by the different fields of the file.
Depending on the raw structure used, AIF creates one or multiple messages. If the file
contains a data table and the raw structure resamples the table with a corresponding table
type, AIF only creates one message per file. If the raw structure is a structure that
resamples one line of the file, AIF creates a new message for every line in the selected file.

© Copyright. All rights reserved. 163

Unit 10: File Adapter

For example, the file contains a table with IDs, names, and cities. The ID is 6 characters
long. The name can be 30 characters long and the city can be 60 characters long.
In this case, the source structure must contain a table containing the different entries. The
table is defined by the different fields of the file.
The line type is a structure with the following fields: ID Char 6, Name Char 30, and City
Char 60. This structure is used as line type for the table. The table is then included into the
source structure.

Destination Structure

Figure 142: Create Destination Structure

The destination structure must contain tables/structures that are required in the follow-up
processing of the message.
To define the correct destination structure, you must identify the required parameters.
In the example above, BAPI 1 for processing customers requires a table with the customer
information. BAPI 2 requires a table with the city information.
Both parameters, the customer table and the city table, need to be part of the destination
structure.
In this example, the destination structure must contain a table for the customers. The line
type is defined by the data type of the processing function/BAPI parameter. In addition to the
customer table, it must contain a second table for the cities. Again, the line type is defined by
the data type of the processing function/BAPI parameter.

LESSON SUMMARY
You should now be able to:
● Explain the file adapter

164 © Copyright. All rights reserved.

 Unit 10

Learning Assessment

1. [Question]What is true about the AIF File Adapter?

Choose the correct answers.

X A The AIF File Adapter can read XML messages.

X B The AIF File Adapter can read flat files.

X C The AIF File Adapter can make one message out of many files.

X D The structure has to be the same for all lines if a flat file is used.

X E The AIF File Adapter uses the AIF XML engine.

© Copyright. All rights reserved. 165

 Unit 10

Learning Assessment - Answers

1. [Question]What is true about the AIF File Adapter?

Choose the correct answers.

X A The AIF File Adapter can read XML messages.

X B The AIF File Adapter can read flat files.

X C The AIF File Adapter can make one message out of many files.

X D The structure has to be the same for all lines if a flat file is used.

X E The AIF File Adapter uses the AIF XML engine.

This is correct. The AIF file adapter can read XML messages and flat files and it uses the
AIF XML engine. See BIT750, Unit 9, Lesson 1.

166 © Copyright. All rights reserved.

 UNIT 11 Additional Features for
Simplified Monitoring

Lesson 1
Using Additinal Features for Simplified Monitoring 169

UNIT OBJECTIVES

● Use additional features for simplified monitoring

© Copyright. All rights reserved. 167

Unit 11: Additional Features for Simplified Monitoring

168 © Copyright. All rights reserved.

 Unit 11
Lesson 1
Using Additinal Features for Simplified
Monitoring

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Use additional features for simplified monitoring

Additional Features for Simplified Error Handling

Figure 143: Custom Objects

The figure symbolizes the build of custom objects.

There are several custom objects that allow a user to simplify the handling of errors in the
Monitoring and Error Handling transaction:
● Custom Functions: User-specific forward navigation to other transactions.
● Custom Hints: User-specific information.
● Custom Data Links: User-specific data links from log message to corresponding data
fields.
● Custom Message Text: User-specific message texts.

All custom objects are identified by a message class and a message number. You can define
custom objects directly in the Log Messages view of the Monitoring and Error Handling or in
the maintenance dialog of the custom object.
A custom object is linked to a specific log message and an interface. You can have multiple
custom objects linked to one log message.
By default, the custom object is only available for the user who created the custom object. But
the visibility and the scope of custom objects can be changed.

© Copyright. All rights reserved. 169

Unit 11: Additional Features for Simplified Monitoring

Figure 144: Visibility of Custom Objects

The visibility of a custom object can be changed in the maintenance transaction for this object
type.
If a new custom object is created in Monitoring and Error Handling, per default, the visibility is
set to only for current user.
You can change the visibility of a custom object. There are the following three options for
visibility settings for a custom object:
● Only for current user: Only the user who created the custom object is able to see it in
Monitoring and Error Handling.
● A list of users: A specified list of users can see the custom object in Monitoring and Error
Handling. If you select this option, you must also assign users to the custom function.
● For all: All users can see the custom object in Monitoring and Error Handling.

If the visibility of a custom object has been changed, you can no longer edit it in the
Monitoring and Error Handling transaction. You need to change the custom object using the
maintenance transaction for this object type.
You can find the following transactions for changing custom objects in the SAP Menu under
Cross-Application Components → SAP Application Interface Framework → Administration:
● Define Custom Functions (transaction code /AIF/CUST_FUNC).

● Define Custom Hints (transaction code /AIF/CUST_HINTS).

● Define Custom Data Links (transaction code /AIF/CUST_LINK).

● Define Custom Message Texts (transaction code /AIF/CUST_TEXT).

170 © Copyright. All rights reserved.

 Lesson: Using Additinal Features for Simplified Monitoring

Figure 145: Scope of Custom Objects

The scope of a custom object can be changed in the corresponding AIF maintenance
transaction.
If a new custom object is created in Monitoring and Error Handling, per default, the scope is
set to 'visible for selected message in this interface'.
You can change the scope of a custom object. There are the following four options for setting
the scope for a custom object:
● Visible for selected message in this interface: The custom object is only visible for the
message and in the interface it was created for.
● Visible for all messages in this interface: The custom object is visible for all messages in
the interface it was created for.
● Visible for selected message in all interfaces: The custom object is only visible for the
message it was created for. It is visible in all interfaces.
● Visible for all messages in all interfaces: The custom object is visible for all messages and
all interfaces.

If the scope of a custom object was changed, it is no longer possible to edit it in the Monitoring
and Error Handling transaction. In this case, it is necessary to change the custom object via
the corresponding maintenance transaction.
You can find the following transactions to change custom objects in the SAP Menu under
Cross-Application Components → SAP Application Interface Framework → Administration:

Custom Function
The configuration dialog to define custom functions can be found in Define Custom
Functions (or via transaction code /AIF/CUST_FUNC).
Custom Hint
The configuration dialog to define custom hints can be found in Define Custom Hints (or
via transaction code /AIF/CUST_HINTS).
Custom Data Link

© Copyright. All rights reserved. 171

Unit 11: Additional Features for Simplified Monitoring

The configuration dialog to define custom data links can be found in Define Custom Data
Links (or via transaction code /AIF/CUST_LINK).
Custom Message Text
The configuration dialog to define custom message texts can be found in Define Custom
Message Texts (or via transaction code /AIF/CUST_TEXT).

Figure 146: Custom Functions

A custom function allows a user to jump into another transaction directly from the Monitoring
and Error Handling transaction.
A custom function is defined for a specific log message in a specific interface.
You can maintain the custom function in the Monitoring and Error Handling transaction. If the
scope or visibility of the custom function has been changed, it is no longer possible to
maintain the custom function in Monitoring and Error Handling. You can only maintain a
changed custom function via the Define Custom Functions activity (or via transaction
code /AIF/CUST_FUNC).
A custom function can use different parameters. Those parameters can be filled by:
● Manual values: the value for the parameter is directly entered in field value
● Message Variables: select one of the message variables displayed in the message details.
The variable can be selected via drop down list in the field Value from Message Variable
● Offset Message Variable: the offset can be maintained via the field Maintain
● Value mapping: the value mapping can be maintained via the field Maintain

172 © Copyright. All rights reserved.

 Lesson: Using Additinal Features for Simplified Monitoring

Figure 147: Custom Hints

A custom hint allows a user to create notes with additional information, for example, what to
do if a specific error occurs, next processing steps, and so on, for a specific log message in an
interface. The hint displays in the Monitoring and Error Handling transaction if the users press
the corresponding button in the Log Messages view.
You can maintain the custom hint in the Monitoring and Error Handling transaction. If the
scope or validity of the custom hint has been changed, it is no longer possible to maintain the
custom hint in Monitoring and Error Handling. You can only maintain a changed custom hint
via the Define Custom Hints activity (or via transaction code /AIF/CUST_HINT).

Figure 148: Custom Message Text

A custom message text allows a user to replace log messages with user specified texts, which
are for a specific log message in an interface. Per log message, it is possible to have more
than one custom message text. In the Log Messages view of Monitoring and Error Handling,

© Copyright. All rights reserved. 173

Unit 11: Additional Features for Simplified Monitoring

the custom message text is displayed instead of the standard log message. If more than one
custom message text is available for a specific log message, the newest custom message text
is displayed in the Message Text column of the Log Messages view. To indicate that a custom
message text was specified, an icon is displayed in the Texts column. A click on the icon
opens a list of all available custom message texts for this log message. The displayed custom
message texts are dependent on the user and the visibility and scope specified for the defined
custom message texts.
You can maintain custom message texts in Monitoring and Error Handling. If the scope or
validity has been changed, it is no longer possible to maintain the custom message text in
Monitoring and Error Handling. You can only maintain a changed custom message text via the
Define Custom Message Texts activity (or via transaction code /AIF/CUST_TEXT).

Figure 149: Custom Data Link

In Monitoring and Error Handling, to create, overwrite, or delete custom data links, select both
a message in the Log Message view and a cell in the Data Content view.

Note:
In the Data Content view, if a custom data link exists, for a field that is part of a
table, the relevant line number is not known and may differ from the line number
with which the link was created. Therefore, the relevant column is highlighted in
red.

LESSON SUMMARY
You should now be able to:
● Use additional features for simplified monitoring

174 © Copyright. All rights reserved.

 Unit 11

Learning Assessment

1. You can use your own text for every error message.
Determine whether this statement is true or false.

X True

X False

2. Which sort of custom objects exists in AIF?

Choose the correct answers.

X A Customer hints

X B Customer link to additional Help

X C Customer message texts

X D Customer dependent functions for restart

X E Customer functions to display created objects

X F Customer data links

© Copyright. All rights reserved. 175

 Unit 11

Learning Assessment - Answers

1. You can use your own text for every error message.
Determine whether this statement is true or false.

X True

X False

This is correct. You can even have different texts per interface and user. See BIT750, Unit
11, Lesson 1.

2. Which sort of custom objects exists in AIF?

Choose the correct answers.

X A Customer hints

X B Customer link to additional Help

X C Customer message texts

X D Customer dependent functions for restart

X E Customer functions to display created objects

X F Customer data links

This is correct. Existing sorts of custom objects are customer hints, customer message
texts, and customer functions to display created objects. See BIT750, Unit 11, Lesson 1.

176 © Copyright. All rights reserved.

 UNIT 12 Interface Variants

Lesson 1
Explaining Interface Variants 179

UNIT OBJECTIVES

● Explain interface variants

© Copyright. All rights reserved. 177

Unit 12: Interface Variants

178 © Copyright. All rights reserved.

 Unit 12
Lesson 1
Explaining Interface Variants

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain interface variants

Interface Variants

Figure 150: Interface Variants

An interface variant can be created if the original interface must not be changed.

© Copyright. All rights reserved. 179

Unit 12: Interface Variants

Figure 151: What can be Changed in an Interface Variant?

Interface variants enable you to do additionally or different mappings or checks depending on

the sender of the interface. It is not possible to avoid something that is done in the original
interface definition.

Figure 152: Interface Variant Example

In this example the mapping for the company code is not done in the original mapping as
three different Mappings are needed. Everything that is needed for all three senders is done in
the regular definition and then a variant per sender is added that fills the company code
following the different logics.

180 © Copyright. All rights reserved.

 Lesson: Explaining Interface Variants

LESSON SUMMARY
You should now be able to:
● Explain interface variants

© Copyright. All rights reserved. 181

Unit 12: Interface Variants

182 © Copyright. All rights reserved.

 Unit 12

Learning Assessment

1. Interface variants can tell AIF to skip a check for a special message content.
Determine whether this statement is true or false.

X True

X False

© Copyright. All rights reserved. 183

 Unit 12

Learning Assessment - Answers

1. Interface variants can tell AIF to skip a check for a special message content.
Determine whether this statement is true or false.

X True

X False

This is correct. Interface variants do everything the original mapping does, but additional
checks or mappings can be defined. See BIT750, Unit 12, Lesson 1.

184 © Copyright. All rights reserved.

 UNIT 13 Analyzer

Lesson 1
Using the Analyzer 187

UNIT OBJECTIVES

● Use the analyzer

© Copyright. All rights reserved. 185

Unit 13: Analyzer

186 © Copyright. All rights reserved.

 Unit 13
Lesson 1
Using the Analyzer

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Use the analyzer

Analyzer

Figure 153: What Happened?

If you want to use the analyzer the message you want to analyze has to be started with the AIF
Test tool.

© Copyright. All rights reserved. 187

Unit 13: Analyzer

Figure 154: Analyze the Interface

The AIF test tool enables you to test the interface. By executing the test file, you can see, how
the data will look like after its transformation. Log messages, which are created during the
transformation, are displayed here, too.
The AIF test tool has an additional feature to see what happened during the processing of the
interface, the AIF Analyzer.

Figure 155: Analyzer

After you start the mapping, the Analyzer button appears. You can use the Analyzer to see
what happened.

188 © Copyright. All rights reserved.

 Lesson: Using the Analyzer

Figure 156: Show DDIC Structure/Log Messages

The Show DDIC navigation does not work for simple data types, such as STRING. In these
cases, a message is displayed that the forward navigation is not working for the selected data
type.
In the Analyzer you can follow every step inside the mapping and see what is done in which
sequence.

Figure 157: Show Content of Processing Step

Fields that are used in customizing settings are categorized as follows:

● Yellow: Customizing settings for the selected field/fields

© Copyright. All rights reserved. 189

Unit 13: Analyzer

● Red: (All) fields that are used in customizing settings highlighted in yellow
● Blue: (All) fields that are changed by the customizing settings highlighted in yellow

Figure 158: The "Show where field Is used" Function

The where used list of fields of the source message gives you the possibility to see if you can
change this field in the interface definition.

Figure 159: The "Show where field has been changed" Function

It is possible to see the content changes of fields during the process and it is possible to
directly see the fields definitions in the Data Dictionary.

190 © Copyright. All rights reserved.

 Lesson: Using the Analyzer

LESSON SUMMARY
You should now be able to:
● Use the analyzer

© Copyright. All rights reserved. 191

Unit 13: Analyzer

192 © Copyright. All rights reserved.

 Unit 13

Learning Assessment

1. The analyzer can be used for every message.

Determine whether this statement is true or false.

X True

X False

2. What can you do with the Analyzer?

Choose the correct answers.

X A Find where a field of the source structure is used in mapping.

X B Show the definition of a field in the data dictionary.

X C Change fields during the execution of a mapping.

X D See, if checks have been performed and what was the result of the check.

X E Show the content of a structure at a certain step.

© Copyright. All rights reserved. 193

 Unit 13

Learning Assessment - Answers

1. The analyzer can be used for every message.

Determine whether this statement is true or false.

X True

X False

This is correct. The analyzer can only be used for messages that have been created and
executed with the AIF test tool. See BIT750, Unit 13, Lesson 1.

2. What can you do with the Analyzer?

Choose the correct answers.

X A Find where a field of the source structure is used in mapping.

X B Show the definition of a field in the data dictionary.

X C Change fields during the execution of a mapping.

X D See, if checks have been performed and what was the result of the check.

X E Show the content of a structure at a certain step.

This is correct. The analyzer can not change fields during the execution of a mapping. See
BIT750, Unit 13, Lesson 1.

194 © Copyright. All rights reserved.

 UNIT 14 Additional Information

Lesson 1
Exploring Additional Topics 197

Lesson 2
Determining Interfaces 203

UNIT OBJECTIVES

● Explore additional topics

● Determine Interfaces

© Copyright. All rights reserved. 195

Unit 14: Additional Information

196 © Copyright. All rights reserved.

 Unit 14
Lesson 1
Exploring Additional Topics

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explore additional topics

Additional Topics

Figure 160: Reprocess Messages

Some problems are solved without requiring the user to do anything other than restart the
message, for example, update of an object and the object was locked. It is a problem if the
user spends a lot of time analyzing errors that are already solved.

Figure 161: Automatic Reprocessing

© Copyright. All rights reserved. 197

Unit 14: Additional Information

Configure automatic reprocessing for errors that can be solved automatically via
transactions /AIF/REP_AC_DEF and /AIF/REP_AC_ASGN. Example: “Object is locked by
user &1”.
The following settings are possible:
● Define a reprocessing action and maintain a function module (/AIF/RESTART_MSG with
AIF)
● Define for each interface in which error case the message should automatically be
restarted
● Define the maximum number of retries
● Define maximum and minimum waiting time
● Define a Runtime Configuration Group with Run Active and Run Scheduled /AIF/
PERS_CGR

Figure 162: Trace Levels

Trace Levels are defined in AIF Customizing → Error Handling → Global Features.
There you define the following:
● Which messages are added to the application log.
● By default, trace level 0 is used.
● Set trace level for interface in view /AIF/V_FINF_TL.

Then restart with a higher trace level from Monitoring and Error Handling.
Restart the message with a higher trace level for error analysis.

198 © Copyright. All rights reserved.

 Lesson: Exploring Additional Topics

Figure 163: Structure Labels

The figure explains the use of structure labels.

Roles and Authorizations

Figure 164: Roles and Authorizations

In AIF, you can restrict authorizations on at least namespace level. In some places you can
also restrict the authorization on interfaces level.
In addition you can restrict the authorization for the Monitoring and Error Handling on data
content level. To restrict the authorization on data content level, a corresponding single key
field is needed.

© Copyright. All rights reserved. 199

Unit 14: Additional Information

For example, if business user A should only be able to see messages of VKORG 1 (VKORG →
Sales Organization) and business user B should only be able to see messages of VKORG 2,
you can set this up in Monitoring and Error Handling.
AIF delivers the following role templates:
● SAP_AIF_ADMIN - AIF Administrator
● SAP_AIF_ALL - AIF All Authorizations
● SAP_AIF_ARCHITEXT - AIF Architect
● SAP_AIF_DEVELOPER - AIF Developer
● SAP_AIF_POWER_USER - AIF Power User
● SAP_AIF_PROCESSING - AIF Processing
● SAP_AIF_TEST_TEMPL - AIF Test Template (Non-Productive)
● SAP_AIF_USER - AIF Business User

Detailed information about AIF roles can be found in the AIF Master Guide and application
help.

Figure 165: Authorizations Objects

The figure illustrates the three authorization objects:

/AIF/PROC - Authorization Object for Interface Processing

The authorization object /AIF/PROC is used by the system to check the user's
authorization for processing a data message of a given interface in SAP Application
Interface Framework. This authorization is required to process data messages in AIF. The
authorization object can be set on namespace and interface level.
/AIF/CUST - Authorization Object for Customizing Steps

200 © Copyright. All rights reserved.

 Lesson: Exploring Additional Topics

The authorization object /AIF/CUST is used by the system to check the user's
authorization for a Customizing activity in SAP Application Interface Framework. This
authorization object enables a user to use the AIF Customizing. You can limit a user's
authorization to specific namespaces. For example, an interface developer is authorized
to create, edit, and delete interfaces in namespace X but not Y.
/AIF/ERR - Authorization Object for Error Handling
The authorization object /AIF/ERR is used by the system to check the user's
authorization for error handling in the SAP Application Interface Framework. The user's
authorizations can be limited to read only access to the transaction. The authorizations
can be limited by namespace, interface name, and version.

Other AIF authorization objects:

● /AIF/TECH - Authorization Object for Technical Error Handling
● /AIF/EMC - Authorization Object for Emergency Corrections
● /AIF/CFUNC - Authorization Object for Custom Functions
● /AIF/HINTS - Authorization Object for Custom Hints
● /AIF/IFDET - Authorization Object for Interface Determination
● /AIF/VMAP - Authorization Object for Value Mapping Maintenance
● /AIF/LFA - Authorization Object for File Adapter
● /AIF/CDLOG - Authorization Object for Change Log
● /AIF/CTEXT - Authorization Object for Custom Message Texts
● /AIF/CLINK - Authorization Object for Custom Data Links

LESSON SUMMARY
You should now be able to:
● Explore additional topics

© Copyright. All rights reserved. 201

Unit 14: Additional Information

202 © Copyright. All rights reserved.

 Unit 14
Lesson 2
Determining Interfaces

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Determine Interfaces

Interface Determination
Basics about interface determination:

● The Interface Determination enables you to define which AIF interface is used to process a
data message.
● The interface determination can be specified for:
- Proxy Interfaces
- IDoc Interfaces
- XML Interfaces
- Customer-Specific Engines
● When to use the Interface Determination?
- Example: You have more than one XML interface using the same RAW structure or you
have different IDocs using the same Message Type / Basic Type combination. In these
cases, AIF cannot determine which interface must be used and, thus, requires an
interface determination to set the right interface.

Under which conditions can you use the interface determination?

Proxy Interfaces
Interface determination is only available for inbound messages coming from a PI proxy,
that is, interfaces that are using the local integration engine / proxy framework.
IDoc Interfaces
Interface determination is only available for IDoc inbound messages. To use the IDoc
interface determination, the basic type and message type should be maintained either in
the interface definition or in Customizing for the SAP Application Interface Framework.
The interface determination for IDoc interfaces is not available if the standard IDoc
runtime is used.
XML Interfaces
Interface determination is available for inbound and outbound messages coming from
the persistence layer.
Customer-Specific Engines

© Copyright. All rights reserved. 203

Unit 14: Additional Information

You have created a customer-specific interface determination class. This class has to
implement the interface /AIF/IF_INF_DET_ENGINE. Alternatively, the class can inherit it
from /AIF/CL_INF_DET_ENGINE_BASE. In addition, you have maintained your
customer-specific interface determination class in Customizing for the SAP Application
Interface Framework.

Figure 166: Interface Determination

Depending on specific values of a field, a message is processed by one or the other interface.

LESSON SUMMARY
You should now be able to:
● Determine Interfaces

204 © Copyright. All rights reserved.

 Unit 14

Learning Assessment

1. Can messages with an error be restarted automatically with AIF?

Determine whether this statement is true or false.

X True

X False

© Copyright. All rights reserved. 205

 Unit 14

Learning Assessment - Answers

1. Can messages with an error be restarted automatically with AIF?

Determine whether this statement is true or false.

X True

X False

This is correct. You can automatically restart faulty message with AIF. See BIT750, Unit
14, Lesson 1.

206 © Copyright. All rights reserved.