Exploring the Role of Actions in the SAP Application Interface Framework

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.

Watch this video as we delve into the intricacies of actions within the SAP Application Interface Framework, exploring how actions are defined, linked to interfaces, and facilitate efficient data processing. Let's discover the key steps involved in defining actions and the crucial concepts of commit mode and commit level, essential for seamless transaction handling. Learn through examples how actions operate and contribute to effective data management within SAP Application Interface Framework.

• Structure: In the SAP Application Interface Framework, a well-defined structure is essential for organizing and mapping data within interfaces. Structures determine how data is stored, processed, and transmitted, ensuring consistency and efficiency in information exchange.
• Interfaces: Interfaces serve as the bridge between different systems or components, allowing data to flow seamlessly. In SAP Application Interface Framework, interfaces define the parameters, mappings, and actions required for data transmission and processing, facilitating communication between diverse entities.
• Action Definition: Actions in SAP Application Interface Framework encapsulate specific functionalities or operations that can be executed on data. Defining actions involves naming, grouping, and structuring tasks, enabling users to perform consistent actions across interfaces and namespaces within the framework.
• Commit Mode and Level: Understanding commit mode and level is crucial in SAP Application Interface Framework as they determine how data changes are managed and persisted during transactional processes. Commit mode specifies when data changes should be committed, while commit level defines the scope or granularity of these commitments, ensuring data integrity and reliability.

The init function is used to do some precalculations / additional data enrichment before an action is processed.

The init function is processed at the beginning of an action call.

Application Interface Framework delivers the /AIF/FILE_TEMPL_INIT_ACTION template function module that you can copy and reuse.

Recommendation: Create an init function before processing via forward navigation.

The Action Function implements the business logic of the interface. An action can contain more than one action function.

An action function can:

• Call a BAPI
• Call a function module
• Execute customer-specific code

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.

Action Function Stop on Error

For every defined action function, you need to set the behavior in case an error occurs.

If Stop Processing on Error is selected for an action function, the processing of the current line is stopped if an error occurs. You can select the Stop Processing on Error checkbox on:

• Action level
• Structure Mapping level

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 SAP Application Interface Framework 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.

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.

If a function module was executed successfully and the data was committed, it's not executed again during restart.

If you selected the restart always checkbox for an action, the function module is executed again during a restart.

Action Function – Check

You can define checks for an action function. The check is executed before the action function. Depending on the result of the check, the action is executed or skipped.

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

• 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.

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

Restart behavior when commit is done after each function:

• Line 1: Has already been processed successfully → No function will be executed.
• Line 2: FUMO_1 and FUMO_2 will be executed.
• Line 3: FUMO_1 will be executed.

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.

Data determined during the execution of an action function is sometimes required by action function executed later on.

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.

1. Recognize Key Data and Error Consequences: Note the importance of the customer number determined in the first function for creating an invoice, as shown in the example. Understand the potential loss of critical data if errors occur during the second function and the failure to restart action function 5.
2. Step 2 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.
3. Implement Field to Restore for Data Integrity: Utilize a field to restore to prevent follow-up processing errors when restarting action functions without the previously determined data. This field stores the crucial values, ensuring their retrieval when reprocessing an action function in case of an error. For instance, designate the customer number from the initial function as a Field to Restore, allowing seamless retrieval and transfer during reprocessing to facilitate the creation of the invoice.

In the Monitoring and Error Handling, the message content is displayed. In some cases, the displayed data is incorrect. By Default, the users cannot change the value of a field in the Monitoring and Handling. Using a changeable field, the users can define specific fields to be editable in the Monitoring and Error Handling transaction and restart the corrected message.

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

It's possible to set authorizations for changing the content in the monitoring and error handling tool at the field level.