Skip to Content
Technical Articles
Author's profile photo Fatih Pense

Two Types of CPI Mapping Flows

“Mapping Flow” is a concept in CPI that should be more popular. It is useful for the following reasons:

  • Organize your complex mapping logic in one place
  • Reuse your mapping from different flows
  • Easier to test, without involving sender or receiver systems

What is a “Mapping Flow”?

Basically, it is a flow that accepts ProcessDirect connections, applies any number of mapping steps, then returns the result back or calls another flow with the result. Based on this distinction, we can group them under two categories. Here is a diagram explaining the scenarios:

  • Each arrow is a ProcessDirect connection
  • Arrowheads illustrate only request message flow, response is not shown in the diagram
  • Processing is started with Sender Flow
  • Each color is a complete process from sender to receiver

Request-Reply Mapping Flow without Receiver

This type is the simpler one if you can use the sender flow to route message to all required receivers. You can combine the routing logic into the caller flow.

Here is a basic example:

1 ProcessDirect Adapter Sender Flow will use this address. To be able to test this flow you can just create another flow (HTTPS) -> (ProcessDirect) and give this address to the receiver.
2 Flow Body

Flow can have one or many mapping steps together. You can use Message Mapping, XSLT, Groovy, etc.

Serial Mapping Flow with Receiver

This is useful if you want to delegate the routing to mapping flows and have dynamic chaining flows.

1 ProcessDirect Adapter Same as Request-Reply Mapping Flow.
2 Flow Body Same as Request-Reply Mapping Flow.
3 Router

This router enables testing, you can create another Flow triggerred with HTTPS and point to this flow with the right headers. Then, you don’t have to worry about the receiver system.

Example Non-XML route configuration for test messages (ending the processing). The logic can be the absence of receiver flow:

${header.receiver_flow} = null

Or if you specify a header in the Test Sender Flow:

${header.test_run} = 'true'

Routing Condition example:

4 ProcessDirect for Receiver You can make it dynamic. The value can depend on a header that comes from Sender or mapping result.



I wonder your experiences and ideas using Mapping Flows!

See you in the comments & in the next posts!

Assigned Tags

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

      I've never thought of having separate mapping iFlows. I've never come to the situation that mappings were re-used though. Something that bothers me about using ProcessDirect is the lost of properties that aren't in the header. I use those quite a lot and it happened to me that I didn't take into consideration that those aren't available in the ProcessDirect flow.

      I just came across your test tool for mapping:

      That would be a good reason to start using mapping iFlows!

      Author's profile photo Fatih Pense
      Fatih Pense
      Blog Post Author

      Hi Christopher!

      I agree, it is annoying that properties are not passed. I searched for an explanation in the Camel world and this seems to be the reason. If the message is passed to another endpoint, exchange and related information like properties are lost.

      I like the reusability aspect and also the separation of concerns for the flows. But it can be overkill for most integrations.

      I released the test tool as open-source, based on the reception I can improve it more. I think people want something that can be used without much overhead & black terminal screens. Maybe there can be a test solution with a UI in the future 🙂

      Also, there are 3.5 different technical approaches for iFlow testing I can count. I would love to discuss their pros & cons over a cup of virtual coffee.