Flux orchestrates file transfers and batch processing. Without human intervention, Flux orchestrates the transfer of high volumes of data and business transactions across different platforms and systems. Flux then manages batch processes performed against this data, including conversion of data, data compression, encryption, enterprise-specific processes as well as secure transfer for backup, replication, and distribution of files.
IT organizations realize that not all enterprise processing is interactive and web driven. Enterprises need to process high volumes of data not suited for interactive processing. IT organizations must optimize hardware and network resources to balance these resources.
As enterprises expand the sharing of data across disparate platforms, operating systems, and database management systems, reliable file transfer and batch process orchestration becomes indispensable.
Flux excels in satisfying circumstances where:
- Files and data need to be transferred unattended to reduce processing time and expense, increase reliability, and meet service level agreements.
- File and data need to be transferred in a secure and reliable manner among different platforms and systems.
- High volumes of data need to be moved between many different functions running on a variety of platforms and machines.
- File transfer and related processing are time-driven, process-driven, or manually triggered.
- Processes need to be set up to run with the same programs and same (or varying) parameters, ensuring data integrity and consistency of processing.
Flux provides the solution core for many top-tier banks and financial service providers, including solutions for check image exchange, image and document delivery, treasury management, wealth management, and institutional investor solutions (to name just a few).
All of these solutions support high-volume, high availability, and highly-reliable processing that offers each institution opportunities to increase revenue and garner new customers, while reducing operational and administrative costs. Flux's ease of integration into multi-platform solutions, its extensibility using open Java and Web Services APIs, and its unique clustered and easily-scaled architecture provides the underpinnings for current and next-generation product offerings.
Before beginning to program using Flux, you should become familiar with Flux's architecture. Flux is a software component. It becomes a part of your enterprise or standalone Java application. It gives your application advanced workflow, scheduling, and business process management capabilities in a small package.
Flux interacts with your Java EE or Java application, application server, and database. Interactions with application servers and databases are optional. If you don't need them, you don't have to use them. Enterprise applications, almost by definition, make use of application servers and databases.
The Flux engine is based on a peer-to-peer architecture in which each Flux engine in the cluster is capable of failing over and clustering flow charts. A Flux engine can be run on platforms like Windows, UNIX, Solaris, IBM mainframes, or any other operating systems with appropriate Java support. For a complete list of operating systems and platforms known to work with Flux, refer to Technical Specifications. See the diagram below for an accurate depiction of the behavior of the Flux engine.
Flux Engine Architecture
Flux can be used with databases like Oracle, DB2, MySQL, and SQL Server to store flow chart structure and data. An in-memory H2 database implementation is provided for applications that do not need or have persistent storage. For a complete list of databases supported by Flux, refer to Technical Specifications.
Flux clients run the Flux software. These clients create instances of Flux that will work with the client’s servers and networks to share information and flow charts created and run by Flux. The protocol used for client-engine communication is RMI.
A Flux client may be:
- A Web client (Web User Interface)
- A standalone GUI
- The Command Line Interface (CLI)
- Application code using Flux APIs
- The Flux Business Process Dashboard
- The Flux JSP tag library
Flux with Java SE
The Java Standard Edition (Java SE) gives you a complete environment for doing applications development on desktops and servers. It also acts as the base for the Java Enterprise Edition (Java EE) and Java Web Services.
The diagram below illustrates Flux running on the Java SE platform.
Flux with In-Memory Databases
You can use Flux with its embedded, in-memory database to create a fast and simple environment for Flux to run in.
The following diagram displays the architecture of Flux using the Java SE platform with its embedded database.
Flux with Java EE
The Java Enterprise Edition (Java EE) is the standard for developing multi-tier enterprise applications. The Java EE platform can simplify enterprise applications by basing them on standardized, modular components; by providing a set of services to those components; and by automatically handling details of application behavior; all without complex programming. If you are running Flux on a Java EE platform, it is suggested that you do not depend on the Java EE JAR files that are packaged with Flux, as these files could be out of date. Instead, we recommend you use the EJB and JMS JAR files that are distributed with your application server.
The following diagram illustrates Flux running on the Java EE platform.
The Cycles and States of the Flux Engine
Like other components and objects, Flux is created, initialized, started, and later disposed. During initialization, you provide information to Flux so that it can communicate with your database and application server. Once it is initialized, you can interact with Flux. However, scheduled flow charts will not fire until the component is started. Once started, the component can be stopped and restarted indefinitely. When the component is stopped, flow charts do not fire. Finally, when your application is ready to shut down, the component is disposed. Once disposed, the component cannot be re-used.
As has been explained, Flux can be in one of three states: Stopped, Running, and Disposed. When Flux is first created and initialized, it enters the Stopped state. From this state, you can fully interact with Flux. However, any scheduled flow charts do not fire. From the Stopped state, you can proceed to the Running state. In the Running state, scheduled flow charts fire. Flux may go back and forth between the Running and Stopped states indefinitely. You may wish to re-enter the Stopped state from the Running state in order to temporarily prohibit flow charts from firing.
Finally, when your application is ready to shut down, Flux transitions into the Disposed state. Once the Disposed state has been entered, you cannot interact with Flux, nor will flow charts fire, until a new Flux instance is created, initialized, and started.
As explained in greater detail below, you create jobs as flow charts. All flow charts have a start action, which is the first function to be performed. In many situations, the start action is a Timer Trigger. Timer triggers wait for a particular time and date. These times and dates are calculated using Time Expressions, which are simple strings that succinctly describe when, and how often, a timer should fire, with precision down to the millisecond.
Continuing this example, once a timer trigger fires, flow of control transfers to another action in the flow chart. Typically, this subsequent action notifies a listener in your application. Listeners can be Java objects, EJB session beans, EJB message driven beans, or JMS message listeners. Java EE applications, for example, find it convenient to use EJB session beans and JMS message listeners as flow chart listeners. The kind of listener you choose depends on your application's architecture.
Because Flux models jobs as flow charts, after a listener action executes, control can flow to other actions. Possible actions include File actions for writing files, Email actions for sending email, Messaging actions for sending messages to other applications in the enterprise. Besides actions, control can flow into other triggers. Flux includes a sophisticated timer trigger that waits for certain times and dates. Other triggers are possible, including File triggers that wait for a file to be created or modified, Email triggers that wait for incoming email to arrive, messaging triggers that wait for inbound messages from other software systems in the enterprise. You can create your own triggers and actions to plug into the Flux scheduler. Your custom triggers and actions should make it easy to create new flow charts that tightly interact with your application.
Scheduled flow charts can be in different states. Each flow chart has a super-state and a sub-state.
The super-state can be either Normal or Error. A flow chart in the Normal super-state runs in the usual way. However, a flow chart in the Error super-state is being handled by Flux’s default error handling mechanism, which provides a very flexible way to recover from flow chart errors.
The sub-state can be one of several possible states:
- _Waiting:_A flow chart in the Waiting sub-state is eligible for execution at a specific time in the future. For example, active timer triggers exist in the Waiting sub-state as they wait for their scheduled firing time to arrive.
- Firing: A flow chart in the Firing state is executing_._
- Triggering: A flow chart in the Triggering sub-state is waiting for an event to occur. For example, active message triggers, business process triggers, and manual triggers exist in the Triggering sub-state as they wait for an event to occur or to be expedited.
- Paused: Paused flow charts do not execute or fire triggers until they are explicitly resumed.
- Joining: A flow chart in the Joining sub-state is involved in a split-and-join flow chart structure. A split forks a flow chart into multiple, parallel flows of execution. These parallel flows can be joined together at a later point in the flow chart, which is where the Joining sub-state is used.
- Failed: A flow chart in the Failed sub-state has failed to recover from an error and is waiting for some kind of external intervention. The Failed sub-state is legal only if the super-state is Error. A flow chart in the Failed sub-state is temporarily prevented from executing.
- Finished: A flow chart in the Finished sub-state is done executing and is ready to be deleted by the Flux Engine.
The Flux architecture described in the Background section provides an accurate, high-level view of how applications interact with the Flux flow chart scheduling component. In the Examples section, there are complete, working code examples that show how to get started developing your application with Flux.
A firewall is software that helps to protect your network from unauthorized access outside of your network. Flux is engineered to traverse firewalls in a secure manner to ensure that your firewall stays intact and Flux still runs properly.
Flux can traverse firewalls in two ways: simple traversal and IP tunneling.
In a simple Flux firewall traversal, you open a port on the firewall to allow access to the Flux engine. The Flux engine must then be configured to use the open port. This can be set using the registry_port configuration option in your engine configuration file, or programmatically through the Configuration.setRegistryPort() method.
A Flux client obtains a reference to the engine using the Factory.lookupRmiEngine() method. Once this reference is obtained, the client uses it to communicate with the Flux server. This client-server communication is handled through a random port by default. You can specify the port that the Flux engine will use to communicate with the client by setting the rmi_port configuration option, or through the Configuration.setRmiPort() method as demonstrated below. Java's RMI subsystem multiplexes many RMI objects onto one port, so only a single port needs to be configured.
NOTE: If the rmi_port configuration option is set to a different port than the registry_port, you will need to ensure that both are open on the firewall.
When using IP tunneling, you will have to set the JVM property -Djava.rmi.server.hostname to the IP address of the first host in the tunnel on your Flux server. The default value of this property is the IP address of the local host in "dotted-quad" format.
Suppose you have three computers in your IP tunnel; A, B, and C. A can only communicate with B, B can communicate with A and C, and C can only communicate with B. A sends a Flux engine lookup request to B on port 1099. B forwards the lookup request to C. C finds the engine and returns a reference to that engine back to A using B as an intermediary. A can now talk to the engine on C through B.