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.

For each legal entity, you can set up several addresses. For each of these addresses, you can define the Global Location Number (GLN code). You can use the GLN code in EDI to identify the unique location.

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 outbound web service actions. If you run a task, all defined outbound web service actions are run.

For the created key vault, set up an access policy to allow the earlier registered app to access the key vault.

On creation of the access policy:

• On permission selection, select these Secret permissions: Get and List.
• On principal selection, select the earlier registered app.

For more information, refer to Assign a Key Vault access policy.

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.

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. 

In EDI studio:

• All EDI transactions are logged in EDI history management (BisEdiHistory table).
• You can use the staging concept to validate data in an intermediate area before it is further processed. Several predefined staging journals are available for EDI studio:
  • EDI purchase journal
  • EDI Sales journal
  • EDI Delfor journal
  • EDI inventory journal
  • EDI transfer journal

To prevent the database from containing too much data, you can clean up the EDI history and EDI staging journals in recurring mode.

For example, you want to keep the EDI staging journals for six months. Each week, you can do a cleanup, deleting staging journals older than six months.

In EDI studio, you can use the staging concept to validate data in an intermediate area before it is further processed.

Several predefined staging journals are available for EDI studio:

• EDI purchase journal
• EDI sales journal
• EDI Delfor journal
• EDI inventory journal
• EDI transfer journal

To prevent the database from containing too much data, you can clean up the EDI staging journals manually.

To enable browsing the app service, add a redirect URI to the earlier registered app.

To add the redirect URI:

• Select the 'Web' platform.
• Enter this URI: [app service URL]/signin-oidc. For example: https://example.azurewebsites.net/signin-oidc. You can copy the URL from the App service Overview page.
• Select the ID tokens check box.

For more information, refer to Add a redirect URI.

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:

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

When you use the AS2 web app, you need a key vault to set up the secrets and certificates that are required to run the AS2 web app.

Create a key vault and generate these certificates and secrets in the key vault:

For more information, refer to:

• Quickstart: Create a key vault using the Azure portal
• Quickstart: Set and retrieve a certificate from Azure Key Vault using the Azure portal
• About Azure Key Vault secrets

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.

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 get the AS2 web app running in the cloud, deploy the created app service. Ask To-Increase for the AS2WebApp.zip file that contains the AS2 web app files that are required for deployment.

Deploy the AS2 web app files with the Zip Push Deploy tool of the Kudu services portal.

You can use EDI studio to receive EDI message files from the AS2 web app. These EDI message files are stored in a general storage location. From the general storage location, these EDI message files must be distributed to specific storage locations from where the files can be processed by the applicable inbound messages.

To distribute the EDI message files from the general storage location, run the project inbound definitions. Usually, you run the inbound definitions in recurring mode. Always, all inbound definitions of the selected project are run. The inbound definitions are run in the defined sequence.

When an inbound definition is run:

1. It connects to the general storage location as defined by the connector.
2. The EDI message files that match the read filter are opened to search for this data:
   • Type: The EDI message type of the data in the file. For example, 'Order' or 'Invoice'.
   • Recipient: The data in the file that indicates to which company in D365 FO the data must be imported. For example, the GLN.
3. Based on this data, the applicable file distribution definition is determined.
4. The message, as defined for the applicable file distribution definition is used to:
   • Rename the EDI message file: If renaming is applicable, the source document of the message defines how the EDI message file is renamed.
   • Move the EDI message file: The source connector of the message defines to which specific storage location the EDI message file is moved for further processing.
5. If the inbound definition is mandatory, and an EDI message file cannot be processed, the EDI message file is moved to the error location as defined for the connector.

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.

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:

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.

To have a quick start with the EDI setup, you can use the standard EDI tutorials. These tutorials have several pre-defined EDI messages with related setup. The related setup includes, for example: the project, the source and target connectors, and the source and target documents.

These standard EDI tutorial projects are available as a resource:

• Tutorial - EDI
• Tutorial - EDI - 3PL
• Tutorial - EDI Delfor

You can import the standard EDI tutorials by importing the related projects from resource.

If you set up an EDI integration using TIE Kinetix, to have a quick start with the EDI setup, you can use the TIE Kinetix specific EDI tutorials. These tutorials have several pre-defined EDI messages with related setup. The related setup includes, for example: the project, the source and target connectors, and the source and target documents.

These TIE Kinetix specific EDI tutorial projects are available as download:

• Tutorial - TIE Sales
• Tutorial - TIE Purchase
• Tutorial - TIE Warehouse 3PL

You can import these EDI tutorials by importing the related projects from file.

Before you can import the project, download the ZIP file that contains the project files. To do so, click this link: TIE Kinetix integration EDI tutorial projects. After download, extract the ZIP file.

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.

All EDI transactions are logged in EDI history management (BisEdiHistory table).

This topic explains how to monitor the overall EDI history.

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.

For each customer with whom you exchange EDI messages, you can monitor the related document flows.

Only the applicable document flows are shown. For more information on how the applicable document flows are searched for, refer to 'Search for document flow: Vendor'.
To edit vendor document flows, refer to 'Set up buyer messages document flows'.

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 you use a web service, as defined on the applicable document flow, also define the applicable web service action here.

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:

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.

Register an application in Azure to manage the authentication and permissions for the AS2 web app. For more information, refer to Register an application with the Microsoft identity platform.

Add a client secret to the registered application. For more information, refer to Add a client secret.

Later in the AS2 setup, you need these values of the registered app:

• Application (client) ID
• Directory (tenant) ID
• Application ID URI
• Client secret value

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.

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.

You can use the File explorer to quickly access and view the general storage location as defined by the connector of a selected inbound definition. The File explorer offers limited functionality. You can only view, copy, move, or delete files.

You can, for example, use the file explorer to see if all EDI message files in the general storage location are distributed.

If you use the AS2 protocol to receive EDI messages from an EDI partner, use the AS2 web app to manage the interaction with the EDI partner.

The AS2 web app runs in the Azure cloud.

When the web server of the EDI partner sends data to the AS2 web app, it:

1. Decompresses the received data, if the received data is compressed.
2. Decrypts the data.
3. Checks the signature.
4. Stores the data in an EDI message file in the general storage location.
5. Sends an MDN reply to the web server of the EDI partner. The MDN reply can be that the data is:
   • Processed successfully.
   • Not processed because something went wrong. For example, the data cannot be decrypted, or the signature is invalid.

If you use the AS2 protocol to send EDI messages to an EDI partner, use the AS2 web app to manage the interaction with the EDI partner.

The AS2 web app runs in the Azure cloud.

When you run a web service action using the AS2 protocol, an EDI message is sent to the AS2 web app.

The web service action calls the send method of the AS2 web app to send the data to the EDI partner.

The AS2 web app send method:

• Encrypts the data.
• Signs the data.
• Compresses the data, if applicable.
• Sends the data to the web server of the EDI partner.
• Receives an MDN reply from the web server of the EDI partner.
• Sends the MDN reply from the EDI partner to EDI history of the web service action in EDI studio that originally sent the data.

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.

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.

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.

Set up an app configuration. Create the App Configuration and in the App Configuration set the required key values.

Copy the connection string of the App Configuration from the Access keys page and save it somewhere. Usually, you use the connection string of the primary key. You need the connection string to connect the App Service to the App Configuration, in the configuration of the App Service.

For more information, refer to About Azure App Configuration.

Key values

To add the key values to the App Configuration, download the Default AS2 App Configuration and extract it.

The default AS2 web app name prefix for the keys is 'AS2WEBAPP'. If you want to use another prefix, you can change it. To do so, before you import the key values, edit the 'DefaultAS2AppConfiguration.json' file in a text editor.

Note:

• You define the AS2 web app name in the App Service settings (ApplicationSetup:ApplicationId). For consistency purposes, you are advised to use the same name for the App Service and the AS2 web app name.
• When you edit the 'DefaultAS2AppConfiguration.json' file, you can also set the key values. However, do not set the values for these keys in the file:
  • AS2WEBAPP:As2Setup:OwnedPrivateKey
  • AS2WEBAPP:As2Setup:PartnerPublicKey
  • AS2WEBAPP:Storage:Key

When you have finished editing the JSON file, import the 'DefaultAS2AppConfiguration.json' file to your App Configuration. For more information, refer to Import data from a configuration file.

In the App Configuration, you can edit the values of the imported keys with the Configuration explorer. To do so:

• For most of the keys, you can use the Edit option.
• For these keys, use the Add Key Vault reference option:
  • AS2WEBAPP:As2Setup:OwnedPrivateKey
  • AS2WEBAPP:As2Setup:PartnerPublicKey
  • AS2WEBAPP:Storage:Key

The key configuration that is required for the AS2 web app is:

Create and configure an App service in the Azure portal. The app service is the AS2 web app.

On creation of the app service, in the:

• Runtime stack field, select '.NET 6 (LTS)'.
• Operation system field, select 'Windows'.

Fill in the other fields as desired. For more information, refer to Create a Web app.

To configure the web app, add and edit the required app settings. Do not remove the automatically generated app settings. For more information, refer to Configure app settings.

Add and edit these app settings:

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.

If you run the AS2 web app in the AS2 inbound process, it stores the data in EDI message files in the general storage location. Usually, the general storage location is defined by an Azure Storage account.

You can create an Azure Storage account or, if you already have an Azure Storage account, use that one. For more information, refer to Create an Azure storage account.

In the storage account, create the file share where the EDI message files must be stored by the AS2 web app. For more information, refer to Create a file share.

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 document flow to import an item counting message from a specific 3PL warehouse.

On the document flow, set the 'Warehouse - XML to Counting journal' message. This message receives the item counting information from the 3PL warehouse.

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an inbound web service action with the 'Warehouse - XML to Counting journal' message as request message.

Set up a document flow to send a picking list message to a specific 3PL warehouse.

On the document flow, set the 'Warehouse - Picking list to XML' message. This message sends the picking list to the 3PL warehouse.

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an outbound web service action with the 'Warehouse - Picking list to XML' message as request message.

Set up a document flow to define how to import a picking list registration that you received from a specific 3PL warehouse.

On the document flow, you can set one of these EDI messages to import a picking list registration:

• 'XML picking list registration to EDI inventory order' (custom message): If you use staging, use this message to receive a picking list registration from a 3PL warehouse. This message imports the received picking list registration into the EDI inventory order journal. When the import is completed, the applicable validations are done automatically.
• 'Warehouse - XML to Picking list registration': If you do not use staging, use this message to receive a picking list registration from a 3PL warehouse. This message imports the received picking list registration directly into the Picking list registration journal.

You can choose to exchange this EDI message using a web service. In this case, instead of a message, use an inbound web service action with one of the above messages as request message.

Set up a document flow to define how to import an order acknowledgement message from a specific vendor.

On the document flow, set the 'Purchase - XML to Acknowledgement' message. This message updates the acknowledgement status in the EDI history.

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an inbound web service action with the 'Purchase - XML to Acknowledgement' message as request message.

Set up a document flow to define how to import a packing slip message from a specific vendor.

On the document flow, set the 'Purchase - XML to Delivery' message. This message imports the packing slip from your vendor into the arrival journal. This message is also known as an advance shipping notice (ASN).

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an inbound web service action with the 'Purchase - XML to Delivery' message as request message.

Set up a document flow to define how to import an invoice message from a specific vendor.

On the document flow, set the 'Purchase - XML to Invoice' message. This message imports the invoice from your vendor into the invoice register journal.

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an inbound web service action with the 'Purchase - XML to Invoice' message as request message.

Set up a document flow to define how to send a purchase order message to a specific vendor.

On the document flow, set the 'Purchase - Order to XML' message. This message sends the purchase order to your vendor.

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an outbound web service action with the 'Purchase - Order to XML' message as request message.

Set up a document flow to define how to import an order confirmation message from a specific vendor.

On the document flow, set the 'Purchase - XML to EDI confirmation' message. This message imports the order confirmation into the EDI purchase order journal. When the import is completed, the applicable validations are done automatically.

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an inbound web service action with the 'Purchase - XML to EDI confirmation' message as request message.

Set up a document flow to send a receipts list message to a specific 3PL warehouse.

On the document flow, set the 'Warehouse - Receipts list to XML' message. This message sends the receipts list to the 3PL warehouse.

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an outbound web service action with the 'Warehouse - Receipts list to XML' message as request message.

Set up a document flow to define how to send a sales packing slip message to a specific customer.

On the document flow, set the 'Sales - Delivery to XML' message. This message sends the packing slip to your customer. This message is also known as an advance shipping notice (ASN).

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an outbound web service action with the 'Sales - Delivery to XML' message as request message.

Set up a document flow to define how to send a sales order confirmation message to a specific customer.

On the document flow, set the 'Sales - Confirmation to XML' message. This message sends the sales order confirmation to your customer.

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an outbound web service action with the 'Sales - Confirmation to XML' message as request message.

Set up a document flow to define how to send a sales invoice message to a specific customer.

On the document flow, set the 'Sales - Invoice to XML' message. This message sends the sales invoice to your customer.

You can choose to exchange this EDI message using a web service. In this case, instead of the message, use an outbound web service action with the 'Sales - Invoice to XML' message as request message.

Set up a document flow to define how to import a received order (Delfor) from a specific customer.

On the document flow, you can set the 'Sales (Delfor) - XML to EDI Delfor journal' message. This message imports the received sales order (Delfor) into the EDI Delfor journal. When the import is completed, the applicable validations are done automatically.

You can choose to exchange this EDI message using a web service. In this case, instead of a message, use an inbound web service action with the 'Sales (Delfor) - XML to EDI Delfor journal' message as request message.

If you set up EDI to export data to the AS2 web app, for the outbound document flows, define a web service action instead of a message.

Make sure the desired export message is defined for the web service action that you use in an outbound document flow. You can link, for example, the EDI tutorial export messages to a web service action that you define for an outbound document flow.

Before you can exchange EDI messages, set up the EDI setup for your legal entity.

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

Use inbound definitions when you receive EDI message files from the AS2 web app.

Set up an inbound definition of type EDI to move files that are structured in line with an EDI standard (for example, EDIFACT) from the general storage location to a specific storage location.

To determine which file distribution definition applies, this data must be read from the file:

• Type: The EDI message type of the data in the file. For example, 'Order' or 'Invoice'.
• Recipient: The data in the file that indicates to which company in D365 FO the data must be imported.

Example

EDI file content example:

UNH+1+ORDERS:d:12A:EU:EAN123

Example of setup that can be applied to get the type (ORDERS):

Use inbound definitions when you receive EDI message files from the AS2 web app.

Set up an inbound definition of type Fixed text to move files with defined start positions and lengths for fields from the general storage location to a specific storage location.

To determine which file distribution definition applies, this data must be read from the file:

• Type: The EDI message type of the data in the file. For example, 'Order' or 'Invoice'.
• Recipient: The data in the file that indicates to which company in D365 FO the data must be imported.

Example

Fixed text file content example:

ORDER10002US-027M0001123.452025-03-01

Example of setup that can be applied to get the customer ID (US-027):

Use inbound definitions when you receive EDI message files from the AS2 web app.

Set up an inbound definition of type JSON to move files with data-object notation from the general storage location to a specific storage location.

To determine which file distribution definition applies, this data must be read from the file:

• Type: The EDI message type of the data in the file. For example, 'Order' or 'Invoice'.
• Recipient: The data in the file that indicates to which company in D365 FO the data must be imported.

Example

JSON file content example:

{"Stores":["Lambton Quay","Willis Street"],"Manufacturers":[{"Name":"Acme Co","Products":[{"Name":"Anvil","Price":50}]},{"Name":"Contoso","Products":[{"Name":"Elbow Grease","Price":99.95},{"Name":"Headlight Fluid","Price":4}]}]}

Examples of JSON path expressions that can be applied to this example:

• Manufacturers[0].Name: Finds the name of the first manufacturer: Acme Co.
• $..*[?(@.* == 'Acme Co')]: Finds the name of the token: Name.

Note: JSON path expressions are case sensitive.

Use inbound definitions when you receive EDI message files from the AS2 web app.

Set up an inbound definition of type Text to move files with field and line separators (for example, CSV files) from the general storage location to a specific storage location.

To determine which file distribution definition applies, this data must be read from the file:

• Type: The EDI message type of the data in the file. For example, 'Order' or 'Invoice'.
• Recipient: The data in the file that indicates to which company in D365 FO the data must be imported.

Example

Text file content example:

ORDER;10002;US-027;M0001;123.45;2025-03-01

Example of setup that can be applied to get the customer ID (US-027):

Use inbound definitions when you receive EDI message files from the AS2 web app.
Set up an inbound definition of type XML to move files in XML format from the general storage location to a specific storage location.

To determine which file distribution definition applies, this data must be read from the file:

• Type: The EDI message type of the data in the file. For example, 'Order' or 'Invoice'.
• Recipient: The data in the file that indicates to which company in D365 FO the data must be imported.

Example

XML file content examples, without and with namespace:

• <xml><invoice><header><id>invoice123</id><sender>ABC</sender></header></invoice></xml>
• <xml xmlns=[namespace]><invoice><header><id>invoice123</id><sender>ABC</sender></header></invoice></xml>

Examples of XPath expressions that can be applied to this example:

• /*: Finds the name of the first tag: invoice. Note: if you use * in the XPath expression, it finds the name of the tag instead of the tag value.
• /xml/invoice/header/sender: Finds the value of the 'sender' tag: ABC.
• /ns:xml/ns:invoice/ns:header/ns:id: Finds the value of the 'id' tag: invoice 123. Note: If the XML has a namespace, make sure to define the namespace in the Namespace field. When the inbound definition is run, in the expression, 'ns' is replaced with the defined namespace.

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

Set up a web service application for the project that connects to the AS2 web app.

For more information refer to: Set up web service application for project.

For the web service application, use these settings:

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

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.

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 the outbound web service actions to export data to the AS2 web app. With the mentioned settings, the web service action calls the send method of the AS2 web app to send the data to the EDI partner.

For more information, refer to Set up web service action - Outbound.

For the outbound web service actions for AS2, use these settings:

For the outbound web service actions for AS2, set these attributes:

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.

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

You can test if the setup of a specific inbound definition or of all inbound definitions delivers the expected result. usually, you do so for a test file.

During the test, these checks are done:

• Is the selected test file found? Or if no test file is defined, are the files in the general storage location found?
• Is a matching file distribution definition found in the selected inbound definition? Or if no inbound definition is selected, is a matching file distribution definition found in any of the inbound definitions?

The test result is shown in an info message.

Note: During the test, no files are moved from the general storage location. Also, no renaming of the files is applied.

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.

To test an inbound definition, make sure a test file is available in the Working folder as defined by the connector of the inbound definition.

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