1. Data Management
  2. Connectivity Studio

Flows

Flow Description

Analyze projects

 		You can use these tools to analyze a project:
  • Compare: You can compare a project for reviewing purposes. You can compare a:
    • Project with another project.
    • Project version with another version of the same project.
    • Project with a project that is exported to a file.
    • Project with a project that is available as a resource.
  • Create Microsoft Word document: A summary of the project setup and related components setup is added to the document. You can use the document to review the setup.

Compare content packages

Use the Environment comparison studio to get the most relevant data from different environments or companies. In the Environment comparison studio, you compare the desired data using content packages. The comparison results show all the differences between two content packages. 

When you create a comparison, it is saved. You can also save intermediate results of the comparison. You can view the comparisons on the Compare history page. 

When you process your comparison results, for each table, a separate XML file is created. In the XML files, you can change the values that you want to synchronize manually. 

Create content package

In the Environment comparison studio, you can compare data files using content packages.

You can compare the data of:

  • The same company in different environments
  • Different companies in the same environment.
  • Different companies in different environments.

A content package must contain all data for one side of the environment comparison. It can also contain data from several XML files and tables. Use a content package as a stable point of reference for the tables you want to compare.

Define data migration project

Use a project as the basis for each data migration. Most connectivity elements are linked to a project, for example, documents, connectors, and tasks. Because these elements are related to a project, use a project to deploy a data migration.

For each data migration project, at least define the:
  • Applications that are used in the project.
  • Default connectors.
  • Data migration statuses.
  • Data migration areas.

Define field options

For each field mapping, you can set additional field options. Each field option has specific properties. If you select a field option, also fill in the related properties.

Define project

 		Use a project as the basis for each integration. Most connectivity elements are linked to a project, for example, documents, connectors, and tasks. Because these elements are related to a project, you can also use a project to deploy connectivity setup and do version management.
For each project, you can also define the:
  • Subprojects that are run if you run the project.
  • Applications that are used in the project.
  • Default connectors.
  • Web service applications.

Define transformation

You can use a transformation to change a source value into another value.

Define type conversion

You can use a type conversion to convert the data to match the format as required in the target. With a type conversion, you can convert values from any type to string or from string to any type. Usually, the string value is the external value. Note: Type conversions from any type to any type are not supported. For example, a conversion of type integer to type date is not possible.

You can use these conversion types:

Conversion type Description
Text Define the format in which a text is imported or exported. You can, for example, replace or remove characters, or use one element of the text.
Amount Define the format in which an amount is imported or exported. You can, for example, define separators and unit conversion.
Date Define the format in which a date is imported or exported. You can, for example, define the sequence and separator.
Enum Define the format in which an enum value is imported or exported. You can, for example, define that the enum value is imported or exported as text.
Time Define the format in which times are imported or exported. You can define the format and the separators to be used.
UtcDateTime Define in which format a date and time field value is imported or exported. This type combines the Date and Time types.
Date/time format Define in a flexible way the format in which a date and time field value is imported or exported. You can also include a time zone. Note: The format is case sensitive. For example, the lowercase 'm' is the identifier for minute, and the uppercase 'M' is the identifier for month. Example: dd-MM-yyyy. For more information on how to set up the date/time format, refer to Custom date and time format settings.

 

 

Design data migration

To design a data migration from AX2012 to D365 FO, you can use the ODBC mapping generator. Using a Database connector with an ODBC connection to the AX2012 database, you can easily map the desired AX2012 tables to the related D365 FO tables.

Inbound web service process

 		The inbound web service process is used to receive a request from and send a response to an external application, via an inbound web service.
The inbound web service can be an IIS application or Azure Logic Apps. This inbound web service receives the HTTP requests from the external application.
Depending on the execution mode, the inbound web service process runs directly or asynchronously. When triggered, the inbound web service action runs the defined messages.
This flow shows a general overview of the inbound web service process when run directly (Run asynchronous = 'No').
When the web service action is triggered, the request message is run. Depending on the result and setup, also a response message or error message is run.

Inbound web service process - Asynchronous

The inbound web service process is used to receive a request from and send a response to an external application, via an inbound web service.

The inbound web service can be an IIS application or Azure Logic Apps. This inbound web service receives the HTTP requests from the external application.
Depending on the execution mode, the inbound web service process runs directly or asynchronously. When triggered, the inbound web service action runs the defined messages.
This flow shows a general overview of the asynchronous inbound web service process.
How an asynchronous inbound web service is processed, depends on the execution mode. These asynchronous execution modes are supported:
  • Asynchronous: When the web service action is triggered, directly a default response text is sent back to the inbound web service. Also, the request message is run. Several request messages can run in parallel. Usually, no response message and error message are defined.
  • Batch: When the web service action is triggered, directly a default response text is sent back to the inbound web service. The data, as received by the web service request, is stored in the Inbound web service staging table. These staging table records are processed in batch. The batch job runs the request message as defined for the applicable web service action. Usually, no response message and error message are defined.

Manage Connectivity studio parameters when copying database

In some cases, it can be required that you copy a database to another environment. For example, you have a test environment and a production environment. An issue occurs in the production environment. So, testing is required to find the cause of the issue. However, you do not want to mess up the production environment with testing data. You can copy the full production database to the test environment.

If you copy a database to another environment, the Connectivity studio parameters are overwritten with the parameter settings of the copied database. However, usually, you want to keep the original and unique parameter settings for an environment.
You have two options to make sure the Connectivity studio parameters are unique for the environment:
  • Before copying the database to an environment, export the Connectivity studio parameters from that environment. And after copying the database, import the parameters back to the environment.
  • After copying the database to an environment, delete the Connectivity studio parameters and set the parameters again. A disadvantage of this approach is that a new environment ID is generated. With a new environment ID, it is difficult to get back checked-out projects because these are checked out by another environment ID.
Prerequisites:
Before you copy a database:
  • From an environment, for example the production environment, make sure that all version-managed projects are checked in or get latest is done.
  • To an environment, for example the test environment, make sure that:
    • All version-managed projects are checked in.
    • The non-version-managed projects that you want to keep are exported. After copying the database, you can import these projects back into the environment.

Manage document record field setup - Internal documents

 		You have several options to manage the document record field setup for internal documents.
You can:
  • Change the sequence of the fields.
  • View where a field is used.
  • Clean up unused fields.
  • Create a related record.

Manage document record setup - EDI documents
You have several options to manage the document record setup for EDI documents.
You can:
  • Change the sequence of the records.
  • View where a record is used.
  • Define a range if you use qualifiers.
  • Validate the record setup.

Manage document record setup - External documents

 		You have several options to manage the document record setup for external file-based documents.
You can:
  • Change the sequence of the records.
  • View where a record is used.
  • Validate the record setup.

Manage document record setup - Internal documents

 		You have several options to manage the document record setup for internal documents.
You can:
  • Change the sequence of the records.
  • View the D365 FO table relations.
  • View where a record is used.
  • Check or change the table relations.
  • Define the data querying order.
  • Define the range of data to be queried.
  • Validate the record setup.

Manage document record setup - ODBC documents

 		You have several options to manage the document record setup for ODBC documents.
You can:
  • Change the sequence of the records.
  • View where a record is used.
  • Check or change the table relations.
  • Define the data querying order.
  • Define the range of data to be queried.
  • Validate the record setup.

Manage project versions

With project version management, you can manage changes on your Connectivity studio projects and all related components. This includes all project details and components, like messages, web service actions, documents, connectors, type conversion, or transformations. Changes to project details and related components are stored by project version. Each project version is stored as a file in the file storage folder as defined in the Connectivity studio parameters.

You can use project version management to synchronize projects between several D365 FO environments. For version management, to work properly, the file storage folder, as defined in the Connectivity studio parameters, must be the same for all environments between which project versions must be synchronized. So, the version files are stored centrally and can be accessed by all applicable environments.
In Connectivity studio, if version management is active, you:
  • Manage versions on project level only, including all project components and settings.
  • Must check out a project to make changes to the project or its components.
  • Must check in a project to make changes generally available for other environments.
  • Can restore a project version or get the latest project version.
This picture shows an example of a typical environment setup. For each environment, project version management is active, using the same Azure Storage Account and folder to store project version files. In this case, the project is checked out on the Development environment, changes are made, and the project is checked in. Because the changes are required in the Acceptance environment, Get latest is done here.
You can use project version management, for example, for these scenarios:
  • Project changes: A change to a project component in an environment can be easily applied to other environments.
  • Issue resolution: During testing, you can find and solve an issue in a project component in one environment. The solution to the issue can be easily applied to other environments.
  • Updates in the test environment: In a test environment, project components are often changed. Using project versions, you make sure that changes are saved, and you can always restore a previous project version.

Manage project versions - Advanced

 		Project version management offers several advanced options. For example, to solve issues related to project versions.

Message process

This flow shows a typical example of a message process.

Example

Import customers from a webshop to D365 FO. In this case, the webshop is the source and D365 FO the target.


For both the source (webshop) and the target (D365 FO) a connector and a document are required. Also, a message is required to map the source and target data.

Monitor and troubleshoot Service Bus dead letter data

 		If you use Azure Service Bus queues or topics to export data, you can monitor and troubleshoot the Service Bus dead letter data information on several specific pages.

Monitor and troubleshoot Service Bus import

If you use Azure Service Bus queues or topics to import data, you can monitor and troubleshoot the data import information on several specific pages.

Monitor data synchronization log

For messages and web service actions, you can use table events to track data changes. You can define, for each table, which table events are logged. The table events are logged in the Data synchronization log.
This topic explains how to monitor the data synchronization log.

If table events are not logged in the Data synchronization log as expected, you can check the data synchronization setup for your message or outbound web service action.

If logged events in the data synchronization log are not processed to the outbound queue, you can:

  • Check if processing the data synchronization log is set up correctly.
  • Test the data synchronization log processing.

If processing the data synchronization log does not run at all, the batch server can be down.

Monitor file history
You can review and analyze the file history of message runs for messages with an Azure file storage connector. All actions that are done to the related file, are registered in the file history.
Registered file actions are the:
  • Standard file actions related to the Working, Archive, Error, and Split folders. For example, on import, a file is read from the Working folder and when successfully processed, it is moved to the Archive folder. Both the 'read' and the 'move' action are registered.
  • Additional file actions as set up for the Azure file storage connector.
You can monitor the file history from the Connectivity studio Integration operations workspace.

Monitor inbound web service history

Depending on how you run an inbound web service integration, you can monitor the integration on these levels:

  • Web service action
  • Message
  • File
  • Inbound web service staging table (only applicable if the asynchronous mode of the web service action is 'Batch')
To monitor an inbound web service integration, use the Connectivity studio Integration operations workspace.

Monitor message history

You can review and analyze the history of message runs that have run with errors. You can investigate these errors and take the appropriate actions to solve the errors. If the errors are solved, you can re-run the message run.

To monitor the message history, use the Connectivity studio integration operations workspace.

 

Monitor outbound queue

For messages and web service actions, you can use table events to track data changes. You can define, for each table, which table events are logged. The table events are logged in the data synchronization log. On processing the data synchronization log, based on the logged events, records are added to the outbound queue. On processing the outbound queue, for each record, the related message or web service action is run to export the applicable data.

When the outbound queue is processed, errors can occur. You can reset the outbound queue record status to New. For example, when running a web service action, the external web service can be down. As a consequence, running the related outbound queue records fails and these get the status Error. When the issue is solved, you can reset the status to New, And the next time the outbound queue is processed, these records are processed again.
This flow explains how to:
  • View the outbound queue.
  • Reset the outbound queue to rerun outbound queue records. Usually, you do so in case of any issue.
To monitor the outbound queue, use the Connectivity studio Integration operations workspace.
If the outbound queue does not run at all, the batch server can be down.

Monitor Service Bus data

 		If you use Azure Service Bus queues or topics to exchange data, you can monitor the data exchange information on several specific pages.

Monitor staging journal

 		In Connectivity studio, you can use the staging concept to validate data in an intermediate area before it is further processed. This is usually used to import data into D365 FO from another system. In this way, you can validate the data before it is written into the D365 FO database.

Use the staging journal to monitor the data validation.
One predefined generic staging journal table is available for Connectivity studio: 'BisStagingBufferOrderJournal'. Usually, you only use this generic table if you have a limited number of simple integrations. So, integrations that integrate one smaller table.
If you want to use staging for integrations with multiple tables or bigger tables, you are advised to develop a customized staging journal table instead of using the generic staging journal table.
This flow explains how to monitor staging journals using the generic staging journal table. You can monitoring a customized staging journal table in a similar way.

If the validations are not met, errors or warnings are reported in the staging journal. Usually, issues as shown in the staging journal are data related.

If it appears that issues are not data related, extend your issue investigation to the messages that import data to or export data from the the staging journal.

Outbound web service process

The outbound web service process is used to request data from an external application and to process the response in D365 FO, via an external web service.

Only D365 FO can trigger an outbound web service action. When triggered, the outbound web service action automatically runs the defined messages.
This flow shows a general overview of the outbound web service process that is started when an outbound web service action is triggered.

Process data synchronization log process

 		When you process the data synchronization log, automatically several actions are done, and several decisions are made based on the applicable setup. This flow shows the automatically executed actions and decisions when the data synchronization log is processed.

Release project

 		You can release a project and export it as a data file to import and publish it in another environment.

Run integration

You can run an integration on these levels:

  • Project: All related tasks are run. And for each task, all related messages are run.
  • Task: All related messages are run.
  • Message: Only used if an individual message must be run.
  • Data synchronization: The data synchronization setup of the message defines which records are processed.

Run message from a button

You can use button on a form to run a message. You can add a button to a form in these ways:

  • Dynamic button
    Use a dynamic button to manually start a message from a form. To add a dynamic button, no coding is required.
  • Action menu item
    Use a custom action menu item to manually start a message from a form. To add an action menu item, custom coding is required.

Run outbound web service

An outbound web service action can only be triggered by D365 FO. When triggered, the outbound web service action automatically runs the defined messages.

You can run an outbound web service action on these levels:

  • Project: All related tasks are run. And for each task, all related web service actions are run.
  • Task: All related web service actions are run.
  • Web service action: Only used if an individual web service action must be run.
  • Data synchronization: The data synchronization setup of the web service action defines which records are processed.

Run web service action from a button

You can use button on a form to run an outbound web service action. You can add a button to a form in these ways:

  • Dynamic button
    Use a dynamic button to manually start an outbound web service action from a form.
  • Action menu item
    Use a custom action menu item to manually start an outbound web service action from a form. For the action menu item, custom coding is required.

Set Connectivity studio parameters

Before you start using Connectivity studio, set up the Connectivity studio parameters.

Set up Azure file storage connector

Set up a connector of type Azure file storage. Use this type to exchange data files between your D365 FO environment (on-cloud or on-premises) and another environment, for example an on-premises environment.

With the Azure file storage type connector, you can exchange these external file-based documents: EDI, Fixed text, Microsoft Word, Microsoft Excel, Text, XML, JSON.

You can exchange data files using:

  • Azure File Storage: You can use an Azure Storage Account to exchange data files between your D365 FO environment (on-cloud or on-premises) and another environment, for example an on-premises environment.
  • Local folders: If you use Connectivity studio on a D365 FO (on-premises) environment, you can choose to use local Windows folders to exchange data files.

Set up Azure Service Bus for Database connection
You can connect D365 FO to an external on-premises database. If you connect to an external on-premises database, you must connect through firewalls. With Connectivity studio, you can connect to an external on-premises database using an Azure Service Bus.
To establish a connection between an external on-premises database and D365 FO with Connectivity studio, these elements must be in place:
  1. Azure Service Bus namespace.
  2. BIS Azure Service Bus client installed on the external on-premises server.
  3. Data Source Name (DSN) on external on-premises server.
  4. Database connector and ODBC document in Connectivity studio on D365 FO.

This picture gives an architectural overview of the Azure Service Bus solution in Connectivity studio with the required elements. (Note: The numbers in the picture correspond with the before-mentioned element numbers.):

Prerequisites to establish this connection:
  • Azure subscription.
  • D365 FO with Connectivity studio installed.
  • External on-premises server and database.

Set up Azure Storage for Azure file storage connector

 		You can use an Azure Storage Account to exchange data files between your D365 FO environment (on-cloud or on-premises) and another environment, for example an on-premises environment.

Set up Azure Storage for general files

 		You can use an Azure Storage Account to exchange data files between your D365 FO environment (on-cloud or on-premises) and another environment, for example an on-premises environment.

Set up Blob storage connector

Set up a connector of type Blob storage to exchange data files between your D365 FO environment and another environment, using Azure Blob storage. Azure Blob storage is Microsoft's object storage solution for the cloud. Blob storage is optimized for storing massive amounts of unstructured data.

With the Blob storage type connector, you can exchange these external file-based documents: EDI, Fixed text, Microsoft Word, Microsoft Excel, Text, XML, JSON.

Set up business event for message

You can set up a business event that is triggered by a message.

Business events provide a mechanism that lets external systems receive notifications from D365 FO. In this way, the external systems can perform business actions in response to the business events.
For more information on business events, refer to Business events overview .
Note:
  • Only use business events to send small sets of data. So, do not use business events to export data.
  • You can export a project to move the Connectivity configuration to another environment, for example, from a Test to a Production environment. The message business events are included in the export. So, after import in the new environment, you do not need to create the message business events again. However, you must redo the other activities of this flow due to the environment change.

Set up D365 FO document

 		Use a D365 FO document to read data from or write data to D365 FO.

Set up data synchronization for message

On export of data, the data synchronization setup defines which records are processed.
Data synchronization only applies to messages with an internal document as source document.
You can use these types of data synchronization:

Type Description
All This is the standard data synchronization. All records that are found, based on the source document setup, are exported. No data synchronization setup is required for this.
Table events You can use table events to log data changes. You can define, for each record, which table events are logged. The table events are logged in the Data synchronization log. From here, the logged entries must be processed further to the Outbound message queue. Process the outbound message queue to run the messages to export the records.
Date range You can use a date range to export only the records that are changed or added since the latest message run.

Set up data synchronization for outbound web service action

On export of data with an outbound web service action, the data synchronization setup defines which records are processed.
Data synchronization only applies to the request message of the outbound web service action.

Note: The request message also can have data synchronization set up. This setup is overruled by the outbound web service data synchronization setup.

You can use these types of data synchronization:

Type Description
All This is the standard data synchronization. All records that are found, based on the source document setup, are exported. No data synchronization setup is required for this.
Table events You can use table events to log data changes. You can define, for each record, which table events are logged. The table events are logged in the Data synchronization log. From here, the logged entries must be processed further to the Outbound message queue. Process the outbound message queue to run the messages to export the records.
Date range You can use a date range to export only the records that are changed or added since the latest outbound web service action run.

Set up Database connector

Set up a connector of type Database. Use this type to directly connect to an external database. This external database can be an on-premises database or a cloud database.
If you want to connect to an external database via ODBC and you run D365 FO:

  • In the cloud, use an Azure Service Bus to connect to the external database.
  • On-premises, you can connect to the external database without an Azure Service Bus. 
  • On-premises, you can also connect without an Azure Service Bus and additionally use Direct SQL to export data to the external database.

You can also directly connect to an Azure SQL database.

 

Set up EDI document

 		Use an EDI document to read data from or write data to a file if you use EDIFACT or ANSI X12 for your EDI. The data in the file is structured in line with these standards.
You can use an EDI type to indicate which EDI standard is used for the EDI document. For example, EDIFACT or ANSI X12.
For each EDI type, you can set up qualifiers for an EDI segment.

Set up EDI type and qualifiers

You can use an EDI type to indicate which EDI standard is used. For example, EDIFACT or ANSI X12. This is used for informational purposes only.

For each EDI type, you can set up qualifiers for an EDI segment.

Set up Environment comparison studio

Define the basic settings for the Environment Comparison Studio.

Set up external documents - File based
 

Use an external file-based document to define the data model of the external source or target with which you want to exchange data.

The available file-based external document types are:
Document type Description
XML Use an XML document to exchange data in XML format without the need to code. With a document of type XML, you can read data from or write data to an XML file.
JSON Use a JSON document to exchange data with an application that uses data-object notation. With a document of type JSON, you can read data from or write data to a JSON file.
Text Use a Text document to read data from or write data to a file with field and line separators. For example, a CSV file.
Fixed text Use a Fixed text document to read data from or write data to a file with defined start positions and lengths for fields.
EDI Use an EDI document to read data from or write data to a file if you use EDIFACT or ANSI X12 for your EDI.
Microsoft Excel Use a Microsoft Excel document to read data from or write data to a Microsoft Excel file (XLSX).
Microsoft Word Use a Microsoft Word document to write data to Microsoft Word document (DOCX) using a template.

Set up external documents - ODBC

Use an ODBC document to define the data model of the external source or target with which you want to exchange data. You can exchange data with an external database via ODBC or with an external Azure SQL database.

Set up field mapping

The message is the carrier for all the information that is needed for the integration. On the field mapping you define which target document record fields are mapped to which source document record fields. The resulting field mapping is used to get the right data from the source and get it in the right format to the right place in the target.

 

Set up field mapping - Advanced
For each field mapping, you can define several advanced settings. You can set up:
  • Conditions
  • Type conversions
  • Transformations
  • Options
  • Company-specific field mapping
Note: A field mapping without any advanced settings gives a better performance. So, the more advanced settings, the more time it takes to execute the field mapping.

Set up file action - Email

 		You can use the Email file action to exchange files with email.
If the direction is:
  • Source, before the message is run, the defined email account inbox is searched for applicable emails. If found, the attached files of these emails are saved to the Working folder.
  • Target, after the message is run, an email is created using the defined email account, the created file in the Working folder is attached to the email, and the email is sent. The original file stays in the Working folder. If you want to zip the file before sending it by email, do a Zip file action previously to the Email file action. In this case the zipped file is attached to the email.
These email options are available:
  • Exchange server: To send or receive files using a Microsoft Exchange server.
  • IMAP server: To receive files using an IMAP server.
  • SMTP server: To send files using an SMTP server.
  • D365FO email: To send files using the email setup as defined in D365FO.

Set up file actions for Azure file storage connector

With a Azure file storage connector, you exchange files between your D365 FO environment and another environment via an Azure file share or a local folder. If the other environment has no access to the Azure file share or local folder, you can use file actions to transfer the files to a location where the other environment can access the files.

Each file action has one direction. The file action direction defines when the action is applicable. If the direction is:
  • Source, the file action is done:
    • Only if the connector is used as source connector on a message.
    • Before the message is run.
  • Target, the file action is done
    • Only if the connector is used as target connector on a message.
    • After the message is run.
The file actions are done in the sequence as shown in the grid. To put the file actions in the correct sequence, use Move up and Move down.

Set up Fixed text document

Use a Fixed text document to read data from or write data to a file with defined start positions and lengths for fields.

Set up inbound web service - Azure App Service

 		If you want to run the inbound web service application in the cloud, use an Azure App Service.

Set up inbound web service - Azure Logic Apps

 		Instead of an Azure App service, you can use other applications to run an inbound web service in the cloud. An often-used alternative is an Azure Logic App.
This topic explains globally how to set up the web service using Azure Logic App. For more information on Azure Logic Apps, refer to Azure Logic Apps documentation.

Set up inbound web service - IIS application
If you want to run the inbound web service application on premise, use the predefined IIS application.
You can use the IIS application to route external HTTP requests to the applicable inbound web service actions in D365 FO.
Prerequisites:
Before you set up the IIS application, make sure:
  • The on-premises server has Internet Information Services installed and .NET 4.6 (or higher).
  • A D365 FO environment with Connectivity studio installed runs in the cloud or on premises.

Set up inbound web services

 		You can use the inbound web service process to receive a request from and send a response to an external application, via an inbound web service. To manage the inbound web service process, set up an inbound web service action.

Set up internal documents

Use an internal document to define the data model of the internal D365 FO source to read data from or D365 FO target to write data to.

The available internal document types are:
Document type Description
D365 FO Use a D365 FO document to read data from or write data to D365 FO.
Journals Use the journal documents to write journal data to D365 FO.
Staging Use a Staging document to read data from or write data to the staging table.

Set up journal documents

 		Use the journal documents to write journal data to D365 FO journals.

Set up JSON document

Use a JSON document to exchange data with an application that uses data-object notation. 

With a document of type JSON, you can read data from or write data to a JSON file.

Set up message

 		Use messages as the carriers that transport data from a source to a target, based on the mapping as defined on the message.
On a message you define:
  • The source information: the connector and document that is used for the data source.
  • The target information: the connector and document that is used for the data target.
  • The record mapping and field mapping that define which data goes where in which format.
This flow explains how to set up the message header.

Set up messages

Use messages as the carriers that transport data from a source to a target, based on the mapping as defined on the message.
On a message you define:
  • The source information: the connector and document that is used for the data source.
  • The target information: the connector and document that is used for the data target.
  • The record mapping and field mapping that define which data goes where in which format.

Set up Microsoft Excel document

Use a Microsoft Excel document to read data from or write data to a Microsoft Excel file (XLSX).

Set up Microsoft Word document
In Connectivity studio, use a Microsoft Word document to write data to a Microsoft Word document (DOCX) using a Microsoft Word template (DOTX).
With a Microsoft Word document, you can, for example, add data to text, include contract text, support multi-language output, or include product attributes or specifications. In this way, you can, for example, generate invoices or contracts with the style texts as defined in the template.

Set up ODBC document
Use an ODBC document to define the data model of the external source or target with which you want to exchange data. You can exchange data with an external database via ODBC or with an external Azure SQL database.

Set up outbound web service - Azure Logic Apps

 		Instead of an external web service managed by an external application, you can use other applications as outbound web service in the cloud. An alternative application is an Azure Logic App.
This topic explains globally how to set up the web service using Azure Logic App. For more information on Azure Logic Apps, refer to Azure Logic Apps documentation.

Set up outbound web services
You can use the outbound web service process to request data from an external application and to process the response in D365 FO, via an external web service. To manage the outbound web service process, set up an outbound web service action.

Set up record mapping

 		The message is the carrier for all the information that is needed for the integration. On the message record mapping, you define for each target document record the mapped source document record.

Set up secret references

You can create secret references to store secrets at a central place in Connectivity studio. Wherever you need a secret in Connectivity studio, you can use a secret reference.

Benefits of using secret references are:

  • One place to maintain secrets. For example, you can use a secret in several connectors. If the secret expires, you only update the secret reference instead of updating the secret separately for each applicable connector.
  • When you use a secret reference, the secret is not shown or visible where the secret is applied. The secret is also not visible when you export or import project configurations.

You can use secret references for:

  • Azure storage setup (Connectivity studio parameters)
  • Database connector
  • Azure file storage connector
  • File actions (Azure file storage connector)
  • Blob storage connector
  • SharePoint connector
  • Service Bus queue connector
  • Web service application (Project)
  • Web service action attributes

Note: You can only use secret references if the the Display secret field of the Connectivity studio parameters is set to 'Secret reference' or 'Both'.

Set up Service Bus queue connector

Set up a connector of type 'Service Bus queue' to exchange information via an Azure Service bus queue or topic.

The 'Service Bus queue' connector supports these Service Bus entities:

  • Queue: Queues provide First In, First Out (FIFO) message delivery to one or more competing consumers. That is, receivers typically receive and process messages in the order in which they were added to the queue. And only one message consumer receives and processes each message.
  • Topic and subscriptions: Topics and subscriptions provide a one-to-many form of communication in a publish and subscribe pattern. It's useful for scaling to large numbers of recipients. Each published message is made available to each subscription registered with the topic. Publisher sends a message to a topic and one or more subscribers receive a copy of the message, depending on filter rules set on these subscriptions.
For more information, refer to Service Bus queues, topics, and subscriptions.

Set up SharePoint connector

Set up a connector of type SharePoint to exchange data files between your D365 FO environment and another environment, using SharePoint. SharePoint is a solution to share and manage content, knowledge, and applications to empower teamwork, quickly find information, and seamlessly collaborate across the organization.

With the SharePoint type connector, you can exchange these external file-based documents: EDI, Fixed text, Microsoft Word, Microsoft Excel, Text, XML, JSON.

Set up Staging document

 		Use a Staging document to read data from or write data to the staging table.

Set up tasks

 		You can use tasks to set up the execution of:
  • An integration or data migration. In this case, define the messages to be run by the task.
  • Outbound web services. In this case, define the outbound web service actions to be run by the task.
  • Batch classes. In this case, define the batch classes to be run by the task.
  • Master data management. In this case, define the master data entities to be run by the task.
  • Test cases. In this case, define messages with test cases for the task.
You can use task dependencies to run tasks sequentially or in parallel. If you run tasks in parallel, the performance increases.
You can run tasks:
  • By running a single task. Usually, you only do so for testing purposes.
  • By running the related project. All tasks of the project are run.

Set up Text document

 		Use a Text document to read data from or write data to a file with field and line separators. For example, a CSV file.

Set up XML document

Use an XML document to exchange data in XML format without the need to code.

With a document of type XML, you can read data from or write data to an XML file.

Troubleshooting connectors

When a message does not run successfully, you can troubleshoot the related source connector and target connector.

You have several options to troubleshoot a connector. You can, for example:
  • Validate the connector setup.
  • Solve a connection issue for an Azure file storage connector.
Common issues on the connector are:
  • Connection issue to folder for Azure file storage connector:
    • Test the connection. To do so, on the Connectors page, in the Action Pane, on the Development tab, click Test connection.
    • Verify the connector properties: Share, User name, Password.
    • Verify the folder setup, like Work and Archive. Do these folders exist in the file system? Are these folders defined correctly on the connector? You can use the File explorer to quickly access and view the share as defined for the Azure file storage connector. To open the File explorer, on the Connectors page, in the Action Pane, on the Development tab, click File explorer.
  • Connection issue on Database connector:
    • Test the connection. To do so, on the Connectors page, in the Action Pane, on the Development tab, click Test connection.
    • Verify the Azure Service Bus settings on the connector, in case of an ODBC connection.
    • Verify the ODBC data source settings on the connector, in case of an ODBC connection.
    • If applicable, verify the direct SQL settings on the connector. 

Troubleshooting documents

 		When a message does not run successfully, you can troubleshoot the related source document and target document.
When a document is used in a message run, based on the document setup, a query is created that reads the data.
You have several options to troubleshoot a document. You can, for example:
  • Validate the document setup.
  • Test a document.
Common issues on the document are:
  • No files are read from the Work folder: Check the read settings on the document header.
  • Missing data in export: Verify the setting of these fields on the record setup: 'Join mode' and 'Combine with parent record'. For more information, refer to this blog.
  • No records are processed: Verify the range as set up for document records.

Troubleshooting messages
When a message doesn't run successfully, you can troubleshoot the message.
You have several options to troubleshoot a message. You can, for example:
  • Validate the message setup.
  • Run a message for testing and troubleshooting purposes.
  • Analyze the message history.
  • Analyze the file history, if the message has an Azure file storage connector with file actions.
  • Analyze the tracer, if you have used the tracer on the message run.
Common issues on the message are:
  • Field mapping sequence: Make sure the fields are mapped in the same sequence as shown on the related form in D365 FO.
  • Mapping conditions and field conditions: Conditions limit the records that are processed. So, if records are skipped unexpectedly, check if conditions are defined.
  • Key field setup: Key fields are used to find and update records. If records are not updated unexpectedly, verify if the correct fields are marked as key fields.

Troubleshooting web services

When a web service action doesn't run successfully, you can troubleshoot the web service action.

You have several options to troubleshoot a web service action. You can, for example:

  • Validate the web service action setup.
  • Test an outbound web service action.
  • Test an inbound web service action.

Use Environment comparison studio

Use the Environment comparison studio to get the most relevant data from different environments or companies. In the Environment comparison studio, you compare the desired data using content packages.

Use form mapping

For a message, you can generate the record mapping and field mapping based on an external document and a recording of the applicable forms and fields in D365 FO.

The form mapping recording also records the data structure of the mapped D365 FO fields.
You can use this, for example, as a starting point for the message record mapping and field mapping.
 

Validate connectivity setup

If you open a form or save (changes to) the setup of a key element in Connectivity studio, the setup is validated automatically. If errors are found in the setup, an error icon   is shown. You can click the icon to show the related error messages.

You can also manually start an automated test to check for errors in the setup. As a result, the found errors are shown. Also, the error icons are shown where applicable.
When errors are found, you can try to fix these errors automatically.
You can check and auto-fix errors for these key elements in Connectivity studio:
Key element Check
Projects When automatically checked, only the project setup is checked, and not the related setup like messages and connectors. When started manually, the full project setup is checked.
Documents The document setup is checked, including the document records setup.
Document records Only the document records setup is checked.
Messages The message setup is checked, including the data synchronization setup and message mapping.
Message - Data synchronization setup Only the data synchronization setup is checked.
Message mapping Only the message mapping is checked.
Message business events A check is done if a business event is created for the message business event. Also, a check is done if the target fields and source fields match with the related document setup.
Connectors Only the connector setup is checked.
Web services The web service setup is checked, including the data synchronization setup.
Web service - Data synchronization setup Only the data synchronization setup is checked.

In this flow, in the activity steps, as an example, the validation is done for documents.

Provide feedback