Taking a closer look at how Flows and Apps communicate with connectors

By | November 22, 2019

I used to think that connectors would be isolated from my local machine in the sense that, since they are in the cloud, my machine would be talking to the Flow/Canvas Apps/Flow Designer/etc, but not to the connector directly. Basically, like this:

image

And I was going to mention it in the context of security in one of the following posts. But it turned out there is an interesting scenario where connectors do behave differently depending on whether we are working with them in the “designer” or whether our flows are responding to various triggers.

Earlier today, I got the following error when trying to choose environment for the CDS connector in the Flow:

image

So I got on the call with Microsoft Support just to find out that everything was working. How come?

Well, I was using a laptop which was connected to a different network. You can probably see where it’s going now.

Back to the machine where it was not working, and, in the network tab of Chrome dev tools I see that the following request is failing:

image

That’s the evidence that there is some communication with the connectors which may be happening from the “client side”. In other words, the communication diagram should look a little different:

image

In practical terms, that means one should always read the manuals rather than assuming too muchSmile For this particular issue, there is a whole section in the documentation related to the IP address configuration:

https://docs.microsoft.com/en-us/power-automate/limits-and-config#ip-address-configuration

And the one which we ran into is mentioned there, too. It seems to be one of a few for which I would not be able to explain the purpose right away (would not even recognize them):

image

But, if you look at where the error happened on the screenshots above, you’ll see how having a connectivity issue between your client machine and that domain could hurt you.

Now, in my case there was a problem with DNS resolution. I fixed it temporarily by adding required ip address to the hosts file:

52.242.36.40 canada-001.azure-apim.net

Which also allowed me to do an interesting test. What if, after fixing the connections, I saved the flow and removed that IP address from the hosts file?

The Flow just ran. Without any issues.

Even though, when I tried editing the flow, I could not load the environments again.

Which kind of makes sense, but also gives a clue about what that azure-apim.net is for. Flows will be running on the cloud servers, so they won’t have a problem connecting to the azure-apim.net from there. However, when editing Flows in the designer, the designer will need to work with those connectors, too. Turns out there is a special server(s), which is hosting “connectors runtime”, and which needs to be accessible form our local machines to let the Flow designer communicate with the connectors.  It’s not CDS-specific, it’s not connector-specific… For instance, just out of curiosity, I tried Outlook connector and got an error on the same URL:

image

This is not all, though. If you open network tab for a canvas application, you’ll actually see that Canvas Apps are communicating to the apim servers even in the “play” mode, so, essentially, there is no way around this. We just need to make sure apim servers are accessible from our network.

Leave a Reply

Your email address will not be published.