Kuali Rice at Indiana University

Important Workflow Concepts Leveraged in Production Environments

July 29-30, 2008

Eric Westfall

Document Type

• Document Type− Specification for a document that can be created in

KEW− Contains identifying information as well as policies

and other attributes• Super user, blanket approve, exception groups• “from” email address for email notifications

− Defines the Route Path executed for a document of that type (Process Definition)

− Hierarchical - children can inherit certain attributes from their parents

− Defined in XML

Route Node

• Route Node− Represents a “step” in the routing process of a

document type.− Defines the behavior of the document when it

reaches that node− Examples:

• Simple - do some arbitrary work• Requests - generate action requests using a Route

Module or the Rules engine• Split - split the route path into one or more parallel

branches• Join - join one or more branches back together• Sub Process - execute another route path inline• Dynamic - generate a dynamic route path

Implementing Custom Nodes

• Custom nodes can be implemented in Java• Examples include:

−A SplitNode with custom, app-specific logic−A DynamicNode to generate a route path which climbs a

hierarchy (KC does this for Unit Hierarchy routing)−A SimpleNode to do some arbitrary work

• Send an email• Call a web service• Etc.

Documents

• Documents are created for specific Document Types

• Submitted to KEW engine for routing• Interaction with documents is done

through KEW API (or by using KNS)• Can receive further actions throughout

lifecycle (Approval, Disapproval, etc.)• Have an XML payload attached to them

which can be used for routing purposes

Types of Routing

• Ad-hoc Routing− Simplest form of routing− Application manually dictates who to route to using API

• Route Module− Heavyweight component which can be implemented to provide

completely custom routing− Most of what can be done in Route Modules can be done using

Routing Rules

• Routing Rules−Rule Attributes−Role Attributes−Rule Templates−Routing Rules

Rule System

• The Rule System is the most commonly used type of routing in KEW

• The Rule System consists of the following pieces:−Rule Attributes−Rule Templates−Routing Rules

• GUI for creating Routing Rules• Rule Quick Links

Rule Attributes

• A Rule Attribute is a multi-purpose component with the following responsibilities:−Executes logic for Rule evaluation−Defines how Rule data related to the attribute should be

collected−Performs validation of Rule data−Generates XML to attach to the payload

• Can be written in Java or XML+XPath

Rule Templates

• A Rule Template is a collection of Rule Attributes

• Defines what data should be collected and evaluated on the Rule

• Example – A template used to create Rules which route to Deans might include Rule Attributes for “Campus” and “School”

Routing Rules

• Routing Rules evaluate data on the document and determine who should receive action requests (approve, ack, fyi)

• Configured via a GUI (or imported from XML)• The RuleTemplate and it’s attributes define what

fields will be collected in the Rule GUI• During routing, Rule Evaluation Sets are

“selected” at each node. Default is to select by Document Type and Rule Template defined on the Route Node

• Other Rule Selector implementations are available

XML-based Routing and Rules

• XML data on document can be used to make routing decisions.

• Rule system can leverage this XML for Rule evaluation using Xpath.

• An example of “Campus Code” XML:− <campusCode>BL</campusCode>

• Example Xpath configured on Rule Attribute− //campusCode = wf:ruleData(‘campusCode’)−Returns “true” if the campus code on document matches

the campus code on the rule, causing rule to fire

“Role-based” Routing

• Sometimes it’s not convenient to use Rules because routing data is already available elsewhere or needs to be resolved dynamically

• In these cases, use “Role” Attributes• A Role Attribute is a component written in Java

which can be used to resolve users/groups to route to based on document data

• KFS Example – Fiscal Officer−Mapping between account and fiscal officer is stored in KFS

database−Would be redundant to redefine this mapping in rules

Delegation

• KEW supports ability to delegate Action Requests− Primary Delegation− Secondary Delegation

• Delegation is currently rule-based• Attached to specific responsibilities in Routing

Rules

Exception Routing

• If failures or errors occur during routing, the document will go into exception routing

• Document will retry a configurable number of times before triggering exception routing

• Users in Document Type’s Exception Workgroup will receive it in their Action List

• There are other reasons a document might end up in exception routing:− DEFAULT_APPROVE policy is false and no approval requests were

generated on the document− No approval requests were generated at a node marked

“mandatory”− An approval request was generated after the “final approval” node

Searchable Attributes

• Searchable Attributes can be used to customize Document Search

• We’ll set up Searchable Attributes for Campus Code so we can search by it

• Open sample-thin-client-5.xml

• Ingest sample-thin-client-5.xml

• Route a document and then search by it’s Campus Code

Document Search Security

• Document Search supports the ability to filter rows from results based on Document Type security constraints

• Example:

<security> <initiator>true</initiator> <routeLogAuthenticated>true</routeLogAuthenticated> <searchableAttribute idType="emplid" name="emplid" /> <workgroup>SIS.SR.E.SU.Apprv</workgroup></security>

Super User Actions

• Super Users are defined by a workgroup associated with Document Type

• Super Users can access a special screen available from Document Search

• Can take Actions in place of other users

• Recorded on Route Log

• Also a pseudo-super user feature called Blanket Approval

Post Processors

• Receives events as the process is executed− Status Change− Node Transition− Action Taken by User

• Often used to “commit” the business transaction once all approvals have been gathered− Update database− Execute remote service call

• Have ability to participate in same JTA transaction as KEW engine

Plug-ins

• A plug-in is a packaged set of code that can be deployed into the standalone server

• Plug-in layout:−META-INF/workflow.xml− lib− classes

• When not using an Embedded KEW engine, Post Processors, etc. need to be deployed in a plug-in

• Additionally, Rule Attributes and other code used by the Rule System should be in a plug-in even if using Embedded KEW

Workgroups

• Workgroup names are globally unique so we encode a namespace into the group name− i.e. SIS.SR.E.SU.Apprv

• In general, we try to use workgroups on Rules whenever possible

• Workgroup membership change automatically updates Action Lists

Workgroup Types

• Important for decentralizing routing of groups• Allows for different routing based on group

type• Allows for additional attributes to be attached• We are currently just beginning to take

advantage of this feature at IU• We also have an “ADS” workgroup type

which identifies groups from our active directory

eDoc Lite

• eDoc Lite is a simple, form-based system that runs entirely within a Standalone Rice Server, and can be created with no java, just XML.

• Will learn more about EDL tomorrow