Kinetic Data – Models

Video Transcript

Hello, my name is Donnie Holmes, and I’m here to talk to you about models. Models within the kinetic platform are used to create an abstraction for your data, making it easier and more flexible to work with bridge plugins that fetch data for your forms and the underlying bundle.

A common example of this would be to populate a drop down menu with data fetched through a bridge and model. Models have two major components, attributes and qualification mappings. Attributes are an interface mapping between the source systems field names and the models 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 usages of the model.

Qualification mappings is a mechanism for passing parameters to the source system. In most cases, the qualifications are passed to the bridge adapter as a URL query parameter that HTTP request passes to the source system.

Let’s dive into the attributes and qualification mappings in a bit more detail. Model attributes are an abstraction that map’s the data being returned from a bridge to custom fields, forms can reference the custom named attributes of the model and not the source data.

This means that a model can swap out the source system, since forms would reference the models name. If the source system changed, only the model would need to be updated, the forms using the model would remain intact and would not require updating. Here’s an example of a generic model.

We’ve defined the following attributes email first name, full name, last name, user ID and user name. It is important to know the structure of the data that is returned from the source system, because the bridge adapter will take the value in each attribute field and attempt to map it to the source data.

Here’s an example of what the data from a bridge adapter might look like. In some circumstances, more advanced mapping can be done in the Attribute fields to better display data and to drill down into more complex data returns.

You can see that we matched the return data’s field to the mapping of each attribute we are interested in fetching and use the JSON dot parse method to drill down into the user properties object of the return data where we pulled out the user’s email and ID. We also constructed the full name of our user by combining several fields and their mapping into a single attribute.

Model attributes are a great way to format your incoming data into easily digestible formats for your form builders to use. Qualification mappings they have three parts the name, which is used by kinetic forms to identify which qualification should be used for the model.

The result type, which defines what type of results is expected by the model single or multiple, and the query, the parameters passed to the bridge adapter that will form the query being made to the source system.

To continue using our example from earlier, some source systems will allow you to define some aspects of the return data you’re trying to obtain. Here, we are asking for the first name, middle initial last name, user name and user properties. But this won’t always be the case.

Once the models and mappings are set up, all the form builders need is an understanding of the models fields, they will be able to see these details in the form builder. This is why it is so important that the model attributes his names are useful and readable. It enables your form builders to use the data they need without knowing anything about where the data is sourced from. And that’s how models can help your builders and developers to be even more powerful and flexible within the kinetic platform.