It is the two parts in the middle which are the extra steps you will need to add into any flow which meets the criteria I mentioned at the opening of this post This HTTP request uses the URI from the child flow. Now we have the child flow up and running let’s plumb it in to a parent flow I will go through each step with images again. ![]() Replace the your_client_ID and your_client_secret parts to form the correct string:Ĭoncat('grant_type=',encodeUriComponent('client_credentials'),'&scope=',encodeUriComponent(''),'&client_id=',encodeUriComponent('your_client_ID'),'&client_secret=',encodeUriComponent('your_client_secret')) Like a boomerang Here is the text string from the compose action mentioned in the gallery of images. Stick the access_token value from there into a final action which sends the result to the initial requester. The Body here is the output of the compose action from the previous image Last steps of the child flow is to parse the JSON from the access token HTTP request. This HTTP request then puts things together so we can call the token request URI. The blogs from Arend Jan explain more about where to get the information from. A sample of the value is below the image gallery. I’ve added a note in the image about the “Compose” actio This is a concatenated text string of the values needed. This is something you could pass from your parent flow if you set a request body in the previous step. This is the account you want to use when calling Azure AD. I’ve used the GET method here so there is no need to pass a request body I have 2 variables for my users username and password. This could be called by a variety of applications, not just a PA flow. We are calling this one “Get Access Token BC” The trigger for the child flow is receiving a HTTP request. Here is the top level view of the components making up the child flow. Let’s get the child flow out the way first as that’s the longer part. This pattern will work well as you don’t have to alter your existing PA flows using the HTTP connector that much. You will use this flow as a child to you main PA flow. The solution is to have a standalone flow which will retrieve the access token. I will admit early on I only came across my answer thanks to some brilliant blogs! I highly recommend reviewing Arend Jan’s posts in particular if you have little background on working/setting up OAuth2 for BC. If you’re still with me let’s get to the good bit… In which case if they use the HTTP connector, same explanation as above. You might have Power Automate flows which run from PowerApps. After all Power BI get to use legacy web services so Power Automate should get to as well right? For PowerApps you need to use a custom connector or the BC connector. Lesser reasons might be that you don’t have development resource or want to avoid cost of refactoring. If you have published a codeunit as a web service or you use query objects (which aren’t the API type). I say there are two main reasons you wouldn’t move things to the BC connector. That way you can just natively pickup the correct authentication. If you can move away from using the HTTP connector then please do. ![]() Why does this post matter? Well at the date of writing, 01/03/22, basic authentication for BC web services is being deprecated ( ). ![]() So what’s the point of this blog you ask? If you use the HTTP connector in your flows to interact with BC data – you have opened the right blog post. If you have custom connectors for BC data which use OAuth2 for authentication. However, if you have Power Automate flows using the BC connector you are already covered. As the title suggests this post is about using OAuth2 with Power Automate – applies also to Azure Logic Apps. I need to break that rule here to avoid confusion. ![]() Generally when writing a post I quickly explain the scenario and get straight to the solution.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |