Search Crosser Knowledge Base

Flow-to-Flow Communication

Nowadays it is important to react to new requirements in a fast and efficient way. As a result, Flows that represent your processes or address certain issues, usually evolve over time and end up more complex than initially expected. The more complex a flow becomes the more difficult it can become to debug it. 

One way to address this is to separate your flow into smaller chunks and bind them together with the concept of Flow-to-Flow communication, leveraging the built-in MQTT broker in the Crosser Node.

Another advantage of this concept is that you can decouple data acquisition from processing, storing data into a data-sink, or react on data in a different process.

In addition this concept allows you also to update modules and configurations in one flow without interfering with other deployed flows.

Let’s take a look at one example:

Your flow subscribes to data from OPC UA, transforms it and saves all raw data into an on-prem database. In addition you send process metrics to your Cloud environment in case a certain threshold is reached and trigger a notification to an external system in case the production order is finished.

You could break up your use case into four flows:
1. OPC to MQTT
2. MQTT to on-prem database
3. MQTT to Cloud
4. MQTT to Slack

-- same concept works perfectly fine across several Nodes.

If you want to know more check out the following knowledge base article.

https://www.crosser.io/knowledgebase/flow-to-flow-communication-article/

About the author

David Nienhaus | Senior Solution Engineer

David is a Senior Solution Engineer at Crosser. He has over 10 years experience working with software integration and digitization projects for critical infrastructure.
His engineering background gives him the understanding and focus needed to solve customer use cases in the most efficient and successful way.