You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
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:
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:
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 .debugger.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. Multiple occurrences of a service-call/function-call/subflow within the same flow cannot be distinguished, as the logpoint identifier is only determined based on the referenced name.
Repeated subflows
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 a node within the subflow itself.
Data mapping
Each direction of a data mapping have their own logpoints, with the possibility to log the source profile before the mapping executes and the target profile after the mapping has executed.
Occurrence | Logpoint name |
---|---|
Forward, source profile | data-mapping:fwd_DataMappingName/before |
Forward, target profile | data-mapping:fwd_DataMappingName/after |
Backward, source profile | data-mapping:bwd_DataMappingName/before |
Backward, target profile | data-mapping:bwd_DataMappingName/after |
Domain schema & schema sets
Reading XML and JSON data into the profile is done through either a domain schema or a schema set. The following logpoints can be used to log the profile after the profile has been populated from the data:
Occurrence | Logpoint name |
---|---|
Domain schema | domain-schema:DomainSchemaName/parsed |
Schema set | schema-set:DomainSchemaName/parsed |
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:
<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.