Time-triggered transaction reference

Sterling™ Order Management System provides a collection of time-triggered transactions, which are utilities that perform a variety of individual functions, automatically and at specific time intervals.

Time-triggered transactions perform repetitive actions on a scheduled basis, typically performing database updates, raising events, or calling APIs. One type of transaction, monitors, are designed to watch for processes or circumstances that are out of bounds and then raise alerts. Often, but not always, they retrieve tasks from the task queue or work from the pipeline.

Some transactions enable you to collect statistical data regarding the application's health. This data is collected periodically, using the value specified for the yantra.statistics.persist.interval attribute in the yfs.properties file. By default, statistics collection set to on. To override this property, add an entry in the <INSTALL_DIR>/properties/customer_overrides.properties file. For additional information about overriding properties that use the customer_overrides.properties file, see Configuring Property Files topic.

For more information about statistics persistence, see the Configuring for Performance Management topic. For more information about the specific statistics parameters used, see the applicable time-triggered transactions.

The time-triggered transactions that are described in this chapter are unique transactions, that may or may not be document type specific. For document-specific transactions, the nomenclature helps define which unique transaction it is based on: a transaction ID is in the format Unique_Transaction_ID.Document_Type_Code. For example, the transaction ID for Purge Return is PURGE.0003, indicating that it is based on the unique transaction PURGE, for document type 0003, which is Return Order. Therefore, in order to be able to configure Purge Return, you must look for the PURGE transaction ID in this chapter, which is Order Purge.

Sterling Order Management System provides the following types of time-triggered transactions:

Sterling Order Management System tracks the following statistics for each time-triggered transaction:

  • ExecuteMessageCreated - The number of jobs added to the JMS queue in a given time interval.
  • ExecuteMessageSuccess - The number of jobs that were run successfully in a given time interval.
  • ExecuteMessageError - The number of jobs that failed to run in a given time interval.
  • GetJobsProcessed - The number of GetJob messages that were processed in a given time interval.
    Note: Some of the statistics collected and tracked in Release 9.1 for time-triggered transactions, monitors, and integration and application servers may change with the next release of Sterling Order Management System.

The time-triggered transactions that retrieves the jobs from the task queue table are called as task queue agents. These agents work from the pipeline, retrieve jobs for the transaction from the task queue, process jobs, and based on the outcome, place jobs in the task queue for the subsequent transactions. These jobs are then processed by task queue agents of the subsequent transactions.

Generally, the jobs that are placed first in the task queue are processed first. Every job in the task queue for one transaction has different workload. Some jobs have more workload than the other jobs. For example, the workload to schedule an order with 3000 lines is enormous in comparison to the order with 10 lines. If both types of orders are processed in a single agent instance, orders with large number of lines can lower the overall throughput and also can impact normal order throughput because these orders are processed only after a very large order is processed. Similarly, every job for a transaction does not require same quantum of resources like memory, CPU, and IO to process, might not undergo same process flow like pipeline, order or line validations, and might not be configured to invoke same components such as event handlers and user exits. It is better if such jobs with different workload and different business flows are processed in separate JVMs so that you can prioritize one or more such groups among others and individually scale up the processing powers.

IBM Sterling® Order Management System provides a capability to segregate workload of task queue agents and create jobs with different segregation patterns. You can put these segregation patterns as a filter in the agent criteria of task queue agents to process the matching jobs. As the segregation of workload is accessible with agent criteria, it provides flexibility to prioritize and run a specific type of workload with required capacity to scale up the agent processing for individual workload. For more information, see Workload segregation for task queue agents.