Announcing Flux 8.0.13

Flux 8.0.13 continues Flux’s commitment to providing strong value within a reasonably priced solution to the workflow marketplace. Flux 8.0.13 improvements simplify the development, deployment, migration, and monitoring of your enterprise’s batch processes. Its new user interface, named ‘Flux Cockpit,’ offers a lean, flat, and consistent user experience. Default settings and new layout features allow you to construct, test, and edit workflows quickly. Improvements in navigation make identifying issues easier, and getting to resolution faster. Whether you’re running a few workflows per day, or thousands of workflows per day, Flux 8.0.13 offers new capabilities to make your task easier and simpler.

Restyled User Interface (Flux Cockpit is now the primary user interface)

The Flux Operations Console has been replaced with the Flux Cockpit as the default Flux user interface. The legacy Operations Console is still available by selecting the link at the bottom of the Flux login dialog. Here is a screenshot of the new Dashboard. Cockpit allows batch operations such as pause and remove on workflows, and quick access to the audit trail, run history, and log entries for selected workflows.

flux cockpit user interface

Configuring Cockpit for Access

After installing Flux you will need to edit the file fluxConfig.js in the webapp folder for Flux if your browser is not connecting to your server as ‘localhost’.

Here is an example setup:

//Set the cockpit connection parameters here – and default username and password
hostName = ‘flux-rcs’; // Specify this host name or IP address of the host running the ops console webapp
opsConsolePort = ‘7186’; /// or something like ‘8080’. Default is 7186
engineHostName = “flux-rcs”; // hostname or IP address of the Flux engine itself
enginePort = ‘7520’; // default engine port
contextPath = ”; // or something like ‘/flux’ if deploying in a webapp server like Tomcat
var username = ‘admin’;
var password = ‘admin’;
// End of parameter settings

The restyled Flux Designer improves upon the existing designer, adding copy/paste functionality as well as more consistent action and property dialogs.

flux designer user interface

Still to come …

Note that certain features from the Legacy Flux Operations Console have not yet been ported to Flux Cockpit. This includes uploading PGP keys and Flux custom actions. The File Test Dialog has also not yet been ported. If needed, these facilities can still be used in the Flux Operations Console.

Updating and maintaining Flux engine and agent configurations will not be ported to Flux Cockpit. Almost all customers maintain these using the supplied engine and agent configuration properties files.

Graphical Status View of Workflow

By clicking on the status column for a workflow in the Dashboard, a graphical status is rendered showing the states of the actions within the workflow. The status view below shows the workflow is in a WAITING state on a timer event, and the grayed-out actions have been completed and their last execution information is shown.

Improvements to Audit Logging

Additional audit trail events have been added to better track Flux activity such as repository actions – all available from the Cockpit user interface.

flux audit logging

Workflow Provisioning

One of the features of Flux 8.0.13 is the ability to ‘provision’ a workflow when it is submitted to the engine. Provisioning sets variables in the workflow using a displayed form added to the workflow. The form layout is simple but the feature significantly increased the power and flexibility of Flux workflows. The form itself is a JSON string. For example, the following JSON string creates a form prompting the user for the Start Date, Mail To, and Time Expression for the workflow. The form variables are uppercased when added to the Flux Engine, so the workflow variables from with Flux (using the example below) would be STARTDATE, MAIL_TO, and TIME_EXPRESSION.

flux workflow provisioning

To add the above form to a workflow, create and save a workflow variable named PROVISIONFORM when editing the details of a workflow (i.e., editing the Workflow Variables at the bottom of the select ‘Edit Details’ dialog) after opening a workflow in the Cockpit designer.

When submitting a workflow on the repository tab to the engine:

If a provisioning form is present in the workflow, Flux automatically renders the provisioning form for input:

Entering the fields and pressing the submit button submits the workflow for execution on the Flux engine.

Upgrading Flux 7.x Flowchart (.ffc) Files

Flux Cockpit now will upgrade older format ffc files into Flux 8 format. Workflows containing Flux Messaging, since it has been removed, cannot be upgraded. Make sure any custom jar files or custom code has been updated for any Java API changes in order to ensure the upgraded workflows will work as expected.

Export or collect the .ffc or .xml files from an older version of Flux, and upgrade them to Flux 8 format using the ‘Upgrade’ button on the Cockpit Repository tab.

The workflows are upgraded and loaded to the repository. During the upgrade the workflows are graphically rearranged also. Old workflow layouts are not preserved.

Predefined Server Definitions

Flux Cockpit supports saving File Transfer server definitions in the runtime configuration file, and making these definitions visible when creating workflows involving file actions.

Be careful to avoid carriage returns and line feeds in the server definitions.

The server definitions are stored as JSON strings in the runtime configuration file, and look as follows. Note that no carriage returns or line feeds are allowed so the second bullet is a very long line in the runtime configuration file.

  • /Server1.LocalHost={‘Local Host’:{‘Local Host’: ‘Local Host’}}
  • /{‘Secure FTP Host’: {‘Secure FTP Host’:’Secure FTP Host’,’Name’: ‘’,’Port’: ’22’,’Username’: ‘sfluxly’,’Password’: ‘==Encrypted’,’Transfer Mode’: ‘BINARY’,’Issue CD Commands Mode’: false,’Passive Mode’: true,’File List Parser’: ”,’Private Key Filename’: ”,’Private Key Passphrase’: ”}}

When a file action is displayed in the designer, those entries that start with /SERVER are shown in the Predefined hosts dropdown.

When a predefined host is selected, its values are copied into the workflow and saved. Later changing the runtime configuration file will have no impact on already configured hosts existing in workflows. To get around this limitationyou can embed in the server definition runtime variables which are resolved when the workflow executes. For example, the following definition configures SERVER2 at runtime with a set of runtime variables.

  • /{‘Secure FTP Host’: {‘Secure FTP Host’:’Secure FTP Host’,’Name’: ‘${DOCSERVERNAME}’,’Port’: ’22’,’Username’: ‘${DOCUSER}’,’Password’: ‘${DOCPASSWORD}’,’Transfer Mode’: ‘BINARY’,’Issue CD Commands Mode’: false,’Passive Mode’: true,’File List Parser’: ”,’Private Key Filename’: ”,’Private Key Passphrase’: ”}}

Of course you would then need to define runtime configuration variables for DOCSERVERNAME, DOCUSER, and DOCPASSWORD for the above to work.

  • /
  • /DOCUSER=sfluxly
  • /DOCPASSWORD===Encrypted

REST API to Remove Workflow Run History for a Specific Workflow

This feature allows removing a specific workflow’s run history. This is useful as a precursor to collecting new history for a recently updated workflow. This API is called from a button on the Cockpit Dashboard to perform this remove interactively.

Workflow Form to Request Input

In a Flux workflow, the Manual Trigger can have a form added to it to request user input. This feature is different than the Workflow Provisioning feature mentioned earlier in that the form is within the flow of processing of the workflow, as opposed to providing data at the submission of a workflow as Workflow Provisioning addresses. A Sample form description is shown below.

When the Manual Trigger is reached in the Workflow, it presents itself for being ‘Claimed’ in the Claim Tab of Flux Cockpit.

When claimed, the form renders itself, accepts the user’s input, and it can then be submitted or cancelled or bypassed. If submitted, the variables in the form are added to the Flux flow context for downstream processing, and are acceeible to Flux actions further in the flow, such as database actions or REST actions.

Flux Form Editor

A Flux Form Editor is provided to design, view, and validate forms before adding them into a Flux workflow. Form descriptions are based on JSON Schema. The form editor, in a default Flux installation is available at http://FluxServerName:7186/FormEditor.html.

Improved Flux Cluster Performance

A Flux cluster consists of multiple Flux engines. If workflows are configured to run on any available Flux engine, and the schedules for many jobs are identical (like run 500 jobs all at 12 noon) there can be database contention over claiming jobs for execution. This is due to each Flux engine fetching the same jobs from the Flux database in the exact same order as the other engines. This specific performance improvement returns the selected workflows in random order (within the time they are expected to fire) to each engine to reduce the contention over job selection. This yields a noticeable improvement in overall performance for Flux clusters.

Note: this improvement is not used if Flux Cluster_Networking is enabled. In such instances the cluster networking itself reduces such job contention.

To enable this feature the following setting must be set in the Flux engine configuration properties file and the engine restarted:


Optionally Showing Completing Workflows on Dashboard

Flux by default rolls completed workflows off of the dashboard as they complete. Flux 8.0.13 allows completed workflows to remain on the dashboard if desired. This is particularly useful for testing and reviewing workflows during development. To enable this feature the following setting must be set in the Flux engine configuration properties file and the engine restarted:


Improved Integration with Version Control Systems

Flux now writes and overwrite workflows into a VCS managed directory for VCS control, or Flux simply saves the workflow with a timestamp appended to it, or both, or none. This event occurs after a successful save to the Repository. In prior version of Flux, the workflows were only in the Flux Repository and/or on the file system as an FFC file. Prior versions of the workflow were not kept.

Now, after saving a workflow to the Flux Repository, the workflow is also saved to the VCS directory where the user may perform whatever their version control policies and procedures dictate.

To enable this feature the following setting must be set in the Flux engine configuration properties file and the engine restarted. The default is to version the workflows to the vcs directory using both overwrite and time-stamped file names.

VERSION_WORKFLOWS= [true | false] (Turn on/off versioning)
VERSION_LOCATION=[A directory path] – defaults to /vcs and is automatically created if not present