Session 2 will cover advanced options for configuring workflows beyond what is available on the administrative screens, including a case-study of implementing a unit hierarchy routing node. Technical attendees not familiar with KEW functionality are encouraged to attend the Session 1 as well. Both sessions will also provide information on where to find resources for further learning.
2. Quick review of key topics
KEW Routing Components
The KEW Document Type Config file
Building a Proposal Development workflow
Other features to explore
3. In KC, business data and processes are
encapsulated within a document (eg Proposal
Development Document)
The document workflow – routing, approvals,
etc. – is implemented using the Rice module
Kuali Enterprise Workflow (KEW)
Kuali Identity Management (KIM) also
provides hooks for workflow routing
4. XML configuration file
Describes features and behavior of the
document to KEW, including its routing and
approval chain – AKA the Process Definition
ProposalDevelopmentDocument.xml
5. Parent – the parent document type. Document
types are hierarchical – attributes are inherited
from the parent and can be overridden.
Also useful for assigning KIM roles at
document type – e.g., assign admin role to all
Preaward maintenance documents
<documentType>
…
<parent>KC</parent>
7. <postProcessorName>org.kuali.rice.kns.workflow.postprocessor.Kuali
PostProcessor</postProcessorName>
A Java class that will be called after a KEW
action is taken on a document.
This allows documents to code some special
behavior after certain steps in the routing.
For example, we use the doRouteStatusChange
postprocessor hook to set custom statuses on
the proposal development document
8. <superUserGroupName namespace="KC-WKFLW">OSP Superuser</
superUserGroupName>
A group of users who can take super user
administrative actions on the document
<defaultExceptionGroupName namespace="KC-WKFLW">ProposalAdmin</
defaultExceptionGroupName>
The group of users who will get an action
request for the document if there is a problem
with the routing and it goes into exception
routing
10. <policy>
<name>DOCUMENT_STATUS_POLICY</name>
<stringValue>app</stringValue>
</policy>
Policies – Allow you to configure behavior on a
doc type basis
DOCUMENT_STATUS_POLICY – Display KEW
route status or custom application document status
(status specific to that document)
LOOK_FUTURE – Display the future action requests
panel on the route log (screen shot)
11. Attributes
Render fields specific to this document on doc
search, action list, etc
See document search screen
<attribute>
<name>AggregatorSearchAttribute</name>
</attribute>
14. Route Path – The order in which route nodes
are visited during the document workflow
Route Nodes – Details about each node
Route Path plus Route Nodes is referred to as
the Process Definition
15. Route nodes – The stops on the route path.
Many different types of nodes but we will look
at 3: requests, role, dynamic.
Rule Attributes – Tell KEW how to find data
within the document used to make routing
decisions. For example, here’s how to find the
lead unit.
Rule – Tell KEW what to do when certain
conditions are met. For example, when the
lead unit is BL-CHEM, route to this person for
approval.
16. Rule Template
Defines the rule attributes needed to evaluate the
node – e.g., a Unit Number
Links doc types, rules and rule attributes.
Indirection layer that allows reuse of the various
components, ie a rule attribute can be used by
multiple document types.
17. In KIM, permissions and responsibilities are
assigned to Roles, and Roles are assigned to
Principals (users)
Permissions are for authorizations
Responsibilities trigger KEW action requests –
role-based nodes will route based on KIM
Responsibilities
Requests nodes will route based on KEW rules
18. Approval Request
Initiator/Aggregator Principal Investigator
submits into routing
Approval
Request
Departmental Approval Request Preaward Specialist
Approvers Group
Delegation
Approval
Request Acknowledge for
Submission to
OSP Office Sponsor
19. First, build the route path.
Need to keep the split for proposal hierarchy.
Will talk more about split nodes later.
Start at initiated node – document is in
initialized/saved state. Initiator will have a
complete request.
Define the next nodes until we join back up
from the split.
21. Next, configure the route nodes.
activationType – Parallel or Serial. If the node generates
multiple requests, should they all go out at once (parallel)
or should they be staggered based on the priority defined
in the rule (serial)
mandatoryRoute – There should be at least one recipient
at this node; if not, go into exception routing.
finalApproval – This should be the last node that
generates approval requests, if not, go into exception
routing
forceAction – If true, the user should approve again even
if they approved earlier in the routing
22. Initial Node – Not yet submitted; places a
complete request in Initiator’s Action List
See route log screen
<start name="Initiated">
<activationType>P</activationType>
<mandatoryRoute>false</mandatoryRoute>
<finalApproval>false</finalApproval>
</start>
23. Route to PI / CO-PI’s / Key Investigators
Based on KIM Role, not rules
Will send to Roles with ProposalPersons
responsibility for this Proposal
See responsibility screen
<routeNodes>
…
<role name="ProposalPersons">
<qualifierResolver>ProposalPersonsXPathQualifierResolver</qualifierResolver>
<activationType>P</activationType>
<finalApproval>false</finalApproval>
</role>
…
</routeNodes>
24. To resolve the role, KIM needs a proposal
number qualifier.
XPathQualifierResolver – Tell KEW how to find
data in document XML.
<ruleAttribute>
<name>ProposalPersons-XPathQualifierResolver</name>
<className>org.kuali.rice.kew.role.XPathQualifierResolver</className>
<resolverConfig>
<qualifier name="proposal">
<xPathExpression>//document/developmentProposalList[1]/
org.kuali.kra.proposaldevelopment.bo.DevelopmentProposal[1]/proposalNumber
[1]</xPathExpression>
</qualifier>
</resolverConfig>
</ruleAttribute>
25. You can look at the XML for a specific
document using the Document Operation
screen
See Document Operation screen
<documentContent><applicationContent><org.kuali.kra.workflow.KraDocument
XMLMaterializer>
...
<developmentProposalList >
<org.kuali.kra.proposaldevelopment.bo.DevelopmentProposal>
<proposalNumber>10000</proposalNumber>
...
</documentContent>
26. Role-based routing
Specify NullQualifierResolver because this is
not based on rules or document roles – based
on KIM responsibility
See Preaward Specialist role screen
<role name="PreawardSpecialistInitial">
<qualifierResolverClass>org.kuali.rice.kew.role.NullQualifierResolver</
qualifierResolverClass>
<activationType>P</activationType>
<finalApproval>false</finalApproval>
</role>
27. Rule-based requests node
Again, we use Xpath to tell KEW how to find
the data it needs to make a routing decision,
then specify a rule for that data
All linked by rule template
<requests name="DepartmentApproval">
<ruleTemplate>DepartmentApproval</ruleTemplate>
<activationType>S</activationType>
<finalApproval>false</finalApproval>
</requests>
28. The rule template links to the rule attribute
which provides the unit number
<ruleTemplate>
<name>DepartmentApproval</name>
<description>Department Approval Routing Rule</description>
<attributes>
<attribute>
<name>DepartmentApprovalAttribute</name>
<required>false</required>
</attribute>
</attributes>
</ruleTemplate>
32. The rule says that if the unit number is IN-
CARD, send an action request to Inez Chew
Could also be a group or role
What if I need to route a hierarchy – school,
campus? Will see in a minute.
See rules editor screen
33. Same as preaward specialist group, except here
we have a delegation
See Role screen
<role name="OSPOffice">
<qualifierResolverClass>org.kuali.rice.kew.role.NullQualifierResolver</
qualifierResolverClass>
<activationType>P</activationType>
<finalApproval>false</finalApproval>
</role>
34. Going back to the preaward specialists for
submission to Sponsor.
However, this time we are just using an
Acknowledge request so the document can
proceed to Processed status. See role screen.
<role name="PreawardSpecialistFinal">
<qualifierResolverClass>org.kuali.rice.kew.role.NullQualifierResolver</
qualifierResolverClass>
<activationType>P</activationType>
<forceAction>true</forceAction>
<finalApproval>false</finalApproval>
</role>
35. Ingest XML config files; KEW parses the files
and inserts data into KEW tables
See ingester screen
36.
37. For unit hierarchy routing – build an approval
chain dynamically based on your KC unit
hierarchy
Implement the KEW HierarchyProvider
interface – tell KEW how to build a DOM tree
Replace the Department node with a dynamic
node
40. University Unit Hierarchy
Proposal Approval Units
Tree
edu.iu.uits.kra.workflow.engin.node.hierarchyrouting.SimpleHierarchyPr
ovider
41. NamedRuleSelector: Pick the rule for the given
Unit based on a string matching pattern
<rule>
<name>hierarchy-UA-VPIT-Approver</name>
<documentType>ProposalDevelopmentDocument</documentType>
<description>Unit Approver for UA-VPIT</description>
<forceAction>true</forceAction>
<responsibilities>
<responsibility>
<principalName>lsalander</principalName>
<actionRequested>A</actionRequested>
<priority>1</priority>
</responsibility>
</responsibilities>
</rule>
42. Graphical view of document hierarchy, Process
Definition, KEW roles/permissions/
responsibilities
See doc config screen
43. Different types of nodes – split/join nodes for
branched routing; email nodes; custom
nodes….
Different types of rule attributes/qualifier
resolvers – Java rule attributes, groovy,
DataDictionary…
Compound rules – e.g., route to the Co-PI’s
lead unit approvers if the total cost is over
100,000
And much more!
44. Rice 2.0 – Rule authoring user interface (fall
2011)
Will be able to hook into KEW for routing
Needed for functional equivalence with Coeus
45. http://wiki.kuali.org
KC Public Documentation
Rice Public Documentation
Collaboration lists
kc.technical.collab@kuali.org
rice.collab@kuali.org
Conferences
Kuali Days 2011 – kuali.org
rSmart Training
Rice Training – August 15 – 19
KC Training – August 22 – 26