Skip to Content
Technical Articles

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

You must be Logged on to comment or reply to a post.
  • 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.


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


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




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