The Dataset Request is an operational record which stores the details and outcomes of an incoming dataset import or a scheduled dataset export.

An Dataset export can create many Dataset Requests depending on the dataset query and batch size.

A Dataset import is created when an incoming Dataset message containing an attachment with data is received.

A Transaction is a vehicle used in the flow of Messages on a bonded ticket. It is essentially a container for a Request/Receipt pair. The Transaction record contains the necessary fields to facilitate and track both the movement and the processing of the pair of Messages.

Functions

A Transaction’s primary functions are:

• To contain the Request/Receipt pair of Messages.

• Handling the queueing of Requests and Receipts.

• Tracking the state of the Transaction from two perspectives:

  • Transaction state

    • The condition of the Transaction from a movement (transactional) perspective (i.e. the condition of the transport of the data).

  • Process state

    • The condition of the Transaction from a process perspective (i.e. its relation to the business logic that’s in place).

  • Example:

    • System A sends a Request to system B to update the value of the urgency field on a ticket without having ‘ownership’ of that ticket. The Request is properly formed and authenticated and is received in system B.

      System B sends a response acknowledging the Request and then subsequently processes the Request asynchronously. If, on processing the Request from system A, system B discovers that system A did not have the authority to change the value of the urgency field, they would send a Receipt Message stating the error. That Receipt is also properly formed and authenticated and is received in system A without any problems.

      The Transaction state in this case would be set to ‘Complete’ as both the Request and the Receipt were transported successfully. However, the Process state would be set to ‘Rejected’ as system A did not have the authority to update the value of the urgency field.

State Control

One of the many defining features of Unifi is its ability to track the state of the Transaction from both a transport (What’s happening with the movement of the message?) and a process (How does the content of the message align with business logic?) perspective.

Having the combination of these two states is extremely useful and gives a far more precise understanding of the condition of the Transaction and opens up more options. This means, for example, that an analyst can see and has the opportunity to fix issues based on a process error without the need for technical support (Unifi won’t break an Integration for a process error). For transactional errors Unifi can throw events which can be correlated to send notifications, or trigger the system’s Incident process as appropriate.

Transaction State

Process State

Fields

The following table gives a description of the fields that are visible on the Transaction record:

Debugging

You can view the transaction logs from the Transaction record by navigating to the 'Unifi Activity Logs' related list, or from the Unifi Operations Manager portal. This hugely significant feature offers considerably more detail than is available with the OOTB ServiceNow system logs and puts that information right where you need it - saving an inordinate amount of time hunting through the [sys_log] table.

Activity Logs will be populated if logging is enabled when debugging. They are particularly helpful to ShareLogic when debugging Unifi itself.

Common Activity Logs

Transaction process next queued

Once the initial Transaction has completed, Unifi checks if there are any other transactions queued and processes them.

Request sending

Here Unifi is processing the outbound HTTP Request and sending it to the integrated system.

Transaction sending

Unifi is picking up the generated Stage data and generating an outbound HTTP Request.

Transaction receive message

A payload has been received from the external system and Unifi is processing that data and updating the target record within ServiceNow.

RestHelper

An inbound request has been received and generated an inbound HTTP Request.

Activity Log Sequence

Each of the logs relate to a specific part of the process flow, so depending on the direction of the Transaction the logs will occur in a different sequence. From a process perspective, the logs would occur as follows:

Inbound Message

• Inbound request: RestHelper (relates to the inbound HTTP Request), Transaction receive message (relates to the inbound Transaction).

• Corresponding outbound receipt: Transaction sending (relates to the outbound Transaction Receipt), Request sending (relates to the outbound Request).

• When Transaction completes: Transaction process next queued.

Outbound Message

• Outbound: Unifi Business Rule (relates to the logs defined in the Trigger on the process table being integrated), Transaction sending (relates to the outbound Transaction), Request sending

  (relates to the outbound Request).

• Corresponding inbound receipt: RestHelper (relates to the inbound Transaction Receipt), Transaction receive message (relates to the Receipt processing).

Replay

You can click the Replay button on the Transaction record to replay that transaction.

This will be used when testing/debugging. For example, if there is a transactional error, after you have investigated the cause & made any required changes you will want to replay the Transaction to check if the error clears.

The Poll Request is an operational record which stores the details and outcomes of a scheduled poll. It represents a single instance of a being run (a Poll Request record is created each time a Poller is run).

HTTP Request records are created every time an HTTP Request is generated for sending to or receiving from an external system. They contain all the low-level data about the individual request; the headers, the payload, the URL, timings, etc.

These records are extremely useful for developing and debugging integrations because of the immediate availability and contextual relevance to the integration you are developing. You will often find that it is easier to debug an integration from within Unifi than it is from any external system.

State Control

The Request will be inserted in a ‘Ready’ state. Unifi will then asynchronously pick it up and process it. The following table defines the state field value choices:

HTTP Request Fields

The following table gives a description of the fields that are visible on the HTTP Request record:

Request Fields

The following table gives a description of the Request fields that are visible on the HTTP Request record:

Response Fields

It is often far quicker and easier to tell what has been sent from the integrated system by looking at the values in the Response fields in Unifi than it is to get the same information from the system that has sent it.

The following table gives a description of the Response fields that are visible on the HTTP Request record:

Debugging

Unifi logs can be viewed by navigating to the 'Unifi Activity Logs' related list.

Activity Logs

The logs that relate to the HTTP Request are as follows:

RestHelper

An inbound request has been received and generated an inbound HTTP Request.

Request sending

Here Unifi is processing the outbound HTTP Request and sending it to the integrated system.

Replay Request

You can click the Replay Request button on the HTTP Request record to replay that request.

This will be used when testing/debugging. For example, if the Request errors you may want to edit the payload & then replay the Request to check if the error clears.

Definition

A Snapshot is a representation of the bonded record and data from the relevant message that created/updated it.

A snapshot is created in one of two scenarios:

• A process record is updated and one or more integrations are interested in it (outbound).

• A process record is updated by an integration (inbound).

Processing

In the Unifi Transport Data Flow process (see the diagram here), the Snapshot record sits between the Stage and the source/target record. In order for it to be an accurate representation of the source/target record, the Snapshot is taken the same side of the relevant Message Script.

Outbound

A snapshot is taken of the source record prior to running the Source to Stage Message Script (before transforming any data).

Inbound

A snapshot is taken of the target record after running the Stage to Target Message Script (after transforming any data).

Fields

Snapshots can be viewed by navigating to Unifi > Transport > Snapshots.

The top of the Snapshot record looks like this:

The bottom of the Snapshot record looks like this:

The following table gives a description of the fields that are visible on the Snapshot record.

Stages are a snapshot of the data either at the time of being sent or received. The Stage stores the snapshot of data, which is what facilitates the asynchronous exchange of Messages. Having that data called out into separate fields provides a clean & clear view of the data being sent/received, which in turn can provide a clearer picture of the cause of any potential discrepancies in the mapping of data that is being translated*/transformed**.

Fields

The following table gives a description of the fields that are visible on the Stage record:

The following is an example of a Stage record: