Activities

To each document record, add the data fields which values must be exchanged. For external file-based documents, set up the fields in line with naming in the file.

For JSON documents, fields are always of type string, to enable type conversions.

This topic explains how to add record fields to a JSON document.

If fields are already initialized for the document, selected for the record, or copied to the record, you can review and complete the setup for these fields. To do so, skip step 6.

To each document record, add the data fields which values must be exchanged. For external file-based documents, set up the fields in line with naming in the file.

For XML documents, fields are always of type string, to enable type conversions.

This topic explains how to add record fields to an XML document.

If fields are already initialized for the document, selected for the record, or copied to the record, you can review and complete the setup for these fields. To do so, skip step 6.

To each document, add the data records to be exchanged. For external file-based documents, set up the records in line with how the data is structured and named in the file.

This topic explains how to add records to an EDI document.

To each document, add the data records to be exchanged. For external file-based documents, set up the records in line with how the data is structured and named in the file.

This topic explains how to add records to a Fixed text document.

To each document, add the data records to be exchanged. For internal documents, set up the records in line with how the data is structured and named in D365 FO.

This topic explains how to add records to documents of these types: D365 FO, Journal, or Staging.

To each document, add the data records to be exchanged. For external file-based documents, set up the records in line with how the data is structured and named in the file.

This topic explains how to add records to a JSON document.

If records are already initialized for the document, you can review and complete the setup for these records. To do so, instead of adding a record, select the desired record.

To each document, add the data records to be exchanged. For external file-based documents, set up the records in line with how the data is structured and named in the file.

This topic explains how to add records to a Microsoft Excel document.

To each document, add the data records to be exchanged. For external file-based documents, set up the records in line with how the data is structured and named in the file.

This topic explains how to add records to a Microsoft Word document.

To each document, add the data records to be exchanged. For ODBC documents, set up the records in line with how the data is structured and named in the external database.

This topic explains how to add records to an ODBC document.

To each document, add the data records to be exchanged. For external file-based documents, set up the records in line with how the data is structured and named in the file.

This topic explains how to add records to a Text document.

To each document, add the data records to be exchanged. For external file-based documents, set up the records in line with how the data is structured and named in the file.

This topic explains how to add records to an XML document.

If records are already initialized for the document, you can review and complete the setup for these records. To do so, instead of adding a record, select the desired record.

Set up the field mapping for each record mapping of the message. 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.

To set up the field mapping, you can:

• Add fields manually.
• Select fields from a list.

You can only use the fields, as defined for the related record in the target document.

For each task, you can define several master data entities. If you run a task, all defined master data entities are run.

For more information on master data entities, refer to Master data management studio.

For each task, you can define several outbound web service actions. If you run a task, all defined outbound web service actions are run.

If version management is activated in the Connectivity studio parameters, you can add projects to version management. So, version management is only applicable to the projects that you added to version management.

As a result of a content packages comparison, all differences between the selected content packages are shown on the Compare page.

Compare results

On the Compare page, the Compare results tree shows where differences between the compared content packages exist. The Compare results tree has these types of entries: 

• Table: This is the highest level in the Compare results tree. It represents a table with records for which data differences exist between the compared content packages. 
  The entry name is defined by the target record name in the applicable message mapping. 
  The number of data differences for the table is shown in parentheses. 

• Record: This is the lowest level in the Compare results tree. It represents a record for which data differences exist between the compared content packages. 
  The entry name is defined by the key as set up in the applicable message field mapping. 
  The number of data differences for the record is shown in parentheses. 

Possible differences

For the selected entry in the Compare results tree, the related differences are shown in the Results pane. In the Results pane, for each difference, one of these messages is shown to describe the difference: 

• Field values are different 

• Field does not exist in source 

• Field does not exist in target 

• Record only exists in source 

• Record only exists in target 

Note:

 "Field does not exist in source" and "Field does not exist in target" messages do not imply that the original data tables do not have the specified field. It implies that the applicable message mapping removed this field from the resulting XML file.

Analysis

Use the Source value and Target value fields to analyze the difference between the field values. 

You can choose one of these options to indicate how to solve a difference:  

• Synchronized manually: You want to set the field value manually. You can do so in the resulting XML file. 

• Use source value: Use the value from the source content package as final value. 

• Use target value Use the value from the target content package as final value. 

You can use the View source record and View target record buttons to view the full selected record details in XML format. The shown data is retrieved from either the source content package or the target content package. 

You can use an expression to modify the value. In the expression, use source fields, target fields, or mapping variables as variables.
As a variable in the expression, you can use a:

• Field from any record of the applicable document. If you use a field from another record than the current record, make sure this record is mapped before the current record.
• Mapping variable that is defined for the message.

Examples:

You can use an expression to:

• Combine two fields. You can, for example, make a contact location name specific by combining it with the purpose. The expression can be: Description+'-'+Purpose. This results in, for example: Shop Main Street-Financial.
• Calculate the unit price based on the quantity and line amount on a purchase order confirmation. The variables are from the source record: Qty (PurchLine, PurchQty field) and Amount (PurchLine, LineAmount field). The expression is: Amount/Qty.

Note: 

• Usually, you use string and real values as variables.
• Date calculations are not supported.

You can use a handler class to set the target field value. Several handler classes are available. For example, to get the current date, to add the time to a date, or to get the current company.

On D365 FO tables, a financial dimension is expressed in a RecId to a financial dimensions table. So, it does not reflect the financial dimension name and value. You can use the Dimension set option to get or set the financial dimension value based on the RecId and the dimension name (or number) as defined for the field option. If the message is used to:

• Import, you receive the dimension value. Based on the RecId in the target field and the name (or number), the value is set in the relevant financial dimensions table. Note: On import, the target field type must be other than String.
• Export, based on the RecId in the source field and the name (or number), the dimension value is gotten from the relevant financial dimensions table. Note: On export, the source field type must be int64.

Note:

Only use the Dimension set field option if one of these fields is part of the field mapping:

• DefaultDimension: This field is used to store default dimensions for, for example, customers, vendors, or customer groups.
• LedgerDimension or OffsetLedgerDimension: These fields are used to store financial dimensions for ledger journals of the 'Main account' account type.
• DefaultDimension or OffsetDefaultDimension: These fields are used to store financial dimensions for ledger journals of other account types.

• Target field of the field mapping for imports.
• Source field of the field mapping for exports.

You can use a display method to get the applicable value. For example, you can use a display method to calculate a value.

You can use an edit method to set the target field value. On import, the edit method changes the value in the target field of the D365 FO table.

In a field mapping, you can apply an external code as defined for the related entity.

As a result, on:

• Import, the external code is replaced with the related code in your D365 FO environment.
• Export, the code in your D365 FO environment is replaced with the related external code.

You can only use the external code setup in messages that are run in EDI studio.

To use the external code functionality, in EDI studio, additional external code setup is required for the EDI parties or EDI groups. For each EDI party or EDI group, you can define an external code definition as set up for a:

• Currency
• Released product
• Charge codes of miscellaneous charges
• Modes of delivery
• Terms of delivery
• Unit

You can link an external ID to a record ID in D365 FO. Together with the external ID, you can also link an external revision number to a record ID.
The application, as defined for the connector, is used to store the link between the reference table and record ID in D365 FO and the external ID and revision number.
If you:

• Export data, the applicable external ID or revision is searched for in the target connector application. If a record exists for the reference table and the source field (RecId) combination, the external ID or revision of this record is as the output value of this option.
• Import data, the applicable target record ID is searched for in the source connector application. If a record exists for the combination of reference table and external ID and revision, the reference record ID of this record is the output value of this option. If no record exists for the combination, a record is created. The reference record ID of this record is the output value of this option.

Note: 

• You can only link an external ID or revision number to a record ID if, on the applicable document, the External reference field and the Revision field are filled in for the source field or target field of the current field mapping.
• You can only link a revision to a record ID in D365 FO if you also link the external ID. The external ID field mapping must precede the revision field mapping.
• Usually, you use the External reference option on a field mapping where the source field (export) or target field (import) is the RecID.

On several D365 FO tables, inventory dimensions exist. Each inventory dimension is expressed in a RecId that refers to the Inventory dimensions (InventDim) table. So, it does not reflect the inventory dimension name and value. You can use the Inventory dimension option to get or set the inventory dimension value based on the RecId and the dimension name as defined for the field option.

• On import, you receive the dimension value. Based on the RecId in the target field and the selected inventory dimension, the value is set in the InventDim table.
• On export, based on the RecId in the source field and the selected inventory dimension, the dimension value is gotten from the inventory dimensions table. Note: On export, the source field type must be int64.

Note: 

• Only use the Inventory dimension field option if the InventDimId field is the target field of the field mapping.
• For each used inventory dimension, add a separate field mapping. For example, if you use five inventory dimensions on a sales line, add five field mappings for the sales line target record. Each of these field mappings has the InventDimId field as target field. For each InventDimId field mapping, select the Inventory dimension field option and select the applicable inventory dimension.

To exchange journal data, you can get or set the account number for ledger transactions as main account (Default) or using another field (Ledger) to indicate if the value is, for example, a project, customer, or main account.

Note: If the account type is Main account, only use the Ledger field option if one of these fields is part of the field mapping: LedgerDimension or OffsetLedgerDimension.

During a message run, you can use mapping variables to temporary store values. You can write (calculated) values to a mapping variable, and later during the message run, read the value from the mapping variable. You can use mapping variables across records.
The mapping variable values are only stored during the message run. When the message run is finished, the mapping variable values are deleted.
During a message run, to read a mapping variable, on a field mapping, define the target field to be filled with the mapping variable value. Instead of a source field, use the 'Variable' field option to define the mapping variable which value must be used to set the target field value.

You can use a number sequence to get the field value. So, instead of the source field value, the next available number in the number sequence is the applicable value.

If all errors and warnings of an EDI Delfor journal are solved, accepted, or canceled, you must approve the EDI Delfor journal. The EDI Delfor journal is again validated according to the applicable journal validation setup. If the applicable validation rules are met, the EDI Delfor journal journal status is set to Approved. Approved EDI Delfor journals are processed by the 'Sales (Delfor) - EDI Delfor journal to Order' message batch.

If version management is active and a project is checked out to make changes, check in the project to make the changes generally available for other environments.

For internal documents and ODBC documents, the relation between the tables of a parent record and a child record are important. The relation is required to be able to query from parent to child records in the record tree.

Check or define the relation between the table for the current record and the table of the parent record.

Note: If you define the parent record for an internal document and a table relation exists with the current records table, it automatically adds the first-found relation to the current record. If the relation fields are not yet added to the parent record or the current record, these are automatically added. For an ODBC document, you must set the relations manually.

If you have finished the setup, you can run a test to check for errors in the setup. You can do so for:

If an error is found, in the message bar, a message is shown indicating the error.

If for an entity, an error exists or the setup is incomplete, an error icon   is shown. You can click the icon to show the related error in the message bar. 

On a message header, in the Log changes field, you can indicate if data changed are logged. If set to 'Yes', on import, the D365 FO data that is changed during import, is logged. Changes are logged by field. Only the latest change is stored for each field.

The data changes are logged in the History change log (BisConHistoryChangeLog) table. To view the logged data changes for a message, on the Message page, on the Action Pane, on the Operations tab, click Show changes.

You can clean up the logged data changes manually or in recurring mode.

Each integration run results in history records. History records can be logged for:

On processing the outbound queue, for each record, the related message or web service action is run to export the applicable data. A successfully processed outbound queue record gets the status Processed. 

You can clean up the outbound queue by deleting the records with the status Processed.

You can create a copy of a message. For example, to troubleshoot a failing message that is already in operation, you can copy the message. So, you do not disrupt the operational data.

You can use a connector of type Database to connect to an Azure SQL database.

For more information on Azure SQL databases, refer to Azure SQL Database.

You can use an Azure Storage Account to:

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

To start a data comparison, you need two content packages. Generate each of these content packages based on the XML files in the applicable Azure Storage account folder from the desired company/environment combination.

The generation process:

1. Creates a content package
2. Gets the data from all XML files in the specified Azure storage account folder
3. Adds this data to the created content package

You can compare the generated content package with another content package.

• Working
• Archive
• Error
• Split
• Copy
• Move

For the Azure Storage Account, create a file share for the version management files and history reporting files.

During a message run, you can use mapping variables to store values. You can write (calculated) values to a mapping variable, and later during the message run, read the value from the mapping variable. You can use mapping variables across records.

The mapping variable values are only stored during the message run. When the message run is finished, the mapping variable values are deleted.

During a message run, to:

• Write a mapping variable, on a field mapping, define the mapping variable as target variable, instead of using a target field. To set the mapping variable value, you can use several field mapping options, for example, a constant value, a custom expression, or a source field value. You can also use mapping variables on custom methods.
• Read a mapping variable, on a field mapping, define the target field to be filled with the mapping variable value. Instead of a source field, use the Variable field options to define the mapping variable which value must be used to set the target field value.
• Read a mapping variable for use in a custom expression, for the custom expression, create a variable with the Mapping variable field filled.

To analyze a project, you can create a Microsoft Word document based on the project. A summary of the project setup and related components setup is added to the document. You can use the document to review the setup.

When created, the Microsoft Word document is downloaded to your local downloads folder.

To create the document, the Microsoft Word template is used that is defined in the Connectivity studio parameters.

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.

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.

Usually, the data validations are done automatically.

On import, the business logic in D365 FO calls the ModifiedField method. This method can set or change other values. If the field mapping sequence is not right, it can reset values which are just imported.
You can modify the sequence of the fields in the mapping. The sequence is important if you:

• Import data.
• Exchange data between D365 FO environments.

For each record, you can define the range of data that is queried for export or import.

For example, you only want to export sales orders for a specific customer group. To do so, on the Range tab, add a record for the CustGroup field.

For more information on how to define ranges in the Range field, refer to Advanced filtering and query syntax.

When you run a message, a query is applied. For this query, you can define several specific settings:

• Cross company:
  If you run a message, the query is done in the company where you started the message. However, sometimes, for a specific record, it can be required to read data from another company. For example, if you run a message for a purchase order, you can read the data of a related sales order in another company.
• Time validation:
  If some record is valid for a specific time period, by default, the time validation uses the currently valid record. You can disable the time validation. As a result, the first available record is used. Which doesn't need to be the currently valid record. For example, addresses are valid during a specified time period. If time validation is applied, the currently valid address is used. If time validation is disabled, the address is used with the first time period.

You can organize the business document records in these ways:

• Define a parent-child relation with another record to define the record structure.
• Change the sequence of the records.

For internal documents and ODBC documents, you can define the order in which the data in the record is queried and processed during export or import.

For example, to export sales orders, you want the sales order to be queried by customer and for each customer by delivery date. To do so, on the Sorting tab, add a record for both the CustAccount field and the DeliveryDate field, in this sequence.

To analyze a project, you can create a Microsoft Word document based on the project. A summary of the project setup and related components setup is added to the document. You can use the document to review the setup.

To create the document, you must define the applicable Microsoft Word template in the Connectivity studio parameters.

To do so, first download the BIS Documentation Template.dotx template. Move the downloaded template to the folder as defined in the Connectivity studio parameters, in the Version management section, in the Shared path field.

If you want to copy a database to the current environment and you want to keep the Connectivity studio parameters, first export these parameters.

To compare data, first export your data from the applicable D365 FO environment to XML files. You can use XML files to generate a content package.

To generate an XML file for a content package, run the applicable message. As a result, an XML file with the content, as defined by the message, is generated and placed in a specified folder on your Azure Storage account. You can run several messages to export different sets of data to XML files. You can generate a content package based on several XML files. In this case, make sure all desired XML files for the content package are placed in the same Azure Storage account folder.

To exchange a configuration, you can export a project. All elements that are related to the project are exported. Transactions and history are not exported. For example, the related messages and web service actions are exported, but the message history and web service history are not exported.

Which settings are included in the export is defined by the Export options parameter in the Connectivity studio parameters. If you export a project, and the export option is:

• All, the full project configuration is exported, including the not encrypted secrets.
• Encrypt environment secrets, the full project configuration is exported, but the secrets are encrypted. To encrypt the secrets, you must define the Encryption key in the Connectivity studio solution parameters.
• Skip environment, the project configuration is exported except for the environment-specific properties of connectors and webservice actions.

As a result of the export, an XML file is created with the project configuration.

This topic explains how to export a project configuration to a file.

If you have released a Connectivity studio project a project release record is created in the BisReleaseTable table that contains an XML file with the data of the project and all related components. You can export this project release as a data entity with the Data management framework.

You can export secret references from a D365 FO environment to be imported in another D365 FO environment.

If you export a project, the secret references are not exported. If an export of the secret references is required, you can export the secret references separately.

Usually, you only export and import secret references to a D365 FO environment of the same type. For example, you only export secret references from a Development environment to import these in another Development environment. Reason: You don't want to mix up data. For example, you don't want to mix up Test data with Production data.

You can generate messages based on the data migration setup records. If you generate a message, this is generated:

If you have copied a database to the current environment and you first exported the Connectivity studio parameters, you can import these parameters.

When you process comparison results, for each table, a separate XML file is created. By default, the generated XML files are stored in the Import folder. You can import the files into D365 FO to create the desired environment setup. The import message, with the ECS Azure file storage connector as source connector, gets the XML files from the Import folder.

 You can: 

• Change the XML output folder. 

• Move the comparison results XML file to the Import folder of another environment. Then, you can import the data in that environment. 

If you have exported a project release as a data entity, you can import it in another environment with the Data management framework. As a result, a project release record is created in the BisReleaseTable table that contains an XML file with the data of the imported project and all related components.

To view the created project release, go to Connectivity studio > Periodic > Version management > Release.

Several project configurations are included as resources in the Connectivity studio release. If the Connectivity studio is deployed, you can import these project configurations from the resources.

You can import data from a Service Bus queue or topic subscription.

You can import secret references that are exported from another D365 FO environment.

If you import a project, the secret references are not included. If the related secret references are required, you can import the secret references separately.

Usually, you only export and import secret references to a D365 FO environment of the same type. For example, you only export secret references from a Development environment to import these in another Development environment. Reason: You don't want to mix up data. For example, you don't want to mix up Test data with Production data.

For documents of type Text or Microsoft Excel, you can initialize the fields for a record. To initialize record fields for:

• A Text document, use a connector of type Azure file storage and an input file of type TXT. The fields are initialized based on the header-line setup in the TXT file.
• A Microsoft Excel document, use a connector of type Azure file storage and an input file of type XLSX. The fields are initialized based on the header-line setup in the XLSX file.

When the initialization is finished, review and complete the properties of the initialized fields. Usually, during review, you do not add fields. However, you can remove the not needed fields.

For documents of type ODBC, you can initialize the fields for a record. To initialize record fields for an ODBC document, use a connector of type Database to connect to the applicable external database.

You can initialize a form mapping from an existing message. As a result, the record mapping and field mapping of the message are translated to a form mapping.

You can do this, for example, to bridge the gap between functional users and technical users.

You can troubleshooted a failing message using a copy of that message. When you have made changes to the message copy to solve the issue, the same changes must be applied to the original message. To do so, you can merge the message copy with the original message.

When you merge a message (source) with another message (target), the:

• Target message settings are overwritten with the source message settings.
• Target message documents settings are overwritten with the source message documents settings.

Note: Use this merge option carefully. You cannot undo the overwrite action.

On export of data to an Azure Service Bus queue or topic a message is added to the Service Bus queue. Each message that is added to the Service Bus queue is logged in Connectivity studio.

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.

Depending on the asynchronous execution mode of the inbound web service action, the inbound web service process runs directly or asynchronously.
If the asynchronous execution mode is 'Batch' and the web service action is triggered, the data, as received by the web service request, is stored in the Inbound web service staging table.

You can monitor the inbound web service staging table.

The project history shows, the project runs of the selected project. And for each project run, for example, its status is shown and if the project tasks have run with errors.

Usually, you run a task by running the related project. However, you can also run a single task, for example, for testing purposes.
When a task is run, you can view the task history. The task history shows, for example, the status of the task run and if the related messages have run with errors.

For each EDI Delfor journal with message status Processed, you can open the related sales order from the EDI Delfor journal.

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.

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.To fully process the logged events, process the:

1. Data synchronization log: The logged events are processed and for each applicable message or web service action, a record is added to the Outbound queue.
2. Outbound queue: For each record, the related message or web service action is run to export the applicable data.

This topic explains how to process the data synchronization log.

Note:

• Events are logged only for tables and event types that are defined in the data synchronization setup of any message or web service action.
• If on the data synchronization setup, the Update check box and the Check used fields check box are selected, event logging is restricted to changes to the fields as defined for the record in the applicable source document.
• Only the event is logged and used for further processing. So, in case of an update, an event is logged of type Update. However, the changed data is not marked as changed and not used for further processing. For example, if you change a customer address, an event is logged that the customer is updated. However, the address change as such is not logged. When, for the logged event, a record is processed in the outbound queue, the then current data of the customer is used.
• If a logged event is processed, it is deleted from the data synchronization log.

Example:

This table gives examples of the results for several data synchronization log processing scenarios:

If a receiver reads a message from a Service Bus queue or topic subscription, an error can occur. If so, the Service Bus moves the message to the applicable dead letter queue.

You can receive the Service Bus dead letter queue data. When received, you can further process this data into D365 FO. For example, you can set a Production order 'On hold' when a dead letter is received on the export of a production order.

To further process the received dead letter data, run the messages as assigned to the received dead letter data records. You can run the messages in several ways, as desired. You can run a message by running a:

When you analyze data differences, you can edit a record value manually. To process your analysis results, you can choose to use the source value. As a result, in the created XML file, for the fields to be edited manually, the source value is used as field value. You can manually edit the value in the resulting XML file.

When you analyze data differences, you can edit a record value manually. To process your analysis results, you can choose to use the target value. As a result, in the created XML file, for the fields to be edited manually, the target value is used as field value. You can manually edit the value in the resulting XML file.

If a receiver reads a message from a Service Bus queue or topic subscription, an error can occur. If so, the Service Bus moves the message to the applicable dead letter queue.

You can receive the messages from the Service Bus dead letter queue.

On receiving data from the Service Bus dead letter queue, based on the Service Bus search definitions and settings on the received data, messages are automatically assigned to the received dead letter data records. The assigned messages are used to further process the dead letter data into D365 FO. For example, you can set a Production order 'On hold' when a dead letter is received on the export of a production order.

If you want to connect to the Azure Blob storage with an authentication of type 'Password' or 'Client credentials', register an app in Microsoft Entra ID and configure the Azure Storage permissions.

Register a native web application in Microsoft Entra ID to access D365 FO. For more information, refer to Register an application with the Microsoft identity platform.

To be able to fill in the Client ID and the Secret in the HTTP action settings of the Azure Logic App, register the Azure Logic App in Microsoft Entra ID. For more information, refer to: Register an app.

To connect to D365 FO, you must register the Microsoft Entra ID application in D365 FO.

In unusual cases, the header information can get disturbed in the files on the file storage. You can repair the header information in the files on the file storage, based on the project version management table.

On a message, you can use a connector of type Azure file storage. For a Azure file storage connector, you can set up several file actions. These file actions are run in the defined sequence. If one of the file actions fails, the next file actions are not run.

If you have solved the errors in a message run, you can run it again. The message is re-run in the company in which it was originally run. As a result:

• The status of the selected message run is set to Reprocessed.
• A new message run history record is created for the re-run.

• At once for all received dead letter data records with the same message assigned. You can, for example do so if you have troubleshooted a message for which you have received several dead letter data records.
• Manually for a specific received dead letter data record.

• 'New' if you want to run the import message again for the received dead letter data records.
• 'Finished' if no import of the received dead letter data record is required.

In an environment, you can restore another project version. As a result, the current project version is replaced with the selected project version.

You can restore a project version for these reasons:

• To temporarily use it, for example, for reviewing or testing purposes or if the latest version has issues. In this case, do not check out the project when you restore it.
• To make it the basis for further design. In this case, check out the project when you restore it. When you check in the project, the restored version becomes the latest version.

You can run a message for testing and troubleshooting purposes. You can find and analyze the results in the:

• Message history.
• File history if the message has an Azure file storage connector with file actions.
• Tracer if you have used the tracer on the message run.

You can add a dynamic button to a form to run a message or an outbound web service action from the form.
To add a dynamic button, no coding is required.
The dynamic button is added to the Business integration tab of the ActionPane of the form.

To check if all test cases of a message work properly, you can run the message test cases. So, no full message run is done. Only the test cases, as defined for the message, are run.

If you want to run an outbound web service action immediately, you can run it from the Web service action page.

You can add a selection of table fields to a record. You can select fields from the D365 FO table that is defined in the Record table field.

This is mainly applicable to internal documents. However, you can also use this to quickly set up fields for external file-based documents.

When the field selection is added to the record, review and complete the properties of the added fields.

You can add a selection of table fields to a record.

You can select fields from an external table via ODBC. To connect to the external environment, the default connector of type Database. You can set up this default connector for the applicable project.

To find the external table name, the name that is defined in the Record table field is used.

When the field selection is added to the record, review and complete the properties of the added fields.

For a data migration from AX2021 to D365 FO, you can generate messages based on data migration setup records. Before you can do so, select the AX2012 tables which data you want to migrate to D365 FO. As a result, the related data migration setup records are created with the selected AX2012 tables as source table. If in D365 FO a table exists with the same name, this is automatically set as target table.

To compare data, select two content packages. If a desired content package does not exist, import the content package. As a result, a comparison is created.

You can apply data quality policy rules on import of data into D365 FO with a Connectivity studio message. On the message header, define which types of rules are applied on data import with the message.

For more information, refer to Apply data quality rules on data import with Connectivity studio.

Define the applications that are involved in integration or data migration projects. You can link an application to several projects.

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 one of these file systems:

You can use a connector of type 'Service Bus queue' to exchange information via an Azure Service bus queue. A Service Bus queue provides 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.

Set up the Azure App Service Web App that is used to manage the web service. For more information, refer to App Service documentation .

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. You can only use this connector in combination with a document for which the version 3 (V3) handler class is selected.

You can use one of these authentication methods to access the Blob storage:

• Shared access key: Grants access to a storage account.
• Shared access signature (SAS): Grants access to a specific Blob container.
• Client credentials: Grants access to Blob storage via an Microsoft Entra ID application with Azure storage permission.
• Password: Grants access to Blob storage via an Microsoft Entra ID application with Azure storage permission.

Set up a connector of type D365 FO. Use this type to directly connect to a D365 FO database.

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.

You can connect to an external database with an:

• ODBC connection: Connects to an external database via ODBC, using an Azure Service Bus.
• SQL connection: Connects to an external Azure SQL database.

{

"response": "We have received the request."

}

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

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.

To add data to the Microsoft Word document, you can add markers to the Microsoft Word template. You can add markers for document records and for document record fields.

Note: You can use a Microsoft Word document only to write. So, no read options need to be set.

Use an ODBC document to directly read data from or write data to an external database. You can exchange data with an external database via ODBC or with an external Azure SQL database.

Set up a connector of type ECS Azure file storage. Use this type to connect to your Azure file storage location. The connector creates the Environment comparison studio folders in the share that is defined in the Environment comparison studio parameters.  

On the Connector page, in the ECS connector details section, you can view the generated folder paths.  

The ECS Azure file storage connector creates: 

• The environment-specific parent folder. This folder is created in the Share that is defined in the Environment comparison studio parameters. 

• A folder for each legal entity in the environment. These folders are created in the environment-specific parent folder. 

• A Work (ECSWorkFolder) folder for each legal entity. This folder is created in the legal entity folder. 

• Archive, Error, Export, and Import folders. These folders are created in the Work (ECSWorkFolder) folder. 

Use the ECS Azure file storage connector to manage the paths and to place Environment comparison studio files in the applicable folders. 

Use messages as the carriers that transport data from a source to a target, based on the mapping as defined on the message. 

In Environment comparison studio, for a message to: 

• Export data from D365 FO, the: 

  • Source document type is D365 FO. 

  • Source connector type is D365 FO. 

  • Target document type is XML. 

  • Target connector type is ECS Azure file storage. 

• Import comparison result data into D365 FO, the: 

  • Source document type is XML. 

  • Source connector type is ECS Azure file storage. 

  • Target document type is D365 FO. 

  • Target connector type is D365 FO. 

Make sure the Key field is added to the source XML document. The key is a constant value that is used to compare records. The Key field is a manual addition and is not part of the table that is used in the message. 

Set the general Environment comparison studio parameters that define the storage location for the ECS Azure file storage connector generated folders. 

• Source, before the message is run, the file is copied from a defined folder to the Working folder. The original file stays in the defined folder.
• Target, after the message is run, the created file is copied from the Working folder to the defined folder. The original file stays in the Working folder.

• 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.

• Source, before the message is run, the file is moved from a defined folder to the Working folder.
• Target, after the message is run, the created file is moved from the Working folder to the defined folder.

• Source, before the message is run, the file is unzipped to the Working folder. The original ZIP file stays in the Working folder.
• Target, after the message is run, the created file is zipped to the Working folder. The original file is deleted from the Working folder. Next file actions in the file action sequence are done with the ZIP file.

• Working
• Archive
• Error
• Split
• Copy
• Move

If you use Connectivity studio on a D365 FO (on-premises) environment, you can choose to use local Windows folders to exchange data files.

To connect to SharePoint, the Microsoft Graph API is used. Register an app in Microsoft Entra ID and configure the Microsoft Graph permissions.

• DP; Delivery party; Party to which goods must be delivered.
• IV; Invoicee; Party to whom an invoice is issued.

• Working
• Archive
• Error
• Split/Temporary
• Temporary

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. You can only use this connector in combination with a document for which the version 3 (V3) handler class is selected.

Set up a connector of type Staging journal. Use this type to validate and approve data before it is imported into D365 FO.

A staging journal scenario consists of:

• A message to import the data from the source into the staging journal. This message has a target document of type Staging and a target connector of type Staging journal.
• A staging journal which is an additional table in which the data is validated and approved before the data is imported into D365 FO.
• A message to get the approved data from the staging journal and import it into D365 FO. This message has a source document of type Staging and a source connector of type Staging journal.

For each document record, you can define data validations to be done when a data record is inserted in the staging journal.

You can use a template company as source company. If you run a message, the data is exported from the template company and imported in the target company.
In a template company, you can, for example, define generally applicable master data. You can use this to set up the master data for a new company.
To be able to use a template company, in the Connectivity studio parameters, define the template company for each target company. You can define several template companies. For example, with country-specific or industry-specific data.

If you need a type conversion and it does not already exist, you must set it up.

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:

Set up a connector of type Upload and download. Use this type to:

• Upload files: On the message, select the connector as source connector. On running the message, you can manually select and upload a file from a folder and import its contents.
• Download files: On the message, select the connector as target connector. On running the message, a file is created and downloaded to your local downloads folder.

With the Upload and download type connector, you can upload or download these external file-based documents: EDI, Fixed text, Microsoft Word, Microsoft Excel, Text, XML, JSON. You can only use this connector in combination with a document for which the version 3 (V3) handler class is selected.

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

Attributes

The attribute styles define how the attribute is applied to the request. You can use these attribute styles:

Set up a connector of type Web service. Use this type to exchange data via a web service using a stream.

If you:

• Import data, the web service adds its data to a stream. From this stream, the data is imported into D365 FO.
• Export data, the data is exported from D365 FO and added to a stream. The web service takes the data from this stream and processes it.

The related document defines which data is added to or taken from a stream and in which format and structure. So, the document does not result in a file.

With the Web service type connector, you can use these external file-based documents: EDI, Fixed text, Text, XML, JSON. You can only use this connector in combination with a document for which the version 3 (V3) handler class is selected.

You can show the records where a secret reference is used. This can be helpful, for example, if you want to change a secret and you want to see which records are involved.

For an Azure file storage connector, you can connect to an Azure file share. To access the Azure file share, you can mount the Azure file share.

When an EDI Delfor journal is processed with the 'Sales (Delfor) - EDI Delfor journal to Order' message, errors can occur. If an error occurs:

• The EDI Delfor journal is not processed.
• The EDI Delfor journal message status is set to Error.
• The error is logged in the EDI Delfor journal Infolog.

You can solve processing errors and have the EDI Delfor journal processed again.

The delivery forecast sales orders that you receive with the 'Sales (Delfor) - XML to EDI Delfor journal (830)' message are stored in the EDI Delfor journal.

These EDI Delfor journals are validated according to the applicable journal validation setup. If the applicable validation rules are not met, an error or warning is given. Before the EDI Delfor journals can be processed further, review the errors and warnings, and take appropriate actions.
If journal validation errors are given, you have these options:

• Solve the errors. You can solve validation errors in:
  • The EDI Delfor journal, where you can make the appropriate changes.
  • Microsoft Dynamics 365 for Finance and Operations. For example, if the setup must be changed to solve the error.
• Cancel the EDI Delfor journal, line, or address with errors.

You cannot accept headers, lines, or addresses with errors. If you do so, and approve the EDI Delfor journal, the header, line, or address with errors is again set to Rejected.

If the errors are solved or lines or addresses with errors are canceled, approve the EDI Delfor journal.

The delivery forecast sales orders that you receive with the 'Sales (Delfor) - XML to EDI Delfor journal (830)' message are stored in the EDI Delfor journal.

These EDI Delfor journals are validated according to the applicable journal validation setup. If the applicable validation rules are not met, an error or warning is given. Before the EDI Delfor journals can be processed further, review the errors and warnings, and take appropriate actions.

If journal validation warnings are given, you have several options:

• Accept the header, line, or address with warnings.
• Solve the warnings. You can solve validation warnings in:
  • The EDI Delfor journal, where you can make the appropriate changes.
  • Microsoft Dynamics 365 for Finance and Operations. For example, if the setup must be changed to solve the warning.
• Cancel the EDI Delfor journal, line, or address with warnings.

If all warnings are solved, accepted, or canceled, approve the EDI Delfor journal.

• The EDI inventory order is not processed.
  
• The EDI inventory order message status is set to Error.
  
• The error is logged in the EDI inventory order journal Infolog.
  

The EDI inventory orders are validated according to the applicable journal validation setup. If the applicable validation rules are not met, an error or warning is given. Before the EDI inventory order can be processed further, review the errors and warnings, and take appropriate actions.
If journal validation errors are given, you have these options:

• Solve the errors. You can solve validation errors in:
  • The EDI inventory order, where you can make the appropriate changes.
  • Microsoft Dynamics 365 for Finance and Operations. For example, if the setup must be changed to solve the error.
• Cancel the EDI inventory order, line, or address with errors.

You cannot accept headers, lines, or addresses with errors. If you do so, and approve the EDI inventory order, the header, line, or address with errors is again set to Rejected.

If you use EDI inventory order staging in your EDI process, the received information is imported into the EDI inventory order journal by the relevant custom messages. You can, for example, use staging in your EDI process for picking list registrations or product receipts.
The EDI inventory orders are validated according to the applicable journal validation setup. If the applicable validation rules are not met, an error or warning is given. Before the EDI inventory order can be processed further, review the errors and warnings, and take appropriate actions.

• The EDI purchase order confirmation is not processed.
  
• The EDI purchase order confirmation message status is set to Error.
  
• The error is logged in the EDI purchase order confirmation journal Infolog.
  

The purchase order confirmations that you receive with the 'Purchase - XML to EDI confirmation' message are stored in the EDI purchase order confirmations journal.
These EDI purchase order confirmations are validated according to the applicable journal validation setup. If the applicable validation rules are not met, an error or warning is given. Before an EDI purchase order confirmation can be processed further, review the errors and warnings, and take appropriate actions.
If journal validation errors are given, you have these options:

• Solve the errors. You can solve validation errors in:
  • The EDI purchase order confirmation, where you can make the appropriate changes.
  • Microsoft Dynamics 365 for Finance and Operations. For example, if the setup must be changed to solve the error.
• Cancel the EDI purchase order confirmation, line, or address with errors.

You cannot accept headers, lines, or addresses with errors. If you do so, and approve the EDI purchase order confirmation, the header, line, or address with errors is again set to Rejected.

The purchase order confirmations that you receive with the 'Purchase - XML to EDI confirmation' message are stored in the EDI purchase order confirmations journal.

Solve the file action errors that occurred during the message run.

Solve the errors that have occurred in the message run.

• Solve the errors or warnings.
• Cancel the records with errors.
• Accept the records with warnings.
• Cancel the journal.

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.

When the logged events are processed, for each applicable message or web service action, a record is added to the Outbound queue.

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, which is explained in this topic.

When tested, a logged event is processed to the outbound queue. If processing a logged event goes:

• Fine, a record is added to the outbound queue. But, different from normal processing, the logged event stays in the data synchronization log.
• Wrong, no record is added to the outbound queue.

When the test is finished, you can view the processing steps and result in the message details. For each message or web service action that is subscribed to events of the same table, you can view the processing steps. In case of errors, verify the processing steps to see where the issue occurred.

This picture is an example of message details, with an explanation of the different parts:

Explanation:

1. The type of the logged event.
2. The message or web service action that is subscribed to events of the table.
3. The checks that are done to see if the logged event is valid for the message:
   • In case of an update: Is the field for which a value is changed defined in the source document of the message?
   • Is the company for which the event is logged defined as source company for the source connector of the message?
4. In the example, on the message, for the data synchronization setup, the Redirect event field is set to Yes. This means, on processing the data synchronization log, if the event is logged for a child record of the source document, it is added to outbound message queue for the root record of the source document. Example: The source document has a root record 'Sales order' and a child record 'Sales line'. A table event is logged for a sales line. The sales order record is added to the outbound message queue instead of the logged sales line record. As a result, the sales order and all its sales lines are exported by the message.
5. The message if no record is added to the outbound queue. In no record is added to the outbound queue, also a Query info section is shown. This section shows the query that is applied.
6. A summary of the result of the test.

If you run into an issue with a message, you can separately test the source and target documents.

You can test an inbound web service action without receiving an HTTP request from the external application. So, you only test the inbound web service action setup and not the full process with connection to the external application.

When testing, the inbound web service action does run the request message and response message. So, data can be impacted. Therefore, you are advised to only test an inbound web service action in a Development or Test environment.

For the result of an inbound web service action test, view the Result section on the test page. You can also view the message history of the related request message and response message.

You can test an outbound web service action without sending a request to the external web service. So, you only test the outbound web service action setup and not the full process with connection to the external web service.

When testing, the outbound web service action does run the request message and response message. So, data can be impacted. Therefore, you are advised to only test an outbound web service action in a Development or Test environment.

For the result of an outbound web service action test, view the message history of the related request message and response message.

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.

In Connectivity studio, you can use the staging concept to validate data in an intermediate area before it is further processed. Usually, the 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.

An integration can be triggered in several ways. If a trigger fails, no errors are shown in the Connectivity studio Integration operations history.

Batch job

You can change a secret reference name. this automatically updates the secret reference in all places where it is used.

You can update a secret reference name, for example, after you upgraded from local secret storage to central secret storage. In this case, you can change the automatically created secret reference names.

For each project, you can migrate from 'locally' stored secrets to centrally stored secrets. To do so, you can automatically collect the locally stored secrets and store these in the centrally stored secret references.

During upgrade:

• All locally stored secrets of the project are collected. Note: Also, the Azure storage password from the Connectivity studio parameters is collected and upgraded.
• For each unique secret, a secret reference is created with an automatically generated name. So, no duplicate secret references are created. Note: A secret reference is unique for the secret and environment type combination.
• For each record with a 'local' secret, the secret is removed, and the newly created secret reference is linked to the record.

Note: Usually, you only use this upgrade function once per project during migration from locally to centrally stored secrets.

You can use the File explorer to quickly access and view the share as defined for the applicable Azure file storage connector. The File explorer offers limited functionality. You can only view, copy, move, or delete files.

Use the EDI Delfor journal to monitor the delivery forecast sales orders.

The delivery forecast sales orders that you receive with the 'Sales (Delfor) - XML to EDI Delfor journal (830)' message are stored in the EDI Delfor journal.

If you monitor EDI Delfor journals, the statuses are important. For more information on these statuses, refer to 'EDI staging journal statuses'.

For each customer, item, and customer order combination, for which you receive delivery forecasts, you can provide an overview of the related EDI Delfor sales information. You can use this data to apply several validation rules to EDI Delfor journals.

The EDI Delfor sales information is:

• Created and updated when an EDI Delfor journal is processed, and the related delivery forecast order is imported into the Sales orders table with the 'Sales (Delfor) - EDI Delfor journal to Order' message. To create and update the EDI Delfor sales information, on this 'Sales (Delfor) - EDI Delfor journal to Order' message, you must add the mapping for the EDI Delfor Sales information (BisEdiDelforSalesData) table.
• Updated when a packing slip is posted for a sales order that is created based on an EDI Delfor journal. This update is only done if the EDI Delfor sales information exists for the customer, item, and customer order combination.

You can view a report in Microsoft Excel format that contains the errors that occurred during a message run. You can, for example, use this to inform the sender of data on the errors.

You can review and analyze the history of message runs.

You can view the messages on a Service Bus queue or topic subscription for a specific connector.

Use the staging journal to monitor the staged records.

When in an inbound web service process, the request message did not run successfully or an error occurred, the inbound web service action runs the error message, if defined. This is managed by the handler class as defined for the web service action.
The error message sends the error information from D365 FO to the inbound web service. For example, you can use an error message to change the status of a record in the external application.

When triggered, the inbound web service action first runs the request message, if defined. This is managed by the handler class as defined for the web service action.
The goal of the request message depends on the HTTP action of the web service action. In general, the request message provides D365 FO with data from the external application.

When triggered, the outbound web service action first runs the request message, if defined. This is managed by the handler class as defined for the web service action.

When in an inbound web service process, the requested data is received from D365 FO, the inbound web service action runs the response message, if defined. This is managed by the handler class as defined for the web service action.
The goal of the response message depends on the HTTP action of the web service action. In general, the response message sends the response from D365 FO to the inbound web service.

When in an outbound web service process, the requested data is received from the web service, the outbound web service action runs the response message, if defined. This is managed by the handler class as defined for the web service action.
The goal of the response message depends on the HTTP action of the web service action. In general, the response message processes the response from the web service in D365 FO.