In recent weeks I have been in a number of discussions on how to support various integration scenarios through Dynamics 365 Operations (formerly known as Dynamics AX and hereafter referred to as D365O). Let’s be clear from the outset, I consider D365O as a pure cloud-delivered solution, so I am not considering any potential on-premise scenarios in this blog post.
With D365O being a cloud delivered solution and with (virtually) all customers having most of their other applications running on-premise at present, a key challenge is how we move data to and from Azure in this hybrid scenario. The Help WiKi for D365O is not flush with information on how to do this. However, a couple of things can now be ascertained in relation to how we integrate:
- peer-to-peer integration (or system integration) is supposed to be performed using web services either through the SOAP or the REST protocols.
- recurring integration scenarios are supported through processing of Data Packages configured in Data Projects.
- all integration revolves around the data entity concept.
Let’s deal with the simpler form of integration first. Already in Dynamics AX 2012 we were using SOAP-based web services. This does not appear to have changed much in D365O. In addition to SOAP-based web services, D365O now also supports REST allowing us to exchange JSON messages and perform CRUD operations using ODATA (you can read more about the ODATA protocol here).
For more information on supported services, see this Help WiKi article.
Conceptually, integration to D365O revolves around the data entity. The normalised database schema is aggregated into a number of high-level logical units called data entities to hide the physical implementation and make it easier for developers, who do not need to understand the underlying schema. An example is the Customers data entity. This data entity maps the simple concept of a customer into multiple tables in D365O.
This type of integration makes is relatively simple to integrate synchronously with D365O across a wide range of apps and systems. I have not been able to find a description of how Microsoft intends to scale out the service, so that remains to be seen.
To enable easy integration across the Dynamics 365 stack and Office 365, Microsoft is developing the Common Data Model (CDM), which is similar to data entities, but spans across all the applications in the ecosystem. This article by Ukka Niiranen is a pretty introduction to CDM. As the article indicates, CDM is intrisically linked with Flow.
With synchroneous integration taken care of through web services, let’s turn to asynchroneous integration. Data import and export is configured through the Data Management Workspace:
In the Data Management Workspace you are able to configure multiple data sources. Out-of-the-box data sources includes D365O itself, Excel and CSV. You can reconfigure these or you can add new ones (also based on ODBC and XML). In this example I am creating a Data Project that exports all exchange rates to an Excel file:
In the data project, I can select one or more data entities to export and determine the sequencing. This means I can export all currencies before I export all exchange rates, which makes sense.
Once I have saved the data project, I am able to set up a recurring data job:
The following screenshot shows the exchange rates Excel spreadsheet generated by the export:
Once I am done with the Data Project I download the Data Package file, which defines the structure of my Data Project.
Now I am able to import the data into an instance of D365O by creating an import Data Project and using the Package data source format. This can also be set up to happen on an a recurring basis. Pretty simple stuff, really.
THE TRICK IS GETTING DATA TO THE CLOUD…
This simple example shows how easy it is to configure and execute recurring import / export jobs using the Data Management framework and data entities. However, since D365O runs in the cloud (Azure), we need to get data in to or out of Azure to be able to process them. Probably the simplest way is to use the Azure Service Bus. Transferring data to and from Azure Service Bus, however, this will require some sort of broker service such as BizTalk, but that discussion is for another day… I think, at this stage, it is fair to say that D365O offers good tools for integration, but operating in a hybrid world will require some extra work for the foreseeable future.