Summary of Integrations in Dynamics 365 for Finance and Operations (2024)

The New Data Management Framework, Data Entities and Integration APIs

Using a complex, fully integrated ERP system where we have a large amount of data, the big question is always; how we can manage our data? We need to look at what the available options are, when do we need to deal with the core data management tasks and import-export data, and we must also look at the application integration scenarios.

In Dynamics AX 2012 there were multiple ways to manage data such as Microsoft Excel Add-ins, AIF (Application Integration Framework), and DIXF (Data Import/Export Framework). In Dynamics 365 Finance and Operations,* Microsoft has introduced a new concept; the Data Management Framework (DMF), and Data Entities, which combine those different data management concepts into one.

Let’s have a look at Figure 1below which displays the core data management scenarios managed and supported by DMF in Dynamics 365 Finance and Operations:

Figure 1. Core Data Management Scenarios

In this article we are focusing on integration scenarios, it’s intended to give a high-level overview of possible integration tasks and available options in Dynamics 365 Finance and Operations.

Before going further, below is a quick overview of the terminology used in the new DMF/Data Entities and application integration concept:

Data Management Framework

DMF is the new all-in-one concept introduced by Microsoft in Dynamics 365 for Finance and Operations. It supports and manages all core data management tasks, see Figure 1. above.

Data Entity

A data entity is a simplified de-normalized representation of underlying tables. A data entity represents a common data concept or functionality, for example; Customers or Vendors where the details are stored in normalized relational tables, but all details are represented in one flat view in Customer Details or Vendor Details data entity. Data Entities are intended to be easily understood by users familiar with business concepts. Data Entity is the core object of Data Management Framework. Do NOT confuse it with Legal Entity which is an organization or a person in Dynamics AX and Dynamics 365 Finance and Operations. Data Entity and Legal Entity are different!

Data Package

Data Package is simple .zip file which contains the source data itself i.e. a xxxx.csv file and the manifest files which contain metadata information of the Data Entity and the processing instructions for DMF.

Blob Storage

In most cases the Dynamics 365 Finance and Operations instance is an Azure hosted environment and the storage for those instances is called Blob storage. This is an Azure hosted storage area, where the incoming and outgoing data and data package(s) are placed during the integration (import-export) processes.

• An example for uploading data (write) to Blob storage is, when a data import project is created in Dynamics 365 Finance and Operations with a Data Entity to be used, a user then clicks on the Upload button of the import project to upload the source Data Package which will be imported. The upload logic writes the package to Blob storage to be processed by DMF within Dynamics 365 Finance and Operations.
• An example for downloading (read) data from Blob storage is, when a data export project is created with a Data Entity to be used for data export, once the processing export data job is finished you need to click on the Download button to get the exported data. The download logic reads the data package from Blob storage and it can be saved to a file share location for further processing outside Dynamics 365 Finance and Operations.

SOAP/XML

Simple Object Access Protocol is a messaging protocol that allows programs that run on different operating systems (such as Windows and Linux) to communicate using Hypertext Transfer Protocol (HTTP) and its Extensible Markup Language (XML). This is mainly used in web integration services. It is available out of the box in Dynamics 365 Finance and Operations.

REST/JSON

Representational State Transfer (REST) is a software architectural style that defines a set of constraints to be used for creating web services. Web services that use the REST architectural style are called RESTful web services. The data representation layer is textual, but the payload can be formatted in either HTML, XML, JSON, or some other format. In Dynamics 365 Finance and Operations the data representation is JSON for the REST protocol.

OData

Open Data Protocol is a REST-based protocol. It is used for creating and consuming RESTful APIs. Even though OData is a REST-based protocol, it is different from other web REST-based web services. In Dynamics 365 Finance and Operations it is used for real time integrations, but based on the latest documentation by Microsoft it supports batch requests.

Now that the terminology has been explained, let’s have a look at Figure 2below which displays the integration scenarios grouped by integration processing types/patterns and approaches. These are the three main types of integrations and can help organizations determine which approach fits best for the given integration task based on the related business requirements.

Figure 2. Data Integrations by Pattern and Approaches

Integrations Utilizing Data Management Framework

These are the file-based integration scenarios; file import and file export. There are two out of the box APIs available in Dynamics 365 Finance and Operations to support these scenarios; Data management framework’s API and Recurring integrations API.

The pattern is Batch data API for both, these are asynchronous integrations. Data processing is done by DMF and batch framework of Dynamics 365 Finance and Operations.

• Data management framework’s API
  • Scheduling outside Finance and Operations
  • Only data packages
  • REST protocol only
  • Service type is OData
• Recurring integrations API
  • Batch job is scheduled in Finance and Operations
  • Blob storage is used to ‘feed’ the recurring import data job (upload import file)
  • Blob storage is used to ‘get’ the exported data created by the recurring export job (download export file)
  • Files and data packages both accepted
  • REST and SOAP protocols can be used
  • Service type is custom service

Integrations Utilizing OData Service

The pattern is OData, it is synchronous and there is a batch scheduled within Dynamics 365 Finance and Operations.

• Microsoft Office Integration
  • Real time
  • An example for MS Office integration; when you open master data (Vendor) in MS Excel for editing, edit the data, then import it back to Dynamics 365 Finance and Operations, it uses Data Entity and DMF and consumes OData for export and import.
• Mobile App Integration
  • Real time
  • For example, when you create a mobile app for a Tablet, which allows you to enter a sales order, when you click on Submit, it creates the sales order in real time in Dynamics 365 Finance and Operations.
• Third Party Integrations
  • Real time
  • Using OData endpoint and services which can be consumed by third party web sites and integration web services.
  • For example, you have a home builder third party application and you enter a new customer and contract using your web-based internet site, then your integration interface sends the customer details and contact information to Dynamics 365 Finance and Operations, where the new customer details with contact information will be created in real time.

Integration Utilizing Custom Service

Custom services can be created by a developer within Dynamics 365 Finance and Operations.

• SOAP based. These services remain the same as they were in Dynamics AX 2012.
• REST based. This feature enables X++ classes to be consumed as JSON services. In other words, the return data set is in JSON format. JSON, which stands for JavaScript Object Notation, is a compact, lightweight format that is commonly used to communicate data between the client and the server.

Integration Development and Special Scenarios

In the event that none of the out of the box Data Entities can cover the actual integration scenario and business requirements, a developer can create a custom Data Entity (or Data Entities) in Microsoft Visual Studio, then those Data Entity/Entities can be consumed in integration cases and by the users for manual data management processes. Data Packages can be created based on the custom data entities, once the data entity is published (internally by a developer or through LCS).

Real time OData-based custom solutions for application integration also can be created an easier way in Visual Studio, consuming the out of the box OData endpoint and protocol. Visual Studio does have an add-on to create OData integration proxy classes from all available Data Entities. A developer can instantly create code against the data entities proxy class to utilize the data entities and the OData services.

It’s easy to see that in Dynamics 365 Finance and Operations, Microsoft has introduced a powerful new concept to support and utilize the most recent technology and the new platform; Azure hosted environment(s), and web-technology based Dynamics 365, regarding data management tasks and integration scenarios. Data Management Framework and Data Entities provide a much more efficient solution for core data management scenarios, compared to what we had in earlier version(s) of Dynamics AX. The out of the box OData, REST and SOAP protocols and endpoints offer various choices for implementing different integration types and approaches.

Please feel free to contact us if you have any questions about Dynamics 365 for Finance and Operations.

* Most customers still call it Finance & Operations, but Microsoft now licenses it as 2 different apps: Dynamics 365 Finance and Dynamics 365 Supply Chain Management.