Overview
Development Steps
- Create Users
- Create Workgroups
- Create the Parent Document Type
- Create the Child Document Type
- Create the eDocLite Form
- Create the Definition
- Create the Stylesheet
- Create the Rule Template
- Create Routing Rules
The Business Process
The Request 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.
<?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 Workgroups
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>
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, workgroup names will tend to be long as a result of several UCD departments using eDocLite:
|
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, workgroups, etc., but use the same form, have the same super user workgroup, 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.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: |
Here we define the superUserWorkgroupName as eDoc.FirewallPolicyGroup.Workgroup. In production, the super user workgroup will likely be the group of eDocLite super users or Kuali Rice system administrators (some systemwide administrative group). Create the Child Document TypesRFC-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> Create the eDocLite Form
|
Create the Rule Template
<?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
<?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:
- Users: RFC-Users.xml
- Workgroups: RFC-Workgroup.xml
- Rule Template: RFC-Users.xml
- Parent Document Type: RFC-ParentDocType.xml
- Child Document Types: RFC-ChildDocTypes.xml
- EDL Form: RFC-EDLForm.xml
- 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