This chapter discusses the following:
One of the first things you have to consider, when you start making a concept for a workflow, is the number and organization of scopes. If you would like to refresh your knowledge about scopes, please refer to the introduction to scopes.
Of course you can always modify the workflow in later steps, but this might have implications for existing tickets, views, and reports. This is particularly significant if the workflow is used in a production environment.
Consider the following points when setting up the basic structure of a workflow:
A global scope is a scope which contains all other scopes of the workflow. You might want to use such a global scope because some processes require reactions to events during the entire process. Those events are implemented using triggers which are attached to the global scope. For example, if you want to supervise for the entire process, if an e-mail has been received, you attach a mail trigger (see section Mail Triggers) to the global scope. All sub-scopes of the global scope inherit the sensitivity to this trigger. If the e-mail should only be supervised for a sub-scope, you can attach the mail trigger to this sub-scope.
The same applies to all kinds of triggers, i.e., business event triggers (see section Business Event Triggers) and time triggers (see section Time Triggers).
The START node always has to be positioned outside the global scope!
Figure 171: ConSol CM Process Designer - Workflow with global scope
Please keep in mind that you can always use triggers in inner scopes which will then consume the event (see section Firing Order of Business Event Triggers in Hierarchical Scopes as an example for business event triggers). For example, if you would like to use a mail trigger in the entire process in the global scope but you need a certain reaction of the ticket in the Finished scope, you can use a mail trigger which is attached to the Finished scope.
An alternative way to construct a workflow is to use three or more main scopes:
The following picture shows an example for a workflow which has been built according to this principle.
Figure 172: ConSol CM Process Designer - Workflow with three types of main scopes
The best position of the START Node (see section Workflow Components: START Node) depends on the use of triggers in the following scope. If time triggers are used in the first scope, where tickets are forwarded after the start node, the start node should be placed outside the scope. In case the start node is placed inside the first scope, the time trigger might not be initialized correctly. So place the start node in the default scope.
Figure 173: ConSol CM Process Designer - Position of START node
For scripts, which are used over and over again in workflow activity and/or precondition scripts, it might be better to store them in the Script section of the Admin Tool and call them from the workflow script.
Figure 174: Calling a script directly in the workflow
Figure 175: Calling an Admin Tool script from a workflow activity
We would neither recommend to always use this method nor would we advise against it. We will illustrate the advantages and disadvantages of this approach and you can then decide for yourself where in your system you want to apply it.
The advantages of storing workflow scripts in the Admin Tool are the following:
The disadvantages of storing workflow scripts in the Admin Tool are the following:
Admin Tool scripts which are used in the workflow have to be of type Workflow. An Admin Tool script is always called from the workflow using the interface ScriptProvider.
def scriptProvider = scriptProviderService.createDatabaseProvider("scriptName.groovy")
def r = scriptExecutionService.execute(scriptProvider)
Code example 94: Calling an Admin Tool script from the workflow (only way in CM versions 6.10.4 and older, in CM 6.10.5 and up still available)
// Create the scriptProvider for the required Admin Tool script, here "scriptName.groovy"
def scriptProvider = scriptProviderService.createDatabaseProvider("scriptName.groovy")
// Define a HashMap with the key-value pairs which you would like to pass to the Admin Tool
def params = [ "templateName": "newCustomer" ]
// Execute the script. The passed parameters are available in the Admin Tool script. In the
// example, the variable templateName does not have to be defined in the Admin Tool script
// but it is present based on the definition in the passed HashMap.
// The variable r will contain the return value of the script or Null if there is no return
// value
def r = scriptExecutionService.execute(scriptProvider, params)
Code example 95: Calling an Admin Tool script from the workflow with use of parameters (only way in CM versions 6.10.4 and older, in CM 6.10.5 and up still available)
scriptExecutionService.execute("MyScript")
Code example 96: Calling an Admin Tool script from the workflow (only CM versions 6.10.5 and up)
Since the object workflowApi (see section workflowAPI) is not available in the Admin Tool scripts, you will have to find other classes with methods which you can use instead of the methods of workflowAPi.
Beware of unnecessary trigger executions! They will consume resources and slow down application performance.
Example 1:
This example shows many business event triggers in one big global scope.
Figure 176: ConSol CM Process Designer - Scope with triggers
Example 2:
If it is possible, please use triggers in the smallest scope possible (in this example, the trigger with Decision6 was moved to a smaller scope).
Figure 177: ConSol CM Process Designer - Move trigger to smaller scope
Example 3:
If it is not possible to move triggers to smaller scopes and you do not want to call all of the triggers while executing some activity, move this activity to an outside scope without any triggers.
Figure 178: ConSol CM Process Designer - Separate scopes with and without triggers
In this example, the position of Activity11 is optimized. It triggered many Decision calls and all of them went to NOTHING. Executing Activity11 outside of the global scope keeps a good quality of workflow performance!
Beware of unnecessary ticket update events (Java class TicketUpdateEvent)!
For example, assigning the current engineer (the engineer who is logged in and working with the Web Client) to a ticket can be done in two ways. In one solution a ticket update event is fired, in the other this does not happen. If it is not necessary for a business case to throw a TicketUpdateEvent, avoid it, because an unnecessary call of TicketUpdateEvent causes a decrease in performance.
//this method throws a TicketUpdateEvent after assigning the current engineer to the ticket
workflowApi.assignEngineer(workflowApi.currentEngineer)
Code example 97: Code which triggers TicketUpdateEvent
//this method does NOT throw a TicketUpdateEvent!
ticket.setEngineer(workflowApi.currentEngineer)
Code example 98: Code which does not trigger TicketUpdateEvent
Use the disable auto update flag for workflow components with care!
Please remember that a ticket update event is by default fired after every activity execution. A ticket update event is an operation that has a great impact and must be used with care!
To avoid performance problems, you can use the disable auto update flag. It depends on the business logic, if it makes sense to use this flag or not.
For example, when we have a series of automatic activities, a good practice is:
Figure 179: ConSol CM Process Designer - Activities with "disable auto update" option
When you use a business event trigger which is followed by an automatic activity, be careful that in this automatic activity the fields or objects, which trigger the business event trigger, are not changed again (which would fire the trigger again)!
If the use case requires that the fields, which caused the firing of the trigger, have to be changed again, then the logic, where the fields are changed, has to be placed in an activity outside the scope which hosts the trigger.
Figure 180: ConSol CM Process Designer - Avoiding self-triggering business event triggers