Workflow programming
Programming CM scripts
As you have seen in the previous sections, ConSol workflows can be set up rather easily using the graphical interface. However, in order to bring "real intelligence" into workflows, programming, i.e., writing scripts which are used in the workflow elements, is required.
ConSol CM scripts are written in Groovy, so you should have at least basic knowledge of this programming language. Since Groovy code runs in the Java Virtual Machine, you can also write Java code. Thus, if you are a Java or Groovy developer, it will be easy for you to learn how to build sophisticated workflows using the ConSol CM Groovy API.
In the current manual, we use Java style and Groovy style. You can decide which way to follow.
Development mode
By default, changes to scripts become effective when a new workflow version is deployed. If you want your changes to become effective immediately after saving the script, you can enable the development mode in the local configuration of the Process Designer (option Enable development mode). This is useful because you do not need to deploy the workflow to test changes to scripts during the customization of ConSol CM. In addition, fewer workflow versions are created.
Note that the element which the script belongs to needs to be available in the last deployed version of the workflow for this feature to work.
Java vs. Groovy-style coding
As mentioned above, you have to use Groovy for ConSol CM scripts. There might be different possibilities to express or code the same content. In the following paragraphs, we will give you some hints and provide some examples how to work with the Groovy API.
Omitting getter methods in Groovy
Most Groovy objects possess numerous getter methods to retrieve values from object attributes. You can either use the complete getter methods, or you can use the short (convenience) form. Please see the following examples for workflow scripts.
Use Case |
Java-like syntax (extended version) |
Groovy syntax (short version) |
---|---|---|
Get the subject of a ticket. |
String mysubject = ticket.getSubject() |
def mysubject = ticket.subject |
Get the engineer of a ticket. |
Engineer myeng = ticket.getEngineer() |
def myeng = ticket.engineer |
Get the main contact of a ticket. |
Unit mymaincontact = ticket.getMainContact() |
def mymaincontact = ticket.mainContact |
Get the value of a certain ticket field from a ticket. |
String myprio = ticket.get("helpdesk_fields", "prio") |
def myprio = ticket.get("helpdesk_fields.prio") |
Get the unit type for the primary contact. |
Unit mycustomer = workflowApi.getPrimaryContact() UnitDefinition myunitdef = mycustomer.getDefinition() UnitDefinitionType mydeftype = myunitdef.getType() |
def mycustomer = workflowApi.primaryContact def myunitdef = mycustomer.definition def mydeftype = mycustomer.definition.type |
Access to ticket fields cannot be shortened, because there are no getter methods for those fields. Please read the section Working with data fields for details about working with data from ticket fields.
Omitting setter methods in Groovy
Most Groovy objects possess numerous setter methods to set values for object attributes. You can either use the complete setter methods, or you can use the short (convenience) form. Please see the following examples for workflow scripts.
Use case |
Java-like syntax (extended version) |
Groovy syntax (short version) |
---|---|---|
Set the subject of a ticket. |
ticket.setSubject("asd") |
ticket.subject = "asd" |
CM API documentation
A Groovy API doc is provided for the ConSol CM API. Please ask your ConSol CM consultant or sales rep if you would like to receive the respective .jar file.
CM script types in workflows
In ConSol CM workflows, scripts are used in the following contexts:
- As activity script for an activity.
- As precondition script for an activity which has to return true or false.
- As script for a decision node which has to return true or false.
- As script for a business event trigger which is executed before the trigger fires.
- As script for a time trigger
- which is executed when the time trigger is initialized, i.e., when the ticket enters the scope where the time trigger is attached.
- which is executed when the time trigger fires, i.e., when the defined time has elapsed.
- As script for end nodes.
- As script for jump-in or jump-out nodes.
- As precondition scripts for ACFs which have to return true or false.
- As initializing scripts for ACFs.
Please refer to the respective sections in this manual for an explanation how to insert the scripts.
Script interactions
For each workflow script, you can decide if the code should run directly in the workflow or if the script should be stored in the Admin Tool, section Scripts and should be called from the workflow script. See section Where to save scripts for details.
Scripts in ConSol CM in general
Please keep in mind that the configuration and programming using the Process Designer make up only "half-the-intelligence" of your ConSol CM system! Numerous configurations and scripts are managed using the Admin Tool! As far as scripts are concerned, please read the section about Admin Tool Scripts in the ConSol CM Administrator Manual.