Model transform
Last updated
Last updated
Model transform is a feature where you as REST connector developer can manipulate the response from a REST API before returning it to the workflow. You can also use it to manipulate an outgoing object (body parameter).
Typical use case is when an API returns data like this:
When used as an output model in REST connector you would end up with an output looking like this in Flow:
This can be managed with Flow Script, but it can be more convenient and efficient to do the transformation inside the connector. Especially if the connector is used in multiple workflows.
The output of the remote operation is of course still the data above, so we have to define a model to represent that data:
But we can also define the model that we want to expose to the workflow. Something like this:
Let's add the transformation.
Select "Model transformations" in connector tree and press the "NEW" button
Give the transformation a descriptive name and select source model and target model
Double click on the newly created transformation in the list, or select it from the connector tree. Something like this should be loaded:
So the actual transformation is done with c# code that you provide. Do not enter any code above //Transformation code start or below //Transformation code end
This is a very powerful feature. You are, however, limited to provide code that is compliant with c# 5.0. You are also limited to only use types from the following assemblies:
Note that not all of these assemblies are available by default. The "usings" that all transformation code uses can be changed here:
An example of transformation code for this situation could be:
Note that models are called 'Model_' followed by the name of the model.
All that is left to do now is to apply the transformation to the operation of interest:
Which is easier to work with as a workflow designer.
There are a lot more scenarios that this feature enables. You could for instance add new output members (composed of values from other members for instance) or hide members that are not of interest to the workflow designer.
The code will run with limited permissions. It is for instance not allowed to access the file system, so code such as
will not work and you will get an error in runtime.
Like incoming models there are scenarios where it makes sense to transform the outgoing models before it is sent to remote API. Let's assume the same data structures as above are in action here as well. The transformation now needs to be from the model 'transformedOutput' to model 'operationOutput'. Names now becomes a bit off, since we are not dealing with output, but I'm sure you get the picture.
Then the transformation code could look something like this:
Apply the transform.
In the machine step the operation input would then look like this:
Without the transformation the machine step would look like this:
There certainly are situations where the later is preferred, maybe there is already a table with property+values available and so forth. With the transformation feature you can control what best suites your scenario.
Now when the connector is used in a workflow the output from the operation will look like this: