Bridges are the mechanism the platform uses for connecting systems to the forms for working with and displaying the information. Bridges 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
This can be done to any system that allows API access. Bridges actually make the API calls, handling the login, the call, and formatting the results into a standard format regardless of the system being contacted.
Bridges create a standard and consistent interface for interacting with other systems for the form developers, regardless of what that other system is. They can access an AD bridge in exactly the same way they would access Samba; they can access Remedy exactly the same way they would access ServiceNow. They don't really even need to know what system they are accessing, just what data they want and what data each 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.
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 obsure names for attributes, etc, which make 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.
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 Bridgehub.
Also referred to as Bridging is the connection between this bridge in Bridgehub and the request portion of the platform. This involves providing the URL for that bridge in Bridgehub and then setting up models and mappings for the bridge.
Models and mappings are what set up the attribute names to be used in request, 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 request part of the platform 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.
Because bridge activities have two components (Request/models/mappings and Bridgehub), there could be two places the logging could be for an issue. The platform (Request/Model/Mappings) logs interactions between the request/submission and the models and mappings into the application log. The details of the query, request, and response from the third party system are in the bridgehub logs. The application log is generally the first place to look for issues for a bridge, but it can be necessary to dig deeper (into the bridgehub log) if the issue isn't clear from the application log.
NOTE: When bridgehub is on debug, all parameters are logged to the bridgehub 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.