It is very typical for someone looking at a file orchestration system like Flux to already have a suite of “home grown” scripts that they’ve been using, or other external executables.
The common question that comes from this is: Can Flux call on and orchestrate these external executables that are already in place?
Flux has customers that call on command line executables, Powershell scripts, bash and other shell scripts, SQL scripts and DDL commands, Oracle Financials, Hyperion, Actuate, and a whole bunch of other applications by using Flux Process Actions.
An Overview Of Flux Process Actions
The Process Action, also known as the “Command Line Action”, can execute command line programs, batch files, scripts, and, more generally, any native program.
You can run processes in the foreground, with the workflow waiting for the Process Action to finish running before moving on. Or, you can run processes asynchronously in the background, with the workflow moving on immediately while the Process Action continues to run.
If the process prints output to standard in (stdin), standard out (stdout), or standard error (stderr), you can configure the Process Action to store that output in a file, or you can direct that output to the engine’s standard out / in / error.
You can set the process’s working directory and its environment, allowing you to control when and how the process is executed.
You can indicate whether the process should be terminated if a user interrupts the workflow, if a signal is raised, or if the action times out.
You can also configure if (and when) the Process Action should invoke Flux’s Error Handling mechanism by setting an exit code or codes that indicate that an error has occurred.[columns] [one_full class=”center”] Dig Deeper Into Flux Process Actions [/one_full] [/columns]