Depending on how you run an outbound web service integration, you can monitor the integration on these levels:
Name | Responsible | Description |
---|---|---|
Monitor project history |
Application Consultant |
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. |
Monitor task history |
Application Consultant |
Usually, you run a task by running the related project. However, you can also run a single task, for example, for testing purposes. |
Monitor web service action history |
Application Consultant |
When a web service action is run, you can view the web service history. The web service history shows, for example, the:
Possible issues can occur, for example, in the:
|
Monitor message history |
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.
|
Monitor file history |
Application Consultant |
You can review and analyze the file history of message runs for messages with an Azure file storage connector. All actions that are done to the related file, are registered in the file history.
Registered file actions are the:
You can monitor the file history from the Connectivity studio Integration operations workspace.
|
Monitor outbound queue |
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:
To monitor the outbound queue, use the Connectivity studio Integration operations workspace.
If the outbound queue does not run at all, the batch server can be down.
|
Monitor data synchronization log |
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. 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:
If processing the data synchronization log does not run at all, the batch server can be down. |