In the previous blog – we looked into getting Logic Apps CI/CD using ARM Template Parameter, we briefly touched on logic app definition parameter. In this post, we will look further into using Logic app definition parameter as an intermediary and the benefits of doing so.
Comparison:
| ARM Parameters | Logic App definition Parameters |
| Used with ARM Template | Used within a Logic App |
| Value evaluated during Deployment | Value evaluated during Runtime |
| Syntax: “uri” : “[parameters(‘vsts_bug_url’)” | Syntax: “uri”: “@parameters(‘url’)” |
| Not referenced post-deployment | Available in Code view and Designer view |
| Suited for Environment Specific values | Suited for Reference objects |
so the obvious question is how we can leverage Logic App parameters as an intermediary and why to do so?
WHY: If a parameter is a part of logic app definition it is available irrespective of how you are editing the logic app, you can see it in Code view, designer view. it is available while editing from Azure Portal or accessing and modifying it via Cloud Explorer, whereas ARM template Parameters are only available in ARM templates.
If Logic App gets modified outside of Visual Studio/ARM Templates the ARM template file needs to be updated and this sometimes could be a daunting task.
How: we will continue with a logic app from last Blog Post and modify it to use Logic app definition Parameters, once done we update the definition parameter to reference ARM Template parameters.
Step 1: Define Parameters in Logic app definition
Step 2: Update logic App definition to reference the parameters
Step 3: Update the reference to ARM parameters from the last blog post
Step 4: is deployment, Once done with the above step you are ready to deploy using deployment wizard or PowerShell.
Once deployed Designer view for HTTP connector shows the parameters
But Dynamics 365 connector’s designer edit capability is lost.
this is because logic app designer parses the details about the URL in edit mode and presents available options. as the parameters are only evaluated in runtime dynamics 365 edit windows fail to load, all the edits need to be done through code view.
The parameterized version of the above Logic APP is available on Github for reference.
Final Thoughts: Only relying on one or the other form of the parameter for the template is not ideal, efforts need to be made to set a Development process for editing and modifying the Logic App and use the suitable parameters options to augment the process.
I generally use ARM template for all configuration parameters and use Logic App parameters for configuration which are dependent on other resources or logic apps.
One very useful use case for logic app definition parameter is: when the VSTS destination where the Bug is to be created is dynamic and its dependent for runtime evaluation.
I am presenting a webinar on Upgrading Adxstudio Portals to Dynamics 365 Portal capabilities, If you have an Adxstudio Portals install, this session might be helpful, You can register here.