-
Notifications
You must be signed in to change notification settings - Fork 8
Writing flows
The flows for Cascades can be written using one of the coordination language formats:
The syntax of the FBP DSL is very simple. Consider the following example:
'some data' -> PORT ProcessName(ComponentName)
Here some data or in terms of FBP Initial Information Packet (IIP) is sent to a process named ProcessName based on component ComponentName using its input port called PORT. We ->
to define a connection between the building blocks of the flow.
ProcessA(ComponentA) OUT -> IN ProcessB(ComponentB) OUT -> IN ProcessC(ComponentC)`
In the example above we have defined two connections in a single line. Once ProcessA, ProcessB and ProcessC are defined we can use them in other parts of the flow:
ProcessA ERR -> IN Log(Console)
ProcessB ERR -> Log
ProcessC ERR -> Log
As you can see from above we use only process name to refer to the same process defined above.
Array ports are named ports that have indices. Each index is a separate port and can be connected independently. This feature allows to have a dynamic number of slots in a component without chancing its source code and re-compilation. An array port can be used as an input and as an output port of a component.
Ticker1(Timer) OUT -> IN[0] Mux(Merge) OUT -> IN Log(Console)
Ticker2(Timer) OUT -> IN[1] Mux
Ticker3(Timer) OUT -> IN[2] Mux
In the example above we connected three timers into an array port of the Mux process.
One of the FBP features besides the power of configurable modularity is a step-wise decomposition using so called subnets or subgraphs. We can design a flow and make it re-usable in the future, become a part of a large flow. For this purpose we need a way to export input and output ports so the flow can be used as any other black box component.
Consider creating a file subticker.fbp with the following definition:
INPORT=Ticker.INTERVAL:OPTIONS
OUTPORT=Forward.OUT:TICKS
Ticker(Ticker) OUT -> IN Forward(Passthru)
Here we are exporting the input port INTERVAL of the process Ticker under a new name OPTIONS. The output of the Forward process via its OUT component is exported under TICKS name. Then you can use this flow (after registering it in the Components Library as described in Manage components library) in other flows:
'15s' -> OPTIONS NewTicker(subticker)
NewTicker TICKS -> IN Log(Console)
Without looking into a source code of each component we cannot see if it is an elementary component or a composite one (so called subnet).
The JSON representation of the flow is documented in the NoFlo's JSON Documentation. Writing JSON by hand is not the best programming experience. We have added JSON support to Cascades only to be able to use third-party visual tools such as NoFlo UI.
A typical ticker example flow written using NoFlo's JSON:
{
"properties": {
"name": "Send tick via passthrough to the console"
},
"processes": {
"Time Ticker": {
"component": "core/ticker"
},
"IP Forwarder": {
"component": "core/passthru"
},
"IP Logger": {
"component": "core/console"
}
},
"connections": [
{
"data": "5s",
"tgt": {
"process": "Time Ticker",
"port": "INTERVAL"
}
},
{
"src": {
"process": "Time Ticker",
"port": "OUT"
},
"tgt": {
"process": "IP Forwarder",
"port": "IN"
}
},
{
"src": {
"process": "IP Forwarder",
"port": "OUT"
},
"tgt": {
"process": "IP Logger",
"port": "IN"
}
}
]
}