Jeopardy Management

Jeopardy is implemented as a tightly coupled component in TIBCO Fulfillment Order Management along with existing features like OMS, AOPD, and Orchestrator. Notifications to Jeopardy will be sent as low level API calls or through in-process communication, which is similar to other component communication. The advantages of Jeopardy Managment System are as follows:

  • Jeopardy runs in cluster-mode.
  • Jeopardy notifications are processed in synchronous, or asynchronous (batch) modes.
  • Improved performance of Jeopardy performance due to in-process (low level API calls) communication between this application's components.
  • Jeopardy is tightly coupled with orchestrator and it follows all the finite state automata states.
  • Orchestrator has complete control over the jeopardy functionality improving its performance.
  • In case of any issues, the Orchestrator rolls back any updates to a plan, or plan item, and jeopardy automatically reads the latest changes.
  • Instead of saving plan, plan item, and process component information as part of Jeopardy, all the information is now saved as part of state machine. Jeopardy reads and updates the information as part of the state machine itself.

The following diagram is a representation of the architecture of Fulfillment Order Management:

Architecture of Fulfillment Order Management

The following diagram is a representation of the Plan and Order Execution using Jeopardy:

Plan and Order Execution

In-memory (Cache) Plan and Process Component Repository

The performance of Jeopardy has been improved by an in-memory implementation of plan and process repository. The plan repository is managed as a component in the Orchestrator finite state machine. If the server is abruptly terminated, both the plan, and the process component repositories will be backed by the database that acts as a secondary level cache to safeguard the changes.

Working of in-memory cache

The in-memory cache provides local cache access and extreme performance. It uses the database as the persistence system to persist information across server startups. The Hibernate feature continues to use active spaces as a silent second level cache for any spillovers from the main memory cache.

The application uses Orchestrator state machine’s state as the primary in memory caching system. It also uses an existing Orchestrator caching and spill over mechanism to handle additional caching of data running out of memory. This practically sets no limit on the in-memory cache size.

Datastore Compatibility

A new datastore (secondary cache) has been added to the system. The application can now be deployed with in-memory cache along with the database as a secondary cache.

The configuration to setup the database as a datastore, can be configured in Configvalues_JEOMS.xml file as follows: 

<ConfValue description="Operation Data Store Type" name="Operational Data Store Type" propname="com.tibco.jm.config.odstoreType" sinceVersion="2.0" visibility="Advanced">
   <ConfString default="cache" value="cache" />
</ConfValue>
Note: With the colocated architectural changes, the application cannot run in standalone mode with Cache as a datastore. This restriction is added to keep the orchestrator component as a master component, to control the jeopardy notification functionalities.

Database: Secondary Cache Option

Database is implemented as a second-level cache for durability purposes. The database is configured as the application second level cache in Configvalues_JEOMS.xml file as follows: 

<ConfValue description="Operation Data Store Type" name="Operational Data Store Type" propname="com.tibco.jm.config.odstoreType" sinceVersion="2.0" visibility="Advanced">
   <ConfString default="cache" value="cache" />
</ConfValue>

Cache is the default value and the only configuration supported in colocated mode.

Note: Hibernate will use active spaces as a dialect for silently maintaining in memory spill overs.

Batch Notification and Messages

Following are the notifications sent by JeOMS:

  1. JMS notification: To save jeopardy messages and risk region in the database when a jeopardy condition is detected for a plan or planItem.
  2. JMS notification: To report an alert in dashboard when a jeopardy condition is detected for a plan or planItem.
  3. Database notification: To update cache.

In case of existing architecture, notifications are processed and saved into the database. Processing is sequential and not in the batch. Each notification has a dedicated connection from connection pool. With the new architecture, there are options to synchronously process the JMS notifications sequentially, and also to execute the notification in the batch.

Batch Event Processing

Events are consumed by state machine and notifications generated by the state machines that are posted to the Batch process. Events update the cache repositories for any status updates, or event notifications related to jeopardy detection. The following is the sequence of activities involved:

  1. State Machine receives the events from JMS.
  2. Events are consumed by State machine.
  3. State machine generates database notifications and JMS notifications that are posted to Batch Processes.