• 1. Introduction to Flux
• 2. Technical Specifications
• 3. Background
• 4. Flux Agent Architecture
• 5. Creating and Initializing Flux
• 6. Creating Flow Charts
• 7. Running Flow Charts
• 8. Modifying Flow Charts
• 9. Flow Chart Runs
• 10. Core Triggers and Actions
• 11. File Triggers and Actions
• 12. Custom Triggers and Actions
• 13. JEE Actions
• 14. Database Actions
• 15. Mail Action
• 16. Web Service Actions
• 17. Prescripts and Postscripts on Triggers and Actions
• 18. Coordinating and Synchronizing Jobs Using Messaging and Checkpoints
• 19. Coordinating Actions Using Signals
• 20. Timeouts
• 21. Complex Dependencies and Parallelism with Splits and Joins
• 22. Business Process Management
• 23. Security
• 24. Runtime Configuration
• 25. Scheduling Options
• 26. Time Expressions
• 27. Business Intervals
• 28. Forecasting
• 29. Caching
• 30. Databases and Persistence
• 31. Transactions
• 32. Clustering and Failover
• 33. Application Servers
• 34. Logging and Audit Trail
• 35. Best Practices
• 36. JMX MBean
• 37. Flux Command Line Interface
• 38. Flux Designer
• 39. Embedding the Web-based Designer
• 40. Flux Operations Console
• 41. Troubleshooting
• 42. Examples
• 43. Upgrading from Flux 3.1
• 44. Migrating Collections in Persistent Variables from Flux 3.2, 3.3, and 3.4 to Flux 3.5 and Higher
• 45. XML Wrapper
• 46. Flux API Documentation
• 47. Trigger and Action Properties (JavaBeans Documentation)
• 48. Typical Flux Activites
• 49. Engine Configuration File
• 50. Runtime Data Map Type Conversion Support
• 51. Integrating Flux Security with WebLogic
• 52. Change Logs

Introduction to Flux

Flux is an embeddable software component for performing job scheduling, file transfer, and workflow. Job scheduling is a traditional function that executes different tasks at the right time or when the right events occur.

Flux can be used in any Java environment, including JEE, XML, client-side, and server-side applications. Jobs can be scheduled to run on specific dates, certain days of the week, at certain times, and on a recurring basis. Jobs can also be scheduled to run when certain events occur, such as when a different software system performs some action. The Flux engine persists its scheduling data in a relational database so that once scheduling begins, Flux can be stopped and restarted without rescheduling jobs.

Flux integrates with Java by calling user-defined callbacks when a job is ready for execution. Furthermore, once a job becomes ready to fire, Flux integrates with JEE applications by invoking EJB session beans, sending JMS messages, and invoking Message-Driven Beans.

Flux models jobs using a traditional flow chart. Flux flow charts, like most, consist of triggers, actions, and flows. These triggers, actions, and flows can be combined to create flow charts that are as simple or as complex as your specific needs require.

• A trigger waits for an event to occur. Traditionally, these events are time-based. For example, a trigger can fire at 9 AM and 4 PM, Monday through Friday, except on company holidays. Other triggers may respond to activities that occur in other software systems in the enterprise, such as financial settlement engines, messaging systems, and email servers. You can use the triggers built into Flux or write your own and plug them into Flux.

• An action performs some function such as updating a database, calling into a JEE application, communicating with another software system, and so on. Flux itself comes with a suite of actions, but you can write your own custom actions and plug them into Flux.

• A flow connects a trigger or action to another trigger or action. For example, after a trigger has fired, a flow may guide execution into the next appropriate action. Flows can be conditional or unconditional: for example, when an email trigger fires, execution may unconditionally flow into a database action. On the other hand, it may be appropriate for execution to branch to different actions depending on the e-mail's sender. In those cases, conditional flows ensure that the appropriate action is taken.

Throughout this document, the terms flow chart, workflow, and business process are used interchangeably. In general, actions and triggers are referred to as nodes or flow chart nodes.

(cross reference) illustrates how Flux defines a job using a common flow chart. This job fires from 7:45 am through 3:15 pm, every 20 minutes. Each time the job fires, a program called MyProgram.exe is executed.

Sample Flow Chart or Job Diagram

Features

Flux provides the following features.

• Simple Configuration, Lightweight, Small Footprint, and Zero Administration. Flux is simple to configure. Flux runs right out of the box. There are no complex setups. Flux is lightweight, has a small footprint, and can be embedded comfortably in server-side and client-side applications. Flux requires zero administration. Multiple Flux instances can be created and configured in applications with a few lines of Java code.

• Suitable as a Standalone Job Scheduler and a Job Scheduling Software Component. Flux can be used both as a standalone job scheduler and an embeddable software component.

• Standalone Graphical User Interface. A standalone desktop application that provides a drag-and-drop, point-and-click graphical user interface (GUI) to view, edit, create, remove, control, and monitor flow charts with a point-and-click GUI. No programming required.

• Time-based Scheduling. You can create flow charts that perform different actions at the right time and on the right day.

• Event-based Scheduling. You can create flow charts that perform certain actions when the right events occur, such as a significant event occurring in an external software system.

• File-driven Flow charts. File-driven flow charts allow applications to come to life when files are created, deleted, or modified, either on the local file system or on remote FTP servers. Using short and powerful expressions to describe large sets of files, you can create, delete, copy, move, and rename files and directories on the local file system, on remote FTP servers, or between the two.
  
  By combining File-driven Flow charts with Flux's time-based and event-driven scheduling, you can create scheduled file transfers to move your business files where you need them at the right times and when the right events occur.

• 42 Built-in Triggers and Actions. By using the 42 built-in triggers and actions in your workflows and flow charts, you can assemble flow charts to perform tasks as time and events dictate. Or you can write your own custom triggers and actions using the Flux API and plug them into your flow charts.

• One-shot Job Scheduling. A single flow chart is scheduled to execute at a specified time. For example, a flow chart might be scheduled to run at 4 am, July 4th, 2007, or a flow chart might be scheduled to run 90 days from the current time.

• Recurring Job Scheduling. A flow chart is scheduled to execute periodically. The flow chart runs indefinitely, until an ending date, or for a fixed number of repetitions. For example, a flow chart might be scheduled to run at 6 am on the second Tuesday of every month. Another flow chart might be scheduled to run at 8:15 am and 5:15 pm, Mondays through Fridays. Additionally, a flow chart might be scheduled to run every 750 milliseconds.

• Flow Chart Dependencies. Flow chart actions can be set to execute after certain other actions have already finished execution. For example, in this manner, flow chart actions A, B, and C can be configured to execute one after the other. You can also configure entire flow charts to be dependent on other flow charts. More powerful than flow chart chaining, Flux’s flow chart dependencies allow you to configure one set of flow charts to execute after a first set of flow charts has reached a certain milestone or has finished running. These dependencies support conditional processing, so that a dependent flow chart will not run until the right flow chart finishes with the right result.

• Conditional Job Scheduling. Actions can be set to execute only if previous actions return certain results. For example, if a previous action finishes with one particular result, action B may execute. But if a different result is generated, action C executes.

• Flow Chart Listeners. Flow chart listeners provide an additional mechanism that allows you to perform certain activities when the Flux engine performs certain tasks. For example, when the Flux engine is stopped, a flow chart listener can observe that event and take appropriate action.

• Workflow. Flux uses a workflow model for creating and executing flow charts. Workflow allows you to create flow charts that accurately model your application requirements. Flux can create flow charts that contain arbitrary sequencing, branching, looping, decision points, splits, and joins (parallelism). With these workflow features, you can design more realistic and sophisticated flow charts that exactly model your business processes.

• Split and Join. Flux’s workflow flow chart model also supports the ability to split (fork) a flow of execution into multiple, parallel flows of execution. These parallel flows can be joined together at a later point in the flow chart.

• Flow Chart Queuing and Producer/Consumer Processing. You can configure a set of flow charts that "produce" data and a second set of flow charts that "consume" that data.

• Tree of Flow Charts. Flow charts are stored in a tree. You can perform scheduling operations on entire branches of the tree or just individual flow charts.

• Transactions. Flow charts run using database transactions, preserving data integrity even if computer systems or flow charts fail.

• Clustering and Failover. Multiple instances of Flux can work together to schedule flow charts. Should any instance go down or become inaccessible, the remaining Flux instances recover and continue scheduling flow charts.

• Time Zones. Flow charts can be assigned to run in any time zone. For example, a client in New York can schedule a flow chart on the server in London to run at 9 AM Singapore time.

• Daylight Savings. Flux uses the JVM's time when calculating scheduled execution dates. Daylight Savings time is handled depending upon which implementation of the JVM Flux is running with.
  
  For more information on daylight savings with Java, see Timezones, Daylight Savings, and the Sun TZupdated for the Java Runtime Environment (JRE).

• Java, JEE, XML, and Web Services Integration. Flux naturally integrates with Java, JEE, XML, and Web Services applications through an extensive API. Flux can be used as a software component in any Java, JEE, XML, or Web Services application to meet flow chart scheduling requirements.

• Holiday and Business Calendar Support. Schedules can be created that are sensitive to local holidays and other days and times that need to be treated specially. For example, a payroll flow chart can be executed every other Friday, unless that Friday is a holiday, in which case the flow chart should be run on the previous business day. Flux's Business Calendars have millisecond resolution and can be combined with other Business Calendars.
  
  The point of saying that Flux's Business Calendars have millisecond resolution is not to say that Flux is a real-time scheduler, which it's not.
  
  The point is to say that Flux's Business Calendars are not simply day oriented. You can create a Business Calendar that is oriented to what makes sense for your business, such as blacking out a period of time from 10 PM until 2:45 AM the next morning, Monday through Friday.

• Web User Interface. A web user interface can be used to monitor and control flow charts from a web browser.

• JSP Tag Library. By using the Flux JSP tag library, web designers can create web pages that interact with Flux without writing Java code.

• Standalone Graphical User Interface. A standalone graphical user interface (GUI) can be used to view, edit, create, remove, and control flow charts with a point-and-click GUI. No programming required.

• JMX MBean Support. Flux is available as a JMX MBean for deployment in a JMX Management Console. System administrators can deploy the Flux JMX MBean in application servers for managing and administering Flux from a JMX management console.

• Persistence. If desired, flow charts can be persisted in a relational database. Flow charts do not need to be re-scheduled if Flux is restarted.

• Concurrency Throttles. Different concurrency throttles allow different kinds of flow charts to get more, or less, running time within the scheduler. For example, if you have "heavyweight" and "lightweight" flow charts, you can configure your scheduler so that at most two heavyweight flow charts can run at the same time, but up to 10 lightweight flow charts can run concurrently.
  
  Concurrency throttles can be set on individual Flux engines as well as across the entire cluster. Cluster-wide concurrency throttles allow you to limit the number of flow charts that can run throughout the entire system, regardless of the number of individual Flux engines that may be running.
  
  Adjusting concurrency throttles, depending on the kind of flow chart being executed, allows flow chart scheduling performance to be tuned and system resources to be conserved.
  
  For example, suppose a reporting system needs to limit the number of Transaction Report flow charts across the flow chart scheduling cluster to 32. This throttle prevents the report servers from being overwhelmed, regardless of how many Flux engines are added to the cluster. Plus, for other kinds of reports, there is still report generation capacity left available for other kinds of report flow charts.

• Pinning flow charts on specific Flux instances. A Flux cluster can be configured so that certain kinds of flow charts must run on certain Flux instances.
  
  For example, if only one of the machines in a Flux cluster has report generation software installed on it, you can specify that all of your reporting flow charts have to be executed on that machine only.
  
  In general, you can specify that a particular Flux instance will, or will not, run certain kinds of flow charts.
  
  By pinning certain flow charts on certain machines, you can make sure that your flow charts run on the machines that have the resources that those flow charts need.

• Pause, Resume, Interrupt, Expedite, Modify Across a Cluster of Schedulers. Flow charts can be paused and later resumed. Running flow charts can be interrupted. Flow charts can be expedited for immediate execution. Flow charts can be modified while they are running. All of these actions can take place on an individual Flux scheduler instance or across an entire cluster of Flux scheduler instances.

• Time Expressions. Flow charts can be scheduled using simple string expressions to indicate when a flow chart should run, such as on the second Tuesday of every other month. Full Cron-style Time Expressions are supported to allow flow chart scheduling in the same way as Unix Cron but with millisecond precision. A helper interface is also available to calculate Time Expressions programmatically.

• Error Handling. If flow charts fail, corrective action can be taken. By default, Flux automatically retries failed flow charts after a delay. Flow charts that repeatedly fail are stopped and are flagged for further inspection. Moreover, Flux's error handling capabilities can be completely customized, including adding in custom notification mechanisms.

  In Flux, an error handler itself is a flow chart, so error handlers can use the same workflow model as regular Flux flow charts. Furthermore, you can define different error handlers for different classes of flow charts. This kind of customization allows you to completely customize your error handling to perform appropriate corrective steps for different kinds of flow charts.

• Logging. At various points during the Flux engine's execution, you can receive logging messages. These logging messages can be configured to include varying degrees of detail. Flux logging optionally integrates with Log4j, the JDK logger, or Jakarta Commons logging. Logging is especially useful for programmers and administrators who want to monitor Flux's behavior at a low level of detail.

• Audit Trail. The audit trail publishes messages that describe what important activities are taking place within the Flux engine, which can be viewed by external observers to determine who performed what activities. The audit trail is useful for non-technical personnel who need to know how high level Flux engine activities were initiated.