Application Modules
This is a quick link which will open the Unifi Integration Designer page in a new browser window. From here, much of the configuration of your integrations can be carried out in a more intuitive and efficient manner.
This is a quick link which will open the Unifi Operations Portal page in a new browser window. It provides a live, real-time view of the last 20 Transactions processed & the Bonds that have been worked on today - showing their state & grouped by Integration. From here, you can jump straight into the relevant records (e.g. Transaction, HTTP Request, Bond, bonded record).
This is a quick link which will open the Unifi Test Assistant page in a new browser window. From here, you can view, run and analyse the automated tests in your instance.
This is a quick link to the legacy Unifi Dashboard which displays reports providing operational insights into the data being exchanged.
The bonding tables are used to manage the state of the connection between the two records in each system.
Table: x_snd_eb_bond
A bond is a record that joins an integration to an internal process record (i.e. a ticket) by storing the internal and external system references together, along with the integration and other bond specific data. It also stores a commentary of the full history of the integration actions, making it very easy to see what has happened across the lifetime of the bond.
Table: x_snd_eb_attachment
Bonded Attachment records track the synchronisation status of attachments on the record that has been bonded.
The communication tables facilitate the transportation, extraction, transformation and loading of data communications. They are used to simplify development and debugging, aid in operations management, and provide full insight into the details of every data exchange.
Table: x_snd_eb_snapshot
A Snapshot is a representation of the bonded record and data from the relevant message that created/updated it. Whenever there is an update to a bonded record, Unifi will take a snapshot of it and capture it in a Snapshot record. The Snapshot is the key to facilitating automated Integration testing.
Table: x_snd_eb_transaction
A Transaction is essentially a container used to group together the stages and requests created for single message exchange. Every inbound or outbound message belongs to a Transaction and this includes response and receipt messages.
Table: x_snd_eb_stage
The Stage table allows data to be extracted and stored before it is processed. Although a requirement for asynchronous messaging, this separation makes it very easy to develop and maintain the integrations that the application supports.
Stage is configured so it can be extended for each process.
The introduction of Dynamic Stage now means there is no need to manually create the staging table.
Table: x_snd_eb_http_request
HTTP Requests are the lowest level of communication, containing the raw data that is exchanged between systems.
Table: x_snd_eb_process
The Process record allows integrations to be aligned to particular process. Many processes can be made available for integrations, and many integrations can belong to each process.
Process records define the top level configuration that all integrations using this process will follow. A typical process to be made available for integration would be Incident.
Table: x_snd_eb_integration
An Integration acts as the top level container for configuring a process to be used by a single external or internal supplier. All the options specific to the integration are set on this record.
An integration is only active when a connection is active.
Table: x_snd_eb_connection
Connection records allow many endpoint access configurations to be set up for a single integration. This makes managing access for different instances very easy, such as development, test and production.
Only one Connection can be made active at any time. Making one Connection active will automatically enable the Integration and disable all the other Connections. Disabling a connection will disable the Integration.
Table: x_snd_eb_message
The Unifi application uses a message centric architecture, meaning that every outbound/inbound request is configured as a single Message. A Message might be a create or update request, a receipt or a response. All Messages will send/receive a response Message and asynchronous Messages can also be configured to send/receive a receipt.
Table: x_snd_eb_field
Fields simplify and bring additional functionality to the configuring of Messages & Message Scripts. They allow Message Scripts to be broken down into smaller, reusable components.
A Field record defines the processing of a discrete component of a Message and often represents the handling of an individual field on the source/target record (e.g. Short description). They are also used to define the objects that will carry other Transaction specific data (e.g. Name, Time stamp, Source reference, Target reference).
Table: x_snd_eb_field_map
The Field Map defines the behaviour, or ‘type’ of a Field. It defines template code into which details from Field records are substituted. It has a template script field for each of the Message Script types (Source to Stage, Stage to Request, Payload to Stage, Stage to Target).
Table: x_snd_eb_message_script
Data extraction, transformation and loading is handled by the Message Scripts. Each message can have custom scripts added that facilitate one of the following scenarios:
Payload to Stage (Inbound)
Stage to Target (Inbound)
Source to Stage (Outbound)
Stage to Request (Outbound)
Table: x_snd_eb_response_action
Response Actions are interceptors that allow you to customise the way responses are handled.
Table: x_snd_eb_event_action
Event Actions are a means of triggering an action from an event. In Unifi, we throw events for Transaction State changes. Like standard ServiceNow Script Actions, Event Actions respond to those events.
The Diagnostic module is a link to a diagnostic test that can be run to check the configuration of your integration.
In cases where it is not possible for a remote system to send us the data, we can make a scheduled request for it using Pollers.
Table: x_snd_eb_poller
A Poller makes a scheduled request to a remote system. It is a configuration record which defines the frequency of polling and which logic to use.
Table: x_snd_eb_poll_processor
The Poll Processor is a configuration record which contains the logic that will be applied when polling a remote system for data.
Table: x_snd_eb_poll_request
The Poll Request is an operational record which stores the details and outcomes of a scheduled poll.
Table: x_snd_eb_integration_test
An Integration Test is the overarching automated test record which correlates to the Bond. The test comprises each of the Integration Test Scenarios (which correlate to the Transactions on that Bond).
Table: x_snd_eb_integration_test_scenario
An Integration Test Scenario represents a Transaction on a Bond. Each contains the relevant Test Scenario Data objects for the particular Scenario.
Table: x_snd_eb_integration_test_scenario_data
Test Scenario Data is a snapshot of all the relevant records created during the processing of a Transaction and is used to both generate the test and ascertain the results of each test run.
Table: x_snd_eb_integration_test_result
When you run an Integration Test, Unifi creates an Integration Test Result record to capture the results of the test run. Each Integration Test Result record will correlate to the Integration Test that was run.
Table: x_snd_eb_integration_test_scenario_result
Here you will find the results of the individual Integration Test Scenario. Whenever you run an Integration Test, for each Integration Test Scenario, Unifi creates an Integration Test Scenario Result record to capture the results of the test run.
Table: x_snd_eb_activity_log
The Activity Logs module displays all the entries to the Unifi Activity Log table from the current day.
Table: x_snd_eb_data_store
A Data Store is simply a key-value pair stored in the database that is available to all records in the system. They are used primarily in Message Scripts and Poll Requests when you want to get and set functional data that is relevant to the integration but does not belong on the target record.
The Properties module is where you will find the global system settings for the Unifi application.
Table: x_snd_eb_scheduled_script
The Scheduled Scripts module displays the scripts which are automatically created by the system in order to perform tasks.
The System Logs module is a quick link to the ServiceNow system logs and shows errors and warnings from the current day.
The Self-test module is a link to a suite of internal tests that can be run at any time.
The Get Help module is a quick link to the Unifi Portal welcome page where you will find links to our Documentation site along with ways to connect with us for application support.
