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

CPI – B2B – make it dynamic

Hi Guys,

Last week I had the opportunity to write a blog related to user dynamic receiver & interface determinations using SAP PO in the B2B world ( link ) and this week I want to share the same approach using CPI 🙂


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)

Can you imagine this landscape following the ICA approach in your CPI tenant?:

Personally I can not imagine it, everything fixed, no isolation, no re-usability of the mappings or connections, in another words it will not work the real life scenarios.

So why not separate the IFLOWs in the following way:

1-Sender IFLOWS: these IFLOWs only receive data from your company or partners to the EDI system

2-Receiver IFLOWs: these IFLOWs only send mapped data from the EDI system to your company or partners

***for test purposes I deleted the receiver system

3-Mapping IFLOWs: these IFOWs only execute a mapping( EDI2XML or XML2EDI )

*** for testing purposes the mapping is putting in the body the result of the following camel simple expression: “${in.body} – ${header.mapping_iflow} – ${header.receiver_iflow}”

4-Receiver Determination IFLOW: here is where all the magic happen, based in the context you must determine the mapping & receiver IFLOWs, so you need to extract the context data that you need like identifiers & message type, and you can execute a lookup wherever you want to get the mapping & receiver IFLOWs:

  • Value Mapping
  • Business Rules
  • Partner Odata API
  • Custom Service
  • TPM???( our dream )


***for the proof of concept I’m using http headers to decide which is the mapping & receiver IFLOWs must be executed


Let’s do some tests:

So if you use the endpoint of our Sender IFLOW, adding the two http headers “mapping_iflow” & “receiver_iflow”, and a dummy payload you will see all the magic in runtme:

After a few tests changing the http headers you can see the IFLOWs executed in the message monitor:

Test 1:

Test 2:

Test 3:


What do you think about this approach?.


Not forget, be curious! 😉


Assigned Tags

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


      Why not just have one main flow that calls out to mapping  steps with process direct  syncronious.

      For receiver party, call you will then just has the information for the receiver.

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

      Hi Daniel,

      Because I wrote it in 30 min 🙂 , i made the adjustment and it's working as expected, thank you for your comment.


      Kind Regards.