I have 2-3 source systems which are on-prem databases. I am planning to use Logic Apps to connect to these source systems. As per the Azure documentation we need to install a On-Prem Gateway on a local computer.
I am skeptical of this methodology as it demands dedicated system, so not sure if this works in actual production scenario.
Please can you suggest what is the right way to do it.
Here is how to connect to on-premise data sources:
If the services are accessible over the internet then you call service endpoint over HTTP or HTTPS from azure logic apps. This article will help you with details steps to be followed: https://learn.microsoft.com/en-us/azure/connectors/connectors-native-http
If it is not accessible over the internet then this article will help with step by step process: https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection
Before you can access data sources on premises from your logic apps, you need to create an Azure resource after you install the on-premises data gateway on a local computer. Your logic apps then use this Azure gateway resource in the triggers and actions provided by the on-premises connectors that are available for Azure Logic Apps.
Also check this for reference.
You may also want to consider the costs.
Related
I'm almost giving up here - how do I connect a Logic App to a Service Bus WCF Relay running on-prem?
Following an (incomplete) tutorial on MSDN/MS Docs, I've successfully create a host and client app that communicate with each other via an Azure WCF Relay. Now, I want a Logic App to communicate with the host on my dev box.
How do I do this?
Here is how to connect to on-prem data sources:
If the services are accessible over the internet then you call service endpoint over HTTP or HTTPS from azure logic apps. This article will help you with details steps to be followed: https://learn.microsoft.com/en-us/azure/connectors/connectors-native-http
If it is not accessible over the internet then this article will help with step by step process: https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection
Before you can access data sources on premises from your logic apps, you need to create an Azure resource after you install the on-premises data gateway on a local computer. Your logic apps then use this Azure gateway resource in the triggers and actions provided by the on-premises connectors that are available for Azure Logic Apps.
Also check this
To simulate a device I want to use a Logic App to fill a Azure Database for PostgreSQL with test data.
I found the two connectors PostgreSQL and SQL server but unfortunately both don't work for me. The PostgreSQL connector does only support onpremise databases and neither the autodetection nor the manually input of the connectionstring works with SQL Server.
Would great if somebody could give me a hint how to write data into a Azure Database for PostgreSQL from a Logic app.
Unfortunately, there is no connector available for this as of today.
The current alternatives would be
Use Azure Functions (which can be called from Logic Apps if required)
Create Custom APIs and a Custom Logic App Connector
Also, there is a feature request on UserVoice that you may upvote to gain traction.
When having some on-premises data sources that one wants to access from Azure, is the "best practice" to create a data gateway, or is this becoming an outdated approach? I ask because I notice it relies on the "Gateway Cloud Service" which as I understand it is on its way out.
The actual requirement for me is only to be able to do a query from a functions app to the on-premises sql server. I'm not even sure this is possible through the data gateway.
Any and all feedback appreciated.
Take a look at hybrid connections: https://learn.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections
They are designed for what you want to do:
Basically, a tunnel is created between the SQL endpoint in your on-premise environment and a target endpoint for your Azure Function in the Azure environment. It uses HTTPS traffic, so it is easy on the on-premise firewall. To create the SQL endpoint, you'll need to install an agent called the 'Hybrid Connection Manager', which will act as a proxy between the Azure endpoint and the SQL server.
After the endpoints are established, you can connect to the Azure endpoint with your function, and it will be tunneled to the on-premise SQL (using the HCM).
Bear in mind that this will only work with SQL accounts, not with AD accounts. Also, the Azure Function must be hosted by a dedicated App Service Plan, not the consumption plan (alas).
I have an on premise oracle database. Can I use anything on AWS e.g. API Gateway to query the database and expose the results via API? I know I could do API Gateway -> Lambda -> Oracle DB where the code in the Lambda function would query the database (assuming query takes less than 5 mins). Are there any other easy options that would be serverless and with minimal amount of code?
Basically I would like to find the simplest way to create an API layer over the top of an existing on premise oracle database so that applications (hosted on AWS) can access this data without connecting directly to the database. Does AWS provide anything out of the box?
There does not seem to be an out of the box way provided by AWS to connect API Gateway to your on premise Oracle DB. So basically the way you provided (API Gateway->Lambda->Oracle) should be the way to go.
Now the question is if you want to connect to your Oracle directly or if your want to create a replication of your database in RDS and create a synch mechanism between RDS and your on premise Oracle DB to keep the DB highly responsive and available (in case of network failure between AWS and your local network). I think that depends on how you access your DB on premise.
If your won't create an replica in RDS you should at least use a VPN connection to your local network to keep data transfer from on premise Oracle to AWS RDS secure.
Yes it is possible to use AWS Lambda and expose the API through API
Gateway. But that is the easy part.
The tough part is to get your On-Premise database connected to AWS
infrastructure. If you have an on premise database, and you are
working in a large enterprise, you will need to get through a lot of
approvals to setup a VPN or a AWS Direct Connect.
The ideal solution is to use AWS Direct Connect to extend your
corporate infrastructure to connect to AWS and then use Lambda to
connect to the DB.
Also there is no out of the box solution in AWS to connect to
OracleDB. At the most, you can wrap all business logic in Stored
Procedures, and execute them in the lambda function. You can always
use the JDBC from Lambda to connect and query your database.
Try this from AWS Marketplace https://aws.amazon.com/marketplace/pp/B01MU8W71L
Is it possible to have a WCF service that is running on Windows Azure communicate with a local / on-premises SQL Server database?
Alternative options we're considering are:
Push the 4 SQL Server databases that the WCF service needs to gather and process data from up to a Azure VM
Create 4 SQL Azure "clones" of the local / on-prem SQL Server databases and use the data sync feature to keep the Azure clones in sync with the local data.
Ideally, we'd like to be able to expose the on-premises database (via the VPN) to the service and hit each of the databases directly.
Yes, you can make outbound connections from any Azure hosted service, whether running in web sites, cloud services or virtual machines. If you need traffic going through a VPN, you'll need to use cloud services or virtual machines, since web sites can't be added to a virtual network.
Actually, an easier solution would be to host your WCF service internally and expose the service via an Azure Service Bus Relay. The service bus relay supports multiple authentication types for securing the service and no VPN is required. There is a good walk-thru here - .NET On-Premises/Cloud Hybrid Application Using Service Bus Relay. We have successfully used this technique to expose several services to third-party vendors.
you can set up Site-to-site VPN as shown in this resource - Step-By-Step: Create a Site-to-Site VPN between your network and Azure
I would think of SQL Data Sync for scheduler times and that too for small amounts of data (at least not in millions)