Udostępnij za pośrednictwem


Creating Logic App API connection to query a Log Analytics workspace via ARM template

It has been a while since my last post. I turn more and more into cloud-based monitoring and this journey is quite fascinating. I constantly stumble upon various things and will blog about the experiences I made in the future.

Scope

I really do like Azure Logic Apps to automate things in Azure and to transfer data from or to Log Analytics. Creating Logic Apps in the portal is quite easy, but if you try to automate things with ARM templates, there are some pitfalls.

Let’s assume, you want to create an ARM template for a simple logic App with

  • One trigger: Recurrence
    Trigger every x Minutes
  • One action: Run query and list result
    Execute a query against a Log Analytics workspace and return the result as JSON objects


The “Run query and list result” action needs an authenticated API connection to the Log Analytics workspace. How do we create this within an ARM template? Unfortunately, there is not a very precise documentation and it took me a while to accomplish that.

This post describes how to configure the undocumented settings within the ARM template, to make the API connection work.

This post is not a step-by-step introduction on how to write the full ARM template!

Requirements

What do we need?

  1. A ServicePrincipal
    For detailed instruction on how to create a ServicePrincipal see /de-de/azure/azure-resource-manager/resource-group-create-service-principal-portal . For our  template we need:
    - Client-ID (APP-ID)
    - Our Tenant-ID
    - The App secret
  2. An export of a working Logic App as an ARM template.
    It is much easier to build a PoC in the Azure Portan and than export it into an ARM template. That export can be done either in the Azure portal or with Visual Studio. Within Visual Studio you can use the Cloud Explorer to navigate to your Logic App and  open it with the Logic App Editor. There you can download the template:

Creating the base ARM template

You can create the ARM template with whatever editor you like. I prefer Visual Studio 2017 with all ARM tools installed.

My template will contain just a bunch of parameters and two resources:

  • One resource for the logic app
  • One resource for the API connection


When you look at the API resource, you can see some parameters :

Keep in mind: these parameters are ONLY available when exported with Visual Studio and NOT via Azure Portal!

The needed parameters are:

  • "token:clientId"
    This is our Client ID
  • "token:clientSecret"
    This is our App secret
  • "token:TenantId"
    This is our TenantID
  • "token:grantType”
    Must be “client_credentials”
  • "token:resourceUri"
    This parameter caused me a lot of headache, as Visual Studio does not dump its value and I could not find the correct value anywhere in the LogicApp documentation. After a lot of try and error I figured out, that it has to be https://management.azure.com/ .

A working sample of the full ARM template is attached to the blog post for you as a reference.
ARM Template

Testing the ARM template

Once you have created the template, you can deploy it to your resource group (“BlogDemoLogicApp” in my case) via Visual Studio:

The result is a working API connection…

… and a running Logic App:

My personal lessons learned

  1. Create a PoC in Azure Portal first
    Having this PoC as a starting point and not needing to start from scratch is very helpful. Just keep in mind, that you have to clean up the exported template later on.
  2. Use Visual Studio
    Yes, it is complex, and I do only understand a fraction of its capabilities, but it simplifies your journey into Azure a lot!
  3. Exporting templates from Azure Portal is not always a good idea.
    Some settings/parameters might be missing. Especially in the API connection case. Use Visual Studio instead and get at least all parameters (unfortunately not all needed values).
  4. Use the Logic App “Run Details” function in the “Run History”
    to get deep error messages for a failed action. They can be much more descriptive than the errors in the visual designer: