An area I’ve been doing a lot of work with so far this year is Azure Resource Manager templates. The primary driver behind this is to ensure our team has fully automated our development/deployment processes within Azure DevOps. The list of recent posts on this blog certainly reflects this fact, as we’ve seen:
- How to configure streaming units when working with Stream Analytic jobs,
- Perform automated validation of Azure templates before deploying them out
- Reviewed some of the things to bear in mind when working with Azure Web App Application Settings alongside templates.
As part of this, we’ve also been migrating across several Microsoft Flows to Logic Apps. This migration will ensure we can manage things centrally within Azure and also allow for these solutions to scale more effectively. Thankfully, this migration has been pretty straightforward, due in no small part to the excellent export capabilities that Microsoft Flow natively provides.
However, there have been a few bumps in the road as we build these into an Azure Template. In particular, one Flow/Logic Apps caused us several initial difficulties. It contained a trigger that would fire whenever a new record gets INSERTed to an Azure SQL database. To prevent a strange issue where the trigger would fire for every record created, we implemented aย Start time condition, as illustrated below:
As we incorporated the above Logic Apps within an Azure Template, we, therefore, had to account for this behaviour. Our proposed solution was to ensure that our Azure Template included a value that would always reflect the current deployment time. Initially, we attempted to use the utcNow Azure Template function to meet this requirement, as illustrated in the snippet below:
"triggers": {
"When_an_item_is_created": {
"recurrence": {
"frequency": "Minute",
"interval": 5,
"startTime": "[utcNow()]"
},
...
}
}
This approach didn’t work, as we would get the following error message:
The template function ‘utcNow’ is not expected at this location. The function can only be used with parameter default value expresions
Fortunately, as we discovered, the Logic Apps Workflow Definition Language also has a large array of different functions available, including one that mirrors the above precisely. We, therefore, modified our Logic Apps template definition as follows:
"triggers": {
"When_an_item_is_created": {
"recurrence": {
"frequency": "Minute",
"interval": 5,
"startTime": "utcNow()"
},
...
}
}
However, it didn’t like this as well, as we got a different error message when deploying this out:
The template validation failed: ‘The template trigger ‘When_an_item_is_created’ at line ‘1’ and column ‘1485’ is not valid: \\\“The string was not recognized as a valid DateTime. There is an unknown word starting at index 0.\\\
Well, at least with a different error message, it was a good sign that we were making some progress! What baffled us at this particular juncture was the default return format of theย utcNow function appeared to match exactly against what Logic Apps is expecting. The only main difference being that it included additional millisecond values - to ensure you have maximum precision, I guess. ๐ We did attempt to override the default formatting on several occasions but, each time, we kept getting the same error message above, which was frustrating. In the end, we had to resort to getting the current date/time as part of a parameter value at the top of our Azure template:
"dateTimeNow": {
"type": "string",
"defaultValue": "[utcNow('yyyy-MM-ddTHH:mm:ssZ')]"
}
(Note that Visual Studio may flag this up as an Unrecognised function name error; you can safely disregard this)
Then, it is possible to reference this parameter value from directly within the Logic Apps definition, like so:
"triggers": {
"When_an_item_is_created": {
"recurrence": {
"frequency": "Minute",
"interval": 5,
"startTime": "[parameters('dateTimeNow')]"
},
...
}
}
This template will then deploy out successfully, grabbing the current date/time value and ensuring that it is populated correctly within the Logic Apps resource.
Once again, we must thank my colleague Andrew Bennett for coming up with this particular solution, which I thought would be useful to share as part of this weeks post. Hopefully, it may help someone else who has been banging their head against a wall with this particular problem ๐