Calling Api different Approaches

[bssienes]

Hi All,

I noticed there are different ways we can call API's in our Power pages project.

1. We call it through Power Automate HTTP action.

2. We can call it through Power Automate using a custom action.

3. We can call an azure function which will call the API.

I don't understand the difference between these approaches. Do I get any advantage if I use power automate instead of azure function? 

[OliverRodrigues · Accepted solution]

Power Automate

• Pros:
  • has many connectors to lots of systems and application
  • low-code/no-code, can be achieved by citizen developers
• Cons:
  • API call happens async, depending on your need you might face caching issues on Power Pages

Azure Functions

• Pros:
  • you have access to the source-code, so you have full control of the API call
  • you will define how you would like the call to be made, so would probably not face caching issues on Power Pages
• Cons:
  • requires a pro-dev
  • dev effort is usually higher than using Power Automate

[bssienes]

Thanks @OliverRodrigues 

Which one is easier to maintain in terms of exporting/importing and deploying the project into new environment? 

[Fubar]

@OliverRodrigues HTTP Request, runs it synchronous.

@bssienes One of the other considerations is Security, and how can you ensure that calls that are made are coming from the Portal and if so is that user authorized to make such a call..

Implicit Grant Flow is the mechanism supported by the portal  https://learn.microsoft.com/en-us/power-apps/maker/portals/oauth-implicit-grant-flow

The other way is to trigger something in a way that a real-time dataverse plugin or workflow can be triggered, and have the results available on the next page you redirect to.  

[bssienes]

Hi @Fubar 

My main goal is to securely call an API from the portal at the click of a button. I am not sure what is the best way to do this but many people in this forum suggested to create HTTP request trigger in power automate and then call the API from there. To secure the HTTP request trigger we can use the trigger condition as shown below so that only the portal can trigger this flow.

I am not sure about the implicit grant flow, I am new to all of this. Is this a place to store my API keys so that I can call the API directly from the portal?

Or does it add another stage of security for calling the power automate flow? That's what I understand by reading this post: https://powerusers.microsoft.com/t5/Power-Apps-Portals/How-to-secure-the-flows-that-called-from-the-...

[OliverRodrigues]

@Fubar sorry yeah, the HTTP request to flow may run Sync, but the Flow itself would run Async, which leads to caching issues 

[OliverRodrigues]

@bssienes what is your API doing? what will be the result? do you need to know the result in real-time on the Portal page? or will you simply send the request and display a generic message to the user like "thanks your request is being processed"? 

[bssienes]

Hi @OliverRodrigues 

Sorry, I am new to this, what are you referring to by caching issues? Any examples on what kind of error this may cause?

I am calling the stripe api to add a credit card, display the credit cards on the portal, add a customer, make a payment etc.

So I need the response in the portal.

[Fubar · Accepted solution]

I believe the potential cache issue that Olive is referring to is that the Portal talks directly to a cache, any 'main' record that is created/updated from the Portal updates both the cache and Dataverse (so its data is available straight away as it is already in the cache), but 'non-main' records and records that are created in Dataverse from another user interface (e.g. via a Model Driven or Canvas App) are only pushed to the cache periodically (whilst this usually happens in less than a few minutes the SLA for it is actually 15min).  

So if your Flow for example created a record in Dataverse, that record would not be available on the portal straight away (and could take a few minutes for it to become available) as the HTTP Flow is not part of the caching mechanism.  But if all you need is data that is in the response from the HTTP call then not an issue.

The Trigger Condition on the flow trigger allows you to lock it down somewhat, but to do it more robustly you would also implement Azure API Management on the URL.  It all depends on what you are doing as to how secure it would need to be in some cases having a Trigger Condition would be adequate in others it may not be.