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

 

Max.

 

Note: Same approach using CPI –> link

1 Comment
You must be Logged on to comment or reply to a post.