Diagnosing Connectors errors

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > System maintenance and monitoring > Environment settings and administration > Management Console > Diagnosing errors in integrated systems >

Diagnosing Connectors errors

Overview

When configuring Connectors in Bizagi, you can rely on several features for error control and diagnostics.

One of these features is the use of Traces whenever you detect there is an issue with the execution of the Connector, and you want to retrieve further details.

 

Connector traces

When you are debugging a Connector execution (in Development environments) or want to retrieve further details about a failed execution, you can turn on the External connectors traces.

 

Connectors_trace_all

 

note_pin

Connectors traces can be enabled anytime, but we strongly recommend that you enable them temporarily when you need them and disable them again when you are done.

Changes in this configuration will probably require a reset in your Work portal services.

 

Enabling these traces is useful to track down, after an error in the application, the exact point where the error occurred. There are five points where details are logged and you can diagnose whether there is a problem when executing your Connector, or when transformations were being applied to the information.

 

Types of traces

The following traces are logged:

 

Chronological order

Trace type

Description

1

Inputs

Writes a JSON file with the inputs sent to the Connector before the execution of its logic.

Its name has the following convention:

[timestamp]_[case_identifier]_IN0_[Connector name]_[action name].json

The timestamp is set as yyyyMMddHHmmss.

2

Inputs transformed

Writes a JSON file with the inputs sent to the Connector after the execution of its logic.

Its name has the following convention:

[timestamp]_[case_identifier]_IN1_[Connector name]_[action name].json

The timestamp is set as yyyyMMddHHmmss.

3

Outputs

Writes a JSON file with the outputs received from the external system before any transformation done by Bizagi.

Its name has the following convention:

[timestamp]_[case_identifier]_OU0_[Connector name]_[action name].json

The timestamp is set as yyyyMMddHHmmss.

4

Outputs transformed

Writes a JSON file with the outputs received from the external system after all transformations done by Bizagi.

Its name has the following convention:

[timestamp]_[case_identifier]_OU1_[Connector name]_[action name].json

The timestamp is set as yyyyMMddHHmmss.

5

Connector logic

Writes a .log file that stores all the LOG commands found during the Connector logic execution. More information about these commands can be found in this article.

Its name has the following convention:

[project name]-bz-ctrl.log

 

Additional measures for error control

We strongly recommend that you define the service's expected time, so that you can explicitly assign both: a timeout for the service, and a logging threshold.

These properties can be set at the specific interface's properties:

The logging threshold parameter for interfaces writes a log to alert you about interfaces whose invocations are delaying more than expected. In this way, you can perform early diagnostics on your Web service and any additional variables affecting its performance.

The timeout thrown in a service invocation is due to the service delaying more than its timeout definition.

For a service invoked in an asynchronous activity, the timeout definition is taken from the minimum time set from either: the timeout property set for the asynchronous task, or the timeout property set for the specific interface (through interfaces administration in the systems module).

 

How to trace your Web service

In the following steps, we illustrate how to use the interface invocations trace to detect and diagnose issues in external Web services invocations.

 

1. Detect the error

As a most common practice, your Web service may be invoked from an Asynchronous Activity.

Should the invocation fail, you can review error details from the Admin menu, in the Asynchronous Activities Console option.

 

WSTrace_console

 

2. Setup the trace configuration

Through the Tracing options, enable all the Interface traces.

 

3. Re-run the interface invocation (to log the error detail)

Retry the invocation of the interface to have a log with details on the faliure.

 

Browse into your Bizagi Server and into the Connectors traces folder (in this .NET example, this location would be C:\Bizagi\Projects\[project_name]\Temporary\Connectors).

 

You may not have all files recorded.

For example, if an error occurs in the transformation of inputs from Bizagi, only the first file (Inputs) appears because the error occurred before the transformation was made.

 

4. Validate the traces to identify the error

Review information contained in the traces.