How to integrate with Dynamics 365 Finance and Operations Part -1

Integrating Microsoft Dynamics 365 Finance and Operations (D365 FO) with external systems, applications, and services is essential for building a connected and efficient enterprise ecosystem. This post explores the major integration methods commonly used in real-world projects.

1️⃣ OData (Open Data Protocol)

OData is an open source protocol to serve and consume interoperable data using common query operations with RESTful APIs. D365FO exposes all its public data entities as OData endpoints, which can then be accessed using the following URI format :

https://<env>.cloudax.dynamics.com/data/<EntityName>

OData provides a quick, codeless data integration method with many data query options and CRUD operations. You can use its open standard query string language to query your data and do data manipulations using standard OData CRUD commands, all using just simple and open standard REST calls. If you would like to call a custom method within your data entity, this is also supported by exposing custom actions with your OData entities, so the commands are also extendable to a certain point.

You can definitely use OData for your own integration projects, but there are also many OData-ready software available today, and these can be directly connected to D365FO OData endpoints. Microsoft Power BI also supports OData connection, and you can connect Power BI using OData if you feel lazy with setting up faster data integration possibilities, like Entity Store and Data Lake integrations.

Although it looks like the optimum way of data integration with D365FO, there are some drawbacks involved. OData queries and data operations are executed really slowly, and data reading may take ages if you try to retrieve a large entity. OData is mainly designed for simple CRUD operations and simpler queries. If you need to execute complex queries, like complex joins and lookups, for example, you may start to hit its limits.. Although you can add some custom actions to extend available OData commands with your own ones, complex operations and business logic unfortunately do not go very well with it. It may be required to place this complex logic in a consumer application if you decide to integrate it using OData.

There is also a rather new feature of D365FO to throttle calls to OData endpoints by giving priorities to them, to avoid system lockdowns that might be caused by frequent OData calls. You can read more about it from the link below :

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/priority-based-throttling

Remember, you can also use OData endpoints in Azure API Manager, just like custom services.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/odata

✅ Best for lightweight, real-time CRUD operations.

🔑 Authentication

Like all external D365 FO integrations:

✅ Register an Azure AD app.

✅ Use OAuth 2.0 to get a bearer token.

✅ Send the token in the Authorization header: Authorization: Bearer <access_token>

2️⃣ Custom Services (X++)

This is by far the most flexible and customizable way to integrate with D365FO and the one I use mostly in my integration projects. Custom services are created with standard D365FO X++ code and can be used for both data based and operation based (posting stuff etc.) integrations, limit being just your imagination.
AIF services used in Dynamics AX are now upgraded to custom services in FO, and they are automatically published into SOAP and JSON REST endpoints when deployed. However, management and monitoring tools used for old WCF AIF services have now disappeared, leaving just naked, non-configurable service endpoints.
When you deploy a custom service, the following endpoints are created and you can call them remotely using standard AAD OAuth authorization and SOAP/REST HTTP calls:

REST (JSON): https://<baseUrl>/api/services/<ServiceGroup>/<ServiceName>/ 

SOAP : https://<baseUrl>/soap/services/<ServiceGroup>/<ServiceName> 

Data integration in custom services is done via data contracts, which are then converted to XML or JSON depending on the endpoint. Performance of doing so is quite fast, compared to other data integration options, since everything is handled with low-level .NET commands. You can, in theory, transfer big amounts of data this way; however, I do not recommend doing so. With large data transfer, you may hit some unforeseen limitations and timeout problems on the way. But it is still possible to program some kind of paging mechanism in your service class to send small chunks of larger data to skip these limitations as well.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/custom-services

✅ Use when OData can't support complex validations or custom workflows.

🔑 Authentication

Like all external D365 FO integrations:

✅ Register an Azure AD app.

✅ Use OAuth 2.0 to get a bearer token.

✅ Send the token in the Authorization header: Authorization: Bearer <access_token>