...
| Code Block | ||
|---|---|---|
| ||
<?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>
|
...
Note:
...
Create the Child Document Types
Here we create one child document type to support the behavior of our particular Firewall Request Changeworkflow. 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
Let's use the convention <process name>.eDoc.ChildDocType for naming Child Document Types and associated XML files.
| Code Block | ||
|---|---|---|
| ||
<?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<name>RequestFirewallChange.eDoc.RequestFirewallChange<ChildDocType</name> <parent>eDoc<parent>RequestFirewallChange.RequestFirewallChangeeDoc.Parent<ParentDocType</parent> <description>eDoc.RequestFirewallChange<description>Request Firewall Change eDocLite Child Document Type</description> <label>eDoc.RequestFirewallChange<label>Request Firewall Change eDocLite Child Document Type<Typee</label> <postProcessorName>edu.iu.uis.eden.edl.EDocLitePostProcessor</postProcessorName> <superUserWorkgroupName>eDoc.FirewallPolicyGroup<superUserWorkgroupName>ucd.IET.AppDev.KualiRice.SysAdmin.Workgroup</superUserWorkgroupName> <defaultExceptionWorkgroupName>eDoc.FirewallPolicyGroup<defaultExceptionWorkgroupName>ucd.IET.AppDev.KualiRice.SysAdmin.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:
...
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:
...