.. _transaction_logging_and_audit:
Transaction Logging and Audit
-----------------------------
Activity on the VOSS-4-UC system results in transactions that are recorded.
The **Transaction** list view provides auditing information for each transaction.
View specific transaction details by clicking on a transaction. The **Back** button
on the button bar (or the **See all transactions** link on the transaction details
screen) can be used to navigate to the previous screen, for example from the parent
transaction screen to the list view of all transactions.
Details
........
Information recorded includes data such as:
.. tabularcolumns:: |p{3.5cm}|p{10.5cm}|
+-------------------------------------------------+----------------------------------------------------------------------------------+
| Info | Details |
+=================================================+==================================================================================+
| Transaction ID | Identifier of 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 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. |
+-------------------------------------------------+----------------------------------------------------------------------------------+
On the Admin Portal, details of a specific transaction are displayed when the transaction
is selected from the list view. Refer to :ref:`bulk_load_transaction_log`.
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 "Filtering Lists" for details.
Cancel
........
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.
Replay
......
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 an Admin Portal form.
Edit and Replay
.................
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,
or pop-up forms.
Edit and Replay 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.
.. note::
* 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 following user
information fields will not automatically update when changing the Username field:
* Entitlement Profile
* Firstname
* LastName
* Email
These need to be edited manually.
Sub-transactions
................
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.
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.
Logs
.....
The Logs section 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.