Page Comparison

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 more complex business processes and subprocesses.

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 , more decisions to be made (not necessarily by people), more notifications, a few subprocesses, a way of skipping steps in the process, and a way to "un-fulfill" a request that was already fulfilled and more levels of decision making (yikes!!!).

Instead of expanding on the workflow in the Simple Workflow tutorial, we will build a brand new workflow. Whereas the previous tutorial 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 conventions ( naming and styling conventions ) that will prevent our work from colliding with other departments' work and do so without confusing us at the same time (a daunting task when similar responsibilities are distributed all over a large organization). .

...

...

...

Also, instead of creating Users and Work Groups ourselves, we will leave that task to the Identity Management system. In production, 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.

Development Steps

1. Study the Business Process
2. Gather the Required Details
3. Create a Document Workflow Diagram
4. Request 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 Rule Attributes
9. Create the Rule Template
10. Create Routing Rules
11. Ingest XML Files
12. Simulate the Business Process

The Business Process

Image Removed
In using eDocLite to facilitate this process, we'll need a few things:

• A workflow diagram translated from the business process.
• A form to capture the request details initially. As the process goes on, the form must accept additional details.
• A way to bring the request to the attention of the Desktop Services, who will receive and do an initial review of the request, the Firewall Policy Group, who will review and approve or disapprove the request, and the Firewall Gatekeeper, who will fulfill the request.
• A way for the requester to get the details on the actions taken on the request.

...

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

Naming Conventions

Development Cycle

1. Model the Business Process
2. Model the Form Details
3. Model the Document Workflow
4. Create Validation Checklists
5. Procure Work Groups
6. 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
7. Implement Workflow Components
8. 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:

...

...

...

...

...

...

...

...

...

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:

Image Added

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:

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

The request details in....detail:

• The details we are asking from the Requester are almost the same as those in the Simple Workflow tutorial. This time we decided to split Source Specification and Destination Specification into two fields and allow for the Requester to tell us that this is an URGENT request.
• The details of the request don't stop there. As the process moves along, we want the other responsible parties to add detail to the form.
• Once Desktop Services fields the request, we want to capture whether the firewall modification being requested is already in effect or not. Depending on the answer, the workflow will route the form to the appropriate party.
• If the Firewall Policy Group decides to disapprove the request, we want to capture their reason for doing so.
• If the request is URGENT, and the Firewall Gatekeeper already modified the firewall rules, and the Firewall Policy Group disapproved the request afterward, we want our workflow to automatically check a box that prompts the Firewall Gatekeeper to revert the modification.

The Document Workflow Diagram

Here is a document workflow diagram based on our business process. It doesn't map exactly to our business process diagram, because we want to represent the state of the Request Firewall Change document as the responsible parties act upon it.

Let's lay down a few ground rules:

• The Request element is the first node (aka Start Node) in the workflow's route path. This is where the Request Firewall Change document is first created.
• Each violet element represents a subsequent 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 docuement.
• Each lavender parallelogram represents a rule template that is applied to each node. Each rule template can be associated with a set of rules.
• The orange skittle represents a split in the workflow. If the request is URGENT, the workflow branches out one way. If not, it branches out the other way.
• The lime skittle represents a join in the workflow. No matter which way the workflow branched, it will end up at this point.
• The green Finish element means the workflow has ended with flying colors.
• The red Acknowledge and Finish elements mean that somewhere in the workflow there was a disapproval. Therefore the entire workflow stops. Out of the box, eDocLite routes the disapproved request back to the Requester for acknowledgment.

Image Removed

Request Work Groups

After going through the easy and expedient process of requesting Work Groups, the Kuali Rice administrator has notified us that the following groups are available for use in our workflow:

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.

Image Added

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

Create Validation Checklists

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

Let's build another one for urgent requests:

And another one for non-urgent requests that are disapproved:

Procure Roles

Looking at our workflow diagram, we build a table responsibility matrix documenting who should act on which node and what action we're requesting of them:. We'll use this later when we build our set of rules.

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 a hierarchy of child document types that inherit attributes of their parents.

Let's use the convention <process name>.eDoc.ParentDocType for naming Parent Document Types. Let's also use the same convention for naming the XML file.

<?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>RequestFirewallChange.eDoc.ParentDocType</name>
		<description>Request Firewall Change eDocLite Parent Document Type</description>
		<label>Request Firewall Change eDocLite Parent Document Type</label>
		<blanketApprovePolicy>NONE</blanketApprovePolicy>
		<docHandler>${workflow.url}/EDocLite</docHandler>
		<active>true</active>
		<routingVersion>2</routingVersion>
	</documentType>
</documentTypes>
</data>

Create the Child Document Type

Here we create one child document type to support the behavior of our workflow. 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.

Let's use the following naming conventions:

...

After going through the easy and expedient process of requesting work groups, the Kuali Rice administrator has notified us that the following roles are available for use in our workflow:

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 a hierarchy of child document types that inherit attributes of their parents.

<?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>RequestFirewallChange.eDoc.ChildDocType<ParentDocType</name>
		<parent>RequestFirewallChange.eDoc.ParentDocType</parent>
		<description>Request Firewall Change eDocLite ChildParent Document Type</description>
		<label>Request Firewall Change eDocLite ChildParent Document Typee<Type</label>
		<postProcessorName>edu.iu.uis.eden.edl.EDocLitePostProcessor</postProcessorName>
		<superUserWorkgroupName>ucd.IET.AppDev.KualiRice.SysAdmin.Workgroup</superUserWorkgroupName>
		<defaultExceptionWorkgroupName>ucd.IET.AppDev.KualiRice.SysAdmin.Workgroup</defaultExceptionWorkgroupName>
		<blanketApprovePolicy>NONE</blanketApprovePolicy>
		<docHandler>${workflow.url}/EDocLite</docHandler>
		<active>true</active>
		<routingVersion>2</routingVersion>
		<routePaths>
			<routePath>
          			<start name="RequestFirewallChange.eDoc.Request.Node" nextNode="RequestFirewallChange.eDoc.ReviewCurrentConfiguration.Node" />
		          	<requests name="RequestFirewallChange.eDoc.ReviewCurrentConfiguration.Node" nextNode="RequestFirewallChange.eDoc.isUrgent.Split" />
				<split name="RequestFirewallChange.eDoc.isUrgent.Split" nextNode="RequestFirewallChange.eDoc.AcknowledgeConfiguration.Node">
					<branch name="RequestFirewallChange.eDoc.isUrgent.Branch">
						<requests name="RequestFirewallChange.eDoc.FulfillUrgentRequest.Node" nextNode="RequestFirewallChange.eDoc.ReviewUrgentRequest.Node" />
						<requests name="RequestFirewallChange.eDoc.ReviewUrgentRequest.Node" nextNode="RequestFirewallChange.eDoc.isUrgent.Join" />
					</branch>
					<branch name="RequestFirewallChange.eDoc.isNotUrgent.Branch">
						<requests name="RequestFirewallChange.eDoc.ReviewRequest.Node" nextNode="RequestFirewallChange.eDoc.FulfillRequest.Node" />
						<requests name="RequestFirewallChange.eDoc.FulfillRequest.Node" nextNode="RequestFirewallChange.eDoc.isUrgent.Join" />
					</branch>
					<join name="RequestFirewallChange.eDoc.isUrgent.Join" />
				</split>
				<requests name="RequestFirewallChange.eDoc.AcknowledgeConfiguration.Node" />
        	      </routePath>
		</routePaths>
	      <routeNodes></documentType>
</documentTypes>
</data>

Create the Child Document Type

Here we create a Child Document Type that identifies the route path and route nodes based on our workflow diagram.

First, we build a table documenting the routePath, the routeNodes and the ruleTemplate applied to each node:

The resulting XML looks like so:

<?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>RequestFirewallChange.eDoc.ChildDocType</name>
		<parent>RequestFirewallChange.eDoc.ParentDocType</parent>
		<description>Request Firewall Change eDocLite Child Document Type</description>
		<label>Request Firewall Change eDocLite Child Document Type</label>
		<postProcessorName>edu.iu.uis.eden.edl.EDocLitePostProcessor</postProcessorName>
		<superUserWorkgroupName>ucd.IET.AppDev.KualiRice.SysAdmin.Workgroup</superUserWorkgroupName>
		<defaultExceptionWorkgroupName>ucd.IET.AppDev.KualiRice.SysAdmin.Workgroup</defaultExceptionWorkgroupName>
		<docHandler>${workflow.url}/EDocLite</docHandler>
		<active>true</active>
		<routingVersion>2</routingVersion>
		<routePaths>
			<routePath>
          			<start name="RequestFirewallChange.eDoc.Request.Node">
				<activationType>P</activationType>
			</start>
			Request" nextNode="ReviewCurrentConfiguration" />
		          	<requests name="RequestFirewallChange.eDoc.ReviewCurrentConfiguration.Node">
				<activationType>P</activationType>
				<ruleTemplate>RequestFirewallChange.eDoc.ReviewCurrentConfiguration.RuleTemplate</ruleTemplate>
			</requests>
			<split name="RequestFirewallChange.eDoc.isUrgent.Split nextNode="InitialApproval" />
				<requests name="InitialApproval" nextNode="FinalApproval" />
				<requests name="RequestFirewallChange.eDoc.FulfillUrgentRequest.Node">
				<activationType>P</activationType>
				<ruleTemplate>RequestFirewallChange.eDoc.FulfillUrgentRequest.RuleTemplate</ruleTemplate>
			</requests>
			FinalApproval" nextNode="AcknowledgeConfiguration" />
				<requests name="RequestFirewallChange.eDoc.ReviewUrgentRequest.Node">
				<activationType>P</activationType>AcknowledgeConfiguration" />
        	      </routePath>
		</routePaths>
	      <routeNodes>
			<start name="Request">
				<ruleTemplate>RequestFirewallChange.eDoc.ReviewUrgentRequest.RuleTemplate</ruleTemplate><activationType>P</activationType>
			</requests>start>
			<requests name="RequestFirewallChange.eDoc.ReviewRequest.NodeReviewCurrentConfiguration">
				<activationType>P</activationType>
				<ruleTemplate>RequestFirewallChange.eDoc.ReviewRequestReviewCurrentConfiguration.RuleTemplate</ruleTemplate>
			</requests>
			<requests name="RequestFirewallChange.eDoc.FulfillRequest.NodeInitialApproval">

				<activationType>P</activationType>
				<ruleTemplate>RequestFirewallChange.eDoc.FulfillRequestInitialApproval.RuleTemplate</ruleTemplate>
			</requests>
			<join name="RequestFirewallChange.eDoc.isUrgent.Join" />
			<requests name="RequestFirewallChange.eDoc.AcknowledgeConfiguration.NodeFinalApproval">
				<activationType>S<<activationType>P</activationType>
				<ruleTemplate>RequestFirewallChange.eDoc.AcknowledgeConfigurationFinalApproval.RuleTemplate</ruleTemplate>
			</requests>		
			<requests name="AcknowledgeConfiguration">
				<activationType>S</activationType>
				<ruleTemplate>RequestFirewallChange.eDoc.AcknowledgeConfiguration.RuleTemplate</ruleTemplate>
				<mandatoryRoute>false</mandatoryRoute>
				<finalApproval>false</finalApproval>
			</requests>
		</routeNodes>
	</documentType>
</documentTypes>
</data>

Create the eDocLite Form

Based First, we build a table documenting the fieldDefs (field definitions) 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.

Let's use the following naming conventions:

...

...

.

Now we build the data entry form:

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 RequestFirewallChange.eDoc.Form.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="RequestFirewallChange.eDoc.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="RequestFirewallChange.eDoc.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>RequestFirewallChange.eDoc.ChildDocType</docType> <definition>RequestFirewallChange.eDoc.Form</definition> <style>RequestFirewallChange.eDoc.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 RequestFirewallChange.eDoc.Form.xml
   <fieldDef name="dateOfChange" title="Date and Time for Change: MM/DD/YYYY"> <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 attributeName="RequestFirewallChange.eDoc.isUrgent.RuleAttribute" name="isUrgent" title="URGENT"> <display> <type>select</type> <values title="NO">NO</values> <values title="YES">YES</values> </display> <validation required="true"> <message>Is this request URGENT?</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="destinationSourceSpecificationsourceSpecification" 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="termOfRuleChangedestinationSpecification" title="TermDestination ofSpecification"> Rule Change (indefinite or otherwise)"> <display> <type>text<<type>textarea</type> <meta> <name>size<<name>rows</name> <value>50<<value>5</value> </meta> </display> <meta> <validation required="true"> <message>Enter term of the rule change.</message><name>cols</name> </validation> <<value>60</fieldDef>value> <fieldDef name="relatedProject" title="Project Related to Requested Rule(s) Change"> <display> <type>text</type> </meta> <meta> <name>size<<name>wrap</name> <value>50<<value>hard</value> </meta> </display> <validation required="true"> <message>Enter athe related project to the requested rule changedestination specification.</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.

   Code Block
   title RequestFirewallChange.eDoc.Form.xml
   <xsl:template <fieldDef name="mainBodytermOfRuleChange"> title="Term of Rule Change <table xmlns="" align="center" border="0" cellpadding="0" cellspacing="0" class="bord-r-t" width="80%"> (indefinite or otherwise)"> <display> <tr> <type>text</type> <td align="left" border="3" class="thnormal" colspan="1"> <meta> <br <name>size</>name> <h3><value>50</value> </meta> University of California, Davis</display> <validation required="true"> <br /> <message>Enter term of the rule change.</message> eDoclite Tutorial </validation> </h3>fieldDef> <fieldDef name="relatedProject" title="Project Related to Requested <br /Rule(s) Change"> <display> </td> <type>text</type> <td align="center" border="3" class="thnormal" colspan="2"> <meta> <br /> <name>size</name> <h2>Request Firewall Change Form<<value>50</h2>value> </td>meta> </tr>display> <tr> <td class="headercell5" colspan="100%<validation required="true"> <b>Request<message>Enter Details</b>a related project to the requested rule change.</td>message> </tr>validation> </fieldDef> <tr>

   
   
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 RequestFirewallChange.eDoc.Form.xml
   <xsl:template name="mainBody"> <table <td classxmlns="thnormal"> align="center" border="0" cellpadding="0" <xsl:call-template name="widget_render"> cellspacing="0" class="bord-r-t" width="80%"> <tr> <xsl:with-param name="fieldName" select="'dateOfChange'" /<td align="left" border="3" class="thnormal" colspan="1"> <br /> <xsl:with-param name="renderCmd" select="'title'" /> <h3> </xsl:call-template> University of <font color="#ff0000">*</font>California, Davis </td> <br /> <td class="datacell"> eDoclite Tutorial <xsl:call-template name="widget_render"></h3> <br /> <xsl:with-param name="fieldName" select="'dateOfChange'" /> </td> <xsl:with-param name="renderCmd" select="'input'" /<td align="center" border="3" class="thnormal" colspan="2"> <br /> <xsl:with-param name="readOnly" select="$isPastInitiated" / <h2>Request Firewall Change Form</h2> </td> </tr> <tr> <td class="headercell5" colspan="100%"> <b>Request </xsl:call-template>Details</b> </td> </tr> <tr> <td class="thnormal"> <xsl:call-template name="widget_render"> <xsl:with-param name="fieldName" select="'descriptionOfChangedateOfChange'" /> <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="'descriptionOfChangedateOfChange'" /> <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="'isUrgentdescriptionOfChange'" /> <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="'isURgentdescriptionOfChange'" /> <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="'ingressEgressCharacteristicisUrgent'" /> <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="'ingressEgressCharacteristicisURgent'" /> <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="'destinationSourceSpecificationingressEgressCharacteristic'" /> <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="'destinationSourceSpecificationingressEgressCharacteristic'" /> <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="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 Rule Attributes

Here we create a Rule Attribute that is associated with the isUrgent field in the form.

<?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">
<ruleAttributes xmlns="ns:workflow/RuleAttribute" xsi:schemaLocation="ns:workflow/RuleAttribute resource:RuleAttribute">
	<ruleAttribute>
      	<name>RequestFirewallChange.eDoc.isUrgent.RuleAttribute</name>
	      <className>edu.iu.uis.eden.routetemplate.xmlrouting.StandardGenericXMLRuleAttribute</className>
      	<label>Request Firewall Change Is Urgent Rule Attribute</label>
	      <description>Request Firewall Change Is Urgent Rule Attribute</description>
      	<type>RuleXmlAttribute</type>

      	<routingConfig>
        		<fieldDef name="isUrgent" title="URGENT" workflowType="ALL">
	          		<display>
            			<type>select</type>
            			<values title="NO">NO</values>
            			<values title="YES">YES</values>
             		</display>
          			<validation required="true" />
          			<fieldEvaluation>
            			<xpathexpression>//isUrgent = wf:ruledata('isUrgent')</xpathexpression>
          			</fieldEvaluation>
       		</fieldDef>
        		<xmlDocumentContent>
          			<isUrgent>%isUrgent%</isUrgent>
        		</xmlDocumentContent>
      	</routingConfig>
    </ruleAttribute>
</ruleAttributes>

</data>

Create Rule Templates

Here we create several Rule Templates that are applied to each route node.

First we document each ruleTemplate and any associated attributes:

<?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>RequestFirewallChange.eDoc.ReviewCurrentConfiguration.RuleTemplate</name>
      		<description>Review Current Configuration RuleTemplate</description>
	</ruleTemplate>
	<ruleTemplate>
      		<name>RequestFirewallChange.eDoc.InitialApproval.RuleTemplate</name>
      		<description>Initial Approval RuleTemplate</description>
      		<attributes>
        

...

			<attribute>
          				<name>RequestFirewallChange.eDoc.isUrgent.RuleAttribute</name>
     

...

...

...

...

  				<required>true</required>
        			</

...

attribute>
      		</attributes>

...

	</

...

ruleTemplate>
	<ruleTemplate>
      

...

		<name>RequestFirewallChange.eDoc.FinalApproval.RuleTemplate</name>
      

...

		<description>Final Approval RuleTemplate</description>
      		<attributes>
 

...

...

      			<attribute>
    

...

...

     				<name>RequestFirewallChange.eDoc.isUrgent.RuleAttribute</name>
       

...

...

...

 				<required>true</required>
        			</attribute>
    

...

...

 		</attributes>
	</ruleTemplate>
	<ruleTemplate>
      		<name>RequestFirewallChange.eDoc.AcknowledgeConfiguration.RuleTemplate</name>
   

...

   		<description>Acknowledge Configuration RuleTemplate</description> 
			<attributes>
				<attribute>
					<name>Initiator.Role.RuleAttribute</name>

...

					<required>true</required>
				</attribute>
			</attributes>
	</ruleTemplate>
</ruleTemplates>
</data>

Create Routing Rules

Finally, we create Rules that are associated with RequestFirewallChange.eDoc.ChildDocType and its associated rule templates. We apply the responsibility matrix we created way above.

<?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>RequestFirewallChange.eDoc.ChildDocType</documentType>
      		<ruleTemplate>RequestFirewallChange.eDoc.ReviewCurrentConfiguration.RuleTemplate</ruleTemplate>
      

...

		<description>Review Current Configuration Rule</description>
      		<ignorePrevious>false</ignorePrevious>
     

...

 		<responsibilities>
        		<responsibility>
   

...

...

			<workgroup>ucd.IET.DES.DevelopmentSupport.WorkGroup</workgroup>
      

...

...

			<actionRequested>A</actionRequested>
    

...

...

...

Create Rule Attributes

Here we create a Rule Attribute that is associated with the isUrgent field in the form. Let's use <process name>.eDoc.<rule attribute name>.RuleAttribute to name our rule attributes and <process name>.eDoc.RuleAttributes to name the associated XML file defining our collection of rule attributes.

<?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">
<ruleAttributes xmlns="ns:workflow/RuleAttribute" xsi:schemaLocation="ns:workflow/RuleAttribute resource:RuleAttribute">
	<ruleAttribute>
  			<priority>1</priority>
        		</responsibility>
      		</responsibilities>
    	<name>RequestFirewallChange.eDoc.isUrgent.RuleAttribute</name></rule>
	<rule>
      <className>edu		<documentType>RequestFirewallChange.iu.uis.eden.routetemplate.xmlrouting.StandardGenericXMLRuleAttribute</className>eDoc.ChildDocType</documentType>
      	<label>Request Firewall Change Is Urgent Rule Attribute</label>
	      <description>Request Firewall Change Is Urgent Rule Attribute<	<ruleTemplate>RequestFirewallChange.eDoc.InitialApproval.RuleTemplate</ruleTemplate>
      		<description>Initial Approval By Firewall SysAdmin Rule</description>
      	<type>RuleXmlAttribute<	<ignorePrevious>false</type>ignorePrevious>
      	<routingConfig>	<ruleExtensions>
        			<fieldDef<ruleExtension>
name="isUrgent" title="URGENT" workflowType="ALL"> 	      	    			<display><attribute>RequestFirewallChange.eDoc.isUrgent.RuleAttribute</attribute>
            				<type>select</type>
<ruleTemplate>RequestFirewallChange.eDoc.InitialApproval.RuleTemplate</ruleTemplate>
           				<values title="NO">NO</values><ruleExtensionValues>
             					<values title="YES">YES</values><ruleExtensionValue>
              		</display>				<key>isUrgent</key>
              					<validation required="true" />	<value>YES</value>
            					<fieldEvaluation></ruleExtensionValue>
            				<xpathexpression>//isUrgent = wf:ruledata('isUrgent')</xpathexpression>
 ruleExtensionValues>
        			</fieldEvaluation>ruleExtension>
	       		</fieldDef>
 ruleExtensions>
      		<xmlDocumentContent><responsibilities>
        		<responsibility>
 			<isUrgent>%isUrgent%</isUrgent>         			</xmlDocumentContent>
<workgroup>ucd.IET.DCCS.FirewallSysAdmin.Workgroup</workgroup>
     	</routingConfig>     </ruleAttribute>
</ruleAttributes>
</data>

Create Rule Templates

Here we create several Rule Templates that are applied to each route node. Let's use <process name>.eDoc.<rule template name>.RuleTemplate to name our rule templates and <process name>.eDoc.RuleTemplates to name the associated XML file defining our collection of rule templates.

<?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>			<actionRequested>A</actionRequested>
          			<priority>1</priority>
        		<name>RequestFirewallChange.eDoc.ReviewCurrentConfiguration.RuleTemplate</name></responsibility>
      		<description>ReviewCurrentConfiguration RuleTemplate</description></responsibilities>
    	</ruleTemplate>
	<ruleTemplate>rule>
	<rule>
      		<documentType>RequestFirewallChange.eDoc.ChildDocType</documentType>
      		<name>RequestFirewallChange<ruleTemplate>RequestFirewallChange.eDoc.FulfillUrgentRequestInitialApproval.RuleTemplate</name>ruleTemplate>
      		<description>FulfillUrgentRequest RuleTemplate</description>
	</ruleTemplate>
	<ruleTemplate><description>Initial Approval By Firewall Policy Group Rule</description>
       		<name>RequestFirewallChange.eDoc.ReviewUrgentRequest.RuleTemplate</name><ignorePrevious>false</ignorePrevious>
      		<description>ReviewUrgentRequest RuleTemplate</description>
	</ruleTemplate>
	<ruleTemplate><ruleExtensions>
        			<name>RequestFirewallChange.eDoc.ReviewRequest.RuleTemplate</name><ruleExtension>
       		<description>ReviewRequest RuleTemplate</description> 	</ruleTemplate> 	<ruleTemplate>
      		<name>RequestFirewallChange<attribute>RequestFirewallChange.eDoc.FulfillRequestisUrgent.RuleTemplate<RuleAttribute</name>attribute>
        		<description>FulfillRequest RuleTemplate</description> 	</ruleTemplate>
	<ruleTemplate>
      		<name>RequestFirewallChange<ruleTemplate>RequestFirewallChange.eDoc.AcknowledgeConfigurationInitialApproval.RuleTemplate</name>ruleTemplate>
       		<description>AcknowledgeConfiguration RuleTemplate</description> 			<attributes> 				<attribute>
					<name>Initiator.Role.RuleAttribute</name>
					<required>true</required>
				</attribute>
			</attributes>
	</ruleTemplate>
</ruleTemplates>
</data>

Create Routing Rules

Finally, we create Routing Rules that is associated with RequestFirewallChange.eDoc.ChildDocType and its associated rule templates. Let's use <process name>.eDoc.RoutingRules to name the associated XML file defining our collection of routing rules.

<?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><ruleExtensionValues>
            					<ruleExtensionValue>
              						<key>isUrgent</key>
              						<value>NO</value>
            			<documentType>RequestFirewallChange.eDoc.ChildDocType</documentType>		</ruleExtensionValue>
          		<ruleTemplate>RequestFirewallChange.eDoc.ReviewCurrentConfiguration.RuleTemplate</ruleTemplate>		</ruleExtensionValues>
        		<description>ReviewCurrentConfiguration Routing Rule</description>
	</ruleExtension>
	      		<ignorePrevious>false<</ignorePrevious>ruleExtensions>
      		<responsibilities>
        		<responsibility>
          			<workgroup>ucd.IET.DESAppDev.DevelopmentSupportFirewallPolicyGroup.WorkGroup <Workgroup</workgroup>
          			<actionRequested>A</actionRequested>
          			<priority>1</priority>
        		</responsibility>
      		</responsibilities>
    	</rule>
	<rule>
      		<documentType>RequestFirewallChange.eDoc.ChildDocType</documentType>
      		<ruleTemplate>RequestFirewallChange.eDoc.FulfillUrgentRequestFinalApproval.RuleTemplate</ruleTemplate>
      		<description>FulfillUrgentRequest Routing<description>Final Approval By Firewall SysAdmin Rule</description>
      		<ignorePrevious>false</ignorePrevious>
      		<ruleExtensions>
        			<ruleExtension>
 		<responsibilities>        	 			<responsibility><attribute>RequestFirewallChange.eDoc.isUrgent.RuleAttribute</attribute>
          			<workgroup>ucd	<ruleTemplate>RequestFirewallChange.IETeDoc.DCCSFinalApproval.FirewallSysAdmin.Workgroup<RuleTemplate</workgroup>ruleTemplate>
          			<actionRequested>K</actionRequested>	<ruleExtensionValues>
            					<priority>1</priority><ruleExtensionValue>
              						</responsibility><key>isUrgent</key>
              						<<value>NO</responsibilities>value>
    	</rule> 	<rule>       					<documentType>RequestFirewallChange.eDoc.ChildDocType</documentType></ruleExtensionValue>
          				<ruleTemplate>RequestFirewallChange.eDoc.ReviewUrgentRequest.RuleTemplate</ruleTemplate></ruleExtensionValues>
        			<description>ReviewUrgentRequest Routing Rule</description>
</ruleExtension>
	      		<ignorePrevious>false<</ignorePrevious>ruleExtensions>
      		<responsibilities>
        		<responsibility>
          			<workgroup>ucd.IET.AppDevDCCS.FirewallPolicyGroupFirewallSysAdmin.Workgroup <Workgroup</workgroup>
          			<actionRequested>A</actionRequested>
          			<priority>1</priority>
        		</responsibility>
      		</responsibilities>
    	</rule>
	<rule>
      		<documentType>RequestFirewallChange.eDoc.ChildDocType</documentType>
      		<ruleTemplate>RequestFirewallChange.eDoc.ReviewRequestFinalApproval.RuleTemplate</ruleTemplate>
      		<description>ReviewRequest Routing<description>Final Approval By Firewall Policy Group Rule</description>
      		<ignorePrevious>false</ignorePrevious>
      		<responsibilities><ruleExtensions>
        		<responsibility>	<ruleExtension>
         	 			<workgroup>ucd.IET.AppDev.FirewallPolicyGroup.Workgroup </workgroup><attribute>RequestFirewallChange.eDoc.isUrgent.RuleAttribute</attribute>
          				<ruleTemplate>RequestFirewallChange.eDoc.FinalApproval.RuleTemplate</ruleTemplate>
          				<actionRequested>A</actionRequested><ruleExtensionValues>
            					<priority>1</priority><ruleExtensionValue>
              						</responsibility><key>isUrgent</key>
              				<		<value>YES</responsibilities>value>
    	</rule> 	<rule>       		<documentType>RequestFirewallChange.eDoc.ChildDocType</documentType>			</ruleExtensionValue>
          				<ruleTemplate>RequestFirewallChange.eDoc.FulfillRequest.RuleTemplate</ruleTemplate></ruleExtensionValues>
        			<description>FulfillRequest Routing Rule</description>
</ruleExtension>
	      		<ignorePrevious>false<</ignorePrevious>ruleExtensions>
      		<responsibilities>
        		<responsibility>

          			<workgroup>ucd.IET.DCCSAppDev.FirewallSysAdminFirewallPolicyGroup.Workgroup</workgroup>
          			<actionRequested>A</actionRequested>
          			<priority>1</priority>
        		</responsibility>
      		</responsibilities>
    	</rule>
	<rule>
      		<documentType>RequestFirewallChange.eDoc.ChildDocType</documentType>
      		<ruleTemplate>RequestFirewallChange.eDoc.AcknowledgeConfiguration.RuleTemplate</ruleTemplate>
      		<description>AcknowledgeConfiguration<description>Acknowledge RoutingConfiguration Rule</description>
      		<ignorePrevious>true</ignorePrevious>
      		<responsibilities>
        		<responsibility>
          			<role>edu.iu.uis.eden.routetemplate.InitiatorRoleAttribute!INITIATOR</role>
				<approvePolicy>F</approvePolicy>
          			<actionRequested>K</actionRequested>
          			<priority>1</priority>
        		</responsibility>
      		</responsibilities>
    	</rule>
</rules>
</data>

...

XML File Ingestion

Now, we take all that we have built and upload it to a Kuali Rice server using the XML Ingestion tool.

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:

   Rule Attributes	RequestFirewallChange.eDoc.RuleAttributes.xml
   Rule Templates	RequestFirewallChange.eDoc.RuleTemplates.xml
   Parent Document Type	RequestFirewallChange.eDoc.ParentDocType.xml
   Child Document Types	RequestFirewallChange.eDoc.ChildDocType.xml
   EDL Form	RequestFirewallChange.eDoc.Form.xml
   Routing Rules: RequestFirewallChange.eDoc.RoutingRules.xml Rules:	RequestFirewallChange.eDoc.Rules.xml

   Info
   In production, each department will submit all XML files to the Kuali Rice team via a formal collaborative process.

Simulate the Business Process

First, letLet'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 RequestFirewallChange.eDoc.Form
5. Click on Create Document
6. Here's the form we built:
   Image Removed
7. Fill out the form, set URGENT to NO and click route
8. Log in as DES1
9. Click on Action List
10. Find and open 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
13. Log in as FPG1
14. Click on Action List
15. Find and open the document initiated by requester1 and approved by DES1. Its status should be ENROUTE
16. Click approve
17. Login as DCCS1
18. Click on Action List
19. Find and open the document initiated by requester1, approved by DES1, and approved by FPG1. Its status should be PROCESSED
20. Click acknowledge
21. Log in as requester1 again
22. Click Search
23. Find the eDocLite whose Definition Name is RequestFirewallChange.eDoc.Form
24. Click on Create Document
25. Here's the form we built:
    Image Added
26. Fill out the form, set URGENT to NO and click route
27. Log in as DES1
28. Click on Action List
29. Find and open the document initiated by requester1, approved by DES1, approved by FPG1, and acknowledged by DCCS1. Its status should be PROCESSED ENROUTE
30. Click acknowledge
31. Click Document Search
32. Find the document again
33. Click on the Log icon
34. The log should like on the document and it should look like so:
    Image Removed

...

1. Image Added
2. Click approve
3. Login as DCCS1
4. Click on Action List. The document should not be in DCCS1's Action List.
5. Log in as requester1 FPG1
6. Click on EDocLitesClick Search Action List
7. Find the eDocLite whose Definition Name is eDoc.RequestFirewallChange.Form
8. Click on Create Document
9. Fill out the form and click route
10. Log in as FPG2and open the document initiated by requester1 and approved by DES1. Its status should be ENROUTE
11. Click approve
12. Login as DCCS1
13. Click on Action List
14. Find and open the document initiated by requester1by requester1, approved by DES1, and approved by FPG1. Its status should be ENROUTE
15. Click on the document
16. Click disapprove
17. approve
18. Log in as requester1 again
19. Click on Action List
20. Find and open the document disapproved by FPG2. It's status should be DISAPPROVEDClick on the docuumentinitiated by requester1, approved by DES1, approved by FPG1, and acknowledged by DCCS1. Its status should be PROCESSED
21. Click acknowledge
22. Click on Document Search and then Search
23. Find the document again
24. Click on the Log icon
25. 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
https://test.kuali.org/confluence/display/KULRICE/EDoclite+Support+Notes
https://test.kuali.org/confluence/display/KULRICE/KEW+Rules
https://test.kuali.org/confluence/display/KULRICE/Routing+Components+and+Configuration+Guide