Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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
languagetext
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
languagetext
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 debugger file is only active when a log file has been configured using the logging.file.name  property. The development dashboard allows you to open the debugger log from the left sidebar (which is typically collapsed) using the "View debugger log" button.


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 typeLogpoint name
Service callflow:FlowName/service-call:ServiceCallName 
Function callflow:FlowName/function-call:FunctionCallName
Pageflow:FlowName/page:PageName
End nodeflow: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.  

Info
titleRepeated 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.

OccurrenceLogpoint name
Forward, source profiledata-mapping:fwd_DataMappingName/before
Forward, target profiledata-mapping:fwd_DataMappingName/after
Backward, source profiledata-mapping:bwd_DataMappingName/before
Backward, target profiledata-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:

OccurrenceLogpoint name
Domain schemadomain-schema:DomainSchemaName/parsed
Schema setschema-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:

Code Block
languagexml
titleLogback configuration
linenumberstrue
<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.