Skip to Content
Author's profile photo Former Member

Recipient Determination by Keyfields

Introduction and Use Case

I recently talked to an AIF-customer, who has to process millions of messages. Because of the expected load and the diversity of the errors’ root causes, he wants to delegate the monitoring to different teams. They already use the error-category-feature to assign a message to a recipient by using the log message (e.g. a message with a financial-error get assigned to one recipient, whereas a message with an error in the master data gets assigned to different recipient). Now he wants to further dispatch the messages between the recipient by using a keyfield. Let me explain the requirement by giving you a concrete example:

In this blog post I used the flightbooking scenario. Let’s assume the load of processing the erronous messages increased and the process of fixing an error depends on the ariline/carrier. In this case it would be great to have one team to process erronous bookings for LH, one for AA, one for DL and one for all the other airlines. This can be achieved by using different recipients and configuring the recipient determination by keyfields. Dependending on a keyfield, a new message gets assigned to a specifc recipient.


As preparation I created an own namespace called Z_FZ9 and copied the standard FLBOOKING interface of namespace /AIF/ via transaction /AIF/CUST_SMAP_COPY. In addition I adjusted the interface determination, in order to receive messages on this interface.

Furthermore I created the following five recipients (/AIF/CUST -> Error Handling -> Namespace-Specifc Features -> Define Recipients):


How to Configure

Create Recipient Assignment Table

The assignment of keyfield values to a specific recipient is managed with a recipient assignment table. The table layout depends on the used keyfields and therefore is customer-specific. To create new recipient assignment table go to se11 and copy the template table /AIF/RECA_TMPL (if you did not use error categories, you alternatively could use the /AIF/T_ALRT_DEF table). In this example I named the new table Z_FZ9_RECIPIENTS. Now you need to add a column for each keyfield, you want to use in the recipient determination. In our example I added a column called CARRID (of type S_CARRID). Save and activate the table.


Now you can fill the recipient assignment table. Therefore go to transaction se16 and create the following records:


With this configuration the ALL-recipient receives all messages sent to the interface – independent of the actual keyfield value. The specifc recipients for AA-, DL– and LH-bookings will only be considered, if the CARRID-keyfield has the corresponding value. If no specific recipient can be determined by using the keyfield, the fallback-recipient, RECIPIENT_FOR_OTHER_BOOKINGS, will be used.

Change Customizing

As the next step, you have to change the customizing to let the interface use the newly created recipient assignment table during the recipient determination. Therefore go to /AIF/CUST -> Error Handling -> Define Namespace-Specific Features -> Configure Alerts and enter the recipient assignment table as shown in the following screenshot:


Furthermore you have to connect the CARRID-keyfield with the added column of the recipient assignment table. Therefore go to /AIF/CUST -> Error Handling -> Define Interface-Specifc Features -> Define Key Fields for Multiple Search and edit the CARRID-keyfield. Enter the name of the column and tick the checkbox Relevant for Recipient Determination as shown in the following screenshot:


Test the Example

In order to be able to test the example, you have to assign the recipients to your user. This can be done in transcation /AIF/MYRECIPIENTS. (If you want to assign a recipient to a different user, you can use transaction /AIF/RECIPIENT). Assign your user to all those recipients and tick the Overview-checkbox as shown in the picture:


Go to the Interface Monitor to check if all recipients show up. Then you can use the test-tool (/AIF/IFTEST) to send some messages to the interface and observe the recipients’ behaviour. Let’s have a look at the following examples:

1. Send an erroneous message with carrier LH: The message will be assigned to the LH-recipient and the ALL-recipient.


2. Send an erroneous message with carrier AA: The message will be assigned to the AA-recipient and the ALL-recipient.


3. Send four erroneous and one succesful messages with carrier DL: All five messages will be assigned to the DL-recipient and the ALL-recipient.


4. Send one erronous message with carrier BA: The message will be assigned to the OTHER-recipient and the ALL-recipient.


Further Information

  • Please note: If you previously assigned the interface to an recipient via the customizing (/AIF/CUST -> Error Handling -> Interface-Specifc Features -> Assign Recipients Without Key Fields), this assignment will get ignored as soon as a recipient assignment table is used. To keep the assignment, they manually have to be entered into the recipient assignment table.
  • This example showed how to assign a recipient to exactly one keyfield value. But it is also possible to assign two keyfield values to the same recipient. Just assume the following example: With the LH-recipient you not only want to cover LH-flight, but also 4U-flights (IATA-code of German Wings). Therefore you have to perform one change: The keyfield-column of the recipient assignment table has to be a part of the table’s primary key.


This blog post gave an introduction on how to use keyfields for the recipient determination. By using a recipient assignment table, the recipient determination can be influenced by specifc values of the keyfields. For instance, this can be used to dispatch message to different processing teams.

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

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Robert Phelan
      Robert Phelan

      Excellent post. We're going to be using AIF 3.0 more heavily in our new implementation.

      Quick question.. does an alert happen for every error record in a file or once per interface?

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hi Robert,

      the behavior is configurable. Each user can decide on his own. The mode is indicated by the Mail-icon in the Interface Monitor and it can be changed by clicking on the icon:


      There are 3 possible configurations:

      /wp-content/uploads/2016/08/comment1_3_1011013.png No mails are sent to the user
      /wp-content/uploads/2016/08/comment1_5_1011014.png A mail is sent for the next alert (when the interface switches to an error state due to an erronous message). But no mail will be sent, if an alert is still active (see light-bulb-icon: /wp-content/uploads/2016/08/comment1_2_1011018.png)
      /wp-content/uploads/2016/08/comment1_4_1011015.png A mail is sent for every error

      Best regards,