Application Module Overview
A quick overview of the Unifi Application and its modules.
Unifi Integration Designer
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.
Unifi Operations Portal
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).
Dashboard
This is a quick link to the legacy Unifi Dashboard which displays reports providing operational insights into the data being exchanged.
Bonding
The bonding tables are used to manage the state of the connection between the two records in each system.
Bonds
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.
Bonded Attachments
Table: x_snd_eb_attachment
Bonded Attachment records track the synchronisation status of attachments on the record that has been bonded.
Transport
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.
Transactions
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.
Stages
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.
HTTP Requests
Table: x_snd_eb_http_request
HTTP Requests are the lowest level of communication, containing the raw data that is exchanged between systems.
Configuration
Processes
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.
Integrations
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.
Connections
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.
Messages
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.
Fields
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).
Field Maps
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).
Message Scripts
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)
Response Actions
Table: x_snd_eb_response_action
Response Actions are interceptors that allow you to customise the way responses are handled.
Diagnostic
The Diagnostic module is a link to a diagnostic test that can be run to check the configuration of your integration.
Polling
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.
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.
Poll Processors
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.
Poll Requests
Table: x_snd_eb_poll_request
The Poll Request is an operational record which stores the details and outcomes of a scheduled poll.
Administration
Activity Logs
Table: x_snd_eb_activity_log
The Activity Logs module displays all the entries to the Unifi Activity Log table from the current day.
Data Stores
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.
Properties
The Properties module is where you will find the global system settings for the Unifi application.
Scheduled Scripts
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.
System Logs
The System Logs module is a quick link to the ServiceNow system logs and shows errors and warnings from the current day.
Self-test
The Self-test module is a link to a suite of internal tests that can be run at any time.
Support
Get Help
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.
Last updated