Build a Simple Document Workflow

Owned by Emerson David
Last updated: Jun 09, 2009Version comment
17 min read

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

  1. Study the Business Process
  2. Gather the Required Details
  3. Create Users
  4. Create Work Groups
  5. Create the Parent Document Type
  6. Create the Child Document Types
  7. Create the eDocLite Form
    • Create the Definition
    • Create the Stylesheet
  8. Create the Rule Template
  9. Create Routing Rules
  10. Ingest XML Files
  11. 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:

  • eDoc.IET.DataCenter.FirewallPolicyGroup.Workgroup
  • eDoc.IET.Middleware.FirewallPolicyGroup.Workgroup
  • eDoc.OOA.AFS.FirewallPolicyGroup.Workgroup
  • eDoc.ORMP.FacilitiesManagement.FMIS.FirewallPolicyGroup.Workgroup

Create the Parent Document Type

Here we create a parent document type that defines the behavior of all Request Firewall Change documents. This particular parent document type defines everything short of routing paths. The idea is to allow for the possibility of other business processes called Request Firewall Change but will have different routing paths, validation rules, work groups, etc., but use the same form, have the same super user work group, the same exception workgroup, etc.

RFC-ParentDocType.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">
<documentTypes xmlns="ns:workflow/DocumentType" xsi:schemaLocation="ns:workflow/DocumentType resource:DocumentType">
	<documentType>
		<name>eDoc.RequestFirewallChange.Parent</name>
		<description>eDoc.RequestFirewallChange Parent Document</description>
		<label>eDoc.RequestFirewallChange Parent Document</label>
		<postProcessorName>edu.iu.uis.eden.edl.EDocLitePostProcessor</postProcessorName>
		<superUserWorkgroupName>eDoc.FirewallPolicyGroup.Workgroup</superUserWorkgroupName>
		<blanketApprovePolicy>NONE</blanketApprovePolicy>
		<docHandler>${workflow.url}/EDocLite</docHandler>
		<active>true</active>
		<routingVersion>2</routingVersion>
	</documentType>
</documentTypes>
</data>

Note:

We define the superUserWorkgroupName as eDoc.FirewallPolicyGroup.Workgroup. In production, the super user work group will likely be the group of eDocLite super users or Kuali Rice system administrators (some systemwide administrative group).

Create the Child Document Types

Here we create one child document type to support the behavior of our particular Firewall Request Change. Besides identifying the name and parent of this document type, we define two other main things: routePaths and routeNodes. These define the behavior of the workflow. In the case of our business process, our routePath requires only one routeNode called eDoc.RequestFirewallChange.Node1.

RFC-ChildDocTypes.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">
<documentTypes xmlns="ns:workflow/DocumentType" xsi:schemaLocation="ns:workflow/DocumentType resource:DocumentType">
	<documentType>
		<name>eDoc.RequestFirewallChange</name>
		<parent>eDoc.RequestFirewallChange.Parent</parent>
		<description>eDoc.RequestFirewallChange Child Document Type</description>
		<label>eDoc.RequestFirewallChange Child Document Type</label>
		<defaultExceptionWorkgroupName>eDoc.FirewallPolicyGroup.Workgroup</defaultExceptionWorkgroupName>
		<active>true</active>
		<routePaths>
			<routePath>
          			<start name="Initiated" nextNode="eDoc.RequestFirewallChange.Node1" />
		          	<requests name="eDoc.RequestFirewallChange.Node1" />
        	        </routePath>
		</routePaths>
	        <routeNodes>
        		<start name="Initiated">
          			<activationType>P</activationType>
		      	<mandatoryRoute>false</mandatoryRoute>
          			<finalApproval>false</finalApproval>
        		</start>
	     		<requests name="eDoc.RequestFirewallChange.Node1">
           			<activationType>P</activationType>
          			<ruleTemplate>eDoc.RequestFirewallChange.Node1</ruleTemplate>
          			<mandatoryRoute>false</mandatoryRoute>
          			<finalApproval>false</finalApproval>
           		</requests>
              </routeNodes>
	</documentType>
</documentTypes>
</data>

Note 1:

We define the defaultExceptionWorkgroupName as eDoc.FirewallPolicyGroup.Workgroup. In production, the exception workgroup will likely be a department-wide or system-wide group of eDocLite super users or Kuali Rice system administrators.

Note 2:

Our lone route node eDoc.RequestFirewallChange.Node1 invokes a rule template of the same name (which we'll create later).

Create the eDocLite Form

Based on the request details required by our process above (way above), we now build the form for the users to enter those details into. Building eDocLite forms requires us to address three pieces to the puzzle:

  • The eDocLite Form Skeleton
  • The Form Definition
  • The Stylesheet Definition

  1. The eDocLite Form Skeleton
    The Form Skeleton is the structure of the entire eDocLite form minus the Form Definition and Form Stylesheet. We separate this out so that you can use it as a base template for all of your eDocLite forms. This particular skeleton follows the scheme of the out-of-the-box Kuali Rice forms. The scheme uses the same look and feel and makes calls to the eDocLite widgets on the Kuali Rice server.
    RFC-EDLForm.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">
<edoclite xmlns="ns:workflow/EDocLite" xsi:schemaLocation="ns:workflow/EDocLite resource:EDocLite">
  
	<edl name="eDoc.RequestFirewallChange.Form" title="Request Firewall Change">
		<security />
		<createInstructions>** Fields with an asterisk are required.</createInstructions>
		<instructions>** Fields with an asterisk are required.</instructions>
		<validations />
		<attributes />
	        ...
	        ...
	</edl>

	<style name="eDoc.RequestFirewallChange.Style">
	<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:my-class="xalan://edu.iu.uis.eden.edl.WorkflowFunctions" version="1.0">
		<xsl:include href="widgets" />
		<xsl:output indent="yes" method="html" omit-xml-declaration="yes" version="4.01" />
		<xsl:variable name="actionable" select="/documentContent/documentState/actionable" />
		<xsl:variable name="docHeaderId" select="/documentContent/documentState/docId" />
		<xsl:variable name="editable" select="/documentContent/documentState/editable" />
		<xsl:variable name="globalReadOnly" select="/documentContent/documentState/editable != 'true'" />
		<xsl:variable name="docStatus" select="//documentState/workflowDocumentState/status" />
		<xsl:variable name="isAtNodeInitiated" select="my-class:isAtNode($docHeaderId, 'Initiated')" />
		<xsl:variable name="isPastInitiated" select="my-class:isNodeInPreviousNodeList('Initiated', $docHeaderId)" />
		<xsl:variable name="isUserInitiator" select="my-class:isUserInitiator($docHeaderId)" />
		<xsl:param name="overrideMain" select="'true'" />
        
		<xsl:template name="mainForm">
			<html xmlns="">
			  <head>
			  <script language="javascript" />
			  <xsl:call-template name="htmlHead" />
			  </head>
  			<body onload="onPageLoad()">
			  <xsl:call-template name="errors" />
			  <xsl:call-template name="header" />
			  <xsl:call-template name="instructions" />
		  	  <xsl:variable name="formTarget" select="'EDocLite'" />
		          <form action="{$formTarget}" enctype="multipart/form-data" id="edoclite" method="post" onsubmit="return validateOnSubmit(this)">
		  	    <xsl:call-template name="hidden-params" />
		  	    <xsl:call-template name="mainBody" />
		  	    <xsl:call-template name="notes" />
		  	    <br />
		  	    <xsl:call-template name="buttons" />
		  	    <br />
		  	  </form>
                          <xsl:call-template name="footer" />
    		  	</body>
    		       </html>
		</xsl:template>

		<xsl:template name="mainBody">
			...
			...
 		</xsl:template>

  		<xsl:template name="nbsp">
			<xsl:text disable-output-escaping="yes">&amp;nbsp;</xsl:text>
		</xsl:template>
	</xsl:stylesheet>
	</style>

	<association>
		<docType>eDoc.RequestFirewallChange</docType>
		<definition>eDoc.RequestFirewallChange.Form</definition>
		<style>eDoc.RequestFirewallChange.Style</style>
    		<active>true</active>
  	</association>

</edoclite>
</data>

  2. Form Definition
    The Form Definition defines the data entry fields on the form. Our definitions define field display characteristics and field validations. Place your form definition between the <edl> and </edl> tags in the Form Skeleton.
    RFC-EDLForm.xml
        <fieldDef name="dateOfChange" title="Date and Time for Change">
      <display>
        <type>text</type>
      </display>
      <validation required="true">
        <regex>^[0-1]?[0-9](/|-)[0-3]?[0-9](/|-)[1-2][0-9][0-9][0-9]$</regex>
        <message>Enter a valid date in the format mm/dd/yyyy.</message>
      </validation>
    </fieldDef>

    <fieldDef name="descriptionOfChange" title="Description of the Port Change">
      <display>
        <type>textarea</type>
        <meta>
          <name>rows</name>
          <value>5</value>
        </meta>
        <meta>
          <name>cols</name>
          <value>60</value>
        </meta>
        <meta>
          <name>wrap</name>
          <value>hard</value>
        </meta>
      </display>
      <validation required="true">
        <message>Enter a description of the port change.</message>
      </validation>
    </fieldDef>

    <fieldDef name="ingressEgressCharacteristic" title="Ingress/Egress Characteristic">
      <display>
        <type>textarea</type>
        <meta>
          <name>rows</name>
          <value>5</value>
        </meta>
        <meta>
          <name>cols</name>
          <value>60</value>
        </meta>
        <meta>
          <name>wrap</name>
          <value>hard</value>
        </meta>
      </display>
      <validation required="true">
        <message>Enter the ingress/egress characteristic.</message>
      </validation>
    </fieldDef>

    <fieldDef name="destinationSourceSpecification" title="Destination/Source Specification">
      <display>
        <type>textarea</type>
        <meta>
          <name>rows</name>
          <value>5</value>
        </meta>
        <meta>
          <name>cols</name>
          <value>60</value>
        </meta>
        <meta>
          <name>wrap</name>
          <value>hard</value>
        </meta>
      </display>
      <validation required="true">
        <message>Enter the destination/source specification.</message>
      </validation>
    </fieldDef>

    <fieldDef name="termOfRuleChange" title="Term of Rule Change (indefinite or otherwise)">
      <display>
        <type>text</type>
        <meta>
          <name>size</name>
          <value>50</value>
        </meta>
      </display>
      <validation required="true">
        <message>Enter term of the rule change.</message>
      </validation>
    </fieldDef>

    <fieldDef name="relatedProject" title="Project Related to Requested Rule(s) Change">
      <display>
        <type>text</type>
        <meta>
          <name>size</name>
          <value>50</value>
        </meta>
      </display>
      <validation required="true">
        <message>Enter a related project to the requested rule change.</message>
      </validation>
    </fieldDef>

  3. Form Stylesheet
    The Form Stylesheet defines the layout of the form and renders the fields from our Form Definition onto the form. Our layout is an HTML table with a row for each field. In this case, we are customizing the mainBody piece of the stylesheet. In general, place your form stylesheet between the <style> and </style> tags in the Form Skeleton.
    RFC-EDLForm.xml
      <xsl:template name="mainBody">
    <table xmlns="" align="center" border="0" cellpadding="0" cellspacing="0" class="bord-r-t" width="80%">
      <tr>
        <td align="left" border="3" class="thnormal" colspan="1">
          <br />
          <h3>
            University of California, Davis
            <br />
            eDoclite Tutorial
	  </h3>
          <br />
        </td>
        <td align="center" border="3" class="thnormal" colspan="2">
          <br />
          <h2>Request Firewall Change Form</h2>
        </td>
      </tr>
      <tr>
        <td class="headercell5" colspan="100%">
        <b>Request Details</b>
        </td>
      </tr>
      <tr>
        <td class="thnormal">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'dateOfChange'" />
            <xsl:with-param name="renderCmd" select="'title'" />
          </xsl:call-template>
          <font color="#ff0000">*</font>
        </td>
        <td class="datacell">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'dateOfChange'" />
            <xsl:with-param name="renderCmd" select="'input'" />
            <xsl:with-param name="readOnly" select="$isPastInitiated" />
          </xsl:call-template>
        </td>
      </tr>
      <tr>
        <td class="thnormal">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'descriptionOfChange'" />
            <xsl:with-param name="renderCmd" select="'title'" />
          </xsl:call-template>
          <font color="#ff0000">*</font>
        </td>
        <td class="datacell">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'descriptionOfChange'" />
            <xsl:with-param name="renderCmd" select="'input'" />
            <xsl:with-param name="readOnly" select="$isPastInitiated" />
          </xsl:call-template>
        </td>
      </tr>
      <tr>
        <td class="thnormal">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'ingressEgressCharacteristic'" />
            <xsl:with-param name="renderCmd" select="'title'" />
          </xsl:call-template>
          <font color="#ff0000">*</font>
        </td>
        <td class="datacell">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'ingressEgressCharacteristic'" />
            <xsl:with-param name="renderCmd" select="'input'" />
            <xsl:with-param name="readOnly" select="$isPastInitiated" />
          </xsl:call-template>
        </td>
      </tr>
      <tr>
        <td class="thnormal">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'destinationSourceSpecification'" />
            <xsl:with-param name="renderCmd" select="'title'" />
          </xsl:call-template>
          <font color="#ff0000">*</font>
        </td>
        <td class="datacell">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'destinationSourceSpecification'" />
            <xsl:with-param name="renderCmd" select="'input'" />
            <xsl:with-param name="readOnly" select="$isPastInitiated" />

          </xsl:call-template>
        </td>
      </tr>
      <tr>
        <td class="thnormal">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'termOfRuleChange'" />
            <xsl:with-param name="renderCmd" select="'title'" />
          </xsl:call-template>
          <font color="#ff0000">*</font>
        </td>
        <td class="datacell">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'termOfRuleChange'" />
            <xsl:with-param name="renderCmd" select="'input'" />
            <xsl:with-param name="readOnly" select="$isPastInitiated" />
          </xsl:call-template>
        </td>
      </tr>
      <tr>
        <td class="thnormal">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'relatedProject'" />
            <xsl:with-param name="renderCmd" select="'title'" />
          </xsl:call-template>
          <font color="#ff0000">*</font>
        </td>
        <td class="datacell">
          <xsl:call-template name="widget_render">
            <xsl:with-param name="fieldName" select="'relatedProject'" />
            <xsl:with-param name="renderCmd" select="'input'" />
            <xsl:with-param name="readOnly" select="$isPastInitiated" />
          </xsl:call-template>
        </td>
      </tr>
    </table>
    <br xmlns="" />
<xsl:template>

Create the Rule Template

Here we create the Rule Template that is invoked by the route node eDoc.RequestFirewallChange.Node1 and by a routing rule that we will create next. This particular rule template simply defines its name and description.

RFC-RuleTemplate.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">
<ruleTemplates xmlns="ns:workflow/RuleTemplate" xsi:schemaLocation="ns:workflow/RuleTemplate resource:RuleTemplate">
	<ruleTemplate>
      	<name>eDoc.RequestFirewallChange.Node1</name>
      	<description>eDocLite RequestFirewallChange Routing</description>
	</ruleTemplate>
</ruleTemplates>
</data>


Create Routing Rules

Finally, we create a single Routing Rule that is associated with the eDoc.RequestFirewallChange document type and the eDoc.RequestFirewallChange.Node1 rule template. Whenever a Firewall Change Request is submitted, this routing rule fires and delegates the approval responsibility to the eDoc.FirewallPolicyGroup.Workgroup work group.

RFC-RoutingRules.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">
<rules xmlns="ns:workflow/Rule" xsi:schemaLocation="ns:workflow/Rule resource:Rule">
	<rule>
      		<documentType>eDoc.RequestFirewallChange</documentType>
      		<ruleTemplate>eDoc.RequestFirewallChange.Node1</ruleTemplate>
      		<description>Routing rule for eDocLite RequestFirewallChange.</description>
      		<ignorePrevious>false</ignorePrevious>
      		<responsibilities>
        		<responsibility>
          			<workgroup>eDoc.FirewallPolicyGroup.Workgroup</workgroup>
          			<actionRequested>A</actionRequested>
          			<priority>1</priority>
        		</responsibility>
      		</responsibilities>
    	</rule>
</rules>
</data>


XML File Ingestion

  1. Open the URL to a Kuali Rice development server (e.g. http://ricedevhost.ucdavis.edu:8080/rice-0.9.3-server/)
  2. Click on Kuali Enterprise Workflow
  3. Log in as admin
  4. Under Administration, click on XML Ingester
  5. Upload the XML files we created in the following order:
    1. Users: RFC-Users.xml
    2. Workgroups: RFC-Workgroup.xml
    3. Rule Template: RFC-Users.xml
    4. Parent Document Type: RFC-ParentDocType.xml
    5. Child Document Types: RFC-ChildDocTypes.xml
    6. EDL Form: RFC-EDLForm.xml
    7. Routing Rules: RFC-RoutingRules.xml

Simulate the Business Process

First, let's simulate a Firewall Change Request that gets approved by someone in the Firewall Policy Group:

  1. Log in as requester1
  2. Click on EDocLites
  3. Click Search
  4. Find the eDocLite whose Definition Name is eDoc.RequestFirewallChange.Form
  5. Click on Create Document
  6. Here's the form we built:
  7. Fill out the form and click route
  8. Log in as FPG1
  9. Click on Action List
  10. Find the document initiated by requester1. Its status should be ENROUTE
  11. Click on the document and it should look like so:
  12. Click approve
  13. Log in as requester1 again
  14. Click on Document Search and then Search
  15. Find the document approved by FPG1. It's status should be FINAL
  16. Click on the Log icon
  17. The log should like like so:

This time, let's simulate a Firewall Change Request that doesn't get approved by by the Firewall Policy Group:

  1. Log in as requester1
  2. Click on EDocLites
  3. Click Search
  4. Find the eDocLite whose Definition Name is eDoc.RequestFirewallChange.Form
  5. Click on Create Document
  6. Fill out the form and click route
  7. Log in as FPG2
  8. Click on Action List
  9. Find the document initiated by requester1. Its status should be ENROUTE
  10. Click on the document
  11. Click disapprove
  12. Log in as requester1 again
  13. Click on Action List
  14. Find the document disapproved by FPG2. It's status should be DISAPPROVED
  15. Click on the docuument
  16. Click acknowledge
  17. Click on Document Search and then Search
  18. Find the document again
  19. Click on the Log icon
  20. The log should like like so:

Reference

https://test.kuali.org/confluence/display/KULRICE/EDocLite+Documentation+Guide
https://test.kuali.org/confluence/display/KULRICE/eDocLite+Example+1