I know there is capability to call logic app from power automate by exporting the logic app as custom connector - Logic app needs to be under the consumption tier having its inbound IP public
Now the issue I face is that from the security requirements I have, I need to secure my logic app inbound endpoint. I can do this by using the standard tier and creating a private endpoint for my inbound traffic of my logic app.
When this is done, I can't export my logic app as custom connector anymore and I do not know how to make it available privately from my power platform environment using power automate for instance.
So to summarize, is it possible to call a logic app resource behind a private endpoint from power automate.
Thank you in advance for any support here.
Regards,
Marc.
I just looked for an answer to that question myself and found your post.
From an old article, I can only find the solution to build your own custom connector in Power Platform that sends HTTPS queries over a data gateway:
https://flow.microsoft.com/en-us/blog/on-premise-apis/
The default connector of Azure Automation doesn't support connection over a data gateway. Probably also Logic Apps.
This also means to me that Azure Automation still needs to stay public for us, too much customization.
Cheers,
Tobi
Related
Apologies if this is a silly question but for the last 2 hrs. I have been reading about the difference between built-in and managed connectors for Azure logic apps and it's driving me crazy. Can someone please explain in simpler language? Initially, I thought built-in connectors are for Azure services like Azure function or table storage whereas managed are for Microsoft services like O365 & Sharepoint, but after going through the list of connectors on Microsoft documentation, its not true.
Is this tenant based? For example, built-in connector will only allow connecting to azure services in that tenant but if we need to connect to an Azure service in a different tenant, we need managed connector. Even if this is true, how can something like SMTP be an inbuilt connector?
Is the difference on the basis of authentication? The mechanism to authenticate is different for built-in / managed
I think there are some differences between the two under the hood regarding how they are hosted, but I don't know how much difference that makes for you as a user. You can read a bit more here.
However, the main difference that I have noticed and that makes me prefer the built-in connectors (when applicable) is how you can set up the authentication. Especially when trying to set up CI-CD for Logic Apps (and devloping locally in VS Code) this makes a big difference. For the managed connectors, a managed api connection is created in the portal and it's a nightmare trying to parameterize that when developing in VS Code and incorporating that to Devops-pipelines.
Built-in connectors run in the same platform where your logic apps is hosted whereas Managed connectors are hosted in public cloud. When you use built-in connectors the information configured for the connector will not be sent to public cloud for processing it will run natively in your Logic Apps. This makes it more secured. There are many differences for example authentication method, api connection file, and many more.
I added a logic app custom connector resource to connect to on premise HTTP API. But I'm not able to find it in logic app actions,
I tried creating consumption logic app and it showed up there.
Not getting in standard logic app for some reason. I tried searching with different keywords like custom connector and name of connectors. No results. Also tried to include this action from code view . It got added, but the logic app stops after executing trigger only.
Both my connector and logic app are in same region as per documentation. Can someone let me know why it is not showing up in standard logic app actions?
Currently we don’t support invoking the customer connector from Logic App standard. This is something product team are planning to support but no ETA yet.
Custom managed connectors currently aren't currently supported.
As Mayank mentioned, custom connectors are not yet supported for Logic app standard version. Couple of possible workaround solutions are:
1.Try built-in connector extensibility - https://techcommunity.microsoft.com/t5/integrations-on-azure/azure-logic-apps-running-anywhere-built-in-connector/ba-p/1921272
2.Use a consumption logic app for integrating custom connectors and invoke it from your standard logic app.
Custom connector support is coming soon to Logic Apps Standard.
By creating a new custom connector and manually adding it to the connection json and manually crafting the workflow code view you can make this work today. Once you do this some of the UI will work, full support coming soon.
I would like to know how to create health checks for some Azure services? Is this possible? I thought of creating time-triggered Azure functions that would test the end-to-end connectivity of for example my Azure storage, Azure map, and Event Hub but it would fail if suddenly my Azure functions would stop working.
I would like to have some kind of Cachethq, but for all the Azure services that I use for my application.
Is there a best practice for this?
Kind Regards,
Normally you would have an endpoint that checks any relevant subsytem for errors. This could be a public available /health endpoint. Some frameworks like Asp.Net Core has built-in support for health checks.
An http triggered Azure function like you propose could also do the trick.
Then you need something like a watchdog that calls the health endpoint at a given interal. In Azure you can use an availability test. If you want you can create alers based on this availability and create dashboards that show the status over a given period.
If you are hosting your app using Azure Web App you can use the built-in health system as described here
If you have a load balancer or gateway in front of your app you can use the /health endpoint for health probe endpoints of those balancers/gateways.
I am trying to build Serverless Microservice Architecture
Azure services used by me are:
Azure CDN
Azure Active Directory
Azure Logic Apps
Azure Functions
Azure Event Grid
Azure SignalR Service
Which below tools do I need mange and secure my API in Azure Serverless Microservice Architecture?
Azure Traffic Manager
Azure Application Gateway
Azure API Management
Azure Function Proxy
Links Referred by me are :
https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/serverless/web-app
https://learn.microsoft.com/en-us/dotnet/standard/serverless-architecture/serverless-design-examples
Please help
Edit:
I understand above tools and it purpose but what I can't understand is do I require them, if yes in what order, all I am developing is an Angular 2+ app, post a Command Event to Azure Functions/Logic Apps using REST api returning RequestId (and triggering chain of events) and subscribing to that RequestId to listen for Domain Event.
This is very broad Architecture question. All the services you mentioned have specific purpose. You can even secure your functions without using any of them by simply turning on authentication on functions.
I would suggest reading all of them in details can help you identify which service may suit your needs in this case. e.g. Traffic manager is used for cross region traffic distribution and may not be required in your case. Function proxies and Api management overlap in few cases and really depends on what you are trying to achieve. To get better idea you may need to share your architecture diagram.
What are the differences between an API App and a Logic App?
Development speed ... e.g. the LA designer response gets very slow
Deployment options ... both through ARM template
Testing options ... API App is Web API, so all usual good testing practices, but Logic App doesn't have anything
Security options ... Logic App's can set "Allowed inbound IP addresses" to specific IP's
Any other differences ?
Azure API Apps are used to host your own, custom Web APIs in the cloud.
Azure Logic Apps allow you to implement workflow process without requiring you to write any code through the use a a visual, "no-code" style designer.
If you look at the documentation on how to use these services you will see the differences quite clearly.