Build a Simple Document Workflow
Overview
The purpose of this tutorial is to:
Get Kuali Rice clients familiar with Kuali Rice's eDocLite web application
Give clients a jump start into developing eDocLite forms and workflows
Help clients with little or no programmer resources to gain expertise in developing lightweight department-wide workflows
Help clients to move from a paper-based form paradigm to an electronic form paradigm
The typical lightweight workflow involves someone submitting a request for something, someone with authority reviewing that request and then approving or disapproving it, and if approved, someone else fulfilling it. In this tutorial we will use eDocLite to facilitate a business process called Request Firewall Change. An IT department somewhere out there implemented this process for use by programmers who work in other departments. When a programmer needs access to any services protected by the IT firewall, s/he submits a request via e-mail to the Firewall Policy Group mailing list. Any one member in the Firewall Policy Group can review the request and approve or disapprove it. We will replace the e-mail with an eDocLite form. We will also replace the manual "read-the-email-and-reply-or-forward" process with an eDocLite workflow.
Development Steps
Study the Business Process
Gather the Required Details
Create Users
Create Work Groups
Create the Parent Document Type
Create the Child Document Types
Create the eDocLite Form
Create the Definition
Create the Stylesheet
Create the Rule Template
Create Routing Rules
Ingest XML Files
Simulate the Business Process
The Business Process
Here's a diagram of our business process:
In using eDocLite to facilitate this process, we'll need a few things:
A form to capture the request details.
A way to bring the request to the attention of the Firewall Policy Group.
A way for any member of the Firewall Policy Group to either approve or disapprove the request.
A way for the requester to get the details on the actions taken on the request.
The Request 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 | Example |
Date and time for change | January 1, 2010 |
Description of the port change | Allow all workstations of the Application Development group access to the Oracle database port |
Ingress/egress characteristic | Incoming on port 1521 |
Destination/source specification | Source: wk1.ucdavis.edu, wk2.ucdavis.edu, wk3.ucdavis.edu Destination: dbhost.ucdavis.edu |
The term of the change (indefinite or otherwise) | Indefinite |
Project related to the requested rule(s) change | Kuali Rice Implementation |
Create Users
Let's create an XML file that defines some users who will help us simulate the Request Firewall Change process. We have requester1 who will submit all requests and FPG1 & FPG2, who will be tasked with reviewing and approving (or disapproving) those requests.
RFC-Users.xml
<?xml version="1.0" encoding="UTF-8"?>
<data xmlns="ns:workflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="ns:workflow resource:WorkflowData">
<users xmlns="ns:workflow/User" xsi:schemaLocation="ns:workflow/User resource:User">
<user>
<workflowId>requester1</workflowId>
<emplId>requester1</emplId>
<authenticationId>requester1</authenticationId>
<uuId>requester1</uuId>
<emailAddress>requester1@ucdavis.edu</emailAddress>
<displayName>Requester One</displayName>
<givenName>Requester</givenName>
<lastName>One</lastName>
</user>
<user>
<workflowId>FPG1</workflowId>
<emplId>FPG1</emplId>
<authenticationId>FPG1</authenticationId>
<uuId>FPG1</uuId>
<emailAddress>FPG1@ucdavis.edu</emailAddress>
<displayName>Firewall Group Policy User One</displayName>
<givenName>Firewall Group Policy User</givenName>
<lastName>One</lastName>
</user>
<user>
<workflowId>FPG2</workflowId>
<emplId>FPG2</emplId>
<authenticationId>FPG2</authenticationId>
<uuId>FPG2</uuId>
<emailAddress>FPG2@ucdavis.edu</emailAddress>
<displayName>Firewall Group Policy User Two</displayName>
<givenName>Firewall Group Policy User</givenName>
<lastName>Two</lastName>
</user>
</users>
</data>
Note: In the Kuali Rice production environment, users will be managed via the Identity Management system. |
Create Work Groups
Here we create a workgroup called eDoc.FirewallPolicyGroup.Workgroup. Per our business process, all Firewall Change Requests will be routed to this group for review and approval. The users FPG1 and FPG2 are hereby inducted into this group.
RFC-Workgroup.xml
<?xml version="1.0" encoding="UTF-8"?>
<data xmlns="ns:workflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="ns:workflow resource:WorkflowData">
<workgroups xmlns="ns:workflow/Workgroup" xsi:schemaLocation="ns:workflow/Workgroup resource:Workgroup">
<workgroup>
<workgroupName>eDoc.FirewallPolicyGroup.Workgroup</workgroupName>
<description>Firewall Policy Group for Firewall Change Requests</description>
<members>
<authenticationId>FPG1</authenticationId>
<authenticationId>FPG2</authenticationId>
</members>
</workgroup>
</workgroups>
</data>
Note 1: | Just like users, workgroups will be managed via the Identity Management system in the Kuali Rice production environment. |
Note 2: | Once Kuali Rice is in production, work group names will tend to be long as a result of several UCD departments using eDocLite:
|