A Mapping in Kinetic Bridging is used to relate the abstract values of the model to the actual fields/elements of the data store.
Using the mapping from the previous article we will configure the fields from the KS_SAMPLE_People form that is included with the install of Kinetic Survey/Request.
The first step is to select a model from the drop-down at the top of the page. This sets the attrichutes and qualifications that you will be using.
Next, click on add beneath the Model Mappings table to start configuring your mapping.
Model Name is filled in automatically and cannot be changed.
Name is the descriptive name you want for your mapping. It can be the same as the model, but does not have to be.
Bridge Name is chosen from the drop-down of available bridges (Bridges Tab - see separate article)
Structure is the name that references the element the data you are bridging to is stored in. In this case the bridge references a Remedy form.
Once you add the Mapping, the attricutes and the Qualifications are set based on what you setup for your Model.
This shows a mapping with the Attributes from the Model already configured to reflect the actual data (fields on a Remedy form in this case). One of the Qualifications has been completed. Incomplete qualifications are marked in red.
Here is an example of a completed attribute mapping.
The Model Mapping and Attribute are set and read only. The field mapping is what attachesthe attribute to the actual data source.
When you click Add Field th following dialog appears:
The field name references your data source, and will be configured in your bridge.
Once you enter the name, the workflow will format it to match what the bridging application is expecting. For example if you data field is Email, the workflow will format is as <%=field["Email"]%>.
All of the Attributes you configured for your Model on the structures tab are available here, and need to reference a field from the data source.
After relating the attributes to their real data elements, the qualifications need to be configured. The qualifications and their parameters were originally configured as part of the Model. However, they were only names with associated parameters. The qualification mappings describe the "actual" qualifications.
For eample, here is the qualification mapping for the "by Login" qualification:
The Model and Qualification cannot be changed. The Result Type is set when the Qualification was creatted in the Model. The Add Parameter drop-down references parameters that are associated to the qualification when it was created in the Model.
Here is the qualification from the model for the "by Login"
Since it only identifies the existence of the qualification - the specifics are done in the qualification mapping.
In the Query field you need to specify the actual qualification. In this case it is a lookup against the AR Login field using a login parameter passed to the qualification - 'AR Login' = "<%=parameter["Login"]%>". You could configure any combination of parameters and other values that your bridge can understand and use to return values. In this case it is Remedy syntax for a Remedy bridge.
When you reference this mapping in an event or dynamic text, you will be replacing this parameter with an answer or application/base value for the lookup (See future articles)
Here is an example of a query that uses multiple parameters:
'First Name' LIKE "<%=parameters["First Name"]%>%" AND 'Last Name' LIKE "<%=parameters["Last Name"]%>%"
Here is an example of query that uses Remedy wildcards (%):
'Full Name' LIKE "%<%=parameter["Full Name"]%>%"