Architecture

The Dynamicweb Integration Framework is pull based. No data is read or persisted unless Dynamicweb is asked to do it.

Fundamentally any integration action follows this flow.

1. A request is sent from Dynamicweb to a web service.
2. The web service handles the request and sends a response.
3. Dynamicweb reads or persists the response.

Both request and response body can contain data that is meant to be persisted. The most common scenario is this: The response body is meant to be persisted in the Dynamicweb database.

In some cases, a response body may be a close match to the table schema in Dynamicweb, but this is not always the case, which is why persisting data requires knowledge about the table structure and relations in Dynamicweb’s database. How data is mapped between a remote system (typically an ERP or CRM system) and the Dynamicweb database is handled with integration activities. 

Connectivity affordances means that there are some fundamental differences between integrating with a Cloud hosted or an On-premises remote system. Please refer to the illustrations and descriptions in the following sections to read more about one or the other.

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 batch integration that uses an integration activity to map the ERP data to the Dynamicweb database or a live integration that renders the ERP data directly in the frontend

Figure 2.1 The architecture of an integration between Dynamicweb and an on premise ERP system.

Similarly to an integration with an on-prem ERP an integration with a cloud hosted ERP is established by communicating with web services of the following types:

• A web service 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 pages such as OData V4 object types.

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 Web Service Access Key (Basic Auth) 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.

The recommended way to reach both plug-in unit and OData endpoints in Dynamicweb is to use the Endpoint management tool.

Figure 3.1 The architecture of an integration between Dynamicweb and a cloud hosted ERP system.

On the Dynamicweb side, the architecture also varies somewhat depending on the type of integration. A Dynamicweb plug-in unit always exposes data as XML, which is both requested and saved as a file by the Batch integration. The Batch integration 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 it's essence:

1. A request is sent from a batch integration to a web service authorized by OAuth 2.0
2. The plug-in unit handles the request and sends a response in XML
3. The batch integration reads the response and saves it to an XML file
4. A data integration activity reads the content of the XML file and stores the data in the Dynanicweb database in accordance to the mappings defined in the activity

An OData integration, on the other hand, is not file based, which means that it does not require a batch integration 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.

The Dynamicweb plug-in units have these standard features:

For examples of standard requests & responses see the Requests & Responses article (NAV/BC responses or AX/F&O responses)

Further functionality can be obtained by extending the codeunit or by supplementing a plug-in unit integration with OData integration activities.

By utilizing the Endpoint - and 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.

Besides the fully customizable OData API approach, an integration with Business Central can also be established with the preconfigured OData v4 endpoints.

By using OData v4 Business Central endpoints specifically designed for Dynamicweb, you can expose custom Business Central fields and take advantage of an extensive list of preconfigured data mappings. 

These OData v4 object types are supported by the endpoint - and OData provider: