Newest Dynamics 365 Fin & Ops platform brings us many direct integration possibilities with Azure and Power Platform, but in older Dynamics AX 2012 we do not have that much. So, how can we achieve same integrations possibilities with the old on-premise Dynamics AX 2012? There are many ways to do that and in this post we will investigate the possible options and do some brainstorming on when and how to use them.
If you need a quick and hassle-free solution or if you need to do such an integration in very short term, you may use some of the MS provided built-in AX 2012 and Azure integration solutions.
Read only Integrations
If the integration you need to do is a read-only, like publishing some data from AX and reading them in Azure or Power platform, then you can use the Entity Store.
As some of you already know, AX is not a SQL server based application and the AX data stored in SQL server is sort of bulk data without metadata and data-type information in it. So the SQL server data of Dynamics AX cannot be used directly for read-write operations. To be able to publish readable and de-normalized data from AX, a new feature called Entity Store is added in AX 2012 R3 version CU11. Entity Store supports direct connection with an Azure SQL Server Database which can be used directly inside Azure services and Power Platform, also Power BI. Using it together with AX Data Entities, we can directly publish data to Azure SQL Server. More info can be found in feature sheet :
If publishing Entity Store directly to Azure SQL Server is not possible for you, you can instead publish the data to your local SQL server and use Azure On-Premises Data Gateway to connect that database to Azure.
Azure On-Premises Data Gateway is a useful tool that lets you connect your local databases, file storage, sharepoint services and even REST/SOAP web services directly to Azure. Using this tool, you can publish your local SQL Server database to Azure/Power Platform, and use it as a direct data source just like an Azure SQL Database.
I will not get into details on how to setup and connect since this blog post will be a generic one but may write another blog post on how to use it in the future. More info, you may find in the following MS documentation :
What if you also need to write some data or run some operations, like posting a journal? In that sort of situation using built-in AX AIF Services is a good option. You can create AIF services in AX 2012 and publish them directly to an Azure Service Bus or to IIS for direct access with AX 2012 standard tools. Using the “Web Services on IIS” feature, you can publish your AIF service directly to IIS and call this public SOAP service directly from Azure. However, direct connection to Power Apps using built-in “Custom connector” feature is not possible for older SOAP type of services (support for REST with swagger documents only).
If your customer does not want to open a public port in their system for security reasons, then you need to setup a sort of gateway or relay service connection for your IIS published AIF service. AX has a built-in “AIF Windows Azure Service Bus Adapter” for connecting on-premise services to an Azure Service Bus. However, the setup of this adapter is quite complicated and can be a pain to maintain as wel. Instead you can also use the Azure On-Premises Data Gateway tool and publish your IIS AIF services to Azure with it.
I would like to mention that there are many drawbacks involved using these ready-to-go gateway services. XML data transfer over SOAP is not the best performing option for an integration service. We have much faster data transfer options today like JSON and even GZIP. On top of that, using API services with Azure On-Premises Data Gateway has always a long response delay to its API calls:
If you need a faster, more versatile and future-proof option to connect your on premise AX 2012 environment to Azure, you need to build a Custom ASP.NET Core REST proxy service for your AIF endpoints. Latest ASP.NET Core technologies and add-ons give you a lot of flexibility to enhance your services, like modern authorizations, swagger documentations, async service calls, relay services, windows services, caching, filtering, docker and microservices support and so on. I recommend you to use these latest technologies and not waste any time with any legacy options like ASP.NET WCF web services.
Building a basic ASP.NET Core proxy service for AIF is quite simple, and I will provide you sample code in my GitHub page below:
Just create a standard ASP.NET Core Web API service and make sure you include these packages in your project :
Then right click on your project’s service references and add a new “Connected service” reference to your AIF service using its WSDL address.
Then use the auto-generated methods and data contracts to call your AIF services and return data. All XML-JSON conversions from data contracts are done automatically for you:
public class ExchRateController : ControllerBase
readonly ExchangeRate.ExchangeRateForCurrenciesServiceClient aifClient;
ExchangeRate.ExchangeRateForCurrenciesServiceClient.EndpointConfiguration endpointConfiguration = ExchangeRate.ExchangeRateForCurrenciesServiceClient.EndpointConfiguration.NetTcpBinding_ExchangeRateForCurrenciesService;
aifClient = new ExchangeRate.ExchangeRateForCurrenciesServiceClient(endpointConfiguration);
// GET: api/<ExchRateController>
public async Task<decimal> Get()
ExchangeRate.CallContext callContext = new ExchangeRate.CallContext();
callContext.Company = "USMF";
response = await aifClient.getExchangeRateForCurrenciesAsync(callContext, "EUR", "USD", DateTime.UtcNow, "USMF");
When you later need to update your AIF services, just right click your service reference node and choose “Update reference”. All updates in your AX data contracts and operations will be directly available to your proxy service.
That’s all you need for the basics, then you can publish your ASP.NET API service to your web server and make it available for Azure calls using REST.
Power apps can use ASP.NET Core REST services by using it’s custom connector. However to be able use it, you will need a Swagger (Open API) document for your service. You can generate it using tools like PostMan app, or just add swagger documentation support to your API service. I recommend going for the second one, you can do so by adding the following AspNetCore swagger package and following the instructions (exists in the sample code as well):
Adding relay services
What if for security reasons your customer does not want to publish their service from one if their servers? Then you have two options, one is using Azure On-Premises Data Gateway and making your service directly available in Azure, however this will deliver a lower performance as mentioned before, another one is connecting their API service to a Azure Relay.
Azure Relay provides an Azure hosted backend service for your on premise services, that you can use for direct connections instead of using the web service hosted in your on-premise server. For more info check the documentation below:
You can directly change your ASP.NET Core Web API Service to a Azure Relay listener. First you need to first setup your relay server on Azure:
Then add a new Hybrid connection:
Click on the hybrid connection and add a new SAS policy for sending and listening, then copy the primary connection string :
After that, converting your .NET Core web service to a relay listener service is quick and easy, just add the Microsoft.Azure.Relay.AspNetCore NuGet package and follow the package instructions, add the necessary lines in your code (Program.cs):
Then start your project with “Kestrel option” (Not IISExpress) keep it running and test it with entering the hybrid connection url + your controller path in the browser:
After converting your web service to a relay listener, you always need to run it on Kestrel option. It will be a listener service instead of a web service so running it also on IIS or IIS Express will not be possible anymore and some web service features like swagger UI will not be working as well. From now on, you always need to keep your Kestrel running to be able to get a response from the relay service endpoint.
That might not be very practical, so why not converting it to a windows service? How complicated it can be?
After that, publish your service with a “Folder” profile and place it to a suitable place in your server. Then register your new windows service with following batch commands in the same folder and your relay listener now will be running as a windows service: