What are Bridges?

Bridges are the platform's mechanism for connecting systems to the forms for working with and displaying the information. Bridges generally provide read-only access into another system by containing the code for

• Accessing the system
• Querying the system
• Formatting the system response into a standard format

Use Bridges to access any system that has an API. Bridges make the API calls, handling the login, the call, and formatting the results into a standard format regardless of the system being contacted.

Why do Bridges Exist?

Bridges create a standard and consistent interface for interacting with systems for the form developers. The form developer can access an AD Bridge the same way as they would access ServiceNow. Form developers don't need to know what system they are accessing, just what data they want and the data the bridge will provide.

Bridges also prevent form developers and platform admins from having to perform authentication, send the queries, and format the results of the system in question. It does not matter if that system uses a REST API or a SOAP API. That is all handled inside the bridge. The platform admin just has to be able to know the data in the system being connected to well enough to map that data and build the correct query structures. The rest is taken care of already.

Advantages and Disadvantages

Many of the advantages have already been laid out:

• Simplicity of interaction with searches
• Consistency in returned data
• Easy set up for form developers
• Simplified set up for platform admins

There is one item that tends to qualify as both an advantage AND a disadvantage, depending on the system, search, and individual circumstances:

• Bridges log in to the recipient system with one login. This allows a user to retrieve any desired data regardless of individual permissions.

Other potential disadvantages:

• Form developers can only use bridges already configured. They must reach out to platform admins to configure new bridges.
• It is possible for platform admins to set up bridges with obscure names for attributes, etc, which makes bridges difficult to use for form developers. It is important the platform admins keep their audience in mind when setting up bridges and don't just use the names that match the system being searched for the fields. This may not be helpful or useful for the form developers.

How Bridges Work

The bridge itself is code that interacts with a third-party system to make queries to and standardize responses from that system. A bridge can be a relatively simple pass-through or a complicated system that handles paging, sorting, and such needs. This will depend on the needs of both the system being interacted with and the use cases the bridge is needed for. This code is what is loaded into the Agent.

Bridge Models are what set up the attribute names to be used in requests, the queries that are defined for the bridge, and the map of the elements of the response (e.g. which fields on the third party system) to the attributes that have been set up. The names of the attributes in the model do not need to be named the same as what is being mapped into that space. For example, you could map cn from LDAP into an attribute called username; or you could map both first and last names from the source into one attribute called Full Name. This allows attribute names to be consistent across sources of data and queries to be made in a consistent manner (from the viewpoint of the Kinetic Form Developer) regardless of the source of that data. For example, a bridge for BMC Remedy could map Remedy Login ID to username and a bridge for LDAP could map cn into username so the Kinetic Form Developer always passes username to the query and don't even need to know what source is being used.

Logging

When there is an on-prem Agent, the logs for that Agent are not aggregated with all the other logs for the space. These would need to be examined in the Agent.

NOTE: When the Agent is on debug, all parameters are logged to the Agent logs for all bridges. This is generally key in debugging but can be problematic if sensitive information is being passed. Debug logging level is recommended for use in production systems only while actively debugging issues.

Building Bridges

Building bridges is now a one-step process. You add the bridge into Space > Plugins.

Creating a new bridge is as simple as selecting an agent and adapter:

And then setting up the slug and the required properties for that adapter.