Best Practices – Development Patterns

Design Patterns

Design Patterns

This blog is a part of my best practices series for SAP PI/PO integration.

Whenever you are developing something, you need to have some design patterns. Design patterns are needed by your organization; you must develop them according to the various options you wish to have. They will make it easier for other developers to perform the same kind of operations because you already know what the package should contain. You will need to build this type of patterns in your organization.


According to, there are 65 different design patterns that cover integration. In most integrations, you will probably have to combine many of these. The website does provide a good list regarding the possible starting points of your integration.


In a lot of situations, you have multiple integrations of the same type, e.g. if you had a way of integrating from a website to the ERP (Enterprise Resource Planning) system, you would probably have several identical connections – it therefore make sense to experiment with making one of the functions work first, so you can make sure that everything will operate properly.


The common patterns I see are the following:


IDoc to File/MQ/Database is one of the most common scenarios, in which the SAP system feeds data to a 3rd party system. It is efficient in that it allows the data to reach the other systems without having to worry about updating the SAP ERP system, which can sometimes pose certain challenges to finding the correct flow.


The synchronous connection, in which a 3rd party connection is trying to access the ERP system through something like an SOAP to RFC/Proxy, is a quite simple scenario to configure, and the only thing you have to consider is the mapping and the WSDL (Web Service Definition Language) the user will see. The newer version uses the REST or OData protocol. Then, there are options where you can skip using the SAP PI/PO system, and just use the Gateway services. It depends on whether you already have Gateway (and whether you will use it for multiple scenarios).


Another pattern I often see is the collect pattern, where you want to group your messages into one message and send them as a bundle. This is quite useful in B2B scenarios, where there is a cost per message you send, or internally, where you want to improve the performance of your message processing. Previously, this was something that required a ccBPMN to achieve, but since this is now mostly used in IDoc scenarios, it stands as an example of a pattern that has changed over the years, making it faster to develop and run scenarios.


There are obviously situations in which you need to have a process in place, in order to handle different requests. Whether you are using ccBPM (Business Process Management), or the newer NW BPM, you don’t want to use them all the time. There is a cost involved on the performance side if you use these processes; therefore, in some situations, you want to avoid heavy usage because it will have an impact on performance.  


I had a conversation with a customer who wanted to have a lot of SOAP (Simple Object Access Protocol) lookups to enrich the messages. It is a thing that you can perform: you can use the BPMN (Business Process Model and Notation) to perform the lookups. The BPMN method takes time, and it can be a bit more challenging to work with; it also costs some more in the area of performance. The positive thing about it is that it makes it easier to understand what is going on. The other approach is to use the Lookup API (Application Program Interface) in your mappings to figure out how to look up values.


My take on this issue is that if it is some small data type that you need, it will be best just to create a lookup, whereas if you are going to use full XML (Extensible Markup Language) structures, then it will probably be better to do this in BPMN.


Another pattern is focused on the connection with third parties. There are a few protocols you can use for these connections. I think an important aspect of these is figuring out which is relevant for your organization. AS2 (Applicability Statement 2) and SFTP/FTPS (Secured File Transfer Protocol) are great examples of good, secure protocols. AS2 is the most secure because you get a receipt of the delivery per message. This is a good way of exchanging transactional messages, such as exchange of orders or invoices.


You may also consider having an SOAP or REST interface that your partners can call. It is obviously a choice between the types of communications that are being used for integration with cloud systems, which need a direct connection with your system or mobile client. You can have an even wider variety of choices if you want some API tools to allow 3rd parties to use your data. If you allow any HTTP (Hypertext Transfer Protocol) traffic to your sites, I recommend that you have some kind of a filtering proxy in front of your systems.


I wanted to illustrate this with some images of the patterns but I really could not find a good way of showing you what was going on (in a way that would have made sense).


Developing patterns for your organization can be very engaging. I think it is a great idea to keep an index of the different design patterns you are using, so that new developers can also develop in your landscape faster.


Do you enjoy developing patterns? Do you keep your patterns organized in an index? Let me know in the comments section.

For the previous posts in the Best Practices series, check out the links below:

Part 1:

Part 2:

Part 3:

Part 4:   

Part 5:



  • Pranil Shinde

    August 24, 2015

    You have mentioned in one para that customer wants to use lot many SOAP lookups.

    Use of lookups affect the performance to great extend.

    So did you try to convince him not to use lookups or you also feel lookup is good option?


    • Daniel Graversen

      August 24, 2015

      It is best not to use lookups if possible and then have the information in the source or target system. If you dont have that option you need to have lookups.
      And my suggestion is to use the lookup api if possible because then you dont have the BPMN overhead. I would create some UDFS that could perform the lookup. And then if they are a performance drain i may consider using some homemade caching on it.
      Loopkup and SAP conversion may be an option with AIF, which my be the best choise for conversions.