Page History
Webservice debugger
Blueriq 16.10 introduces 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. the Spring profile development-tools 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:
Code Block | ||
---|---|---|
| ||
GET http://example.com/server/rest/studio-calculatorbaars-mycalculatorbaars/0.0-Trunk/BAARS?X=123&Y=2&Operator=plus Accept: application/json Blueriq-Debugger-Logpoints: flow:MyStartFlow/service-call:Example |
The presence of the Blueriq-Debugger-Logpoints
header activates 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:
Code Block | ||
---|---|---|
| ||
GET http://example.com/server/rest/studio-calculatorbaars-mycalculatorbaars/0.0-Trunk/BAARS?X=123&Y=2&Operator=plus Accept: application/json Blueriq-Debugger-Logpoints: flow:MyStartFlow/service-call:Example, flow:MySubflow/subflow:AnothterSubflow Blueriq-Debugger-Logpoints: flow:AnothterSubflow/service-call:Example |
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 .debug.log
. Please note that the debug file is only active when a log file has been configured using the logging.file.name
property.
Logpoints
A logpoint is an identifier that corresponds with a part of the model. Logpoints are case-insensitive. The runtime supports the following list of logpoints:
Flow nodes
Each node in the flow is considered as a potential logpoint, according to the following naming convention:
Flow type | Logpoint name |
---|---|
Service call | flow:FlowName/service-call:ServiceCallName |
Function call | flow:FlowName/function-call:FunctionCallName |
Page | flow:FlowName/page:PageName |
End node | flow:FlowName/end:EventLabel |
A logpoint for a flow node is triggered before the flow node is evaluated. Setting a logpoint at the start of a flow corresponds with using the logpoint of the node that is linked from the start node, as the start node itself does not have a logpoint.
Info | ||
---|---|---|
| ||
If a subflow has a repeat expression, its logpoint will always execute exactly once. If each iteration of the subflow should be logged, then a logpoint has to be placed on the subflow's start or end node. |
Logging configuration
The runtime includes default logging configuration such that debugger logging is redirected to the debug 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}.debug</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- rollover daily -->
<fileNamePattern>${logFile}-%d.debug.log</fileNamePattern>
<!-- retain at most 3 days of debug logging -->
<maxHistory>3</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.