Hi all, we are interested in creating a data provider that would point to an Azure SQL database living in Microsoft Fabric. The challenge here is that Fabric supports Entra ID users, service principals, and groups only. SQL or Windows authentication aren’t supported.
It doesn't appear that the built in SQL data provider driver, as of 25R1, supports Entra ID authentication.
We've come up with a couple of ideas but would be very interested to hear if anyone has been able to establish this kind of integration successfully.
Our thoughts:
Find a middleware driver that would support Entra ID authentication through Acumatica. Potentially CDATA?
Access fabric data through a linked server query to a SQL Managed Instance in Azure
Replicate the fabric data to a regular Azure SQL Database
Thoughts welcome. Thank you!
Best answer by chameera71
Hi,
You’re addressing a common challenge as Microsoft Fabric shifts to Entra ID authentication only, while Acumatica’s SQL data provider in version 2025R1 doesn’t yet support Entra ID logins. You’ve outlined three solid wokaround ideas: using a middleware driver like CData to bridge the gap, setting up a SQL Managed Instance (MI) with a linked server to Fabric, or replicating Fabric data into a regular Azure SQL Database. The middleware approach (e.g: CData) is the cleanest for real-time access as it handles Entra ID authentication and presents Fabric data to Acumatica as a standard SQL endpoint, but comes with licensing costs. The linked server option via SQL MI is clever, letting Acumatica connect to MI with SQL authentication while MI queries Fabric, but linked servers can get complex to maintain and may not scale well. The data replication approach is straightforward and reliable Fabric data is synced to an Azure SQL DB on a schedule, and Acumatica connects as usual, but this introduces some data latency depending on how frequently you replicate. If real-time data is a must, middleware is likely your best path; if daily or hourly updates are acceptable, replicating to a standard Azure SQL DB is the simplest long-term solution. The linked server method works for quick wins but could become difficult to manage at scale. Until Acumatica supports Entra ID natively, these are the realistic paths available. It would also be interesting to see if anyone has explored building a custom REST API data provider for this integration, though that’s a heavier lift.
You’re addressing a common challenge as Microsoft Fabric shifts to Entra ID authentication only, while Acumatica’s SQL data provider in version 2025R1 doesn’t yet support Entra ID logins. You’ve outlined three solid wokaround ideas: using a middleware driver like CData to bridge the gap, setting up a SQL Managed Instance (MI) with a linked server to Fabric, or replicating Fabric data into a regular Azure SQL Database. The middleware approach (e.g: CData) is the cleanest for real-time access as it handles Entra ID authentication and presents Fabric data to Acumatica as a standard SQL endpoint, but comes with licensing costs. The linked server option via SQL MI is clever, letting Acumatica connect to MI with SQL authentication while MI queries Fabric, but linked servers can get complex to maintain and may not scale well. The data replication approach is straightforward and reliable Fabric data is synced to an Azure SQL DB on a schedule, and Acumatica connects as usual, but this introduces some data latency depending on how frequently you replicate. If real-time data is a must, middleware is likely your best path; if daily or hourly updates are acceptable, replicating to a standard Azure SQL DB is the simplest long-term solution. The linked server method works for quick wins but could become difficult to manage at scale. Until Acumatica supports Entra ID natively, these are the realistic paths available. It would also be interesting to see if anyone has explored building a custom REST API data provider for this integration, though that’s a heavier lift.
