Advanced queries

Process incorporates its own XML description language of views. We use this language to build the workflow or data universe, but it is also what allows us to query the Process data.

If simple design of these XML files do not specifically request additional documentation, Process incorporates a number of advanced filtering possibilities and sometimes we can be caught out when to use them.

XML standard of views

Here’s a sample XML description of a Process view:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<definition security="false" type="activity" catalogType="0" catalog="Test1" name="TODO"> 
   <filters> 
       <fieldgroup operator="AND"> 
           <field value="$User" operator="equals" name="$activity.fulfiller"/> 
           <field value="STARTED" operator="equals" name="dyn_Status"/> 
           <field value="Test1" name="sys_WorkflowContainer"/> 
       </fieldgroup> 
   </filters> 
   <view itemsPerPage="10" sortAscending="true" sortBy="dyn_CreationDate"> 
       <column name="sys_Reference"/> 
       <column name="sys_Title"/> 
       <column format="datetime" name="sys_CreationDate"/> 
       <column name="dyn_CurrentStage"/> 
       <column maxElements="5" name="dyn_CurrentActors"/> 
       <column format="datetime" name="dyn_CreationDate"/> 
   </view> 
</definition>

This XML corresponds to an XML description of a “TODO” standard view. You can see that in this XML, some filters are already advanced, for example $activity.fulfiller.

Info

The ’label’ attribute of the node ‘column’ allows you to force the wording of a column.

The types of objects queryable

Process can retrieve different types of Workflow objects:

  • Default type: treatment
  • activity: it’s task instance (ITaskInstance) of SDK
  • resource: type used for the data universe for example.

These types are defined in the node definition (see in the example above).

The constraints in the “field” node

This section will focus on filters in views, specifically the field nodes.

Available operators

The filter can include a number of operators (attribut operator):

Operator Description
equals Is equal to
notEquals Is not equal to
startsWith Begin with
endsWith End by
contains Contains in
notContains Not contains in
greaterThan Is greater than
greaterOrEquals Is greater than or equal to
lowerThan Is lower than
lowerOrEquals Is lower than or equal to

The name attribute

In standard, the attribute “name” is assigned with the system name of the properties need to be filtered. However, there are systems names can be used for tests.

All standard system columns can already be used:

  • sys_Reference
  • sys_Title
  • sys_Creator
  • sys_Addressee
  • sys_ModifiedBy
  • sys_CreationDate
  • sys_ModificationDate
  • sys_MaxDuration
  • sys_CurrentActors
  • sys_PastActors
  • sys_AllPastActors
  • sys_CurrentSteps
  • sys_Version

Furthermore, there are system properties that are not included to the basis but that can still be used in filtering:

Propriété Description
sys_Catalog Process group’s system name
sys_WorkflowContainer Process’s system name
sys_Workflow Process version’s system name
sys_ResourceDefinition Resource template’s system name
sys_WaitingActors
sys_Today
sys_Status STARTED, PAUSED, TERMINATED, ABORTED

There are also dynamic keys, related to taskinstances (“activity” type):

Key Description
dyn_Status
dyn_Delay Completion time granted for the current task
dyn_CurrentStage current task task
dyn_CurrentActors current actor
dyn_CreationDate Creation date of the current task
dyn_MaxDuration

Formulas

  • $User : this formula can be used to perform a test on the connected user running the view. Automatic introspection can be performed under this item 
      <field name="fieldLogin" operator="equals" value="$User.login" />
  • $activity.fulfiller : used to test the current operator on a stage 
      <field name="$activity.fulfiller" operator="equals" value="$User" />
  • $Document : if the view is integrated into a workflow document or data universe (or in the case of a selector using a view in a document), it is possible to dynamically filter with the values of the current document 
      <field name="Column_1" value="$Document.Value('Field_1')"/>

Filtering property-property

Suppose we have to show only documents where the value of the field “Field1” is equal to the value of the field “Field2”. Here’s how we might proceed:

<field name="Champ1" field="Champ2"/>

Source : https://wiki.myvdoc.net/xwiki/bin/view/Dev+Floor/AdvancedRequestInViews