In the previous blog – we looked into working with Logic Apps from Visual Studio, which allowed us to manage logic app code in TFS or Git or any other source control system. But to truly do DevOps for Logic Apps while integrating with Dynamics 365 you need to be able to do ALM process for Logic Apps better yet do continuous delivery/deployment.
when we are editing and deploying a Logic app in Visual Studio we are actually editing an ARM Template, So what is an ARM template?
ARM templates are JSON format template, it enables you to deploy Azure resources in a declarative manner and could be used to define all the resources in a resource group.
An Empty ARM Template Schema
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": { },
"variables" : { },
"resources": [],
"outputs": { }
}
To add a resource in ARM template, resource details are declared under resources properties, there could be multiple resources. Below is a sample of Empty Logic app added to empty ARM Template.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {}, //ARM parameters
"variables": {}, //ARM template variables
"resources": [
{
"name": "Logic APP Name",
"type": "Microsoft.Logic/workflows",
"location": "West US",
"tags": {"displayName": "LogicApp" },
"apiVersion": "2016-06-01",
"properties": {
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"contentVersion": "1.0.0.0",
"actions": {},
"outputs": {},
"parameters": {},//Logic App defination parameters defination
"triggers": {}
},
"parameters": {} //parameter values
}
}
],
"outputs": {}
}
The type associated signifies what kind of resource is being deployed, in our case its"Microsoft.Logic/workflows".
In order to deploy resources to a different environment, Location, Subscription we use arm template parameters.
ARM parameter requires a name, type, validation, and metadata, of which metadata and validations are optional.
"logicAppName": {
"type": "string",
"minLength": 1,
"maxLength": 80,
"metadata": {
"description": "Name of the Logic App."
}Logic app definition and ARM templates, each have its own parameters, Logic app parameter persists with Logic app whereas arm template parameter is only referenced until the point of deployment.
That was some of the basics of ARM template, Now let’s look at configuring the logic app from Integration with Microsoft Dynamics 365 using Azure Logic App Service for deployments.
Logic App in the example has two resources, Dynamics 365 Connection (used by the connector) and the Logic app itself. You may download the original logic app project from here.
Step 1. Parameterize:
There are two ways to go about parameterizing. one approach is to use ARM parameters and update the logic app definition to reference parameters as appropriate.
Another approach is to add parameters to the definition of the Logic app and reference them in the definition instead.
Both the approach has its own benefit and downside, General thumb rule is not to use ARM parameter in resource definition rather use resource parameter as an intermediary, This allows us to edit Logic app from Azure Portal or VS studio cloud explorer but as Dynamics Connectors don’t work well with runtime parameters you loose on Logic app designer edit capability. In this post, we will look into using ARM parameters directly.
- Logic App automatically adds few arm parameters :
- logicAppName
- logicAppLocation
- dynamicscrmonline_1_Connection_Name
- dynamicscrmonline_1_Connection_DisplayName
Add values for the above parameters in the parameter file, a suggestion is to append org name to the connection name and set the display name to the account used for the connection.
-
- Identify other items which need to be parameterized, in this logic app I am using HTTP Connector and URL and the password used by the connector are perfect candidates to be parameterized.
Sensitive values like password could be set as type securestring or secureobject, this allows for the parameter to be stored in Azure Keyvault instead of source code. will see more on this when we are ready to hit deploy.
-
-
- once the parameters are added we can reference them in the actual Logic App definition
-
Step 2. Dynamics 365 Connector’s URL :
when using Dynamics 365 connector for a Logic app, every Dynamics 365 action or trigger adds a path URL to the description, the path dictates the action being performed, below is a sample of trigger action URL which checks for new case creation:
"method": "get",
"path": "/datasets/@{encodeURIComponent(encodeURIComponent('orgRandomNumbers.crm'))}/tables/@{encodeURIComponent(encodeURIComponent('incidents'))}/onnewitems"
This presents a challenge as the Orgname is part of the path and we can’t replace the org name with a parameter as that will cause format issue.
one workaround for this is to use a combination of ARM Variable and parameters. As an Example, to parameterize the trigger action we will do the following:
-
- Create a new parameter for Dynamics 365 OrgName
- Create an ARM template variable (getCaseURL) for the trigger action URL and set its value to path content after the CRM org name
-
- Now we have the org name in parameter and the URL in the variable we can do string concatenation to create the URL dynamically during deployment
Step 3: Create parameter files
Now that we have parameters defined and template definition updated to reference the parameter we can define deployment values for the parameter, you could create multiple parameter files for the different environment you may need to deploy and reference them while deploying.
Step 4. Deploy:
To do this you can leverage the deployment wizard, right click on the solution and click Deploy. This will bring the deployment window and ask for which logic app to deploy and which parameters file to use.
Click on “Edit Parameters Option” to edit or add parameters, this will show all the parameters defined in the ARM Template and any values you may already have. you can define the parameter values here and the parameter file with be updated with these values.
Any parameter which is of type securstring or secureobject will have a key symbol next to it, you can click on it and add the value to an existing or new Azure key vault and reference them in the parameter file instead of storing it as plain text in a parameter file.
Once parameter file is updated click on deploy to deploy the Logic App, If deploying for the first time, Authorization needs to be provided for API Connection, this could only be done through Azure Portal.
The parameterized version of the above Logic APP is available on Github for reference.
Hope this post helps to better manage your Logic App deployments, Let me know how you have managed Logic app deployments in your project, this blog became longer than what I have planned for, so I will take a pause and extend this in another blog where we will look into using Logic App parameter as intermediary instead of using ARM expression in logic app definition and the pros and cons of doing so.
Today also marks the end of Microsoft Support for Adxstudio Portals, If you are still using ADX studio Portals, watch out for my webinar session on migrating to Dynamics 365 Portals.