Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
bogar_benedikt
Explorer
1,276

Baseline


In the interconnected world of business, data exchange is crucial for organizations to operate efficiently. Managing and monitoring this process can be complex, especially when dealing with global EDI rollouts, since we have to include a widespread and numerous amount of partners. SAP AIF's tailored authorizations are therefore essential for ensuring the secure and compliant processing and monitoring of data, while also improving communication and streamlining business processes across different countries.

One of the main benefits of SAP AIF is the ability to tailor authorizations for such global EDI rollouts using only one interface. This is achieved by using key field rules, alert recipients, and authorization objects to create one interface in SAP AIF with multiple roles.  In this blog, I would like to show the example of how to implement one interface but fulfill the requirement that business users still only have access to the messages of their origin organization. In EDI in particular, this always creates challenges, as we have to integrate a large number of partners

Prerequisites


Before implementing tailored authorizations for global EDI rollouts in SAP AIF, there are some prerequisites that must be met. First, the SAP AIF interface must be properly configured and set up. This includes defining the necessary key field rules and alert recipients to ensure that the correct data is captured and processed. Second, authorization objects must be created to define the roles and access levels required for each user or group of users. Finally, the necessary authorization profiles must be created and assigned to each user or group of users.

To implement the template for global rollouts in SAP AIF the following steps are needed:

  1. Define Key Field Rules: Key field rules are used to define the fields that must be included in the index table of your interface. This ensures that the correct data is captured and processed by the SAP AIF system. In our example we will set up a key field rule to store the corresponding organization.

  2. Define Alert Recipients: Alert recipients are used to notify the relevant users when any error occurs in the interface. They are also responsible for the assignment to interfaces via transaction /AIF/IFMON. This ensures that the user will only get alert notification for his relevant messages in the interface and not for all failed messages.

  3. Create Authorization Objects: Authorization objects are used to define the roles and access levels required for each user or group of users. This ensures that the appropriate users have access to the necessary data and functionality. They are mainly needed for the access via transaction /AIF/ERR. Without the authorization object the user could access all processed messages in the assigned interface.

  4. Create Authorization Profiles: Authorization profiles are used to assign the necessary authorization objects to each user or group of users. This ensures that each user or group of users has the appropriate level of access to the SAP AIF system and also the maintenance can be done more quickly.


 

Implementation


In this example we look at an inbound orders interface and assume that the normal setup of the interface in the SAP AIF has already been completed.

Now we focus on the needed steps for authorization:

  1. Define Alert Recipient per each required ORGID. In this example we start with two Recipients to distinguish between germany and spain.

  2.  Create the alert recipient assignment Table to determined the alert Recipient based on specific values. Therefore we can make use of the template table /AIF/T_ALRT_DEF and enhance it with the corresponding field.

  3. For this table we need then only a maintenance screen and already we can deposit via SM30 the assignmentThe alert recipients later ensure that the users only receive mail alerts for messages from your company code and also only see the relevant messages in the transaction /AIF/IFMON based on the assigned recipient.


But we still could access all messages via transaction /AIF/ERR - Therefore we need to set up a proper authorization object and role.

  1. Define new Authorization Object in SU21 within class AIF It should include at least two fields (ACTVT and our Key field ORGID ).Here you can also maintain all permitted activities.

  2. Create now the corresponding authorization role in PFCG and add the newly created object to the roleIn the next screen click on manually to add the object to the roleLast step is now to maintain the assignment, same as we did in our Recipients alert table and maintain the specific permissions in field ACTVT.The final result is a new role which will be assigned to the user who will be responsible for monitoring messages in der sale organization 0001. Now we can simply copy this role and assign the organisation 0003 for spain.


In the last step we now add everything in the AIF Customizing in /AIF/CUST.

  1. Add our newly created alert recipient determination table in the namespace specific features

  2. In the interface specific features we now put everything together as a part of the key field



In this case we use a key field rule ( ZAIF_KFLD_DEMO_ORGID which is based on the template function /AIF/TEMPL_ENH_KFLDS ) to determine the sales organization from the data in the system. It is important to note that in the EDI scenario the organization must be determined, since it isn't known to the sender usually and is therefore also not included in the payload.

In this step it is important that we don't forget to add and assign our authorization object to the key field as well!



Test


To test the feature, I simply assigned both Alert Recipients directly to my user, but via SU01 only the role to be allowed to see messages for DE.


Process a new IDoc and check the results for the alert Recipient split:


Now we can test via /AIF/ERR and should get an error since we are not allowed to see the messages. Same if we use the forward navigation in IFMON.


Finally, we want to test the success case. So we assign the role for Spain ( Z_DEMO_ORGID_ES ) to our user and we see the messages again.


 

Conclusion


Tailored authorizations for global EDI rollouts in SAP AIF are essential for ensuring that users only have access to the correct data. By following the steps outlined in this blog, organizations can implement atemplate for global EDI rollouts in SAP AIF and improve their overall data security process.

The initial set up seems to be a lot at first, but when we consider that we now only need one Alert Recipient, the new role and just do the assignments for future rollouts, it's worth it,  or what do you think?

It is important to say that there are many ways to do this. The big advantage of this variant is that we only need a new role and a new alert recipient for each of the subsequent rollouts and don't have to worry about the amount of individual partners in the SAP AIF or create any additional interfaces. This not only saves a lot of customizing, but also time and makes it possible to create a uniform template for rollouts in all hugh S4 projects.
From my point of view, such an authorization concept should be part of every global AIF project at an early stage in order to avoid problems and additional work later on.
Labels in this area