Build an Advanced Document Workflow

Overview

The purpose of this tutorial is to:

Help clients with little or no programmer resources to gain expertise in developing lightweight complex department-wide workflows
Help clients to move from a paper-based form paradigm to an electronic form paradigm
Help clients to progress to building workflows that facilitate complex business processes.

In this tutorial we will use eDocLite to facilitate a business process called Request Firewall Change which is owned by IET Application Development. This time the process involves more responsible parties and more levels of decision making (yikes!!!).

Instead of creating Users and Work Groups ourselves, we will leave that task to the administrators of the identity management system. We can expect all Users to already be present in the system. Work Groups can be specific to workflows, so we can expect to request that these be created by the system administrators.

Also, instead of expanding on the workflow in the Simple Document Workflow tutorial, we will build a brand new workflow. Whereas the previous tutorial has a "get-your-feet-wet" flavor, we will give this one the "little-fish-in-the-big-pond" treatment. This means we will act as though there are several departments (tens of or hundreds of) at UCD who are already using eDocLite for all kinds of document workflows and therefore, we must use naming conventions that will prevent our work from colliding with other departments' work and do so without confusing us at the same time.

In this case, there may be several other departments who:

administer their own firewalls
have a "Firewall Request Change" process that differs from IET Application Development's process
have work groups that have the same name as IET's work groups, but may or may not have the same responsibilities

We will employ a development cycle that closely follows the eDocLite dependency hierarchy:

Naming Conventions

Workflow Component	Naming Convention
Parent Document Type	<namespace>.<workflow name>.ParentDocType
Child Document Type	<namespace>.<workflow name>.ChildDocType
eDocLite Form Definition	<namespace>.<workflow name>.Form
Rule Attribute	<namespace>.<workflow name>.<rule attribute name>.RuleAttribute
Rule Template	<namespace>.<workflow name>.<rule template name>.RuleTemplate
Rule	<namespace>.<workflow name>.<rule name>.Rule
XML Files	Naming Convention
Parent Document Type	<namespace>.<workflow name>.ParentDocType.xml
Child Document Type	<namespace>.<workflow name>.ChildDocType.xml
eDocLite Form	<namespace>.<workflow name>.Form.xml
Rule Attributes	<namespace>.<workflow name>.RuleAttributes.xml
Rule Templates	<namespace>.<workflow name>.RuleTemplates.xml
Rules	<namespace>.<workflow name>.Rules.xml

Development Cycle

Model the Business Process
Model the Form Details
Model the Document Workflow
Create Validation Checklists
Procure Work Groups
Create Workflow Components
- Create the Parent Document Type
- Create the Child Document Types
- Create the eDocLite Form
  - Create the Definition
  - Create the Stylesheet
- Create Rule Attributes
- Create Rule Templates
- Create Rules
Implement Workflow Components
Simulate the Business Process

Model the Business Process

This time there are four responsible parties: Requester, Desktop Services, Firewall Policy Group, and Firewall Gatekeeper
Here is a breakdown of each parties responsibilities:

Requester	Submits the request just as in the previous tutorial. Is now allowed to specify if the request is urgent.
Desktop Services	Field all submitted requests. Check if the requested firewall configuration is already in effect. If so, cancel or deny the request. Otherwise, forward urgent requests to the Firewall Gatekeeper. forward non-urgent requests to the Firewall Policy Group.
Firewall Policy Group	Review requests and decide if they meet policy. Forward approved non-urgent requests to the Firewall Gatekeeper. Forward disapproved urgent requests to the Firewall Gatekeeper.
Firewall Gatekeeper	Implement urgent requested firewall configurations immediately. If disapproved by the Firewall Policy Group afterward, reverse firewall configuration. Implement non-urgent requests upon approval of the Firewall Policy Group.

We documented the Review Non-Urgent Request and Review Urgent Request as subprocesses because there is potential for the members of the Firewall Policy Group to have continuous correspondence with each other and with the Requester. At this point, it is not clear how we will address these subprocesses, since there is no document routing going on during the rounds of correspondence.

Model the Form Details

As part of the process, the Firewall Policy Group requires that anyone who wants the firewall rules modified must provide the following details:

Request Detail	Detail Style	Example
Date of change	Date in MM/DD/YYYY format	11/01/2010
Description of the port change	Descriptive blurb	Allow all workstations of the Application Development group access to the Oracle database port
Ingress/egress characteristic	Descriptive blurb	Incoming on port 1521
Source specification	Descriptive blurb	wk1.ucdavis.edu, wk2.ucdavis.edu, wk3.ucdavis.edu
Destination specification	Descriptive blurb	dbhost.ucdavis.edu
The term of the change (indefinite or otherwise)	One-liner	Indefinite
Project(s) related to the requested rule(s) change	Descriptive blurb	Kuali Rice Implementation
Urgent?	Pick either YES or NO	NO

Additionally, we want to add other detail as the process moves along:

Detail	Detail Style	Example
By Desktop Services:
Configuration is already in effect?	Pick either YES or NO	NO

By Firewall Policy Group:
Reason for disapproval	Descriptive Explanation	This request did not reflect urgency because of Reason A, Reason B, and Reason C.

Model the Document Workflow

Here is the document workflow diagram based on our business process. In it, we want to represent:

The path that the Request Firewall Change document must take in order to yield a successful lifecycle. This is the route path.
The various steps in the route path. Each step is called a route node.
The responsible party or parties who take action on each node. These are either persons, workgroups, or roles.
The rule scheme applied to each node. These schemes are comprised of rule templates, rule attributes and rules.

Let's lay down a few ground rules about the notation:

Element	Ground Rule
Request	The first route node, a.k.a. the start node, in the workflow's route path. This is where the Request Firewall Change document is created by an initiator.
Purple "Document"	A node in the route path. Each node represents a point in the business process where a responsible party is viewing (and possibly editing) the Request Firewall Change document.
Lavender Parallelogram	A rule template that is applied to each node. Each rule template is associated with a set of rules and rule attributes.
Orange Sail	A rule attribute associated with a rule template.
Lime Rectangle	The responsible party or parties who take action on a node.
Red Arrow	The action that must be taken to get from one node to the next node.
Blue Join Line	When connected to a rule attribute, it represents a rule that evaluates that rule attribute
Finish	Means the workflow has completed with flying colors.

Create Validation Checklists

Let's build a checklist that the QA team can use to validate the above simulation:

Requested Node	Current Status	Action	Taken By	New Status
Request	INITIATED	Fill out form, set URGENT to NO, click route	requester1	ENROUTE
ReviewCurrentConfiguration	ENROUTE	Click approve	DES1	ENROUTE
InitialApproval	ENROUTE	Click approve	FPG1	ENROUTE
FinalApproval	ENROUTE	Click approve	DCCS1	PROCESSED
AcknowledgeConfiguration	PROCESSED	Click acknowledge	requester1	FINAL

Let's build another one for urgent requests:

Requested Node	Current Status	Action	Taken By	New Status
Request