Transaction Behavior

The VOSS Automate transaction engine ensures that configuration changes are made efficiently and reliably.

In the event of a transaction failure or error, VOSS Automate allows for transactions to be rolled back to a state preceding the failed transaction.

For example, where a workflow step fails, all successful steps prior to a failed step are rolled back.

Transactions are hierarchical and have parent-child relationships with other transactions. Sub-transactions are always executed sequentially and synchronously, in other words the child transactions of a workflow parent transaction are executed one after another.

Transaction behavior is different for the following actions in the system:

• API

  The API supports executing transactions in both synchronous and asynchronous modes. When executed in synchronous mode the API responds only once the transaction has completed. When executed asynchronously, the API responds immediately with a transaction ID so that the progress and status of the transaction can be polled.

• Bulk Loaders

  With bulk loading, the load of each row on a sheet is a separate transaction. These transactions are run in series. There is no rollback of rows that have loaded successfully prior to, or subsequent to, a failed transaction (a failed row on a sheet). Multiple bulk load sheets can be loaded in parallel.

• Data Import

  A single transaction is created for each record in the import file. If a single transaction fails, the import continues and does not roll back the preceding successful transactions.

• Data Sync

  A single parent transaction is created for a data sync action. The subsequent device API requests are not handled as sub transactions but are executed in-line.

• Events

  Events can be triggered as part of data sync operations or as triggers on operations performed on certain model types. The provisioning workflow executed when the event triggers is executed as a new parent transaction. Transaction failures with the workflow executed after an event do not affect the original transaction that triggered the event.

All transactions are placed on a queue before they are actioned. If the system queue service is restarted while a long-running transaction such as data sync or bulk load is running, all running transactions that are a part of this transaction will be marked as failed and finalized.

Parent transactions can run concurrently, but their subtransactions run serially. There is priority in parent transactions so that user input such as adding on a Admin Portal form will be prioritized over a running import or bulk load process.