SAP PI B2B Add-on 3.0
I’m a humble integration consultant who wants to share my experience after to see all the “new features and amazing changes” included in the SAP PI B2B add-on 2.0, let me say that my first and last impression was the same disappointing, so for that reason with a couple small adjustments( seriously only 2 ) I made a better version of it 🙂 ( hopefully someone of SAP is reading this )
So what would you said if the “SAP B2B Add-on” provide the following features?:
- Dynamic receiver determination
- Dynamic interface determination
Let me explain the inbound processing:
Try to imagine the following EDI landscape:
- Usage of EDIFACT
- 1000 EDI partners
- 20 messages types
- 50 mapping variants per message type
- 5 receiver EDI systems
- The routing of the messages must be per agreement(IDs & message type)
Could you imagine the complexity of ESR & IB for this landscape?, How could you create it?.
The answer is the usage of Service interfaces with multiple operations for EDI & IDOCs, Functional profiles and custom dynamic properties
This is a common inbound agreement defined in TPM, with the assignation of a Functional profile:
The Functional profile contains two different templates:
B2B_RECEIVERS: with the properties “RECEIVER_PARTY & RECEIVER_COMMUNICATION_COMPONENT” , this values will be used in the dynamic receiver determination
B2B_MAPPINGS:with the property “MAPPING_VARIANT” , this value will be used in the dynamic interface determination
The following screenshot demonstrate how your IB could look after the implementation of the dynamic receiver & interface determinations:
001-Inbound:You have the technical connections from the partners to your SAP PO system, so you have 1 per technical connection( nothing new here )
002-Forward messages to EDISEPARATOR:You have a unique ICO to receive all the EDI files and send to the EDISEPARATOR( nothing new here )
003-Execute mappings:Here is where all the magic happen
You have a unique ICO with a Service Interface with multiple operations (one per EDIFACT message type) with a sender communication channel who will handle all the EDIFACT message types
In the EDISeparator sender CC you must create the logic in a custom adapter module to pick the correct agreement & finally the functional profile to put the “RECEIVER_PARTY & RECEIVER_COMMUNICATION_COMPONENT” & “MAPPING_VARIANT” as a custom dynamic properties :
After that we can use those custom dynamic properties in the receiver determination step:
And of course you can use the latest custom dynamic property to execute the corresponding mapping variant:
004-Deliver messages to Systems:You need one Receiver Agreement per receiver EDI System and use a Service Interface with multiple operations( one per IDOC ) to deliver all the IDOCs
So… How many Service Interfaces you need to handle this EDI Landscape?, 1 for all EDIFACT message types and 1 for all the IDOCs
How does it look in the A2A monitor?:
How does it look in the B2B monitor?:
Am I the only one who believe that these two features must be included in the standard “B2B Add-On” as part of the agreement in TPM?.
Not forget, be curious! 😉
Note: Same approach using CPI –> link
Is 3.0 out already ?
Definitely an inspiring approach, and I agree that TPM is unfortunately not mature. Even SAP says so unofficially...
My approach for the Receiver Determination is similar. I use an extended RD to access the Agreement and Functional Profile via a mapping and read the configured receivers in the FP.
But to your solution I have some questions:
1. You write "we can use those custom dynamic properties in the receiver determination step". You also use it in the Interface Determination Condition. However, I don't see a possibility to access Dynamic Configuration Properties in the Receiver and Interface Determination. I also tried creating a Context Object but couldn't figure out how to access the DC neither. How did you do this?
2. After point "004-Deliver messages to Systems:": Don't you mean "one Receiver Agreement per Receiver System" instead of "one ICO..."? That would correspond with your screenshot of the Directory.
3. Why do you need Iflow 001 (Inbound)? I do the same basically in (your) Iflow 002 and send incoming messages directly to the EDI Separator receiver (using Dummy Message Types for Out- and Inbound IFs). In Iflow 002 I also use a Generic Sender Interface with Operations per Message Type.
I got this solution because I dislike a lot solutions like yours( sorry for the honesty- but it was the only solution till mine 😉 ), everything should be done dynamically from the "TPMContentAccessModule" or custom adapter module.
About your questions:
1-That is the biggest trick here, and if you reach this point you deserve to find it yourself, I challenge you to analyze the adapter metadata for the EDISEPARATOR, and you will discover what SAP missed there from the version 1.0 and you will understand what are the DC.
2-I adjusted it long time ago, It was a typo.
3-Well, the idea behind it is that you can have multiple sender channels( multiples ICOs), and you need to decouple that from the EDISEPARATOR receiver channel, you will have N ICOs for "001 Inbound" but you only will have one unique "002".
To Q1: Ah I see, you wrote this blog to challenge us to come up with the essential wisdom by ourselves ;-). That’s new to me on SAP Blogs, but I would accept the challenge. However, the lacking information for me was that this is something that improved from v1.0 to v2.0. Since I currently only have access to a system with B2B v1.0, I’m afraid I can only figure it out after a later upgrade.
To Q3: Well, not sure if I get you right, but couldn’t you just create the ICO with a wildcard sender, then create one Sender Agreement per channel. Like that you can bind multiple sender channels to the first ICO (and hence to the EDISEPARATOR, so to say).
Q1: v2.0 is useless, you do not need it at all
Q3: another use case is the usage of non central adapter engine
I have already done this using B2B Addon 2.0 with a single ICO for multiple partners. There are always different ways on how to design your objects and it would be naïve to say, if someone has not posted a blog saying so, doesn't mean its not been done already. Anyways, I can share ID objects history which shows you the proof if you want one.
Also, To Philippe, I agree to you on what you have said. Also, Try out the new B2B Addon 2.0, its a gem. You will definitely like it.
Thank you for encouraging me to look in to B2B 2.0. In fact, I learned that the above mentioned dynamic routing is indeed a feature of version 2.0, as described in the following blog as first point!: https://blogs.sap.com/2018/12/20/sap-process-integration-business-to-business-add-on-2.0/
Or did you not mean this feature, Maximiliano?
Read it in detail the version 2.0, and after that read it again this blog 😉