Introduction

While some forms are self-contained, most need some way to interact with other systems and applications. Our front-end form builder uses Bridges, Bridge Models, and Bridged Resources to get and present information from those other sources.

Goals

The goals for the article are:

• Understand the concept of Bridges
• Learn about Bridge Models
• Learn about Bridged Resources
• Understand how all three interact

Bridges

Bridges allow you to access data from systems internal and external to Request. Examples include LDAP, ServiceNow, and Salesforce. For the purposes of this class we'll access data from Datastores and use it to simulate external sources. Bridges are defined at the Space level and can be used throughout all the kapps. Take care that any change in a bridge doesn't harm Bridge Models you may not be using.

Bridge Model

A Bridge Model is made from three parts:

• General - Name, Status, Bridge, and Structure of the target system
• Attributes - field names mapped to values in the target system
• Qualifications - specific queries against the target system

Like Bridges, Bridge Models are defined at the Space level. Be cautious making changes, Bridged Resources are not updated automatically to reflect changes to the Bridge Models. Changes to Bridge Models may break Forms.

General

The General console for Bridge Models contains the name and connection information.

• Name - required field with descriptive text
• Status - defaults to Active and used to determine if the Bridge Model is available
• Bridge Slug - required field links to the available Bridges for the Space
• Structure - required field determines the specific object that data comes from. Examples include database tables or forms.

For Datastores in the Request Platform, the Structure needs to also include the Form Slug of the Datastore Form. In the image above you can see the format of "Datastore Submissions > person". person is the Form Slug of the example Datastore Form.

Attributes

Attributes are used to relate a Name to a mapped value in the target system/Structure. For example, a Site Number could be related to a specific column in a table (Structure) in a database (defined by the Bridge). In our examples we are going to use a Datastore, so our attributes are related to fields on a Datastore Form (see the activity for specifics on a Datastore Form).

Each Name is related to a specific Mapping from the Bridged Structure.

Adding a new attribute requires a new unique (for this Bridge Model) Name and then a definition of its Mapping. The Mapping wraps the object from the Structure in the following code - ${fields("NAME")}. To complete the mapping, replace the NAME value with the object value. For example, in a Form you get the value of a submission using the following - values[Site] that represents an answer to a question named Site. To map this to an Attribute Name you have the following - ${fields("values[Site]")}.

Even if you aren't going to use them right away, it is helpful to map all the different objects from your Structure when you create the Bridge Model.

Qualifications

Qualifications are used to define the results returned from the Structure. For example, getting all the Active (Status = Active) sites or retrieving a set of Person information by the ID.

The Qualification is dependant on the system you are accessing. For a database table Structure, it is a SQL Query. For a Datastore Submission it's a REST API call.

Because we are using a Datastore in our activity, here is an example of all sites with an Active Status:

index=values[Status]&q=values[Status]="Active"

If you want to pass a parameter to the query, you can use the </> option to get add it to the Query:

index=values[User ID]&q=values[User ID]="${parameters('User ID')}"

The parameter is displayed in the Bridged Resource on the Form. You can add a static or dynamic value (field from your Form) at that point (see below).

Test

Being able to test your Bridge Model is a tremendous time saver. Testing lets you find any issues, before trying to use the Bridge Model in a Form.

Here's an example of a test for the Person Datastore Form:

The Test is designed to be used after you have created at least a minimum number of Attributes and Qualifications. You select the attributes to display (above are First and last Name), and then select one of the qualifications. If the qualification requires a parameter, you are prompted for it.

The Test Results section shows you either the returned values, or an error message if your test fails.

Bridge Resources

Bridge Resources are the tie between Bridge Models and a specific Form. The Bridged Resource is added under Form Settings (first element in the builder). Bridged Resources are available to multiple elements within the form.

The basic dialog for creating Bridge Resources.

• Name - descriptive text
• Status - Active is default
• Model - refers to the Bridge Model
• Qualification - defined by the Model selected
• Parameters - determined by the Qualification (if needed).

Here is a completed Bridge Resource form:

This bridged resource could be used to get User data and fill fields when a Form is loaded.

Bridged Resources are used for events, default values, list values, set fields (an event type), and I'm sure a few other pieces.

In the Next Article

Now that we have data coming from Bridges Resources, we can use it in Events.

Activity

Create a dynamically driven dropdown menu from a Datastore.

1. Create a Datastore with Site information. For example, cities by state.
2. Create a Bridge Model for the Datastore. You can use the built-in functionality of Kinops for this.
3. Create a dynamic menu based on the data using a Bridged Resource.

For example, create a static dropdown of state names. Then create another dropdown that dynamically displays cities based on those states.