When you need to perform a schema validation at runtime while using the trigger, When a HTTP request is received, Logic Apps gives us the possibility to perform that validation by referring to a setting existing in the Request trigger.
Note: If you provide a sample JSON message, as shown below, the designer will generate the JSON schema for you based on that payload.
📝 One-Minute Brief
Avoid unexpected runtime issues in Azure Logic Apps by understanding why the Response action does not enforce schema validation and how to apply a simple workaround to validate responses reliably.
Request (inbound) Schema Validation
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, since we have nothing else configured beyond schema validation, nothing will happen. The message enters the Logic App, and a run occurs, but since we configured it, the input must include 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 indicates that a property named Location is missing from the object. So, we have done schema validation here!
Response (outbound) Schema Validation
But in contrast to the trigger When a HTTP request is received, which can perform schema validation while the Logic App executes, the Response connector unfortunately does not do the same.
This can feel a bit strange, considering that a parameter named Response Body JSON Schema 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 ensure the response always returns an age.
So, here we stated that our required field is the property age, and one would think that using required fields would condition the response 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 remains true even when we delete the required property we had in our schema.
Response Validation Limitation Workaround
Fortunately, there is a workaround that uses an expression to check whether 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 in our expression, we will be notified.
That will work for all the properties we have defined in our expression, thereby validating 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 to our expression, minus the one we removed, 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, did not retrieve the usual data, and is missing 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!
