This workflow pinning example demonstrates how to make sure specific workflows run only on certain engines. In this case, we'll configure Unix workflows to run only on Unix engines, and Windows workflows on Windows engines.
To run this example, you need two Flux engines running. The first engine will represent "Unix" (for the example, it's not necessary to run on an actual Unix machine — we even can run both engines on the same server). The second engine will represent "Windows".
Example requires database
This example requires that both engines are able to access a database that's configured for Flux. See Configuring Flux to run with Databases for more information on connecting an engine to a database.
Running the Example
Open a command prompt or shell, then execute the run-windows-server script. This command starts the Windows server in a cluster, using your database to store the clustered workflow data.
Now open a second command prompt or shell, then execute the run-unix-server script. This command starts the Unix server in the same cluster.
Create a workflow named /unix/unix workflow with a single Console Action. Set the Console Action's Message property to Unix.
Create a second workflow named /windows/win workflow with a single Console Action. Set the Console Action's Message property to Windows.
Now export the Unix workflow to the Windows workflow scheduler engine. Similarly, export the Windows workflow to the Unix workflow scheduler engine.
Switch back to the command prompts where your Windows and Unix servers are running.
Notice how the Windows server ran the Windows workflow, even though that Windows workflow was originally exported to the Unix server. Likewise, the Unix server ran the Unix workflow, even though the Unix workflow was originally exported to the Windows server.
This behavior demonstrates workflow pinning. Windows workflows are pinned to Windows machines, and Unix workflows are pinned to Unix machines. Of course, you can generalize workflow pinning to suit your particular needs.