Troubleshooting integration

When running an integration, issues can occur at several moments and places in the integration. This flow is an example of how and where to search for the source of integration issues.

Usually, if issues occur in an integration, you start your investigation at the message. And from there, if required, you can extend your investigation to other parts of the integration, such as the connections (as defined by the applicable message connectors), data queries (as defined by the applicable message documents), and triggers.

If issues occur, and you use:

Staging, you usually start your investigation at the staging journal.
Web service actions, you usually start you investigation at the web service action history.
Data synchronization, you can also investigate the data synchronization log and the outbound queue.

Activities

Name	Responsible	Description
Troubleshoot staging issues	Application Consultant	In Connectivity studio, you can use the staging concept to validate data in an intermediate area before it is further processed. This is usually used to import data into D365 FO from another system. In this way, you can validate the data before it is written into the D365 FO database. Use the staging journal to monitor the data validation. One predefined generic staging journal table is available for Connectivity studio: 'BisStagingBufferOrderJournal'. Usually, you only use this generic table if you have a limited number of simple integrations. So, integrations that integrate one smaller table. If you want to use staging for integrations with multiple tables or bigger tables, you are advised to develop a customized staging journal table instead of using the generic staging journal table. This flow explains how to monitor staging journals using the generic staging journal table. You can monitoring a customized staging journal table in a similar way. If the validations are not met, errors or warnings are reported in the staging journal. Usually, issues as shown in the staging journal are data related. If it appears that issues are not data related, extend your issue investigation to the messages that import data to or export data from the the staging journal.
Troubleshoot web service issues	Application Consultant	When a web service action doesn't run successfully, you can troubleshoot the web service action. You have several options to troubleshoot a web service action. You can, for example: Validate the web service action setup. Test an outbound web service action. Test an inbound web service action.
Troubleshoot message issues	Application Consultant	You can review and analyze the history of message runs that have run with errors. You can investigate these errors and take the appropriate actions to solve the errors. If the errors are solved, you can re-run the message run. To monitor the message history, use the Connectivity studio integration operations workspace.
Troubleshoot connector issues	Application Consultant	When a message does not run successfully, you can troubleshoot the related source connector and target connector. You have several options to troubleshoot a connector. You can, for example: Validate the connector setup. Solve a connection issue for an Azure file storage connector. Common issues on the connector are: Connection issue to folder for Azure file storage connector: Test the connection. To do so, on the Connectors page, in the Action Pane, on the Development tab, click Test connection. Verify the connector properties: Share, User name, Password. Verify the folder setup, like Work and Archive. Do these folders exist in the file system? Are these folders defined correctly on the connector? You can use the File explorer to quickly access and view the share as defined for the Azure file storage connector. To open the File explorer, on the Connectors page, in the Action Pane, on the Development tab, click File explorer. Connection issue on Database connector: Test the connection. To do so, on the Connectors page, in the Action Pane, on the Development tab, click Test connection. Verify the Azure Service Bus settings on the connector, in case of an ODBC connection. Verify the ODBC data source settings on the connector, in case of an ODBC connection. If applicable, verify the direct SQL settings on the connector.
Troubleshoot document issues	Application Consultant	When a message does not run successfully, you can troubleshoot the related source document and target document. When a document is used in a message run, based on the document setup, a query is created that reads the data. You have several options to troubleshoot a document. You can, for example: Validate the document setup. Test a document. Common issues on the document are: No files are read from the Work folder: Check the read settings on the document header. Missing data in export: Verify the setting of these fields on the record setup: 'Join mode' and 'Combine with parent record'. For more information, refer to this blog. No records are processed: Verify the range as set up for document records.
Troubleshoot trigger issues	Application Consultant	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 run a project, message or web service in batch, usually in recurring mode. If the message or web service does not run at all, the batch server can be down. Custom code You can run a message from custom code. If you use custom code to run a message, and the message does not run, probably, the custom code is not right. You need a developer to check and repair the custom code.
Troubleshoot outbound queue issues	Application Consultant	For messages and web service actions, you can use table events to track data changes. You can define, for each table, which table events are logged. The table events are logged in the data synchronization log. On processing the data synchronization log, based on the logged events, records are added to the outbound queue. On processing the outbound queue, for each record, the related message or web service action is run to export the applicable data. When the outbound queue is processed, errors can occur. You can reset the outbound queue record status to New. For example, when running a web service action, the external web service can be down. As a consequence, running the related outbound queue records fails and these get the status Error. When the issue is solved, you can reset the status to New, And the next time the outbound queue is processed, these records are processed again. This flow explains how to: View the outbound queue. Reset the outbound queue to rerun outbound queue records. Usually, you do so in case of any issue. To monitor the outbound queue, use the Connectivity studio Integration operations workspace. If the outbound queue does not run at all, the batch server can be down.
Troubleshoot data synchronization processing issues	Application Consultant	For messages and web service actions, you can use table events to track data changes. You can define, for each table, which table events are logged. The table events are logged in the Data synchronization log. This topic explains how to monitor the data synchronization log. If table events are not logged in the Data synchronization log as expected, you can check the data synchronization setup for your message or outbound web service action. If logged events in the data synchronization log are not processed to the outbound queue, you can: Check if processing the data synchronization log is set up correctly. Test the data synchronization log processing. If processing the data synchronization log does not run at all, the batch server can be down.

See also

Troubleshooting messages

Provide feedback