I’m getting a lot of questions along the lines of “how on earth can we integrate our on-premises systems with AX 7 running in cloud?”, therefore let me share some of my thoughts.
The first important point to realize is that “to integrate” means many different things, so there is no single solution for it. On the contrary – you know have more options than before, because you can easily utilize many existing cloud services, which weren’t that useful when your ERP wasn’t running in cloud. Although I mention quite a few options below, the list isn’t comprehensive by any means.
You have to take many things into account when designing your solution: which system triggers the integration (AX, external systems), what’s the trigger (schedule, user activity…), whether you need a response in synchronous manner or you can utilize queues (which is better for load balancing), what are requirements for performance, reliability, monitoring and so on and so on. I’m not going to discuss these things in detail, but you mustn’t forget about them.
Below I look at some integration options based on which system is triggering integration. There are quite a few links, if you want to learn more.
From your servers / workstations
The most straightforward approach is sending requests from your own machines to AX.
It may be a from a desktop application (the Excel add-in calling OData services exposed by AX 7 is a good example) or a server process (e.g. a service monitoring a network folder and pushing files to AX).
If you want to call AX directly, you can use its services (especially OData and custom services), including pushing files through web services (e.g. data management API), but it’s often not the best strategy. For example, you may want to send messages even if AX is down for maintenance and therefore you merely put them to some storage (Service Bus queue, blob storage, file storage…) where AX will find them when it’s back online.
Or maybe you have some additional logic to run, such as a workflow with conditions, message transformations, aggregation with other data and so on. You can utilize things like Logic Apps or Azure Functions for this purpose. Alternatively, you can run your logic on-premises before sending messages to cloud; then you can use BizTalk, for instance.
Logic Apps can also read data from storage and pushing it to AX, so you don’t have to implement it by yourself.
From AX
Running a piece of code in AX (usually in a batch) is a natural choice for many AX developers, but some aspects are a bit different in cloud.
In past, people often put files to import (to take this direction as an example) to a network folder, where AX read them on schedule. Now they ask how to put files to production VMs, which simply isn’t possible. You also can’t expect Azure applications to read files directly from your local hard disk. If you want to use this approach, you must store your files elsewhere, such as in an Azure storage in your subscription, on FTP and so on. For example, you can put files to OneDrive or a file storage mapped as a drive and let AX to read them from there via an API (although you may want to leave it to a Logic App, as demonstrated in File based integration using Logic Apps).
You can also call web services from X++, which includes even web services offered by your on-premises systems (exposed through Azure AD Application Proxy or Azure Relay, for example).
You can also call middle-tier services and execute any other code you like.
From a middle-tier service
There is a third option, when integration is orchestrated by another service in the middle. For example, you may have a logic app that runs on schedule, reads data from your on-premises Oracle database and uses the connector for AX 7 to create records in AX. Then you don’t have to develop any on-premises application pushing data to cloud, you merely install a gateway).
Some people are afraid that there is no way how to integrate on-premises and cloud systems, but that’s obviously not the case. You have many options, you just must choose the right one for your particular goal. It’s different than if everything runs in your own server room and it’s likely confusing if you’re not familiar with Azure (with new types of storage, app authorization and so on), but that’s what always happen when you start working with different architecture. You’ll also often combine several services, rather than having a single universal solution for integration.
