Bridge Models

Overview

Bridge models (also referred to as just models) let you create abstractions of your data. This might not seem important initially, but imagine you're a Kinetic Platform developer who just finished building 34 Kinetic forms. Each form uses a bridge to get a list of locations from your Acme service. As soon as you're done, your manager runs to you and says, "We are shutting down the Acme service and need to get the locations from the database instead!"

You don't panic. You know the abstraction layer between your 34 forms and the bridge is getting the locations. All you need to do is update the Bridge and Model, and then you are good to go.

Kinetic Platform developers use predefined bridge plugins to define abstractions that form and bundle developers can leverage to fetch data. As an example, a form developer can build a dropdown using a bridge and model a Kinetic Form developer can build a dropdown.

Model Building

Models have two major components: attributes and qualification mappings.

Attributes

Model attributes are an interface mapping between the source system's field names and the model's field names. The advantage of the interface is that a model can be pointed to a new source system without the need to update the model usage.

Model attributes let bridge return data be mapped to a custom name, so forms reference the model's custom-named attributes, not the source data. This means that a model can "swap out" the source system. Since forms reference the model attribute name, the mapping to the source system's name can be updated without affecting the forms that use the model.

Accessing Source System Data

It is important to know the structure of the data returned from your source system. The bridge adapter will take the values in fields and attempt to map them to the data. You will need to know the return data from the source system to do the mapping.

Example: The following mapping will pass the "First Name" field to the bridge adapter: ${fields("First Name")}. The bridge adapter will use "First Name" to access a value from the return data after the call to the source system.

Qualification Mappings

Qualification mappings are a mechanism for passing parameters to the source system. For example, a ServiceNow article search of query="How to build" would have a qualification mapping of query=${parameters("Query Value")} where "Query Value" is the parameter name that would map to the query value.

The qualification is passed to the bridge adapter (where it is added in most cases) as a URL query parameter that an HTTP request passes to the source system.

Qualifications have three parts:

• Name: Forms use the qualification name to identify which qualification to use for the model.
• Result Type: The result type defines whether the qualification will return one (Single) or multiple (Multiple) results.
• Query: This qualification passes the query and parameters to the bridge adapter. These values are normally passed along to the source system.

Note: An error will occur if the qualification is configured with a Result Type of "Single" and the bridge call results return multiple records.

Each model can have several qualifications defined.

What Form Builders Need

Once the models and mappings are set up, all form builders need is what is set up in the Models portion of the bridge setup. These details will be available in the Form Builder. This is why models and mappings must be useful and readable (for example, spelling out "Last Name" rather than using a value like "sn"). Even if you are really familiar with the bridged system (such as Active Directory), the beauty of bridges is that your form builders don't even need to know what system they are talking to. You may decide to have a SQL DB for users in dev and your AD in prod. As long as the bridge model attributes and qualifications are all the same, it doesn't matter what they map to.