Category: Uncategorized

How to use Logic Apps Custom Connectors with ARM and CI/CD

What is this?

The documentation on how to deploy Logic Apps Connectors in a proper CI/CD scenario is … lacking.
Being able to use Connectors and to deploy them automatically, is a must in today´s enterprise landscape. I have worked with Connectors for two years and have just recently been able to have everything fully automated.

Also: A huge shout-out to Maxim Zhizhin for solving the last part of the problem and sharing it with me.

Who is this for?

This is not a full walkthru on how to use Connectors, and it mostly focuses on how to use a Connector to connect to an on-premise service, i.e. using the On Premise Data Gateway.
If you are looking at how to incorporate a Custom Connector into your CI/CD setup using ARM, this is for you.


If you know what you are doing and is just looking for the ARM-template file, you can get it here.

The Steps

These are the steps:

  1. Finnish configuring you connector.
  2. Export the Starting ARM Template
  3. Examining the ARM
  4. Adding the Swagger/OpenAPI Definition to the ARM template
  5. Adding additional settings
  6. The Parameter File
  7. Trying to deploy

Finnish configuring your connector

You have created a Logic App Custom Connector and know that it is working properly. In my case I built a SOAP Passthru (the best way to connect to SOAP services). The SOAP service is located on-premise. It looks like this:

The service sends a POST with a header for the SOAPAction (which a SOAP service needs) and another header for Content-type, signaling to the SOAP service that we are using XML and also in what encoding,

Export the Starting ARM Template

I put emphasis on starting because this ARM Template that will be exported is in NO WAY complete.

  • Find the Export Template in the starting page of the Connector (it is under automation).
  • Click it and after the template has been generated, find Download at the top of the screen.
  • Download and open the file using your preferred tool. I am using VS Code.

Examining the ARM

Looking from the top to the bottom, you first have a parameter for the connector name. Then you have basic information about the region. Further down you have information about authentication (basic or none), and funny enough some information about how to fill in the UI for the auth part.
Then we come to the use of the gateway which is a repeat of the auth settings. Is should look like this:

"gateway": {
  "type": "gatewaySetting",
  "gatewaySettings": {
    "dataSourceType": "CustomConnector",
    "connectionDetails": []
  "uiDefinition": {
    "constraints": {
      "tabIndex": 4,
      "required": "true",
      "capability": [

This only defines the UI for use of the gateway, it does not actually implement it.

Scroll further and you have some basic settings, like the name and description. If you have used an Icon it will be exported as a base64 encoded.

Adding the Swagger/Open API definition

The ARM Template you have saved is not complete. You have to manually add the Open API definition to it.
To find the information you go back to the portal, and the start page (Overview) of the Connector. Find the Download link at the top.
Click to download the file. Note! The file has no file extension and therefore you have to choose a text tool to open it.
Copy the text from the file into a new property called swagger, and add the copied text. The end result should look like this:

"swagger": {
        "swagger": "2.0",
        "info": {
            "title": "SOAP pass-through",
            "description": "Get Info SOAP passthru",
            "version": "1.0"

Adding Additional Settings

There are four additional settings you need to manually enter in order for this to work properly.
All these settings should be on the same level as "iconUri", so just add these settings before that property.


Set this property to

"apiType": "Soap"


This property is the path to the on-premise service as if you published your connector on the same network. In my case this is

"backendService":{ "serviceUrl": "http://onpremservice/webservices"}


This is mostly used if you are not using the SOAP passthru method. If you do you should set it to:

"wsdlDefinition": {
   "importMethod": "SoapPassThrough"


Setting this, tells the deployment to use the on premise data gateway, not only have the UI show it (see above). To make this happen add this property

"capabilities": ["gateway"]

The parameter file

This file was downloaded with you initial export of the ARM-template and is located in the same Zip-file. You do not need a parameter file to make this work, it is just good practice. When adding a parameter file you can also have different parameter files for different environments, such as TEST or PROD.
The generated file only contains a single parameter but you should parameterize additional settings in the file to fully integrate the ARM-files in your CI/CD pipeline. Here are the settings I usually parameterize:

  • Location make sure that the Location is the same as the resource group and set that from the CI/CD pipeline.
  • BackendService ServiceUrl This might be different between TEST and prod for instance.
  • Swagger Within the Swagger there might be multiple things that differ between environments. I usually make sure that Host is set by a parameter.

Trying to Deploy

If you do not want (or can´t) go thru the whole DevOps deploy pipeline to test this new ARM template, you can use a built in functionality in the Azure Portal.

In the search box at the top of the portal, search for deploy and select "Deploy a custom template".
This lands you on a page where you can enter your ARM-template and parameter files and deploy them.

  1. Select "Build your own template in the editor".
  2. Paste the ARM template JSON in the window.
  3. Click Save at the bottom left part of the page.
  4. If you are using a parameter file, click the "Edit parameters" link at the top right of the page.
  5. Paste the content of your parameter file and click Save at the bottom left.
  6. Done. Click Review+Create at the bottom left.

If my template can help you, I have uploaded it here.

In conclusion

The Logic App Custom Connector is an underestimated, underdone and under-documented feature in Azure, but if you know how to configure it and where to get the info, it is very useful.

Any questions or feedback regarding this post can be sent to my Twitter.
Hope this helps.

Custom Connector returns 410 Gone?

What is this?

Some time ago, I got this message when executing a Custom Connector from a Logic App. The response was very strange, and was returned in that object way that an HTTP action sometimes does:

'content-type': 'application/octet-stream',
'content': 'eyJjb2RlIjogIkFwaURpc2FibGVkIiwgIm1lc3NhZ2UiOiAiQVBJIGhhcyBiZWVuIGRpc2FibGVkIGR1ZSB0byBpbmFjdGl2aXR5LiBQbGVhc2UgdXBkYXRlIHRoZSBDdXN0b20gQ29ubmVjdG9yIHRvIGVuYWJsZSBpdCBhZ2Fpbi4ifQ=='

Running the $content thing thru a Base64 decoder I got back:

{'code': 'ApiDisabled', 'message': 'API has been disabled due to inactivity. Please update the Custom Connector to enable it again.'}

The connector had been … disabled?!!!
Does this seem familiar?

What to do (short term)

The very short version is to update the connector. To basically force Azure to deploy it again. To solve this I simply added a space in the description-field and clicked Update Connector. Done.

Why did this happen?

I raised a ticket with MS Support and got a very clear answer: They used to disable connectors that had not been used for 30 days. Why? They did not say, only that they no longer have that policy. I think it was due to the datacenter being close to overloaded (thanks Covid-19) and they wanted to remove unused resources.

What to do (long term)

You need to look at your connectors and find all those that have not been used for a while. The Enfo support team checked the run history of all Logic Apps that uses Custom Connectors. If a Logic App had not been run for a long time, they updated the connector behind it. I think you should do this as well.
In our case it was easy, two Logic Apps had not been run for two months and all others are running on a daily basis.

Get to updating your connectors.

OAUTH with Azure – The just make it work edition

What is this?

I do not know how many times I have looked for an article explaining the just make it work part of how to authenticate to Azure from an application calling an Azure API. I usually find myself in a very long article on scope and OAUTH vs OAUTH2 vs OpenID.

This is more for me as documentation and perhaps for you as well, and it will not go thru why you should configure anything in a particular way. It is just a make it work.

If you do not know how to create an App Registration (necessary for login) or how to get the information used below, I have created a post here.

The three stages of logging in

  1. Get the information you need.
  2. Login to get a Token
  3. Use the Token in an API-call.

Getting the information you need

You will need:

  1. A Client ID
  2. A Client Secret
  3. The Azure Tenant ID
  4. Know which resource you are using

The 1, 2 and 3

The Client ID and the Tenant ID you can get from the App Registration Overview page of your app.

The client secret is either something you previously saved or something you created. Take a look at my post. Click on "Create the App Secret" in the Table of contents at the top if you need more information on how to create a secret.

The resource

This is the only tricky part.

  • If you need to manipulate about 90% of Azure you use
  • If you are login into Storage Account you should/could use


The number one client for calling and testing APIs.

Login to get a Token (with Postman)

Gather all the information you have above and lets get to configuring.
You can use variables and environment settings for these.

  • Set the URI to:[Tenant ID Goes here]/oauth2/token
  • Set the verb to POST.
  • Set the format of the body to form-data
  • Fill in the data:
    • client_id: Your Client ID
    • client_secret: Your client secret (password)
    • resource: see heading just above this
    • grant_type: client_credentials
  • Click Send and receive your access-token.

    Bonus content for Postman

    If you want to be fancy, add a script to the test part and assign the token to a local variable for use in other calls.

    pm.test(, () => {;'error');
    pm.environment.set("<your variable>", pm.response.json().access_token);

    Use the token in the API-call (with Postman)

    Now that you have your token, you can use it in other calls.

  • Simply click Authorization
  • In the dropdown select Bearer Token and paste your token in the token-field to the right.
    If you used the fancy script, use the variable instead.
  • Done!


If clients scare you and you like using scripts to call APIs and execute stuff, you can use PowerShell.

Login to get a token (with PowerShell)

Doing this with PowerShell is even easier, once you know what and how to call stuff, all the code below is located in the same file.
Gather all the information you have above.

# Fill in the data in a collection
authBody = @{
    'Client_Id' = 'Your Client ID'
    'client_Secret' = 'Your client secret (password)'
    'resource' = 'see previous heading about this'
    'grant_type' = 'client_credentials'
}tenantId = 'Your Tenant GUID'
# Set the URI
tokenUri = ""

# Login to get a Token 
# Notice -ContentType and -Formresult = Invoke-RestMethod -Uri tokenUri -ContentType "multipart/form-data" -FormauthBody -Method Post

# A token must be a SecureString when used in later API-calls.
secureToken = ConvertTo-SecureStringresult."access_token" –asplaintext –force

Are you using Windows PowerShell?

If you need to use Windows PowerShell, aka 5.1, you need to replace the Invoke-RestMethod line with:

Invoke-RestMethod -Uri tokenUri -Method Post -BodyauthBody

Note the lack the -Form parameter and -ContentType

Use the token in the API-call (with PowerShell)

When you have your $secureToken you can use it in any API call as a bearer-token.

# Use the token in the API-call
uri = 'https://your api call'response = Invoke-RestMethod -Authentication Bearer -Token secureToken -Uriuri 


Bonus content on the Token

Did you know that the Token contains information that you can parse? I sure did not.
Visit eiter or to see the information in the token. You simply paste your token and see what it contains.
Here is an example of a payload for the token I got in Postman:

 "aud": "",
 "iss": "<tenantGUID>/",
 "iat": 1591799017, <-- Issued At
 "nbf": 1591799017, <-- nbf means not before
 "exp": 1591802917, <-- The expiration time in Unix timestamp
 "aio": "42dgYDhp4Pl5Eccb7me1ixxx",
 "appid": "<client ID>",
 "appidacr": "1",
 "idp": "<tenantGUID>/",
 "oid": "ad049d62-472f-4835-90be-qqqwwwee",
 "rh": "0.AQwAHo4e6q_ta0SWTzChaFpEhgeZB<<<<>>>>>.",
 "sub": "ad049d62-472f-4835-90be-<<<<>>>>",
 "tid": "<tenantGUID>",
 "uti": "HZ0eFQf0akCeUE0hJPgjAA",
 "ver": "1.0"

This information can be very useful. The aud (Audiance) should be the same as the resource setting and that might be different in your scenario.

Setting up an App Registration in Azure – The just make it work edition

What is this?

There are a lot of articles out there on how to setup an App Registration in Azure. Most of them contains a lot of useful information on why, rather than how.

This article is only about the how.

What you need to do

  1. Log into Azure
  2. Find the App Registration page.
  3. Create the App registration
  4. Create the App Secret
  5. Where to find information you will probably need later.

The process

Login to Azure

Come on you know this. Why are you even reading this step?

Find the App Registration Page

The easiest way of doing this is to use the search field at the top of the page. Just type App Reg and it should pop up.
Select it.

Create the App Registration

On the start page for App Registration, click New Registration at the top left.

  • Give it a useful name. Better than MyDemoApp
  • Make sure the top radio button is selected.
  • Leave the Redirect URI blank and click the Register Button

Create the App Secret

Remember to store the secret somewhere!!!
When you have registered your app you will be forwarded to its starting page.

  • In the menu to the left, select Certificates & secrets
  • In the new page, click the New client secret button.
  • Give it a description and expiration (I always use 1 year for test and dev keys) and click Add.
  • Important! Take it slow!
  • Copy the value of the key created. This is the only time it is shown.
  • Store the key for later use.

Where to find information you will probably need later

When using this App to log in or authenticate you will use additional information, beside the Client Secret.

  • Go to the start page for the App Registration and choose your App.
  • In the start page of your app you will find everything you usually need
  • Here you will find the Client ID (under Application (Client) ID) and
  • Tenant ID, which you need to get a token.

YouTube Session on Data center redundancy

The session

I am a co-admin of the Azure Meetup Stockholm group. We usually host sessions on anything Azure related at an office and usually in the evening. Due to the current situation, corona, we decided to move the sessions to YouTube. I did my first session this Monday (1st of June 2020).

The session is on how you can achieve full redundancy between different Azure data centers in the event of an outage, the challenges this poses and a proposed solution. It also contains a fair bit on more hard core computer science, trying to explain why it is impossible to reach 100%.

Session link.