SAP Process Orchestration, SAP Process Integration

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 created a better version of it

Read More: SAP PO Certification Preparation Guide

So what would you said if the “SAP B2B Add-on” provide the following features?:

1. Dynamic receiver determination
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 ICO 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?.

Leave a Reply

Your email address will not be published. Required fields are marked *