Page History
In this example we would like to call a webservice, where car data is retrieved based on the license plate number. First step is to import the WSDL, which creates an implementation module containing the domain model specified in the XSDof the WSDL. The second step is to model the mapping between ‘our’ domain model and the domain model from the webservice, both forward and backward.
Our domain model
There is just 1 entity, representing a Vehicle:
WSDL domain model
The target module is generated by importing the WSDL. It has many entities defining a vehicle, all starting from the AudascanV4 entity with a one-to-one relation:
Besides that there are also the entities defining the request and the response:
Data mapping
In order to start using the webservice, we first have to build the request. After the webservice has responded, we have to read the data from the response.
The forward mapping, from our interaction module to the WSDL module, is used to build the request. The backward mapping, from the WSDL module to our interaction module, reads the data from the response and fills the profile with this data.
Forward mapping
When using the mapping to create the webservice request, you have to build the whole request. In other words, the entities geefAntwoordRequest, ABZAUDASCANCOMPLEETV4REQUEST and ABZAUDASCANCOMPLEETV4REQUEST_VT have to be created using the data mapping. Because the sourcemodel is simple, with only one entity, the mapping is also not very difficult. First we map the ‘geefAntwoordRequest’ entity:
This entity has no attributes, only a relation to ‘ABZAUDASCANCOMPLEETV4REQUEST’ called 'parameter':
The same applies to the ‘ABZAUDASCANCOMPLEETV4REQUEST’ entity. It also receives input from the ‘Voertuig’ entity, only the relation to ‘ABZAUDASCANCOMPLEETV4REQUEST_VT’ has to be filled:
For the entity ‘ABZAUDASCANCOMPLEETV4REQUEST_VT’ only the attributes have to be mapped:
Backward mapping
The backward mapping, from the response of the webservice to the ‘Voertuig’ entity, is a little more complex, because values have to mapped from several entities in the response, starting from the ‘AudascanV4’ entity. For this, we have to define ‘Additional context’:
Alert: in the additional context you have to use an expression which returns a single, unique instance. In the 'value/relation mappings' you can reason from this instance.
A common mistake is to define multiple instance mappings , using the ‘Or’, instead of ‘Additional contexts’:
In that case, for each instance mapping, a new instance for the target entity will be created!
From here we can start to map all the data:
As shown above, in the value mapping you can use data-conversion to convert the data into the appropriate format:
Besides that, it is also possible to combine attribute values (e.g. to concatenate strings, do calculations) from the source entities.
The image also shows that you can use conditions to set the values, for example to map a valuelist:
======
Step-by-step guide
| Info |
|---|
...
Overview
Content Tools