Logic App Schema Validation: DateTime Restrictions

I recently published a post regarding BizTalk Schema Validation: DateTime Restrictions on my personal blog. Still, I was curious to see if we have the same capability in Logic Apps Standard and Consumption. And by doing that, see how compatible these two technologies are regarding XML Schemas and validations.

I was sure that the most basic validations were 100% compatible. By saying that, I mean validating the data types (int, decimal, boolean, …), mandatory and optional fields, and the overall XML structure. Still, again, I was curious to see how far we were able to go. So, I decide to use the same test case I did on BizTalk and apply not-so-used restrictions on Date and Time elements formats. And that gave me the idea and inspiration to create this blog post.

And to see how far these two products/technologies can be I decide to simply copy the existing BizTalk Schema that I had created and add it to my Logic App (Standard) project in Visual Studio Code.

Note: I could have used the Logic App (Consumption) but for that, I had to have an Integration Account that is a little bit expensive. So for prof-of-concept, I decide to use LA (Standard) that has these XML capabilities out-of-the-box without the need for an Integration Account.

Applying a pattern (that uses Regex expression) to validate the element or attribute value.

But to recap, when we work with DateTime on Schemas by default we can choose from the following data types:

• xs:dateTime: The DateTime data type is used to specify a date and a time in the following form “YYYY-MM-DDThh:mm:ss.fffK” where:
  1. YYYY indicates the year
  2. MM indicates the month
  3. DD indicates the day
  4. T indicates the start of the required time section
  5. hh indicates the hour
  6. mm indicates the minute
  7. ss indicates the second
  8. fff indicates the milliseconds
  9. K represents the time zone information of a date and time value (e.g. +05:00)
• xs:date: The date data type is used to specify a date in the following form “YYYY-MM-DD” where:
  1. YYYY indicates the year
  2. MM indicates the month
  3. DD indicates the day
• xs:time: The time data type is used to specify a time in the following form “hh:mm:ss.fffK” where:
  1. hh indicates the hour
  2. mm indicates the minute
  3. ss indicates the second
  4. fff indicates the milliseconds
  5. K represents the time zone information of a date and time value (e.g. +05:00)

or you could use an xs:string that basically accepts everything. The only problem here is that by default we can’t do a schema validation to see if it is a valid DateTime format.

But not all systems respect de DateTime formats expected by the XSD default values. So, what are my options if a system expects other types of DateTime, Date, or Time formats? Like:

• MM/DD/YYYY
• YYYY-DD-MM
• YYYY-MM-DD HH:mm:ss
• YYYYMMDD
• HHmmss
• HH:mm:ss
• and so on

Luckily for us, XSD Schemas allow us to derive a simple type, for example, xs:string, by using the restriction mechanism, i.e., we are typically restricting the values allowed in a message for that attribute or element value to a subset of those values allowed by the base simple type. A good and common sample of these types of restrictions is to restrict a string type to be one of several enumerated strings. But we can also apply a pattern (that uses Regex expression) to validate the element or attribute value.

And here is where the fun starts. There are many ways to archive this goal:

• One’s more simple but probably not that efficient since they may not validate all cases (Leap year, and so on)
• Others are more complex that require more knowledge but they are more accurate.

In a general overview, the use of regex to validate the date format supports a variety of situations and possibilities like:

• Rule to validate the year:
  1. \d{4} – it says that accepts 4 digits like 2022
  2. (19|20)[0-9][0-9] -accepts years starting with 19 or 20, i.e., from 1900 to 2099

• Rule to validate the month:
  1. \d{2} – it says that accepts 2 digits like 12, but the problem here is that also accepts invalid months like 24 or 99.
  2. 0?[1-9]|1[012] – accepts 01-09 (leading zero), 1-9 (single digit) and 10,11,12

• Rule to validate the day:
  1. \d{2} – it says that accepts 2 digits like 12, but the problem here is that also accepts invalid days like 32 or 99. It also doesn’t validate what is the month we define to validate if accepts 28, 29, 30 or 31
  2. 0?[1-9]|[12][0-9]|3[01] – accepts 01-09 (leading zero), 1-9 (single digit), 10-19, 20-29 and 30-31. It doesn’t check if it is a Leap year or not.

• To implement the lead year that needs to be with a concatenation of several rules like this sample:
  1. ^(?:(?:31(/)(?:0[13578]|1[02]))\1|(?:(?:29|30)(/)(?:0[13-9]|1[0-2])\2))(?:(?:18|19|20)\d{2})$|^(?:29(/)02\3(?:(?:(?:(?:18|19|20))(?:0[48]|[2468][048]|[13579][26]))))$|^(?:0?[1-9]|1\d|2[0-8])(/)(?:(?:0[1-9])|(?:1[0-2]))\4(?:(?:18|19|20)\d{2})$

This is a different approach to do the same as above:

• (19|20)((([02468][48]|[13579][26])-0?2-29)|\d\d-((0?[469]|11)-([012]?\d|30)|(0?[13578]|1[02])-([012]?\d|3[01])|(0?2-([01]?\d|2[0-8]))))

But we can go further and allow different types of format like:

• ^(?:(?:31(\/|-|.)(?:0?[13578]|1[02]|(?:Jan|Mar|May|Jul|Aug|Oct|Dec)))\1|(?:(?:29|30)(\/|-|.)(?:0?[1,3-9]|1[0-2]|(?:Jan|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec))\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:29(\/|-|.)(?:0?2|(?:Feb))\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\d|2[0-8])(\/|-|.)(?:(?:0?[1-9]|(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep))|(?:1[0-2]|(?:Oct|Nov|Dec)))\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$

Well, your imagination and skills are the limits of what you can archive.

The Logic App POC scenario

To test these DateTime restrictions, I created a simple Logic App Stateless Workflow that:

• Receives an HTTP Request, an XML request.
  (Note: I will use a variable to set up the response message.)

• Validates the XML request we sent against the DataRestriction schema, inside a Try scope in order to catch any exception that may occur there (maybe the scope was not necessary) 

• And then I have a Catch scope configured to run if any error happens on the Try Scope and I’m using a Filter array to filter all the errors and then get the error message and add it to the my response variable.

• And of course, set the response back to the caller

This is quite basic and simple LA. Then we can use Postman to test this workflow and if something fails this will be the expected response

{

    “Startus”: “Invalid Request: {\”body\”:{\”errors\”:[{\”message\”:\”The ‘Date2’ element is invalid – The value ‘20220230’ is invalid according to its datatype ‘String’ – The Pattern constraint failed.\”,\”lineNumber\”:15,\”linePosition\”:22,\”severity\”:\”Error\”}]}}”

}

Resume

In the case of Schemas and Validations, Logic App and BizTalk Server, if not 100%, are almost 100% compatible.

The only issue I see here is that Visual Studio code and Logic App (Standard) doesn’t have an intuitive Schema Editor as BizTalk Server has and that Logic App (Consumption) has. Instead, we have to do it manually or use an external editor.

Source Code

THIS SAMPLE CODE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

You can download the POC: Logic App (Standard) Schemas Validations – Handle Restrictions on Date from GitHub here.