10 Mar 2020 | Juliane Müller
Implementing your logic with a flow is pretty easy. The flow components contain code which is configured with the help of properties. Connect different flow components until the flow has the desired functionality. It prevents bugs and is much easier to reproduce. Your implemented logic can be understood by following the used components. Even by non-coder. But as soon as your functionality becomes more complex it can be hard to follow and to test certain areas of the code. So has the flow-based programming in Flow Director a certain limit? No! The solution is called Subflows.
Subflows are separately developed flows. Those flows are tagged as subflows and then appear in the flow component library with its defined name. Or in other words: they are flow components created via a flow. They can be included in every other flow by just dragging the component into the editor. But it is not possible to deploy or activate them on the router on their own. Subflows can also include other subflows.
There are two scenarios in which it is recommended to use a subflow. Both are displayed here:
Shown is a flow which listens on the topic 'NewOrder_Arrivals'. It saves the general information in the orderhead, then saves each subscription, and lastly the transaction details. The flow includes four subflows: 'Database_Connection', 'SaveOrderhead', 'SaveSubscriptions', and 'SaveTransaction'.
The first scenario is the outsourcing of a frequently used functionality such as the one of the subflow 'Database_Connection' in the screenshot above. The database connection is required in many flows so it is outsourced and created as a subflow. The functionality is implemented only once in the subflow itself and afterwards the component can be included in any flow. This saves a lot of work.
The second situation is the simplification. In the shown flow each of the subflows have their own functionality. Including the functionality only with non-subflow components in the top-level flow would exceed the limits of readability. It would make it also very hard to test each part individually. By dividing it into three parts and only including the subflow components those problems are solved.
What can we learn from it? Implementing your logic with flow-based programming in Flow Director has no limits! Subflows make the development of your logic easier. You can use them to outsource an often used functionality or just to simplify your flow and make it more readable and testable. Go for it!
After being responsible for the development of flow component libraries, our flow based product backend and the integration of field bus devices into Flow Director, Juliane's focus was on marketing and representing the company.