Integration framework: In D365 the integration framework is a framework that enables data flow between different application. It starts with Data Entity. Data Entity is a new concept in Microsoft Dynamics 365 for Finance and Operations. A major part of the integrations is based on Data entity that is deeply embedded at the kernel level.
Data Entities: According to the MSDN, Data entities provide conceptual abstraction and encapsulation of underlying table schema that represents data concepts and functionalities.
Data Entities are updatable views. They have replaced previous concepts in Microsoft Dynamics AX, including AXD, the Data/Import Export Framework (DIXF), and aggregate queries. Data Entities provide a single pack of records that capture business logic and enables scenarios like import and export, integration and programmability. It can also be exposed as OData services for some other third-party integration.
In D365, when we create a new customer through a Customer Form we not only provide basic information about the customer, but also other important additional information, like addresses, credit limit, tax details etc. All the records internally don’t get stored in a single table. It is scattered among a small set of related tables (LogisticPostalAddress, LogisticElectronicAddress, DirParty etc.). During a customer record creation from an external application we must take care of all the mandatory fields across all those related tables. A data entity encapsulates all these tables and exposes the fields that we want to update. The customer data entity is an updatable view in which each row contains all the data from the customer table and its related tables.
There are few highlights of Data Entities -
- Microsoft shipped 1800+ out of the box Data entities and counting.
- Customer/ISVs can extend all out of the box existing entities or add new entities based on their business requirement.
-- Out of the box Sales Order entities can be used and consumed from any third party application for further processing.
-- ISVs can create new Data entities and use those across their integration.
For example, an ISV is developing an interface or add-ins where separate configuration and master tables need to be updated from other .NET based application. In this scenario the ISV needs to create new Data Entity as per the requirement
- Composite entity is another useful and interesting feature of D365 that I mentioned above.
For example, a Sales Order document consists of several tables in D365. In this process, there are some mandatory fields and some optional fields. A composite entity takes care of that. A composite entity contains only the fields that you want to update from an outside application. If you are using Data Entities then missing on a mandatory field will not return any run time error. It will be handled internally by D365.
There are a couple of ways Data entities can be created.
a. Using out of the box Wizard
b. Programmatically using API
Data entities are exposed to the outer world through Data Management Platform and OData Services. For an Asynchronous Integration Data Management Platform is used and Synchronous integration uses OData service.
Data Management Platform:
Data Management Platform is a platform that facilitates data exchange between systems. Any data that goes through Data Management Platform goes through staging tables.
This platform is used for File-based integration and Application lifecycle management.
The data management framework allows us to:
· Move data between two similar systems. For example, between D365FO Development and Production.
· Maintain a reusable library of data templates and datasets.
· Use data packages to create incremental data entities. Data entities can be sequenced inside the packages. You can name data packages, which can be easily identifiable during import or export. When building data packages, data entities can be mapped to staging tables in grids or by using a visual mapping tool.
· Validate and compare view data during imports.
File based Integration – Like any other ERP applications, a file import and export are an important feature in D365. This feature can be used for various purposes. For example, any hourly machine rate updates, sales tax rate updates, exchange rate update etc. There are generally two types of integration.
a. File Import/export - This is an interactive and attendant integration. A rate table, sales update, employee timesheet are some typical examples of that. Initial data migration, copy configuration are some examples of it.
b. Recurring integration – This is an unattended asynchronous integration, end of the day kind of batch process. Daily export of sales data, weekly GL export in a file and folder are some examples.
Application lifecycle management – In an implementation, we often need to copy the master data and other configurations related to settings. Also, data migration between UAT environment and production environment. Application lifecycle management takes care of all these.
a. Copy integration – Data Migration Framework can be used to copy configurations data across companies or environments. It also can configure processes or modules using Microsoft Dynamics Lifecycle Services (LCS).
b. Data migration between systems – This is a data migration or initial data load scenario. After a successful UAT testing of D365, the environment will need to roll over to the production.
Microsoft Dynamics Lifecycle Services (LCS) is used for both the above scenarios.
OData Service : OData is a standard protocol for creating and consuming data. OData uses web technologies such as HTTP and JSON to provide access to information from various mobile or third-party programs. A Data entity is automatically exposed as OData service. Once done Office integration and mobile integration can talk with D365 through OData REST based endpoints. This is a synchronized integration between D365 and any real-time mobile or office apps.
OData also worked with Power BI. Power BI Desktop connects to the OData feed and accesses the available tables and other data elements.
Custom Service : The last bit of integration is the custom services from the old flavor of AX 2012. Custom service features are still supported in D365. Out of the box or custom X++classes can be exposed as custom service to cater with any custom integration requirement. These custom services are consumed from outside applications to read and update D365 tables based on custom business scenarios. In D365 while creating a custom service and exposing it, it automatically creates two service endpoints.
· JASON/REST endpoint
· SOAP/XML endpoint
Custom services are used to integrate with third-party applications and add-ons. In a specific business scenario where an integration is needed with other ERP systems like SAP, custom services are generally used for handshaking. Based on business needs and technology preference D365 integration is possible across the environments.
