Workflow Overview
EJM can be used to create and manage workflows. Most integration tasks require some form of custom workflow.
An Eagle workflow may be as simple as getting a file from a vendor location (be it somewhere in the cloud or on an FTP site) and then loading into the application, or it may be more complex, linking multiple services together, managing exceptions, parallelism, invoking a remote call and providing notification. Using Eagle’s XML technology, you can build custom data driven workflows to meet their exact requirements.
What is a Data Driven Workflow (DDW)?
There are effectively two workflow models supported within the Eagle product today:
- Traditional Scheduler – Using Eagle’s scheduler capabilities it is possible to build a workflow that triggers jobs in either a sequence, based on basic concurrency logic or the state of a preceding event. This architecture typically uses a polling mechanism. In some cases the context of the workflow is not maintained, that is, load securities, poll for changes based on update date and execute an engine on securities that have changed and then publish.
- Data Driven – In a data driven workflow, the context is typically maintained and managed through a series of control messages to maintain and interrogate status of the service. Using the preceding example, load securities, and then pass changed securities to the engine for processing. There is no need for a polling process, the consumer is fed the exact payload to process.
Note
Job Orchestration
“Orchestration describes the automated arrangement, coordination, and management of services.”
You have the following choices in how a custom workflow is orchestrated using EJM:
- Eagle orchestration, using Eagle’s native scheduling and data integration capabilities, we will refer to this as Eagle orchestration.
- External orchestration, using Enterprise job schedulers, such as Control-M, AUTOSYS, Tidal and others or via BPM frameworks and application (such as Pega or IBM’s Lombardi product).
Both orchestration patterns leverage the same rich set of integration and workflow APIs to initiate Eagle services. Those APIs we will refer to generically as Control Messages. The difference lies where the management, or orchestration, of these services resides. With that said there is certainly a possibility that a hybrid approach can be constructed.
For example, consider this workflow scenario:
A customer is using Control-M to orchestrate key jobs within their enterprise. The user configures the necessary file moment jobs in the job scheduler and then wishes to invoke Eagle’s Start of Day process. This process involves a number of tasks that need to be completed in a defined order. In this scenario, the team has created a “coarse grained service” called SOD. The workflow for this service is handled within Eagle, but at the completion of this service the orchestration and management passes back to the enterprise scheduler. In this scenario both the Eagle orchestration and external orchestration patterns have been used.
XSCHEDULE Toolkit
If you are using the XSCHEDULE toolkit today, the external orchestration provides a number of benefits such as alternative transport models, decoupled integration (i.e. cloud to cloud) and enhanced management capabilities with regard to the control and reporting of jobs.
Note