Exploring Integration Patterns in D365 F&O: Strategies and Best Practices

Rumman Ansari   Software Engineer   2024-09-24 10:45:27   808  Share
Subject Syllabus DetailsSubject Details 1 Questions Login to Open Video
☰ TContent
☰Fullscreen

Table of Content:

Session 2: Integration patterns for Dataverse - TechTalk

Session 1: Dynamics 365 Integration - General Guidance - TechTalk

In a cross-platform environment and large enterprises, there are many scenarios wherein many external or third-party solutions are used, which might be a web application or an application inside a domain. They need to integrate data with Dynamics 365 for Finance and Operations in real time or at specified intervals depending on the nature of the business, such as currency exchange rates from banks, syncing with POS terminals, and inbound/outbound integrations with other legacy systems.

Dynamics 365 provides us with ample options that we can use for integrating, such as custom services that we create to expose X++ business logic through a service interface for inbound and outbound integrations, OData REST endpoints that encapsulates Dynamics 365 for Finance and Operations business entities and allows us to perform CRUD operations using OAuth V2.0.

In this chapter, we will learn to use various integration technologies using simple business solution examples that are required day-to-day.

Integration patterns in D365 F and O

The following integration patterns are available for finance and operations apps:

  • OData
  • Batch data API
  • Custom service
  • Consume external web services
  • Excel integration

OData

OData is a standard protocol for creating and consuming data. The purpose of OData is to provide a protocol that is based on Representational State Transfer (REST) for create, read, update, and delete (CRUD) operations. OData applies web technologies such as HTTP and JavaScript Object Notation (JSON) to provide access to information from various programs.

OData provides the following benefits:

  • Allowing developers to interact with data by using RESTful web services
  • Providing a simple and uniform way to share data in a discoverable manner
  • Enabling broad integration across products
  • Enabling integration by using the HTTP protocol stack

Batch data API

Use the batch data API in scenarios that require one or both Data management package REST API and Recurring integrations. Both APIs support data import scenarios and data export scenarios.

For finance and operations apps, we have tried to simplify this process for all parties who are involved, from integration solution builders to customer users.

The package API lets you integrate with finance and operations apps by using data packages. The REST API can be used with both cloud and on-premises deployments. The data management framework's package API uses OAuth 2.0 for authorizing access.

The process of data migration, and movement into and out of any enterprise system, are critical pieces that any platform must support.

Recurring integration does the following:

  • Builds on data entities and the Data management framework
  • Enables the exchange of documents or files between finance and operations apps and any third-party application or service
  • Supports several document formats, source-mapping, and filters
  • Uses secure Representational State Transfer (REST) application programming interfaces (APIs) and authorization mechanisms to receive data from, and send data back to, integration systems

Before the integrating client application can consume this endpoint, you need to create an application ID in Microsoft Azure Active Directory (Azure AD) and give it appropriate permission to finance and operations apps.

When you create and enable a recurring job, you're prompted to enter the Azure AD application ID that will interact with that recurring job. Therefore, be sure to make a note of the application ID.

Much effort and planning go into building third-party integrations between an enterprise line of business (LOB) system, such as Microsoft finance and operations apps, and various source systems.

Custom service

A developer can create custom services for finance and operations apps. When a developer writes a custom service under a service group, the service group is always deployed on two endpoints:

Consume external web services

A developer consumes web services by adding new class libraries to finance and operations apps.

Excel integration

The Microsoft Office integration capabilities provide users with a productive environment that helps them get the job done by using Office products. Microsoft Excel can change and quickly analyze data.

The Excel Data Connector app interacts with Excel workbooks and OData services that are created for publicly exposed data entities. The Excel Data Connector add-in enables Excel to become a seamless part of the user experience. The Excel Data Connector add-in is built by using the Office Web add-ins framework. The add-in runs in a task pane.

Synchronous vs. asynchronous integration patterns

Processing can be either synchronous or asynchronous. Often, the type of processing that you must use determines the integration pattern that you choose.

A synchronous pattern is a blocking request and response pattern, where the caller is blocked until the recipient has finished running the Excel integration and gives a response. An asynchronous pattern is a non-blocking pattern, where the caller submits the request and then continues without waiting for a response.

Consider using OData for synchronous and Batch data API for asynchronous integration scenarios.