Decoding Logic App Dilemmas: How to validate if a JSON property is not an empty string?

Time to start another series of blog posts about Logic Apps: Decoding Logic App Dilemmas: Solutions for Seamless Integration! For a question of simplicity, I will call it Decoding Logic App Dilemmas.

The goal of this new series is to find common problems that people are facing with Logic Apps, either on StackOverflow, Logic App forums, Azure Logic Apps Microsoft Q&A, or any other source – feel free to provide ideas/problems you would like to be addressed – and provide a solution or solutions to that problem. At least I will add my point of view to address that issues. Of course, there may be other solutions; if that’s the case, feel free to comment.

For this first blog post, I selected a problem related to a few tips and tricks I have been writing: Message validation inside Logic Apps or JSON schema validation.

Problem: How to validate if a JSON property is not an empty string?

Assuming that we have the following simple JSON message:

{
“city”: “Porto”,
“name”: “Sandro”
}

I need to make sure only to process these messages if the name is not null or not an empty string.

Of course, ideally, I want to use the OpenJS Foundation standard specification for JSON Schema to apply constraints and perform the validation inside Logic App. This can be easily applied to JSON Schemas using the pattern property keyword in which we define a regular expression. In our scenario, it would be something like this:

However, there is a significant problem with this standard solution…  Logic App Schema validation does not support the pattern keyword – at least for now.

Failed to save logic app <logic-app-name>. The ‘schema’ property of trigger ‘request’ inputs of type ‘Request’ at line ‘1’ and column ‘185 contains ‘pattern‘ or ‘patternProperties‘ properties. ‘Pattern‘ or ‘patternProperties‘ properties are not supported in trigger json schema, trigger schema validation is enabled when operationOptions set to ‘EnableSchemaValidation’ or the workflow contains any actions of type ‘OpenApiConnection’.

I don’t think that this is a trigger issue. If you try to use it inside a Parse JSON, it allows us to save, but when you test the Logic App, it will fail in runtime with the following error:

ActionSchemaNotSupported. The ‘schema’ property of action ‘ParseJson’ inputs contains ‘pattern‘ or ‘patternProperties‘ properties. ‘Pattern‘ or ‘patternProperties‘ properties are not supported in the action json schema.

Workaround: using “minLength”: 1

A simple workaround that can be valid for your scenario is using the minLength keyword to specify that the length of a string has to fall into a particular interval. In this case, that has to have more than one character:

Yes, you see this correctly, don’t put any value on the “Choose a value” being the scene, this is translated to:

Now, if we try it, we will get a 500 Internal Server error:

The advantage of this solution is that we don’t need error handling to see if the validation failed. We are controlling the condition outcome in the design. However, there is a huge disadvantage with this approach if we have not one but several properties that we need to validate, or we need to use several conditions to get the proper error message, or we need to implement a complex OR condition inside the condition action, which will be difficult to read and maintain.

To minimize this last problem, instead of using conditions, we could create a subset of the message with the properties we want to validate inside a Parse JSON action using a mix of expressions and a JSON Schema to accomplish the same results. To do that, and let’s now assume that we want to validate not only the name but also the city, we need to:

• Add a Parse JSON action below the trigger or action that you got the message.
• On the Parse JSON action, set the following Content:

{
“city”: “@{trim(triggerBody()?[‘city’])}”,
“name”: “@{trim(triggerBody()?[‘name’])}”
}

• Set the following Schema:

{

    “properties”: {

        “city”: {

            “minLength”: 1,

            “type”: “string”

        },

        “name”: {

            “minLength”: 1,

            “type”: “string”

        }

    },

    “type”: “object”

}

The advantage of this approach is that I don’t need to implement several or complex conditions. I just need a small data manipulation – using the trim function to remove leading and trailing occurrences. The disadvantage, if we can consider it as a disadvantage, is that I need to implement error handling in order to get the correct error message back.

Above, I explained how you could address the existing Logic App limitation of not supporting the pattern property keyword that could allow us to provide a regular expression to validate if a specific string property was not empty or with only empty spaces inside.

Further, I will explain how you can use the OpenJS Foundation standard specification for JSON Schema to apply constraints and perform the validation inside Logic App. That means using the pattern property keyword!
The problem is still the same as the previous one, but I will recap it here for a better understanding of the problem and the solution.

Assuming that we have the following simple JSON message:

{
“city”: “Porto”,
“name”: “Sandro”
}

I need to make sure that I only process these messages if the name is not null or not an empty string.

Of course, ideally, I want to use the OpenJS Foundation standard specification for JSON Schema to apply constraints and perform the validation inside Logic App. This can be easily applied to JSON Schemas using the pattern property keyword in which we define a regular expression. In our scenario, it would be something like this:

However, there is a significant problem with this standard solution…  Logic App Schema validation does not support the pattern keyword – at least for now.

Failed to save logic app <logic-app-name>. The ‘schema’ property of trigger ‘request’ inputs of type ‘Request’ at line ‘1’ and column ‘185 contains ‘pattern‘ or ‘patternProperties‘ properties. ‘Pattern‘ or ‘patternProperties‘ properties are not supported in trigger json schema, trigger schema validation is enabled when operationOptions set to ‘EnableSchemaValidation’ or the workflow contains any actions of type ‘OpenApiConnection’.

I don’t think that this is a trigger issue. If you try to use it inside a Parse JSON, it allows us to save, but when you test the Logic App, it will fail during runtime with the following error:

ActionSchemaNotSupported. The ‘schema’ property of action ‘ParseJson’ inputs contains ‘pattern‘ or ‘patternProperties‘ properties. ‘Pattern‘ or ‘patternProperties‘ properties are not supported in the action json schema.

Best solution: using an Azure Function to perform JSON Schema validation

If the mountain does not come to Mohammed, Mohammed goes to the mountain!

Again, unfortunately, at the moment, Logic App does not support all the OpenJS Foundation standard specifications regarding JSON Schema definitions. However, we can quickly work around that limitation and implement what I think will be the best solution by using another service of the Azure Integration Services: Azure Functions.

You can find and use my JSON Schema Validation Function that I released on my personal blog. This JSON Schema Validation Function is a simple function that allows you to validate your JSON message against a JSON Schema, enabling you to specify constraints on the structure of instance data to ensure it meets the requirements.

The function receives a JSON payload with two properties:

• The JSON message in the json property.
• The JSON Schema in the jsonSchema property.

Example:

{
“json”: {
“city”: “Porto”,
“name”: ” ”
},
“jsonSchema”: {
“properties”: {
“city”: {
“type”: “string”
},
“name”: {
“type”: “string”,
“pattern”:”^.*[a-zA-Z0-9]+.*$”
}
},
“type”: “object”
}
}

You then just need to call this function inside your Logic App:

You can even remove the Schema from the trigger if you want:

Now if we try with some sample messages, we will see that:

• If we send a valid message, we will get a 200 OK

• If we send an empty message, we will get a 200 OK with an error message – this is because I designed the solution for that. Ideally, this should be different.

• If we send a string full of empty spaces, we will get a 200 OK with an error message.

• If we send a null value, we will also get a 200 OK with an error message.

• If we don’t send the name field, it is assumed that it is a valid message – the reason why this is happening, is because we didn’t specify the field as mandatory.

We can easily change this behaviour by setting the field as required by changing the schema to be:

{
“json”: @{triggerBody()},
“jsonSchema”: {
“properties”: {
“city”: {
“type”: “string”
},
“name”: {
“type”: “string”,
“pattern”:”^.*[a-zA-Z0-9]+.*$”
}
},
“type”: “object”,
“required”: [“name”]
}
}

Now if we try it one more time, we will get the following error:

I hope you find this content useful and stay tuned for more Decoding Logic App Dilemmas.