preceding the Id number.[Index]
Overview
Transactions are a record of all activities that occur in VOSS Automate. You can inspect the summary list view of past and in-progress transactions in the Transaction Log, where you can drill into the details of a transaction and related sub-transactions, as well as view the logs to audit the transaction steps.
Related Topics
View a Transaction
In the Transaction logs you can click on a transaction to view the transaction details, and if available for this transaction, any sub-transactions, as well as the logs.
Three tabs may be available for transaction details:
Transaction Toolbar Actions
When viewing the details of a transaction the following toolbar actions may be available, depending, for example, on the transaction type, and on whether the transaction is in progress or complete, and whether it is a successful or failed transaction:
| Refresh | You can click the Refresh button while a transaction is running to update its progress and status in realtime |
| Auto-refresh | Automatically refreshes the transaction progress and its status, every 5 seconds, while the transaction is running. |
| Cancel | Cancels a transaction, if its still running. The status of a cancelled transaction updates to Fail with a system message that says Transaction canceled. If you cancel a transaction that has sub-transactions, a currently in-progress sub-transaction will complete, and then this sub-transaction as well as any preceding sub-transactions will rollback to their previous states. However, for a cancelled bulk transaction, the system views each bulk load sub-transaction as a main transaction, and thus only the currently in-progress sub-transaction is rolled back to its previous state. |
| Replay | For completed transactions, you can click the Replay button to repeat (replay) the transaction, if required. For example, let's say a transaction fails because a target system service was not running. In this case, you can replay the transaction instead of having to re-input data on the form in the Admin Portal. |
| Edit and Replay | Click Edit and Replay to first open the form that was used for input data prior to running a transaction. You can now make changes to the input data that was used, and then re-run the transaction. This is useful where, for example, incorrect input data causes a transaction to fail. Note the following:
|
Note
If the transaction queue service stops and is restarted, any queued transactions will resume processing, while processing transactions will fail and displays the following message: Transaction aborted due to queue service restart.
This tab provides high level transaction details, such as the transaction ID, the user who initiated the transaction, duration, and so on.
The table describes the details available for transactions:
| Field | Description |
|---|---|
| Transaction ID | Unique identifier for the transaction. |
| Action | The type of action recorded in the transaction, for instance Execute, Create, Modify, Data Import and so on. |
| Detail | A brief description of the processed transaction. |
| User | The user who initiated the transaction. |
| Priority | The priority of the transaction, for example Normal. |
| Status | For transactions to process, this is Queued. For running transactions, this is In Progress; for completed transactions it is Fail or Success. |
| Message | The message displayed upon completion of the transaction. |
| Submitted Time, Started Time and Completed Time | The date and time indicating the transaction progress. |
| Submitted on Node | The host name of the application node that scheduled the transaction. On a clustered system, this can differ from the 'Processed on Node' name below. |
| Processed on Node | The host name of the application node that processed the transaction (this value will only be set once the transaction is processed). On a clustered system, this can differ from the 'Submitted on Node' name above. |
| Rolled Back | Indicates whether the transaction was rolled back or not. |
| Duration | The duration of the selected transaction. If there are sub-transactions, this parent transaction duration is the total duration of the transaction. This includes the total duration of import transactions that carry out provisioning workflows asynchronously. |
Sub-transactions display in a list for transactions that have sub-transactions:
Sub-transactions also contain links to their details and the sub-transaction form displays a link to its parent transaction.
Failed transactions show a Message of the error. However, a sub-transaction with a Create action that has a "fail on error" workflow condition for duplicates, may show its Status as Fail when not creating a duplicate, while the parent transaction then shows its Status as Success.
For asynchronous transactions and sub-transactions, refer to Parent and Sub-transactions for Asynchronous Transactions.
The Logs tab displays a time stamp, Message and Severity details of transactions.
If the Severity has the status of error, the Message section can be expanded to inspect the error, and optionally copy it and send it to Support.
If a workflow is inspected, a separate log entry provides details of each step with a log message as Step n, starting with Step 0.
Resource or Record
Depending on the transaction type, an option is available to navigate to the original record where a resource changed.
Parent and Sub-transactions for Asynchronous Transactions
Parent and sub-transactions for asynchronous transactions are shown in the transaction logs as follows:
Activity on the VOSS-4-UC system results in transactions that are recorded. The Transaction menu provides auditing information for each transaction.
The recorded information includes:
On the GUI, details of a specific transaction are displayed when the transaction is selected from the list view. Refer to the topic on Bulk Load Transactions in the Bulk Administration Guide for the details of Bulk Load transactions.
When a transaction is selected, the Base tab shows details of the columns of the transaction list view. The button bar on the detail list view shows Help and Refresh buttons if the transaction is still running. If the transaction is running, click the Refresh button to update the Progress field.
Lists of transactions can also be filtered. Refer to the topics on filtering transactions, sub-transactions and tranasction logs for details.
If you want to cancel a transaction while it is still running, click the Cancel button. If a transaction, with sub-transactions, is canceled, the sub-transaction currently in progress will complete. This sub-transaction as well as all preceding sub-transactions will then roll back to their previous states. Note that bulk load transactions do not follow this behavior. Each bulk load sub-transaction is seen as a main transaction, and only the 'in progress' sub-transaction will roll back to its previous state.
A Replay button is available if the transaction is complete. A transaction can be replayed if required, for example if a transaction failed because a target system service was not running. The replay of the transaction can then be used instead of re-entering data on a GUI form.
An Edit and Replay button is also available for completed transactions. This is similar to the Replay button, but allows you to first make changes to the previously submitted form before the transaction is resubmitted.
The button is available for transactions that did not originate from bulk loads, wizards or pop-up forms.
Replay and Edit and Replay functionality are not supported by the bulk loader, because the bulk load files are not stored by default. The bulk loader extracts data from the spreadsheets and then performs the necessary action(s). The only time a bulk load file is stored in the database is when the bulk load is scheduled. In this case, the bulk loader keeps the file until it is triggered by the scheduler to execute the actions in the file. When the data is extracted from the file, it is deleted.
When using Edit and Replay for a failed Quick Add Subscriber transaction, the user information fields will not automatically update when changing the Username field:
These need to be edited manually.
Selecting the button opens the original input form that resulted in the transaction. The form also contains the original data that was posted. This data can be edited and the form can be submitted to replay the transaction. This functionality can therefore be used to for example edit a failed transaction or to modify data of a successful transaction.
Since GUI Rules apply to a form from a specific hierarchy, the Edit and Replay functionality should only be used from the same hierarchy as the original transaction was executed.
If a transaction has sub-transactions, a sub-transaction list is available
on the form, with links to their details. The sub-transaction form displays a
link to a parent transaction. On the transaction list view, sub-transactions
are identified by a preceding the Id number.
Failed transactions show a Message of the error. However, a sub-transaction with a Create action that has a "fail on error" workflow condition for duplicates, may show its Status as Fail when not creating a duplicate, while the parent transaction then shows its Status as Success.
For asynchronous transactions and sub-transactions, refer to Parent and Sub-transactions for Asynchronous Transactions.
The Log section on the Transaction base tab displays Message and Severity details of transactions performed by VOSS-4-UC. For example, if the Severity has the status of error, the Message section can be expanded to inspect the error, and optionally copy it send it to Support. If a workflow is inspected, a separate log entry provides details of each step with a log message as Step n, starting with Step 0. For more details, refer to the topic named Transaction Log Example.
The Resource tab, which has content for transaction types where a resource changed, displays the additional information, depending on the transaction type:
The Back button on the button bar can be used to navigate to the previous screen, for example from the parent transaction screen to the list view of all transactions.
You can only view transactions that are relevant to your specific hierarchy level. For instance, if you are logged into the system as a Customer Administrator you will be able to view all transactions that were performed at the customer for which you are the administrator. This includes transactions that were performed at any of the sites that belong to the customer. If you are logged in as a Site Administrator you will be able to view only the transactions that were performed at your specific site. Refer to the topic on Data Partitioning in the Core Feature Guide and to the API Guide to view transactions by means of the API. The steps below can be followed on the Admin Portal.
Choose Administration Tools > Transaction.
By default, the Transaction list view shows all parent transactions in progress or executed. This is indicated in the Status column of the list.
If you also want to see the child transactions (sub-transactions) in the list view, select the parent transaction. The list view shows both parent and sub-transactions.
For completed transactions, the Status column displays either Success, Success With Async Failures, or Fail. Failed transactions are highlighted in red by default, but this can be overridden in the Theme if required. An exclamation icon is also displayed next to the word Fail.
The Detail column provides additional details on the transaction if available. See "Transaction Details" for more information.
The Rolled Back column displays either No or Rolled Back - the latter for any failed transactions (with Status is Fail) that have been rolled back. See also Transaction Logging and Audit.
Click an individual transaction or sub-transaction (if required) to show a detailed view. If the top-level transaction has the status Success With Async Failures, the list of failed async transactions show below the list of sub-transactions. The failed async transactions can be at any level below the top-level transaction. Click the transaction to see the details of the failed async transaction(s). The Detail also shows the number of failed async transactions.
You can only view transactions that are relevant to your specific hierarchy level. For instance, if you are logged into the system as a Customer Administrator you will be able to view all transactions that were performed at the customer for which you are the administrator. This includes transactions that were performed at any of the sites that belong to the customer. If you are logged in as a Site Administrator you will be able to view only the transactions that were performed at your specific site. The steps below can be followed on the GUI.
Click Administration Tools > Transaction. The Transaction list view is displayed. The following information is displayed for each transaction:
By default, the Transaction list view shows all parent transactions in
progress or executed. This is indicated in the Status column of the list.
Parent transactions are identified by a 
preceding the Id number.
If you also want to see the child transactions (sub-transactions) in the list view, click the Filter button, check the Include Sub-transactions check box and click Search. The list view refreshes and shows both parent and sub-transactions.
Sub-transactions are identified by a preceding the Id number.
For completed transactions, the Success column displays either 'Success', 'Success With Async Failures', or 'Fail'. Failed transactions are highlighted in red by default, but this can be overridden in the Theme if required. An exclamation icon is also displayed next to the word 'Fail'.
The Detail column provides additional details on the transaction if available. See Transaction Details for more information.
Click an individual transaction or sub-transaction (if required) to show a detailed view. If the Include Sub-transactions check box is not checked, you can view details of the sub-transaction by clicking on the relevant parent transaction, and then clicking the required Link in the Sub Transactions area of the detailed Transaction view.
If the top-level transaction has the status 'Success With Async Failures', the list of failed async transactions show below the list of sub-transactions. The failed async transactions can be at any level below the top-level transaction. Click on the Link in the Transaction column to see the details of the failed async transaction. The Detail column of the sub-transactions also show the number of failed async transactions.
Refer to the topic on Data Partitioning in the Core Feature Guide and to the API Guide to view transactions by means of the API.
The transaction log is available on the user interface after a bulk load transaction has been run. Refer to the topics on transactions and viewing transactions in the documentation.
Go to the Transaction menu. Bulk load transactions show in the log:
In the list view, the bulk load is shown in the Action column of the log. If the bulk load was scheduled, this is shown as a schedule with the detail column indicating it to be a bulk load. The Action column will show "Execute Bulk Load" or "Execute Schedule" respectively.
The submitted, start and stop time for the entire bulk load transaction is also shown.
The Detail section will hold the name of the file that is bulk loaded as well as the workbook sheet number and the number of successful rows out of the total, for example:
[ 8/9 ] succeeded from [ 1 ] sheet in data_Users_bulkloadsheet.xlsx.
Checks are made to validate the user's access profile, the provided hierarchy information and data constraints for the bulk load transaction when updating the target models. The parent bulk load transaction will show the error message if this validation fails and no rows will be loaded.
Where rows are loaded, each row in the bulk load sheet appears as a sub-transaction within the bulk load transaction. The Message box shows the number of successful and failed rows loaded.
For each loaded sheet, bulk load transactions are run in series for each row. Multiple bulk load sheets can be loaded and these transactions will load in parallel.
Sheet rows can be processed in parallel. The sheet should then not contain multiple, sequence dependent models. Refer to Bulk Load Sheet Layout.
For each row of the bulk load sheet carrying out the default add action, a Create action is shown on the list of transactions. Sheet rows that led to a successful Create action have a Success status, while rows that failed show a Fail status. If a row fails, the load process continues. For failed actions, the transaction can be selected to show the error message.
If one or more rows of the sheet failed to load, the Bulk Load Sub Transaction shows a Success status, while the Log list will show "error" for failed rows.
On the list of sub transactions, you can inspect the details of each sub transaction. For example, the submitted, start, and stop time for the bulk load sub transaction corresponding with a row on the bulk load sheet is shown. In the case of a failed sub transaction, further information about the failure - such as the error message and row data - is shown in the sub transaction.
A canceled bulk load transaction means the Processing worksheet sub transaction, as well as all sub transactions within the worksheet transaction in a Processing or Queued state, will fail.
For parallel transactions, multiple resource transactions may be in a Queued or Processing state. By default, 14 rows are processed in parallel. Refer to Bulk Load Sheet Layout for more details. If a worksheet transaction fails as a result of bulk load transaction cancellation, subsequent worksheet tabs in the bulk load workbook will not be processed by the bulk loader.
The VOSS-4-UC transaction engine ensures that configuration changes are made efficiently and reliably.
In the event of a transaction failure or error, VOSS-4-UC 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 data sync transaction contains sub-transactions that record each device model operation that takes place during a data sync action, for example add, update and delete.
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 in a queue before they are actioned:
Bulk load, data syncs and provisioning workflows are restricted to have no more than 10 sub-transactions queued at any given time.
In addition, bulk load transactions are also restricted to have no more than the number of sub-transactions queued and processing at any given time than is specified as a parallel_transaction_limit value in the sheet header. For example, if a parallel_transaction_limit of 50 is specified and 45 of its sub-transactions are currently processing, then only 5 items would be allowed to be queued. Without this limit, when other transaction workers become available, they would have been able to consume enough queued items to exceed the limit. Refer to the topics on the bulk load sheet layout for more details on parallel_transaction_limit.
These queue limits are in place in order to prevent the transactions at one hierarchy from using all queue resources. Queuing is carried out across hierarchies in a round robin manner.
Parent transactions can run concurrently, but their sub-transactions run serially. There is priority in parent transactions so that user input such as adding on a GUI form will be prioritized over a running import or bulk load process.
The following diagrams show an example transaction flow and also the relationship between parent and child transaction queues and workers.
This section aims to examine the transactions, sub-transactions and logs that are displayed when an example wizard is executed.
The aim of the wizard is to to provide the user with a series of steps to allow input and choices. When the wizard is executed, a Workflow is run and this is displayed as an Action on the Transaction list.
The workflow executes tasks to:
After the wizard is run, the sub-transactions show the actions of the workflow. In the example, only the Unified CM is selected. The first action in the wizard is to execute a workflow, that results in three sub-transactions. The first sub-transaction is itself a workflow that carries out three actions:
Execute : VOSS-AddCustomerWizard-PWF
The transaction log shows all the steps of all the workflows that are executed. The first log entry of the wizard is at the bottom of the log list. The first step of each workflow is marked as Step 0.
The figures below show the example wizard flow and the corresponding logs.
