Skip to Content
Technical Articles
Author's profile photo Maximiliano Colman

SAP PI B2B Add-on 3.0

Hi guys,

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?:

  1. Dynamic receiver determination
  2. Dynamic interface determination

Let me explain the inbound processing:

Try to imagine the following EDI landscape:

  1. Usage of EDIFACT
  2. 1000 EDI partners
  3. 20 messages types
  4. 50 mapping variants per message type
  5. 5 receiver EDI systems
  6. 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


SAP PI B2B Add-on 3.0 – Outbound

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sugata Majumder
      Sugata Majumder

      Hi Max,

      Is 3.0 out already ?

      Author's profile photo Philippe Addor
      Philippe Addor

      Hi Max,

      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.


      Author's profile photo Maximiliano Colman
      Maximiliano Colman

      Hi Philippe,

      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".

      Kind Regards.


      Author's profile photo Philippe Addor
      Philippe Addor

      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).




      Author's profile photo Maximiliano Colman
      Maximiliano Colman
      Blog Post Author

      Q1: v2.0 is useless, you do not need it at all

      Q3: another use case is the usage of non central adapter engine

      Author's profile photo KOTTIYIL RAMNATH

      Hi Maximiliano,

      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.



      Author's profile photo Philippe Addor
      Philippe Addor

      Hi Ramnath,

      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!:

      Or did you not mean this feature, Maximiliano? 

      Best Regards,


      Author's profile photo Maximiliano Colman
      Maximiliano Colman
      Blog Post Author

      Hi Ramnath,

      Read it in detail the version 2.0, and after that read it again this blog 😉


      Kind Regards.