Architecture

There are some fundamental differences between integrating with a cloud-hosted or on-premises remote system. Please refer to the illustrations and descriptions below for more information.

The DynamicWeb Integration Framework is pull-based, meaning that no data is read or persisted unless DynamicWeb requests it. Any integration action follows this flow:

A request is sent from DynamicWeb to a web service.
The web service handles the request and sends a response.
DynamicWeb reads or persists the response.

Both the request and response body can contain data that is meant to be persisted, with the most common scenario being the response body being saved to the DynamicWeb database. However, the data may not always match the table schema in DynamicWeb, which means that knowledge of the table structure and relations in DynamicWeb's database is required to properly map and persist the data.

How data is mapped between a remote system (typically an ERP or CRM system) and the DynamicWeb database is handled with integration activities.

Cloud architecture

CloudArchitecture

An integration with a cloud hosted ERP is established by communicating with web services of the following types:

SOAP web services such as those exposed by a DynamicWeb plug-in unit installed directly on the ERP through the Microsoft AppSource marketplace.
OData web services that expose data through RESTful API's or single OData v4 pages.

The recommended way to reach both plug-in unit and OData endpoints in DynamicWeb is to use endpoint collections.

The main difference compared to an on-prem integration is how access to the web services is authorized. As of October 2022 The capability to access web services in Dynamics 365 ERP systems using basic authentication is deprecated for SaaS, which means that access to the remote system must be authorized with the use of OAuth 2.0. This is the case for both OData - and plug-in unit exposed web services.

On-prem architecture

OnPremArchitecture

A data integration between DynamicWeb and an on-prem ERP system is established by communicating with a web service that exposes data from the ERP database. There are three main components to an on prem data integration:

A web service exposed by a DynamicWeb plug-in unit installed directly on the ERP
The DynamicwebConnectorService which handles authorization and exposes the endpoint beyond the firewall
A scheduled task triggers an integration activity that maps the ERP data to the DynamicWeb database
In addition, a live integration may render the ERP data directly in the frontend

Features

As depicted above, the DynamicWeb integration framework supports working with two different types of web services of a remote system: Plug-in unit based SOAP endpoints or OData REST endpoints. On the DynamicWeb side, the architecture varies somewhat depending on the type of integration.

OData integration

By utilizing the OData provider of DynamicWeb you can import virtually any data exposed through the OData protocol in your ERP or CRM system.

An OData API integration lets you fully customize data mappings between DynamicWeb and an external system. If the required data is not exposed through the standard ERP OData API, DynamicWeb also supports OData integration through pages exposed as custom OData V4 endpoints.

As opposed to a plug-in unit integration, an OData integration is not file based, which means that it does not require a scheduled task to store a file with the response from the endpoint. Instead, an OData integration utilizes the endpoint provider to read the metadata of an OData endpoint from which the mappings to the database can be configured.

Plug-in unit integration

DynamicWeb provides a series of standard plug-in units meant to be installed directly on a remote system in order to transform and expose data. The standard collection contains plug-in units for the following ERP systems:

Dynamics 365 Finance & Operations
Dynamics AX 2012
Dynamics NAV 2013/2015/2016/2017/2018
Dynamics 365 Business Central

A DynamicWeb plug-in unit always exposes data as XML, which is both requested and saved as a file by a scheduled task. The scheduled task will then trigger a data integration activity that inserts the data from the XML file to the database.

The flow of a plug-in unit integration thus looks like this in its essence: