Page Comparison

Overview

Development Steps

1. Create Users
2. Create Workgroups
3. Create the Parent Document Type
4. Create the Child Document Type
5. Create the eDocLite Form
   • Create the Form
   • Create the Stylesheet
6. Create the Rule Template
7. Create Routing Rules

The Business Process

Image Removed

The Request Details

Create Users

...

...

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:
Image Added
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:

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.

<?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>

Create Workgroups

...

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.

<?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>

Create the Parent Document Type

<?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>

Create the Child Document Types

...

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.

<?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<RequestFirewallChange.Parent</name>
		<parent>eDoc<description>eDoc.RequestFirewallChange.Parent</parent>
		<description>eDoc.RequestFirewallChange Child Document Type< Parent Document</description>
		<label>eDoc.RequestFirewallChange ChildParent Document Type<Document</label>
		<postProcessorName>edu.iu.uis.eden.edl.EDocLitePostProcessor</postProcessorName>		
		<superUserWorkgroupName>eDoc.FirewallPolicyGroup.Workgroup</superUserWorkgroupName>
		<blanketApprovePolicy>NONE</blanketApprovePolicy>
		<defaultExceptionWorkgroupName>eDoc.FirewallPolicyGroup.Workgroup</defaultExceptionWorkgroupName>
		<docHandler>${workflow.url}/EDocLite</docHandler>
		<active>true</active>
		<routingVersion>2</routingVersion>
		<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></documentType>
</documentTypes>
</data>

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.

<?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>
          			<finalApproval>false</finalApproval>
   <start name="Initiated" nextNode="eDoc.RequestFirewallChange.Node1" />
		     		</start> 	     		<requests name="eDoc.RequestFirewallChange.Node1" />
 
         			<activationType>P</activationType>        </routePath>
		</routePaths>
	        <routeNodes>
        			<ruleTemplate>eDoc.RequestFirewallChange.Node1</ruleTemplate><start name="Initiated">
          			<activationType>P</activationType>
		      	<mandatoryRoute>false</mandatoryRoute>
          			<finalApproval>false</finalApproval>
        		</start>
	     		</requests>
<requests name="eDoc.RequestFirewallChange.Node1">
          </routeNodes> 		<	<activationType>P</documentType>activationType>
 </documentTypes>
</data>

Create the eDocLite Form

...

...

         			<ruleTemplate>eDoc.RequestFirewallChange.Node1</ruleTemplate>
          			<mandatoryRoute>false</mandatoryRoute>
          			<finalApproval>false</finalApproval>
           		</requests>
              </routeNodes>
	</documentType>
</documentTypes>
</data>

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.

   Code Block
   title 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="buttonshtmlHead" /> </head> <br /> <body onload="onPageLoad()"> </form> <xsl:call-template name="errors" /> <xsl:call-template name="header" /> <xsl:call-template name="footerinstructions" /> </body> <xsl:variable name="formTarget" select="'EDocLite'" /> </html> </xsl:template> <xsl: <form action="{$formTarget}" enctype="multipart/form-data" id="edoclite" method="post" onsubmit="return validateOnSubmit(this)"> <xsl:call-template name="mainBodyhidden-params" /> ... ... </xsl:template> <xsl:call-template name="nbspmainBody" /> <xsl:text disable-output-escapingcall-template name="yesnotes">&amp;nbsp;</xsl:text> /> </xsl:template> </xsl:stylesheet> </style> <association> <docType>eDoc.RequestFirewallChange</docType><br /> <definition>eDoc.RequestFirewallChange.Form</definition> <style>eDoc.RequestFirewallChange.Style</style> <active>true</active> </association> </edoclite> </data>

   Field Definitions

   Code Block
   title RFC-EDLForm.xml
   <xsl:call-template name="buttons" /> <br /> </form> <fieldDef name="dateOfChange" title="Date and Time for Change"> <display> <xsl:call-template name="footer" <type>text</type>> </display>body> <validation required="true"> </html> </xsl:template> <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 <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.

   Code Block
   title RFC-EDLForm.xml
   <fieldDef name="dateOfChange" title="Date and Time for Change"> <display> <type>textarea<<type>text</type> </display> <meta> <validation required="true"> <name>rows</name> <regex>^[0-1]?[0-9](/|-)[0-3]?[0-9](/|-)[1-2][0-9][0-9][0-9]$</regex> <value>5</value> <message>Enter a valid date in the format mm/dd/yyyy.</meta>message> </validation> <meta> </fieldDef> <name>cols</name> <fieldDef name="descriptionOfChange" title="Description of the Port Change"> <value>60</value><display> <<type>textarea</meta>type> <meta> <name>wrap<<name>rows</name> <value>hard<<value>5</value> </meta> </display> <meta> <validation required="true"> <name>cols</name> <message>Enter a description of the port change.<<value>60</message>value> </validation> </fieldDef>meta> <fieldDef name="ingressEgressCharacteristic" title="Ingress/Egress Characteristic"> <meta> <display> <name>wrap</name> <type>textarea</type> <value>hard</value> <meta> </meta> <name>rows</name> </display> <validation required="true"> <value>5</value> <message>Enter a description of the port change.</meta>message> </validation> <meta> </fieldDef> <fieldDef <name>cols</name> name="ingressEgressCharacteristic" title="Ingress/Egress Characteristic"> <display> <value>60</value> </meta><type>textarea</type> <meta> <name>wrap<<name>rows</name> <value>hard<<value>5</value> </meta> </display> <meta> <validation required="true"> <name>cols</name> <message>Enter the ingress/egress characteristic.</message> <value>60</value> </validation> </fieldDef> meta> <fieldDef name="destinationSourceSpecification" title="Destination/Source Specification"> <meta> <display> <type>textarea</type><name>wrap</name> <meta> <value>hard</value> <name>rows<</name>meta> </display> <value>5</value> <validation required="true"> </meta> <message>Enter the ingress/egress characteristic.</message> <meta> </validation> <name>cols<</name>fieldDef> <fieldDef name="destinationSourceSpecification" title="Destination/Source Specification"> <value>60</value> <display> <<type>textarea</meta>type> <meta> <name>wrap<<name>rows</name> <value>hard<<value>5</value> </meta> </display> <meta> <validation required="true"> <name>cols</name> <message>Enter the destination/source specification.</message> <value>60</value> </validation> </fieldDef>meta> <fieldDef name="termOfRuleChange" title="Term of Rule Change (indefinite or otherwise)"> <meta> <name>wrap</name> <display> <type>text</type> <meta> <name>size</name> <value>50</<value>hard</value> </meta> </display> <validation required="true"> <message>Enter term of the ruledestination/source changespecification.</message> </validation> </fieldDef> <fieldDef name="relatedProjecttermOfRuleChange" title="ProjectTerm Relatedof toRule RequestedChange Rule(s) Changeindefinite or otherwise)"> <display> <type>text</type> <meta> <name>size</name> <value>50</value> </meta> </display> <validation required="true"> <message>Enter aterm related projectof to the requested rule change.</message> </validation> </fieldDef>

   Stylesheet "mainBody" Definition

   Code Block
   title RFC-EDLForm.xml
   <xsl:template name="mainBody"> <fieldDef name="relatedProject" title="Project Related to Requested Rule(s) Change"> <table<display> xmlns="" align="center" border="0" cellpadding="0" cellspacing="0" class="bord-r-t" width="80%"> <type>text</type> <tr> <meta> <td align="left" border="3" class="thnormal" colspan="1"> <br /><name>size</name> <h3><value>50</value> </meta> University of California, Davis</display> <br /<validation required="true"> <message>Enter a related project eDocliteto Tutorialthe requested rule change.</h3>message> <br /> </validation> </td> <td align="center" border="3" class="thnormal" colspan="2fieldDef>

   
   
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.

   Code Block
   title RFC-EDLForm.xml
   <xsl:template name="mainBody"> <table xmlns="" align="center" border="0" cellpadding="0" cellspacing="0" class="bord-r-t" width="80%"> <tr> <br /> <td align="left" border="3" class="thnormal" colspan="1"> <h2>Request Firewall Change Form</h2> <br /> </td> </tr> <h3> <tr> University of <td class="headercell5" colspan="100%">California, Davis <b>Request<br Details</b>> </td> eDoclite Tutorial </tr>h3> <tr> <br /> <td class="thnormal"> </td> <xsl:call-template name<td align="widget_rendercenter"> border="3" class="thnormal" colspan="2"> <xsl:with-param name="fieldName" select="'dateOfChange'" <br /> <h2>Request Firewall Change Form</h2> <xsl:with-param name="renderCmd" select="'title'" /> </td> </xsl:call-template> tr> <tr> <td <font colorclass="headercell5" colspan="#ff0000100%">*</font> <b>Request Details</b> </td> </tr> <tr> <td class="datacellthnormal"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'dateOfChange'" /> <xsl:with-param name="renderCmd" select="'inputtitle'" /> <xsl:with-param name="readOnly" select="$isPastInitiated" /></xsl:call-template> <font color="#ff0000">*</xsl:call-template>font> </td> </tr> <tr> <td class="thnormaldatacell"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'descriptionOfChangedateOfChange'" /> <xsl:with-param name="renderCmd" select="'titleinput'" /> </xsl:call-template> <xsl:with-param name="readOnly" select="$isPastInitiated" /> <font color="#ff0000">*</font>xsl:call-template> </td> </tr> <tr> <td class="datacellthnormal"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'descriptionOfChange'" /> <xsl:with-param name="renderCmd" select="'inputtitle'" /> <xsl:with-param name="readOnly" select="$isPastInitiated" /></xsl:call-template> </xsl:call-template><font color="#ff0000">*</font> </td> </tr> <tr> <td class="thnormaldatacell"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'ingressEgressCharacteristicdescriptionOfChange'" /> <xsl:with-param name="renderCmd" select="'title'" input'" /> <xsl:with-param name="readOnly" select="$isPastInitiated" /> </xsl:call-template> </td> <font color="#ff0000">* </font>tr> <tr> </td> <td class="datacellthnormal"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'ingressEgressCharacteristic'" /> <xsl:with-param name="renderCmd" select="'inputtitle'" /> <xsl:with-param name="readOnly" select="$isPastInitiated" /></xsl:call-template> </xsl:call-template><font color="#ff0000">*</font> </td> </tr> <td class="datacell"> <tr> <td class="thnormal"><xsl:call-template name="widget_render"> <xsl:callwith-templateparam name="widget_render"fieldName" select="'ingressEgressCharacteristic'" /> <xsl:with-param name="fieldNamerenderCmd" select="'destinationSourceSpecificationinput'" /> <xsl:with-param name="renderCmdreadOnly" select="'title'$isPastInitiated" /> </xsl:call-template> </td> <font color="#ff0000">* </font>tr> <tr> </td> <td class="datacellthnormal"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'destinationSourceSpecification'" /> <xsl:with-param name="renderCmd" select="'inputtitle'" /> <xsl:with-param name="readOnly" select="$isPastInitiated" /></xsl:call-template> <font color="#ff0000">*</xsl:call-template>font> </td> </tr> <tr> <td class="thnormaldatacell"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'termOfRuleChangedestinationSourceSpecification'" /> <xsl:with-param name="renderCmd" select="'titleinput'" /> </xsl:call-template> <xsl:with-param name="readOnly" select="$isPastInitiated" /> <font color="#ff0000">*</font> </xsl:call-template> </td> </tr> <tr> <td class="datacellthnormal"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'termOfRuleChange'" /> <xsl:with-param name="renderCmd" select="'inputtitle'" /> <xsl:with-param name="readOnly" select="$isPastInitiated" /></xsl:call-template> </xsl:call-template><font color="#ff0000">*</font> </td> </tr> <td class="datacell"> <tr> <td class="thnormal"><xsl:call-template name="widget_render"> <xsl:callwith-templateparam name="widget_render""fieldName" select="'termOfRuleChange'" /> <xsl:with-param name="fieldNamerenderCmd" select="'relatedProjectinput'" /> <xsl:with-param name="renderCmdreadOnly" select="'title'$isPastInitiated" /> </xsl:call-template> </td> <font color="#ff0000">* </font>tr> <tr> </td> <td class="datacellthnormal"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'relatedProject'" /> <xsl:with-param name="renderCmd" select="'inputtitle'" /> <xsl:with-param name="readOnly" select="$isPastInitiated" /></xsl:call-template> </xsl:call-template><font color="#ff0000">*</font> </td> </tr> <td class="datacell"> </table> <br xmlns<xsl:call-template name="widget_render" />> <xsl:template>

Create the Rule Template

...

...

1. with-param name="fieldName" select="'relatedProject'" /> <xsl:with-param name="renderCmd" select="'input'" />

...

1. <xsl:with-param name="readOnly" select="$isPastInitiated" />

...

...

...

Create Routing Rules

...

...

1. </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.

<?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<ruleTemplates xmlns="ns:workflow/RuleRuleTemplate" xsi:schemaLocation="ns:workflow/RuleRuleTemplate resource:RuleRuleTemplate">
	<rule><ruleTemplate>
      		<documentType>eDoc.RequestFirewallChange</documentType>
      		<ruleTemplate>eDoc.RequestFirewallChange<name>eDoc.RequestFirewallChange.Node1</ruleTemplate>name>
      		<description>Routing<description>eDocLite rule for eDocLite RequestFirewallChange.<RequestFirewallChange Routing</description>
  
   		<ignorePrevious>false<</ignorePrevious>ruleTemplate>
      		<responsibilities>
        		<responsibility>
          			<workgroup>eDoc.FirewallPolicyGroup.Workgroup</workgroup>
          			<actionRequested>A</actionRequested>
  </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.

<?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>
       			<priority>1</priority>
 <documentType>eDoc.RequestFirewallChange</documentType>
      		</responsibility><ruleTemplate>eDoc.RequestFirewallChange.Node1</ruleTemplate>
      		</responsibilities><description>Routing rule for eDocLite RequestFirewallChange.</description>
      		<ignorePrevious>false</ignorePrevious>
      		<responsibilities>
        		<responsibility>
          	</rule>
</rules>
</data>

XML File Ingestion

1. widgets.xml
2. Users
3. Workgroups
4. Rule Template
5. Parent Document Type
6. Child Document Types
7. EDL Form
8. Routing Rules

...

			<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:
   Image Added
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:
    Image Added
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:
    Image Added

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. Here's the form we just built:
   Image Removed
7. Fill out the form and click route
8. Log in as FPG1 FPG2
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:
    Image Removed
12. Click approve disapprove
13. Log in as requester1 again.
14. Click on Document Search and then Search Action List
15. Find the document approved disapproved by FPG1 FPG2. It's status should be FINAL DISAPPROVED
16. Click on the docuument
17. Click acknowledge
18. Click on Document Search and then Search
19. Find the document again
20. Click on the Log icon
21. The log should like like so:
    Image Removed Image Added

Reference

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