Build a Simple Document Workflow Using eDocLite

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:

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

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>

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>

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

Open the URL to a Kuali Rice development server (e.g. http://ricedevhost.ucdavis.edu:8080/rice-0.9.3-server/)
Click on Kuali Enterprise Workflow
Log in as admin
Under Administration, click on XML Ingester
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:

Log in as requester1
Click on EDocLites
Click Search
Find the eDocLite whose Definition Name is eDoc.RequestFirewallChange.Form
Click on Create Document
Here's the form we built:
Fill out the form and click route
Log in as FPG1
Click on Action List
Find the document initiated by requester1. Its status should be ENROUTE
Click on the document and it should look like so:
Click approve
Log in as requester1 again
Click on Document Search and then Search
Find the document approved by FPG1. It's status should be FINAL
Click on the Log icon
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:

Log in as requester1
Click on EDocLites
Click Search
Find the eDocLite whose Definition Name is eDoc.RequestFirewallChange.Form
Click on Create Document
Fill out the form and click route
Log in as FPG2
Click on Action List
Find the document initiated by requester1. Its status should be ENROUTE
Click on the document
Click disapprove
Log in as requester1 again
Click on Action List
Find the document disapproved by FPG2. It's status should be DISAPPROVED
Click on the docuument
Click acknowledge
Click on Document Search and then Search
Find the document again
Click on the Log icon
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