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.
Usage
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:
Features
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!
Installation
Chrome Extension Install:
https://chrome.google.com/webstore/detail/mdpgroup-supereasy-extens/nbeijdcbojmlpnhdikiebpdkikkmkljh
Microsoft Edge(Chromium-based) Extension Install:
PS: You can drag them around for fun!
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,
Raffael
Hi Raffael,
Thank you for the actionable feedback! I'm always open to wishes 🙂
For a solution:
Best regards,
Fatih Pense
Hi Fatih,
great idea and great tool! 🙂
Hello Dominic,
Thank you for the feedback!
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,
Malte
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,
Fatih
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.
Regards,
Fatih