Testing workflows

Mention ETW Tracking for testing

 

Test	Description
Host Test
Activity Test
Test Utils

Workflow activity logging

Tracking participants

The Workflow Host is equipped with three different tracking participants which log activities in different places.

• WorkflowLogTrackingParticipant logs entries in wzp_workflow_log.
• EWTTrackingParticipant logs events which can be monitored in the event viewer, if it is enabled.
• SjDebugTrackingParticipant logs entries in sjDebug.

The tracking participant can be enabled/disabled in the web config file in the Scanjour.Workflow4.Host.Settings section. Only the first tracking participant is enabled by default. The two other participants are for troubleshooting.

<Scanjour.Workflow4.Host.Settings>

<setting name="EnableSjDebugTrackingParticipant" serializeAs="String">

<value>False</value>

</setting>

<setting name="EnableLogTrackingParticipant" serializeAs="String">

<value>True</value>

</setting>

<setting name="EnableEtwTrackingParticipant" serializeAs="String">

<value>False</value>

</setting>

</Scanjour.Workflow4.Host.Settings>

Tracking can be disabled for individual workflows for various reasons (for example, workflows never causing any problems or very "noisy" workflow). This is done in the same section of the web.config file. In the example below, all logging of workflows whose typename begins with TestPackage. and Test has been disabled.

<Scanjour.Workflow4.Host.Settings>

<setting name="DisableLoggingInWorkflows" serializeAs="Xml">

<value>

<ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<string>TestPackage.</string>

<string>Test.</string>

</ArrayOfString>

</value>

</setting>

</Scanjour.Workflow4.Host.Settings>

To prevent the wzp_workflow_log from growing infinitely, an oracle batch job is installed that will delete log entries for completed workflows after 3 days – only leaving terminated and faulted workflows in the table. By default, everything possible is being logged. However, you can tune the logging on package level and on workflow level by defining a tracking profile to the package in the PackageDefinition section or the Workflowdefinitionsection.

The tracking profile is an XML description which defines what must be logged:

<PackageDefinition>

<Name>Basis</Name>

<Version>3.1.0.0</Version>

<Description>Basic submission</Description>

<TrackingProfile>Workflows\Basic.xml</TrackingProfile>

</PackageDefinition>

<WorkflowDefinition>

<Version>3.1.0.0</Version>

<XamlFile>Workflows\Submission.xaml</XamlFile>

<FormGuid>{709f3330-9190-4cc9-a7d5-0b30edef0e6e}</FormGuid>

<AccessCode></AccessCode>

<Standard>J</Standard>

<TrackingProfile>Workflows\Sparse.xml</TrackingProfile>

<WorkflowDefinition>

Tracking Profiles

A tracking profile controls the 7 different tracking records which are supported:

WorkflowInstanceRecords

Reports changes in the workflow instance state, for example: Started, Idle, Unloaded, Resumed.

ActivityScheduledRecords

Reports about every activity being scheduled for execution in the workflow. You may need to limit the reporting of scheduled activities because complex workflows may produce a lot of entries.

ActivityStateRecords

Reports the state of an executing activity, including the arguments and variables value in the activity. These records may be very useful for understanding what is going on in a workflow. However, you may need to limit which activities report ActivityStateRecords.

BookmarkResumptionRecords

Reports the bookmarks resumed on the workflow. These are important to understand when and why a workflow is resumed.

CancelRequestedRecords

Informs about activities being canceled, for example, a delay activity being canceled.

FaultPropagationQueries

Reports about unexpected errors in activities and the call stack in the workflow. This is important when you investigate the nature of an error.

CustomTrackingRecords

Reports information the developer of the activities has deemed important in order to understand what the activity is doing and why. This is always the result of a careful consideration from the developer of the activity. The following tracking profile is a tracing profile that tracks everything in a workflow. The * indicates that everything must be tracked.

<?xml version="1.0" encoding="utf-8"?>

<tracking>

<profiles>

<trackingProfile name="Basic">

<workflow activityDefinitionId="*">

<workflowInstanceQueries>

<workflowInstanceQuery>

<states>

<state name="*"/>

</states>

</workflowInstanceQuery>

</workflowInstanceQueries>

<activityScheduledQueries>

<activityScheduledQuery activityName="*" childActivityName="*" />

</activityScheduledQueries>

<activityStateQueries>

<activityStateQuery activityName="*">

<states>

<state name="*"/>

</states>

<arguments>

<argument name="*"/>

</arguments>

<variables>

<variable name="*"/>

</variables>

</activityStateQuery>

</activityStateQueries>

<bookmarkResumptionQueries>

<bookmarkResumptionQuery name="*" />

</bookmarkResumptionQueries>

<cancelRequestedQueries>

<cancelRequestedQuery activityName="*" childActivityName="*" />

</cancelRequestedQueries>

<faultPropagationQueries>

<faultPropagationQuery faultSourceActivityName="*" faultHandlerActivityName="*" />

</faultPropagationQueries>

<customTrackingQueries>

<customTrackingQuery name="*" activityName="*" />

</customTrackingQueries>

</workflow>

</trackingProfile>

</profiles>

</tracking>

Below is a sample tracking profile which only tracks certain activities in a submission workflow, which disables all ActivitySchedulesRecords and limits the activities reporting ActivitStateRecords.

<?xml version="1.0" encoding="utf-8"?>

<tracking>

<profiles>

<trackingProfile name="Basic">

<workflow activityDefinitionId="*">

<workflowInstanceQueries>

<workflowInstanceQuery>

<states>

<state name="Started"/>

<state name="Unloaded"/>

<state name="Resumed"/>

<state name="Completed"/>

<state name="Faulted"/>

</states>

</workflowInstanceQuery>

</workflowInstanceQueries>

<activityScheduledQueries>

</activityScheduledQueries>

<activityStateQueries>

<activityStateQuery activityName="SequentialUserTask">

<states>

<state name="Executing"/>

</states>

<arguments>

<argument name="*"/>

</arguments>

<variables>

<variable name="*"/>

</variables>

</activityStateQuery>

<activityStateQuery activityName="ParallelUserTask">

<states>

<state name="Executing"/>

</states>

<arguments>

<argument name="*"/>

</arguments>

<variables>

<variable name="*"/>

</variables>

</activityStateQuery>

<activityStateQuery activityName="UserTask">

<states>

<state name="Executing"/>

</states>

<arguments>

<argument name="*"/>

</arguments>

<variables>

<variable name="*"/>

</variables>

</activityStateQuery>

<activityStateQuery activityName="SimpleUserTask">

<states>

<state name="Executing"/>

</states>

<arguments>

<argument name="*"/>

</arguments>

<variables>

<variable name="*"/>

</variables>

</activityStateQuery>

<activityStateQuery activityName="UserTaskTimerActivity">

<states>

<state name="Executing"/>

</states>

<arguments>

<argument name="*"/>

</arguments>

<variables>

<variable name="*"/>

</variables>

</activityStateQuery>

<activityStateQuery activityName="ValidateUserTaskActivity">

<states>

<state name="Executing"/>

</states>

<arguments>

<argument name="*"/>

</arguments>

<variables>

<variable name="*"/>

</variables>

</activityStateQuery>

</activityStateQueries>

<bookmarkResumptionQueries>

<bookmarkResumptionQuery name="*" />

</bookmarkResumptionQueries>

<cancelRequestedQueries>

</cancelRequestedQueries>

<faultPropagationQueries>

<faultPropagationQuery faultSourceActivityName="*" faultHandlerActivityName="*" />

</faultPropagationQueries>

<customTrackingQueries>

<customTrackingQuery name="*" activityName="*" />

</customTrackingQueries>

</workflow>

</trackingProfile>

</profiles>

</tracking>

Defining a tracking profile suiting a specific workflow requires knowledge about what the workflow does and where interesting information about the execution is located. The syntax is easy to learn, and it is described both in books and on the internet. A lecture on how to specify the various queries is not in the scope of this description. More information is available at http://msdn.microsoft.com/en-us/library/ee513989(v=vs.110).aspx.

Other tracking records

A number of other tracking records appear in the log, and they cannot be controlled from a tracking profile. The reason is that the records inform about events which must not be hidden from the responsible person.

HostTrackingrecords

Informs about workflows that have been terminated by a user, or which end because of errors inside the workflow.

WorkflowInstanceTerminateRecords

Informs about the reason why a workflow is terminated.

WorkflowInstanceUnhandledexceptionRecord

Informs about unhandled exceptions in the workflow.