Low hanging fruit a company can get from…

1. Even though I wanted to start with a less standard question, I cannot help myself asking about the intentions. Why, oh why 🙂 … What made you Krzysztof decide to tackle the “Interface Monitoring and Error Handling with SAP AIF” area?

Krzysztof: When companies decide to implement SAP AIF, the Monitoring and Error Handling is usually the first thing they look at. This is the quick win, the low hanging fruit, that they can get from SAP AIF. With low effort they can benefit from unification of interface monitoring and error handling, and gain more visibility of their interfaces.

So we decided to pick this topic as we thought it would be helpful to have those parts described in one place.

2. Companies decide to implement … Let’s elaborate a little bit more on that. What effect has SAP AIF exactly made on the companies?

Krzysztof: It makes you rethink how your interfaces are designed. There should be a clear distinction between SAP AIF and SAP PO or CPI, and the roles that they play in your integration setup. SAP AIF gives you ability to put all of the business related logic of your interfaces there, and focus on other parts, like connectivity, structural conversions or routing in the middleware. That makes the design of interfaces more structured and easier to handle in the future. In addition, SAP AIF also unifies the way you do monitoring and error handling of interfaces in SAP application systems. Because only then you have one tool to cover all the interfaces that are coming in and out of your SAP application, instead of needing to monitor each interface in a different monitor, depending on the technology.

3. We have covered the business side with Krzysztof and it just automatically goes in my head to the other side and check what effect SAP AIF has made on the integration consultants. Mateusz, could you take this one, please? (laughter)

Mateusz: The biggest effect that SAP AIF makes on the integration consultants is the unified way of working with different integration technologies. For instance, if you are working with IDocs and Proxies, monitoring and error handling has to be done in separate transactions, the way of working with those transactions and UI is totally different. Once you have SAP AIF in place, everything can be monitored from one, single transaction, regardless of the technology. Moreover, the way interfaces are developed is also simplified, because most of the technologies follow exactly the same rules and patterns, so once you learn how to work with SAP AIF once – you can leverage it for most supported technologies. Last, but not least, for most of the cases it’s almost immediately known whether the issue is business or technical oriented and by the same the ping-pong between different departments is reduced to minimum.

4. Oh, it all sounds as if that was a piece of cake. Is it? Really? There must be some challenge involved  when it comes to the SAP AIF implementation?

Mateusz: At the very beginning when SAP AIF is implemented it’s important to describe its architecture very well. It should be understood not only by technical consultants, but also by business consultants. If it’s not done properly it may lead to misunderstandings. Good example of above is the fact that when you use AIF runtime you can get rid of most of the user exits before the final action is done (e.g. before the sales order gets posted with the standard process function module in SAP AIF action). Let’s stick to the example of sales orders. Thanks to moving logic from user-exit (e.g. customer determination based on some tables and logic before sales order is posted) in SAP AIF you can see the original value and the one after mapping. So the challenge here is to make sure that the logic that can be done in SAP AIF – should be done there. Otherwise, there’s no clear picture where exactly the issue occurs – AIF or user exit logic and it slows the error handling process.

5. I would like to create a twist in the plot with this one a bit. (laughter) Wojciech, what kind of question would you like to hear yourself an answer to, in the AIF field, of course?

Wojciech: That would be definitely about the future of AIF, how it is going to fit into the evolving integration landscape. Most importantly, what new features we may see coming to already take them into consideration in ongoing design processes.

6. Even if I wanted, (laughter) I am not able to feed your curiosity on that one, sorry ;). Moving on, do you remember a specific experience of where you wished that you and the customer had done something differently? If you were to do it over, what would you change?

Wojciech: No specific example comes to my mind. However, AIF is very flexible and you may say it’s a blessing and a curse as you get to make design decisions and have to deal with their consequences. It allows you to address challenges in various ways depending if your aim is for example best performance, scalability or ease of maintenance. Then when the time passes you may realize choosing a different approach might have been more beneficial after all.

7. A follow-up to the previous question: By way of comparison, do you remember something you’ve done or something you wish everyone was doing, and why?

Wojciech: It would be a pretty general advice applicable to all projects, planning in advance is the key here. Sometimes customers want to give AIF a try with a small set of interfaces and keep the rest of their interfaces out of the scope (or at least hold information on those other interfaces back). As I mentioned earlier, AIF is all about design decisions, so the more information is available at the planning level the better the design will be.

8. Wojciech, having written the book (together with Mateusz and Krzysztof) you must have come across a number of questions from the readers. Is there any that you are most tired of hearing on this subject, and what would you like to say about it so you never have to answer it again?

Wojciech: And that would be – (laughter) – “If we have AIF, do we still need SAP PI?”. The answer is not that simple and I would need to say “yes and no”. SAP PI is a different tool that serves different purposes. AIF’s goal is not to replace SAP PI but take over the tasks PI is not so good at. On the other hand SAP PI is better suited for other tasks like handling connectivity and traffic routing. So you don’t need both, but having both will give you best results.

9. You have brought the future to my attention and somehow I need to come back to it and ask you about the most critical changes that we must make to face the future effectively.

Wojciech: I think that it would be the mindset of the business support teams. If there is a chance that they do not recognize that AIF is a step in their direction we would need to make them aware of it, that AIF allows them to be more in control of business logic of the interfaces and rely less on technical teams in that regard.

10. To the three of you, What is the best resource for people who want to dive in deeper into the topic of SAP AIF?

Mateusz: I will take this one :), We can definitely recommend visiting our blog, as there are tons of materials regarding SAP AIF. Not to mention that there are two more books related to SAP AIF that we can recommend: Serializing Interfaces in SAP AIF and Mapping with BRFplus Decision Tables and SAP AIF. And it is not boasting off 🙂

11. Is there a question you have expected me to ask you, and I have not?

Mateusz: Yes, yes, yes (laughter) I counted on: What is your favourite part of the book?

12. Apologies 🙂 So, What is your favourite part of the book?

Mateusz: It’s definitely the part where Kris (Krzysztof) has explained how to set alerts based on some key fields. To be honest, I come back to this part every single time I have such a requirement from my customer.

Read also:

1. Test the components that are crucial to your business

2. Is every new project like returning to university?