Defining transactions

Every process type has a set of base transactions defined for it. A transaction is a logical unit of work that is necessary for performing activity within Sterling Order Management System.

Base transactions are predefined transactions that contain information about how the transaction behaves, such as how many copies of a transaction can be kept in a process type and whether or not it can have configurable base pick and drop statuses. Base transactions can be used to create new transactions. These transactions can be changed within the limits defined in the base transaction.

In Sterling Order Management System, APIs are used to run transactions. When an API is invoked, the transaction ID is determined based on the context the API was run. The transaction ID identifies the transaction to be run. Depending on the situation the transaction ID can be passed as an input parameter or it can be predefined for the invoking API. For more information about APIs, refer to the IBM Sterling Order Management: Javadoc.

Some extended transactions that are created may require custom coding to implement logic for the transaction. However, you can derive new transactions from the abstract transactions provided by Sterling Order Management System. A transaction derived from an abstract transaction contains specific details such as, statuses and triggering mechanisms that do not require custom coding. For example, if you are configuring an order document pipeline that requires several different types of order status change transactions, you can derive multiple extended transactions from the Change Order Status abstract transaction and configure them in your pipeline without requiring custom coding.

Transactions can be classified as one or more of the following types:

• Externally-triggered
• User-triggered
• Time-triggered

Externally-triggered transactions

An externally-triggered transaction is performed through the Service Definition Framework (asynchronous service) which calls a corresponding API within Sterling Order Management System to run the transaction.

You can add an asynchronous service to a transaction as a reminder that service performs some processing around this transaction and that it is triggered externally. For example, you can set up a service that puts a message in a queue, which acts as a trigger. An asynchronous service then picks up this message from the queue and does some processing. Specifying a transaction as externally-triggered explains how to add a service that triggers a transaction in the Externally Triggered tab.

User-triggered transactions

A user-triggered transaction is invoked manually through the Application Consoles, a configured alert queue, or an e-mail service.

Time-triggered transactions

A time-triggered transaction is invoked on scheduled intervals. In Sterling Order Management System, a time-triggered transaction is also called an agent.