Project Open Advanced Workflow Part 4: Automatic Processes
Revised March 31, 2011
Terrance A. Crow
Project Open ships with a powerful workflow editor that lets you control how a ticket is processed. The workflow editor operates in one of two modes: Simple Process and Advanced Process. This tutorial will cover the Advanced Process.
I’ll break down the Advanced Process tutorial into these parts:
- Tasks and Places
- Roles and Responsibilities
- Arcs and Guards
- Automatic Processes
- Adding to Helpdesk Ticket Types
- Adjusting Dynfields
This section will cover Automatic Processes.
To successfully run this tutorial, you’ll need:
- A working installation of Project Open 22.214.171.124.1; 126.96.36.199.0c should work as well.
- A Project Open administrator ID
My Project Open installation runs on CentOS 5.5 Linux. The examples should run on any installation of Project Open, though. I used Apple’s Safari (under OS X 10.6.7) to capture the screen shots.
So far, we’ve setup the skeleton of our straight-forward workflow. Figure 1 shows what the flow looks like on the off chance that you’ve forgotten since you went through the last part of the tutorial.
Figure 1: This is our straight-forward workflow.
So far, we have defined the Tasks that describe the work that needs to be done, the Places that link the Tasks, the Arcs that link Task to Place and Place to Task, and the Guards that move the workflow conditionally along the Arcs.
Movement along the workflow is entirely manual. In other words, someone has to enter the ticket, someone has to assign the ticket, someone has to work the ticket, and someone has to close the ticket.
Manual initiation makes sense for most of these tasks. After all, we’re relying on human oversight to assign the ticket and a human to actually work the ticket. And personally, I hope humans remain in this cycle for awhile, because as much as I like automation, I’d hate to be unemployed.
However, in our workflow, it doesn’t seem to make sense for someone to manually close the ticket. It’s a nuisance even if it is important. Fortunately, Project Open gives us a way to automate this step.
Remember when we created Tasks? Each Task has a Trigger Type, and it can be one of four values:
Our workflow up until now has only used the first one. Now, it’s time to use the second!
You can follow these steps to get to the point where I’m going to start this part of the tutorial:
- Log into Project Open with an ID in the PO Admin group
- Click on the Admin tab
- Click on the Workflow URL
- Find and click on the workflow you want to work on (in our case, Sample 001)
- Under Actions, click on the URL graphic process editor
At this point, you should see a screen a lot like the one from Figure 1.
In order to automatically close a ticket after it’s been worked, we’ll follow these general steps:
- Select (click on) the Close Ticket step
- Set it to process automatically
- Set it to invoke a stored procedure that’ll set the ticket’s status to closed
From the graphical workflow editor, clicking on the Task Close Ticket selects it. That means the menu options near the top of the screen will affect Close Ticket. In about the middle of the screen, you should see an edit Task URL. See Figure 2.
Figure 2: You can edit the Task’s properties by clicking on the edit URL.
If you click on the edit URL, you should see a screen like the one in Figure 3.
Figure 3: This is the screen where you can edit the Task’s details.
There are two changes to be made here. First, change the field Trigger type to Automatic. That’ll tell the workflow that when it hits this Task, it should perform whatever automation we tell it to (we’ll take care of that in a minute). Second, change the Role to “– None –”. Since the Task will execute automatically, it doesn’t need a Role.
Click on Update to save the changes.
If you look near the bottom of the screen, you should see that the Task is now automatic. See Figure 4.
Figure 4: The workflow graphic edit shows that the Task will execute automatically.
The Task is all ready to automatically run — but we haven’t told it what to do yet. If you look near the top of the screen, you’ll see the URLs for assignment, attributes, and actions. Click on actions to see a screen like the one in Figure 5.
Figure 5: This screen gives you a lot of options to control how the Task will execute.
I’m going to focus on the Action Type called Enable for two reasons. First, so far in the workflows I’ve designed, it’s done everything I’ve needed it to. Second, I have no idea what the other Actions Types do.
I may sometimes be ignorant, but I try to always be honest!
What we need to do now is to set the status identifier to match the status we want. So, that begs two questions:
- How do we affect the status column?
- What value do we set it to?
Project Open gives us a stored procedure to answer the first question. Named im_workflow__set_object_status_id (yep — two underlines after “workflow”), it accepts a custom argument, and that custom argument represents the identifier that represents the status we want to set.
And how do we get that status identifier?
You can execute this query against Project Open’s database (projop) to get the answer:
SELECT category_id, category
WHERE category_type = 'Intranet Ticket Status'
ORDER BY category
The query will return something like this:
30095 Can't reproduce
30012 Customer review
30010 In review
30016 Quote Sign-off
30026 Waiting for Other
30094 Won't fix
If you find the category “Closed”, you’ll see that its ID is 30001. That’s the one we’ll use to set the Custom argument. When you’re done, the screen should look like Figure 6.
Figure 6: These Enable Action Type settings will set a ticket’s status to Closed.
Once you click the Update button, the Task is ready to execute automatically!
Note that you can add your own ticket status identifiers to Project Open by following these general steps:
- Log into Project Open using an ID in the PO Admin group
- Click on the Admin tab
- Click on the Categories URL
- Click on the URL for Intranet Ticket Status
- Click on the URL Add a category
Any status you create is valid to use with im_workflow__set_object_status_id (well, assuming the status ID is Enabled).
Our tutorial is inching (or centi-metering — okay, that didn’t work…) toward a functional workflow. It has Tasks and Places, it has Roles and Responsibilities, it has Arcs and Guards, and now it has Task Automatic Processing. In Part 5, I’ll show how to specify which Dynfields display on a Ticket for our Simple 001 workflow.