When you need to perform a schema validation in runtime while using the trigger, When a HTTP request is received, Logic Apps gift us the possibility to perform that validation recurring to a setting existing in said trigger.
Note: If you provide a sample of the JSON message, as you see below, the designer will generate the JSON schema for you based on that payload.
In this example, we want to generate the JSON schema for this message and make the field Location required. Next, we access the trigger settings and turn on Schema Validation.
By default, Schema Validation is off.
Next, using Postman, if we send a request, and since we have nothing more configured than the schema validation, nothing will happen. The message enters the Logic App, and a run occurs, but since we configured that, the input must have the Location. See what happens when we take it out of the context.
{
"error": {
"code": "TriggerInputSchemaMismatch",
"message": "The input body for trigger 'manual' of type 'Request' did not match its schema definition. Error details: 'Required properties are missing from object: Location.'."
}
}
An error message shows us that a property is missing from the object, and its name is Location. So, we have done schema validation here!
But in contrast with the trigger When a HTTP request is received, that can perform a schema validation while the Logic App executes, the Response connector unfortunately does not do the same.
This can feel a bit strange, taking into consideration that a parameter known as Response Body JSON Schema option that can be added to generate a schema to the Response action.
So here we did exactly that. We used another JSON message sample to generate the new response schema.
And in this scenario, we want to make sure that the response always delivers a age.
So, here we stated that our required field is the property age, and one would think that using required fields will condition the response that will be sent to the caller, but unfortunately, that does not happen.
As you can see, if we send our message the output is the same as the input. And that repeats true even when we delete the required property we had in our schema.
Fortunately, there is a workaround that consists of using an expression to check if the output of our chosen connector contains the fields we specified.
Here is the expression code:
if(contains(triggerBody(), 'name'),
if(contains(triggerBody(), 'surname'),
if(contains(triggerBody(), 'age'),
triggerBody(),
'{"error":"age property is missing"}'
),
'{"error":"surname property is missing"}'
),
'{"error":"name property is missing"}'
)
If that turns out to be true, the message will be sent in full.
But if the message does not contain the properties we defined on our expression, we will be notified of that.
That will work for all the properties we have defined in our expression, creating a validation of the response in this way.
On the other hand, if you still want to receive the output but with the error message following it, you can use this other expression, which will help you achieve just that.
Here is the expression code:
if(
contains(triggerBody(), 'name'),
if(
contains(triggerBody(), 'surname'),
if(
contains(triggerBody(), 'age'),
triggerBody(),
concat('{', triggerBody(), ', "error":"age property is missing"}')
),
concat('{', triggerBody(), ', "error":"surname property is missing"}')
),
concat('{', triggerBody(), ', "error":"name property is missing"}')
)
Here, as you can see, you still receive the fields that conform with our expression, minus the one we remove, with an error message indicating that.
Of course, we should only use this in specific cases where it applies. For example, let’s say you have made a call to an API service, and the response should always be the same, or some of those fields should always be present in the output. Let’s say the call failed and did not retrieve the usual data, and is lacking vital information.
You can use this workaround to make a schema validation on the response.
With only two actions and an expression, we can achieve awesome things!
To lazy to read? We’ve got you covered! Check out our video version of this content!
Join us next Friday for another Friday Fact!
Hope you find this helpful! If you enjoyed the content or found it useful and wish to support our efforts to create more, you can contribute towards purchasing a Star Wars Lego for Sandro’s son!
