<name>YOURSERVICE-DOCS.RuleDocument</name>
<parent>YOURSERVICE-DOCS</parent>
<description>Add/Modify Workflow rules</description>
<label>Add/Modify Workflow rules</label>

The section above defines the Document Type's name, its parent, description, and label. The name is used by the client application’s API to communicate with KEW. Here is a sample of code from the client application’s API communicating with KEW:

WorkflowDocument document = new WorkflowDocument(new NetworkIdVO("username"), "DocumentTypeName");
document.routeDocument("user inputted annotation");

The above code will route a document in KEW.

<postProcessorName>your.package.routetemplate.RulePostProcessor</postProcessorName>

The element above determines which class to use for the PostProcessor for this particular Document Type. This component receives event notifications as eDocs travel through routing.

<superUserWorkgroupName>WorkflowAdmin</superUserWorkgroupName>
<blanketApproveWorkgroupName>WorkgroupBlanketApprovers</blanketApproveWorkgroupName>

<defaultExceptionWorkgroupName>WorkflowAdmin</defaultExceptionWorkgroupName>

This section sets KEW managed workgroups in several roles in the Document Type.

<docHandler>https://yourlocalIP/en-prd/Rule.do?methodToCall=docHandler</docHandler>

The docHandler tells KEW where to forward users when they click an eDoc link. See Document Search for more information.

<notificationFromAddress>...@yourEmailServerIP</notificationFromAddress>

When KEW sends an email notification to a user regarding a document of this type, the From address on the message is the address specified here. This is helpful because users will often reply to the messages they receive from KEW, and this allows their responses to go to an appropriate address for the Document Type. This is an optional element. If it is not defined here, KEW uses the default From address. See the Installation Guide for more detail.

<active>true</active>

Use active to define the activeness of a Document Type. KEW does not allow anyone to create eDocs of an inactive Document Type.

<routePaths>
    <routePath>
        <start name="Adhoc Routing" nextNode="Rule routing Route Level" />
        <requests name="Rule routing Route Level" />
    </routePath>
</routePaths>

The above defines the path an eDoc will travel as it progresses through its life. Start and Requests are some of the standard node types used. There is only one stop each eDoc must make as it travels through workflow. The eDoc starts at the step Adhoc Routing and then progresses to the request node named Rule routing Route Level.

This section only defines the path the eDocs will travel. The nodes themselves are defined below.

<routeNodes>
    <start name="Adhoc Routing">
        <activationType>S</activationType>
        <mandatoryRoute>false</mandatoryRoute>
        <finalApproval>false</finalApproval>
    </start>
    <requests name="Rule routing Route Level">
        <activationType>S</activationType>
        <ruleTemplate>RuleRoutingTemplate</ruleTemplate>
        <mandatoryRoute>true</mandatoryRoute>
        <finalApproval>false</finalApproval>
    </requests>
</routeNodes>

This is the node definition XML. This determines certain behaviors each node can have.

Activation Type determines if Approve requests are activated all at once or one at a time. Any given requests node can generate multiple rules that can then generate multiple requests. The ActivationType value specifies if all action requests generated for all fired rules are activated immediately (P = parallel activation), or if the set of action requests generated by each rule are activated one after the other, according to rule order (S = sequential activation). Activation type is only relevant when multiple rules are generated.

Figure 3.22. Activation Type

The mandatoryRoute key determines if it’s mandatory to generate approval requests. If a route node is mandatory and it doesn't generate an approve request, the document is put in exception routing.

The finalapproval key determines if this node should be the last node that has an approve request. If approvals are generated after this step, the document is thrown into exception routing.

Finally, there is a request node named Rule routing Route Level with a key called ruleTemplate. This is our hook into the rule system for KEW:

<ruleTemplate>RuleRoutingTemplate</ruleTemplate>

And this is our hook into a route module:

<routeModule>package.your.ARouteModule</routeModule>

KEW contacts the route module when the document enters that route node and the route module returns Action Requests for KEW to deliver.

If the application integrating with KEW is using Rules to contain the routing data and RuleAttributes for document evaluation, then the routing configuration requires more XML. Below is an XML snippet that defines RuleAttribute; this is written in Java.

<?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>RuleRoutingAttribute</name>
            <className>org.kuali.rice.kew.rule.RuleRoutingAttribute</className>
            <label>RuleRoutingAttribute</label>
            <description>RuleRoutingAttribute</description>
            <type>RuleAttribute</type>
        </ruleAttribute>
    </ruleAttributes>
</data>

The above defines a RuleAttribute called RuleRoutingAttribute. RuleRoutingAttribute maps to the Java class org.kuali.rice.kew.rule.RuleRoutingAttribute. The type of this attribute is a RuleAttribute; essentially this means the RuleAttribute's behavior is determined in a Java class. There are also RuleAttributes made entirely from XML, but programming attributes is outside the scope of this Guide.

Finally, we need to tie the RuleAttribute to the Document Type. This is done using the RuleTemplate and it is defined using XML. The RuleTemplate schema below provides further explanation:

<?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>RuleRoutingTemplate</name>
            <description>RuleRoutingTemplate</description>
            <attributes>
                <attribute>
                    <name>RuleRoutingAttribute</name>
                    <required>true</required>
                </attribute>
            </attributes>
        </ruleTemplate>
    </ruleTemplates>
</data>

<attributes>
    <attribute>
        <name>RuleRoutingAttribute</name>
        <required>true</required>
    </attribute>
</attributes>

The RuleTemplate is the join between RuleAttributes and Document Types. In this way, we can reuse the same attribute declaration (and therefore Java logic) across Document Types.

Once the XML, condensed into a single file, is uploaded into KEW, eDocs of this type can be created and routed from a client application.

All the content in the code examples above is aggregated into a single file below with a single surrounding data tag:

<?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>RuleRoutingAttribute</name>
            <className>org.kuali.rice.kew.rule.RuleRoutingAttribute</className>
            <label>foo</label>
            <description>foo</description>
            <type>RuleAttribute</type>
        </ruleAttribute>
    </ruleAttributes>
    <ruleTemplates xmlns="ns:workflow/RuleTemplate" xsi:schemaLocation="ns:workflow/RuleTemplate resource:RuleTemplate">
        <ruleTemplate>
            <name>RuleRoutingTemplate</name>
            <description>RuleRoutingTemplate</description>
            <attributes>
                <attribute>
                    <name>RuleRoutingAttribute</name>
                    <required>true</required>
                </attribute>
            </attributes>
        </ruleTemplate>
    </ruleTemplates>
    <documentTypes xmlns="ns:workflow/DocumentType" xsi:schemaLocation="ns:workflow/DocumentType resource:DocumentType">
        <documentType>
            <name>EDENSERVICE-DOCS.RuleDocument</name>
            <parent>EDENSERVICE-DOCS</parent>
            <description>Add/Modify Workflow rules</description>
            <label>Add/Modify Workflow rules</label>
            <postProcessorName>org.kuali.rice.kew.postprocessor.RulePostProcessor</postProcessorName>
            <superUserGroupName namespace=KR-WKFLW”>WorkflowAdmin</superUserGroupName>
            <blanketApproveGroupName namespace=KR-WKFLW”>WorkflowAdmin</blanketApproveGroupName>
            <defaultExceptionGroupName></defaultExceptionGroupName>
            <docHandler>https://uisapp2.iu.edu/en-prd/Rule.do?methodToCall=docHandler</docHandler>
            <active>true</active>
            <routingVersion>1</routingVersion>
            <routePaths>
                <routePath>
                    <start name="Adhoc Routing" nextNode="Rule routing Route Level" />
                    <requests name="Rule routing Route Level" />
                </routePath>
            </routePaths>
            <routeNodes>
                <start name="Adhoc Routing">
                    <activationType>S</activationType>
                    <mandatoryRoute>false</mandatoryRoute>
                </start>
                <requests name="Workflow Document Routing">
                    <activationType>S</activationType>
                    <ruleTemplate>RuleRoutingTemplate</ruleTemplate>
                    <mandatoryRoute>true</mandatoryRoute>
                </requests>
            </routeNodes>
        </documentType>
    </documentTypes>
</data>