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 Selling and Fulfillment Foundation.
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 Selling and Fulfillment Foundation, 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 Sterling Selling and Fulfillment Foundation: Javadocs.
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 Selling and Fulfillment Foundation. 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:
An externally-triggered transaction is performed through the Service Definition Framework (asynchronous service) which calls a corresponding API within Sterling Selling and Fulfillment Foundation 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.
A user-triggered transaction is invoked manually through the Application Consoles, a configured alert queue, or an e-mail service.
A time-triggered transaction is invoked on scheduled intervals. In Sterling Selling and Fulfillment Foundation, a time-triggered transaction is also called an agent.