[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.
Additional tabs may display for transaction details:
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:
On the Admin Portal, the sub-transaction list will show below the transaction details if there are 10 or less sub-transactions. Otherwise, sub transactions display on a new tab on the page.
Sub-transactions 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.
Failed asynchronous transactions display below the sub transactions.
If there are more than 10 failed async transactions, these details display on a new tab on the page.
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:
You can only view transactions that are relevant to your specific hierarchy level. For instance, if you're logged into the system as a Customer administrator you'll be able to view all transactions that were performed at the customer for which you're the administrator. This includes transactions that were performed at any of the sites that belong to the customer.
If you're logged in as a Site administrator you'll be able to view only the transactions that were performed at your specific site.
Note
See the topic on Data Partitioning in the Core Feature Guide and to the API Guide to view transactions by means of the API.
To view transactions in 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.
To view 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.
Click an individual transaction or sub-transaction (if required) to show a detailed view.
For top-level transactions with status Success With Async Failures, the list of failed async transaction display below the sub transactions. If there are more than 10 failed async transactions, these display on a separate tab on the page.
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.
Related Topics
Transaction Logging and Audit in the Core Feature Guide.
Overview
Once you run a bulk load transaction, you can view its transaction details on the Transaction Log.
Related Topics
Transaction Logging and Audit in the Core Feature Guide
View a Transaction in the Core Feature Guide
View Bulk Load Transaction Details
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.
Failed asynchronous transactions display below the sub transactions. If the number of failed asynchronous transactions exceeds 10, these details display on a new tab on the page.
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.
| Title | Description | Details |
|---|