Setting Up QPR System to Use Workflows

The following system settings are needed by the Workflow:

•The value of the EnableObjectChangeEventPropagation key in the QPR Settings section of QPR_Servers.ini must be 1.

•A system administrator user account named "qprscript" must be available on the QPR Foundation Server. The account must also have the "Metrics User" and "QPR Modeling Viewer" licenses enabled. This account is used to do all the QPR Web Services Foundation modifications.

•A customized action type.

•SMTP server needs to be defined for the Workflow notifications to be sent.

 

Workflow Definition

To be able to use workflows in QPR Portal, they need to be defined. The workflow definition is a Windows Workflow Foundation based XAML workflow definition done in Microsoft Visual Studio 2010. To use the workflow XAML in QPR workflows, the XAML code needs to be copy-pasted into the Definition field in the QPR Portal 'Create Workflow' or 'Modify Workflow' view.

 

The workflow definition must have the following arguments:

 

<x:Property Name="Context" Type="InArgument(qwb:IWorkflowContext)" />

This argument is used internally by Qpr.WebServies.Workflows.ActivityLibrary. The argument provides custom activities information about the context in which the workflow is being invoked.

 

<x:Property Name="ObjectId" Type="InArgument(x:String)" />

This argument contains the full id of the target object to which the workflow ticket being invoked is attached to.

 

<x:Property Name="TicketId" Type="InArgument(x:String)" />

This argument contains the full id of the workflow ticket being invoked.

 

<x:Property Name="UserId" Type="InArgument(x:String)" />

This argument contains the full id of the user who triggered this invocation. If invocation was triggered "automatically" (due to target object modification), this user id tells who initially started the changes that triggered this invocation. If invocation was triggered "manually" either via buttons in QPR Portal UI or via QPR WSF method call, the user id contains the id of the triggering user.

 

<x:Property Name="TriggerParameter" Type="InArgument(x:String)" />

This argument contains the string given as parameter when the ticket was triggered (if parameter was editable where the triggering occurred). If the ticket was triggered "automatically", this contains any of the following values depending on the reason for the invocation:

"target created" -> target object (and the ticket) was just created.

"target changed" -> target object was modified

"target deleted" -> target object was just deleted (workflow ticket object will also be deleted after this invocation finishes)

 

<x:Property Name="Status" Type="InOutArgument(scg:IDictionary(x:String, x:String))" />

This argument contains key-value pairs of the status-attribute of the workflow ticket. This can be used as a storage for ticket's internal state. Any modifications made to this argument are copied back to workflow ticket object after the invocation finishes. It should be noted that making modifications to this argument is much more efficient than making modifications e.g. to the target object itself, thus it is always recommended to avoid storing workflow-related information to e.g. workflow target object and storing them directly to this argument. Note that "keys" used in dictionary should always be valid "script names".

 

 

Accessing QPR Data from Workflows

Qpr.WebServices.Workflow.ActivityLibrary.dll available in <path to QPR installation>/WebServices/bin directory contains activities specifically designed to make it easier to access information stored into QPR system from workflows. Most of the functionality available in QPR Web Services Foundation is in a way or another made available also via these custom activities. In order to use the custom activities in Qpr.WebServices.Workflow.ActivityLibrary.dll, it must be registered as a reference to the project in which the xaml files are being modified, e.g. by right-clicking on the xaml editor toolbox, selecting "Choose items...", selecting "System.Activities Components" page and browsing the dll from there. Custom activities include:

 

Non-QPR Web Services Foundation related activities for easily accessing dictionaries such as Status workflow argument

•ClearDictionary

•ExistsInDictionary

•FindInDictionary

•RemoveFromDictionary

•SetToDictionary

 

Target settings/style related

•AddAttributeStyle

•GetActiveAttributeStyles

•RemoveAttributeStyle

 

Getting and setting object attributes

•GetAttributeValue

•SetAttributeValue

•GetAttributeValues

•SetAttributeValues

•GetBinaryData

•SetBinaryData

•GetPortalUrl

 

Modifying QPR object model

•CreateCopy

•CreateObject

•DeleteObject

•ModifyReference

 

Miscellaneous other activities

•GetWorkflowTicketForObject

•PerformObjectOperation

•SendEmail

•WriteLogEntry

 

It should be noted that all activity attributes (not even required ones) aren't directly editable in the xaml workflow editor (mostly) due to xaml limitations, since the xaml editors don't support object types that use generics. In these cases, attributes must be modified in the Properties view of Microsoft Visual Studio (e.g. Result attribute of GetAttributeValues).