Business processes are run in persist mode or non-persist mode. Each mode has an impact on the transactional behavior in Unwired Orchestrator.
Transactional behavior, regardless of the mode used for the business process, causes errors generated at any point in the business process. Errors can be handled using the following methods:
Rolling back the transaction;
Changing the business process state to ERROR;
Placing the message on the error transport with error header properties;
Providing tools to manage these business processes.
The mode used during runtime is automatically determined by the design of each business process according to the expected events for each business process:
If the business process expects one event (or notification), the business process runs in non-persist mode.
If the business process expects multiple events (or notifications), the business process runs in persist mode.
Other criteria, such as Delays and Timeouts, also determine in which mode a business process will run. If delays and timers are present, the business process runs in persist mode.
Persist Mode versus Non-Persist Mode Flow diagram
NOTES:
Unwired Orchestrator is not XA-compliant.
Processing no longer supports the
scenario where a single event is distributed to multiple business processes
in the same package; this has been called a multiple route, or spray condition.
If you are migrating from Integration Orchestrator 4.0.x and have existing
business processes that use this scenario, you must follow the procedures
detailed in Migrating to Unwired Orchestrator
4.3.
Non-transactional transports, such as Rendezvous Certified, Rendezvous
Reliable, file, and socket, do not allow for rollback functionality so
delivery is not guaranteed. Non-transaction transports can be problematic
because the message is committed to the transport immediately after a
get or put occurs.
If a Web service performs some transactional activity, it is outside the
control of the engine. The activity must start a transaction, perform
the activity, and commit or roll back the transaction itself. The Unwired
Orchestrator server has no way to pass a transaction handle to a Web service
and knows nothing about the transaction going on inside the Web service.
Transactionality related to a database activity is configurable using the
autocommit property. If the property is set to true, all database calls
are completed in a separate transaction so that a business process rollback
does not result in a database transaction rollback. If the property is
set to false, a business process rollback results in rollback of the database
transaction. See Adding
a SQL Statement Operation and Adding
a Stored Procedure Operation.
Transactional behavior differs from behavior in Integration Orchestrator
4.0.x in that errors that occurred during processing could cause the business
process to fail without error handling.
In this case, the business process expects only one event, or message type, and the processing completes, resulting in a commit or error, which then results in a rollback. A rollback in this case pushes the message back to the input transport.
A new transaction is initiated to pull a message from the input transport.
The message is parsed and an event object is created. If an error is encountered during the parse, the message is put to the Error transport.
A business process instance is created.
The event object is analyzed.
After successful analysis, the transaction is committed, removing the event from the input transport, as are any other resources used by the process to commit. If a processing error is encountered, the open transaction is rolled back, including all process-used-resources.
In this case, the business process expects multiple events, or message types, and uses information from each message type it expects to receive. With each of the multiple events being handled as a single unit of work, running this business process using persist mode allows storage of information during interim periods. With persistent storage, data recovery is possible.
during interim periods. With persistent storage, full recoverability at any stage of the business process life cycle is guaranteed.When an error occurs in this case, the message is rolled-back to the point where the last unit of work was successfully completed, and the business process state is changed to ERROR.
A new transaction is initiated to pull a message from the input transport.
The message is parsed and an event object is created. If an error is encountered during the parse, the message is put to the Error transport.
The key is obtained and checked to find any existing instances of that business process.
If an instance exists, the event is routed to that instance.
If an instance does not exist and the event is an initializer, a new instance is created.
If an instance does not exist and the event is not an initializer, the event object is persisted until the initializer event arrives.
If a routing error occurs, the message is put to the nohit transport.
The event, the route, and the business process are persisted to the database, committing the transaction so that the message is removed from the input transport at the same time it is persisted in the database.
The Analysis thread obtains the route (the event ID and the process ID) and analyzes the route information in a new and separate transaction. Successful analysis results in the process state being switched to ACTIVE.
The flow for subsequent events continues until a terminating state is found in the business process, when the state is switched to COMPLETE.
If an error is encountered at any point, the business process state is switched to ERROR and the error is put to the error transport. The message contains the original header and is appended to include the error-related header properties. Business processes in an ERROR state can be recovered or removed using tools for managing business processes.