Bridges are the Kinetic Platform's mechanism for connecting systems to Kinetic forms. A bridge combines code for accessing the system, querying it, and converting the system response into a standard format. This consistent interface means that a form developer can access AD information the same way as they would access ServiceNow. The form developer doesn't need to know how to use the system or whether it uses a REST API versus a SOAP API. Instead, this is all handled by the bridge. The only requirement is that the Kinetic Platform administrator knows the data in the system being connected to well enough to map that data and build the correct query structures.
A bridge can be a relatively simple pass-through or a complicated system that handles paging and sorting. The complexity of the bridge will depend on the needs of both the system being interacted with and the use cases the bridge is needed for. Bridge code is what is loaded into the Kinetic Agent.
Bridge models set up the attribute names to be used in requests, the queries defined for the bridge, and the map of the response elements (for example, which fields on the third-party system) to the attributes that have been set up. The model attribute names do not need to be 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 keeps attribute names consistent across data sources and ensures that queries are made consistently from the viewpoint of the Kinetic form developer, regardless of the data source. For example, a bridge for BMC Remedy could map the Remedy Login ID to "username." In contrast, a bridge for LDAP mapped "cd" to "username." The form developer would always pass "username" to the query and wouldn't need to know which source was being used.
In a customer-managed environment, the logs for the Agent installation are not aggregated with all the other logs for the Space. You must use the Agent to examine those logs.
Note: When the Agent is on debug, all parameters for all bridges are logged to the Agent logs. While this information is key for debugging, it can be problematic if sensitive information is being passed. Debug logging level is recommended for use in production systems only while actively debugging issues.
Bridge information is stored in the Space console. From the Configuration section, select Plugins, then select the Bridges tab.
Follow these steps to create a new bridge:
- Click New Bridge
- Select an agent and an adapter from the drop-down lists.
- Click Next.
- Enter a slug for the bridge.
- Fill in the required properties for that adapter.
Updated about 1 month ago