If you are someone who has been working with the PI dual stack architecture and has now moved to SAP Process Orchestration or you are starting to work with the Process Orchestration suite, this article looks at providing the basic building blocks for developing Integration centric processes. The focus here will be on certain aspects of SAP BPM and what you need to keep in mind for the end to end integration scenario configuration in SAP PI.
1. Netweaver Developer Studio Version
You will be developing/modelling your Process in the Netweaver Developer Studio. You need to ensure that the NWDS version you are using is the same as that of the Process Orchestration release. This will help avoid errors that might crop up during deployment of your process to the server.
Ex. If SAP PO is on release NW731 SP10, then you will use NWDS 7.3 EHP1 SP10 for your process development.
2. Outbound, Inbound or Abstract Service Interfaces?
If you are on 7.31 SP09 and above, then you can use abstract service interfaces to send and receive data from BPM. This is no different from ccBPM in the PI dual stack.
If you are on a service pack below 7.31 SP9, then its a completely different story. In very simple terms, you will use;
a. For messages going into a process (i.e PI -> BPM), use an Inbound Stateless (XI30-Compatible) service interface
b. For messages coming out from a process (i.e BPM -> PI), use an Outbound Stateless service interface
The below figure should simplify this concept further. In the figure, we have assumed a sample process that requires two messages as input and the process will trigger two messages as output.
3. In and out of BPM with XI 3.0
Your BPM process once deployed can be linked to a business component in the integration directory. Thus the BPM process is treated as a Sender or Receiver system in your configuration (i.e Integration flow). You will use the SOAP Adapter with XI 3.0 Protocol as the corresponding Sender or Receiver adapter.
Apart from using the business component in your integration flows, it will be referred inside the Process as a Sender component in the service reference configuration for your Outbound Service interface or the Abstract Service Interface that will send data out of the Process.
Note: Further details in point 5
4. Integration Flows – How many do I configure?
Every flow in and out of the process will be modeled as an Integration flow. If we take the earlier figure and break it down into individual flows, there would be a total of four Integration flows to be configured;
a. PI to BPM – Message A
b. BPM to PI – Message B
c. PI to BPM – Message C
d. BPM to PI – Message D
5. Service References
You only need to create a service reference for those Service interfaces that are used to Send data from BPM to PI (Outbound Stateless SI). The inbound (PI to BPM) Service Interfaces do not need a service reference and if there are any created as default, these can be deleted.
6. Error Handling
You can refer this blog for details.
Hope this quick read will prove to be helpful for many who are looking to shorten their learning curve and have some Integration centric processes up and running