Page History
Excerpt |
---|
Webservice debuggerBlueriq |
offers the capability of debugging what happens during a webservice invocation, both for SOAP and REST services. This functionality is only available when the development tools are active (i.e. |
has to be active) and a custom header is included in the webservice request to |
represent logpoints, referring to parts of the model. During execution of the model, a profile dump in XML is written to a special debug log file whenever a logpoint is hit. A basic example is as follows:
The presence of |
the |
a logpoint that triggers whenever the service call named "Example" within flow "MyStartFlow" executes. Multiple logpoints can be activated by comma-separating them, as well as including the header multiple times:
The above example activates three logpoints. The profile XML is written to a dedicated debugger log file, separate from the regular log file. It is stored in the same location as the regular log, but suffixed |
with |
|
debugger file is only active when a log file has been configured |
Logpoints
Flow nodes
The development dashboard allows you to open the debugger log from the left sidebar (which is typically collapsed) using the "View debugger log" button.
Debugger idsThe debugger id is an identifier that corresponds with a part of the model. Debugger ids are case-insensitive. The runtime supports the following list of debugger ids: Flow nodesEach node in the flow is considered as a potential logpoint, according to the following naming convention:
A logpoint for a flow node is triggered before the flow node is evaluated. Setting a logpoint at the start of a flow can be accomplished by using the debugger id of the node that is linked from the start node, as the start node itself does not have a logpoint. Multiple occurrences of a service-call/function-call/subflow within the same flow cannot be distinguished, as the debugger id is only determined based on the referenced name.
Data mapping Each direction of a data mapping have their own ids, with the possibility to log the source profile before the mapping executes and the target profile before and/or after the mapping has executed.
Domain schema & schema setsReading XML and JSON data into the profile is done through either a domain schema or a schema set. The following ids can be used to log the profile after the profile has been populated from the data:
|
Logging configuration
The runtime includes default logging configuration such that debugger logging is redirected to a separate debugger log, according to the following Logback configuration snippet:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<configuration>
<!-- ... -->
<!-- Debugger logger -->
<springProfile name="development-tools">
<if condition="isDefined("logFile")">
<then>
<logger additivity="false" level="INFO" name="com.blueriq.debugger">
<appender-ref ref="DEBUGGER"/>
</logger>
<appender class="ch.qos.logback.core.rolling.RollingFileAppender" name="DEBUGGER">
<encoder>
<pattern>
<![CDATA[%d{yyyy-MM-dd HH:mm:ss.SSS} userId="%X{userId}" project="%X{projectName}:%X{projectVersion}" [trace=%X{traceId:-},span=%X{spanId:-}] - %msg%n%n]]>
</pattern>
</encoder>
<file>${logFile}.debugger.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- rollover daily -->
<fileNamePattern>${logFile}-%d.debugger.log</fileNamePattern>
<!-- retain at most 7 days of debug logging -->
<maxHistory>7</maxHistory>
</rollingPolicy>
</appender>
</then>
</if>
</springProfile>
</configuration> |
In a custom runtime, it may be necessary to realize a similar configuration to redirect log entries from the com.blueriq.debugger
logger to a dedicated file.