Project Open 3.5.x

Project Open Advanced Workflow Tutorial Part 4

Project Open Advanced Workflow Part 4: Automatic Processes

Revised March 31, 2011

Terrance A. Crow

 

Introduction

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:

  1. Tasks and Places
  2. Roles and Responsibilities
  3. Arcs and Guards
  4. Automatic Processes
  5. Adding to Helpdesk Ticket Types
  6. Adjusting Dynfields

This section will cover Automatic Processes.

Pre-Requisites

To successfully run this tutorial, you’ll need:

  1. A working installation of Project Open 3.5.0.0.1; 3.4.0.8.0c should work as well.
  2. 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.

Automatic Processes

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.

PO_Adv_Workflow_Part4_Fig1

 

 

 

 

 

 

 

 

 

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:

  1. User
  2. Automatic
  3. Message
  4. Time

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:

  1. Log into Project Open with an ID in the PO Admin group
  2. Click on the Admin tab
  3. Click on the Workflow URL
  4. Find and click on the workflow you want to work on (in our case, Sample 001)
  5. 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:

  1. Select (click on) the Close Ticket step
  2. Set it to process automatically
  3. 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.

PO_Adv_Workflow_Part4_Fig2

 

 

 

 

 

 

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.

PO_Adv_Workflow_Part4_Fig3

 

 

 

 

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.

PO_Adv_Workflow_Part4_Fig4

 

 

 

 

 

 

 

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.

PO_Adv_Workflow_Part4_Fig5

 

 

 

 

 

 

 

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:

  1. How do we affect the status column?
  2. 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
 FROM im_categories
 WHERE category_type = 'Intranet Ticket Status'
 ORDER BY category

The query will return something like this:

30011     Assigned
30018     Assigning
30098     Canceled
30095     Can't reproduce
30001     Closed
30012     Customer review
30097     Deleted
30090     Duplicate
30020     Executing
30010     In review
30091     Invalid
30024     Invoicing
30009     Modifying
30000     Open
30092     Outdated
30016     Quote Sign-off
30014     Quoting
30093     Rejected
30096     Resolved
30022     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.

PO_Adv_Workflow_Part4_Fig6

 

 

 

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:

  1. Log into Project Open using an ID in the PO Admin group
  2. Click on the Admin tab
  3. Click on the Categories URL
  4. Click on the URL for Intranet Ticket Status
  5. 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.

terrance
Terrance A. Crow is the Senior Security Engineer at a global library services company. He holds a CISSP and has been writing applications since the days of dBASE III and Lotus 1-2-3 2.01.
https://www.interstell.com