Skip to Content
Technical Articles

Visually See ProcessDirect Call Dependency for CPI Flows

ProcessDirect adapter enables the modularization of your integration packages. Flows can call each other creating n:m relationships. Basically, they form a graph. I thought it would be fun and useful to actually see this graph.


First, you should install SuperEasy Browser Extension for SAP Cloud Platform Integration. You can find the links below.

Open SuperEasy page:

Start the process by clicking the button:

It’s processing…

And then you can see the graph! When you click on a node(flow) you will see the flow details:

Example Flow

Let’s have a look at a standard SAP flow: “Route Idocs From ERP To SAP Commerce Cloud” in the package “SAP Commerce Cloud Integration with SAP ERP”

You can see this flow leverages ProcessDirect adapter nicely:

This flow should have many outgoing arrows! It is our popular green node in the graph. When we click on the circle we can see its details and ProcessDirect configuration:


Flows in the same packages have the same color. If you have more than 9 packages that have flows with ProcessDirect calls, they can share colors. Finding good distinctive colors is a hard problem.

Currently, configure-only packages are not analyzed.

Nodes which are not connected can mean:

  • Sender adapter is used and there are no incoming ProcessDirect calls to this flow.
  • Sender adapter is used and other flows call it with Dynamic address using Camel simple script. For example ${header.address} . Usual suspects are flows which have an outgoing connection to the “Dynamic Node”
  • There is a bug regarding old packages 🙂

There are three special gray nodes in the graph:

Empty Node

Shows that the receiver adapter address is empty and should be configured. You probably don’t want flows connecting with this node.

Not-found Node

Shows that there is no flow with the sender adapter configured with the address. Again, you probably don’t want flows connecting with this node.

Dynamic Node

Shows that a Camel simple script is used for the receiver adapter. Based on your development decisions this node can have many connections!


Microsoft Edge(Chromium-based) Extension Install:


PS: You can drag them around for fun!

You must be Logged on to comment or reply to a post.
  • Hi Fatih,

    this is a prettty nice add-on to the existing functionality of your plugin! Maybe you guessed it already - if I had a wish... 😉 A nice-to-have upgrade on this function would be the ability to zoom-in into the point cloud. At one of the tenants I'm working on, the graph had over 50 nodes, which made it really hard to click the single dots.

    Best regards,

    • Hi Raffael,

      Thank you for the actionable feedback! I'm always open to wishes 🙂

      For a solution:

      • I will look at zoom-in and out. Maybe I have to make dots smaller.
      • This graph type is useful for exploration and fun. I also had other types of graphs in my mind to get something more documentation-like.
      • Maybe choosing a single package and filtering only the relevant flows can be useful.

      Best regards,
      Fatih Pense

  • Hi Fatih,

    really cool idea and implementation. I thought by myself to implement something like this as we have a lot of dependent iFlows.

    I agree with your idea on filtering the view to improve the visibility of single processes. And if I could wish a feature than I would like to add JMS queues also to this view.

    Best regards,

    • Hi Malte, thank you for the feedback!

      JMS queues would be interesting. I think the best way to show them would be using the same graph but making the links in a different color.

      Feel free to provide any details that work best for your use case. We can also talk about it when I release a version that includes JMS queue connections.

      Best regards,

      • Hi Fatih,

        I think in a first step it would be enough to have JMS "connections" in a different color. This already would enable us to the view our complete scenarios. However, from my perspective also some filtering on iFlow/Package level to de-/activate iflows and their relations would be highly appreciated.

        Just to give you some background:
        We have one iFlow which is used for alerting from nearly all exception flows. In consequence we have some kind of a star of all iFlows, which overruns nearly all other dependencies. (Here a screenshot of our test environment:


        When we could deactivate the iflow in the center of the right circle we could better see the rest of our dependencies.

        Best, Malte

        • Hello Malte,

          Thanks for the explanation and image. It illustrated the issue better. I have updated the extension with the flow and package filtering options. Here is the blog post

          Still, deactivating a particular iflow can be useful. If that makes your workflow easier I can consider implementing the feature.

          Since it is a tool for power users, I think it can have more options for different situations.