I recently had to work on a project that involved B2B communication. Our Business partner had a SAP PI system too so we decided to use XI protocol to communicate between the 2 systems.
The key question was – “How Do I design my Business systems/Services”. Ideally I would have preferred to use Service with Party to represent the Business partner. But one of the limitations of using a Service with Party is that it cannot be associated to a Logical system and my scenario was something like this –
My SAP (idoc)-> My PI (Idoc XML on Xi protocol) > Partner PI (idoc) -> Partner Sap
And few interfaces used the reverse scenario.
I needed a service with an associated Logical system name hence I had to rule out service with party.
Once I decided not to use party I still had two options – Use Business Service or Business system. I suggest using Business system if your partner’s business system names changes with the environment (e.g. – ECC_DEV, ECC_QAS and ECC_PRD – use transport target in SLD to map the systems). Since my partner was using a simple environment neutral service I chose Business service and associated it with an LS
The second important question in a PI-to-PI integration Scenario is whether to share the Business system/Service name or use placeholder names. Why is this important?
When you use XI protocol the messages from the first PI system’s Integration engine is directly transferred to the second PI system’s integration. It is like one big pipeline, the messages do not go through the Adapter engine. Hence it is imperative that the Header tag (Sender system/ Interface/ Namespace) of the incoming message reflect an existing Sender system/ Interface/ Namespace of the target PI system.
The simplest solution is that you exchange the Business service names/ namespace/interface with your partner. You create a BS in your PI system with the exact name used by your partner. You can also treat your each Pi systems as BS but that’s just an other layer of abstraction with very little value add.
If either you or your business partner has apprehensions about sharing your internal BS name then use the header mapping option in the receiver agreement. How does it work?
Well , once the message reaches the receiver agreement step in the pipeline , the message header can be changed to reflect either a new sender or receiver or both. This way you can keep can maintain the privacy of your internal Business systems.
Create a Business service to represent your client partner. Ask your business partner to use this name in their header mapping section. For the reverse scenario you have to return that favor – change the Sender section of your receiver agreement header mapping with a name provided by you Business partner.
The Header Mapping section allows you to choose an existing Business system/service in your integration Directory –
You also have the option of entering free text-
And Voila!!! You are all set to transmit messages to your partner.
Remember to ask your business partner to set the Header mapping before they send you messages.
If you are planning to IDOC acknowledgement – ALEAUD messages, Then header mapping cause an issue. I will write about the work about in a following Blog.