Overview
When configuring ECM integration in Bizagi, you may rely on the use of traces for error control and diagnostics.
Traces let you detect whenever there is an issue with the ECM integration and retrieve further detail.
ECM traces
Whenever you are debugging an ECM integration (in Development environments) or whenever you wish to retrieve further detail about a failed integration, you may choose to turn on the ECM traces.
|
Keep in mind that ECM traces can be enabled anytime, but it is strongly recommended to enable them temporarily only when needed (and afterwards, disable them). Changes in this configuration will most likely require to run the Work Portal again. |
Enabling these traces is useful to track down, after an error during the integration, the exact point where said error has happened. There are three points where detail is logged, and you may diagnose if there is a problem with the integration with your ECM system.
Types of traces
The following traces are logged with a chronological order, as detailed in the table below.
Chronological order |
Trace type |
Description |
|---|---|---|
1 |
Log |
Leaves a log file with the error log during the integration with your ECM system. Its name has the following convention: [timestamp]_ECM.log Note that timestamp is set as YYYYMMDD. |
2 |
Request |
Leaves an xml-formatted file with the message sent to the ECM system. Its name has the following convention: [timestamp]_[OperationID]_[ServiceName]_request.log Note that timestamp is set as YYYYMMDD. |
3 |
Response |
Leaves an xml-formatted file with the response associated to the same OperationID and ServiceName sent by the ECM system. Its name has the following convention: [timestamp]_[OperationID]_[ServiceName]_response.log Note that timestamp is set as YYYYMMDD. |
Last Updated 2/6/2024 10:27:13 PM