Transferring files using a batch job scheduler with fine-grained control and configuration at runtime is a key and often used Flux feature. The following describes one such Flux workflow developed for a large mortgage broker in their transfer and tracking of mortgage files. The same model is in use in insurance, invoicing, logistics, and many other industries needing flexible and configurable file transfers.
This workflow is reusable for multiple customers and configurable at runtime. Submitting the workflow to a Flux engine as the name “/Acme/weekly” will force the engine to configure the workflow based on a runtime configuration specific to weekly runs defined for the Acme customer. The same workflow template can be submitted repeatedly with different names to the Flux engine for various customers and time periods (e.g., customers Acme, Baker, and weekly, daily, and monthly).
The workflow template diagram is depicted below. It can be reused without modification (relying on runtime configuration and not workflow modification) for many SFTP file exchange partners.
Each customer (or file exchange partner) is configured with a set of runtime parameters – loaded at the time the workflow starts for that customer. The runtime configuration is refreshed automatically when the configuration file is changed (note that the frequency of this refresh is configurable). These parameters include when to trigger the workflow, where to place downloaded files, and what files to download. Adding a new customer or exchange partner involves adding the required entries to this file through the Flux user interface, and then submitting the workflow template to the Flux engine for that customer.
# Locations for specific downloads
# Server and Password user names
# File include patterns
A workflow template for generating reports is also provided, as depicted below:
This workflow template also has a set of runtime configuration parameters that allow the template to be dynamically configured at runtime to execute selected reports over particular time ranges. These reports were built using Jasper Report Community Edition. This report generator workflow can be tailored to call any report writer to create reports specific the the customer’s needs. No report server installation is required.
# — Reporting Component Parameters
The following graphic illustrates one of the generated reports for this MFT example.
Since reports are generated themselves via a Flux workflow, these reports can be emailed, file transferred, and made visible within a web browser via hyperlinks from the Flux Cockpit user interface.
Finally, a common requirement is allowing external customers to view the status of their exchanges and workflows. Utilizing Flux’s security model, customers can be configured to only view selected workflows and their execution based on their names. So any number of users can be configured to see only those items they are permitted to view. For example, here is the Flux monitor configured for an admin role presented above a user’s view with restricted access to “Baker” workflows.
Depicted below is the Flux Operations Console for a user configured with admin role with unrestricted access.
And as a user with restricted access to only Baker workflows.
Flexibility and reusability are core to Flux workflows. The templates and configuration file and report definition discussed here are available as an available example in the Flux documentation website for download and use by Flux customers and evaluators.