MODELING BUSINESS PROCESSES IN
KUALI ENTERPRISE WORKFLOW
Eric Westfall – Indiana University
Claus Niesen – Iowa State University
ANATOMY OF A WORKFLOW ENGINE
• What is a Workflow Engine?
• Orchestrates business process workflow
• It accomplishes this via:
• routing content through a variety of routing nodes
• What must it be capable of doing?
• Modeling both simple and complex processes
• Interacting with multiple entities (both humans and services)
• Running asynchronously
• Transactional operation
KEW OVERVIEW
• Composed of a set of services APIs, frameworks, and User Interfaces
• Routes documents based on type, where the associated Document Type definition
declares a route path for the document.
• Based on this route path, various behaviors will be performed based on the
document content.
• Often, this behavior consists of interacting with one or more parties in the form of
approval requests. For example:
• Transfer of Funds
• Timesheet
• Add/Drop Course
• Travel Authorization
KEW – CORE FEATURES
•
•
•
•
•
Action List
Document Search
Route Log (Audit Trail)
Notes and Attachments
Simulation Engine
• Customizable and programmatically extensible
DOCUMENT TYPES
• Document Types allow you to specify content that can be
initiated using KEW
• They are specified using XML markup
DOCUMENT TYPE DEFINITION
<documentType>
<name>...</name>
<parent>...</parent>
<description>...</description>
<label>...</label>
<postProcessorName>...</postProcessorName>
<docHandler>...</docHandler>
<superUserGroupName namespace="...">...</superUserGroupName>
<blanketApproveGroupName namespace="...">...</blanketApproveGroupName>
<defaultExceptionGroupName namespace="...">...</defaultExceptionGroupName>
<security>...</security>
<notificationFromAddress>...</notificationFromAddress>
<serviceNamespace>...</serviceNamespace>
<attributes>...</attributes>
<policies>
<policy>
<name>...</name>
<value>...</value>
</policy>
</policies>
<routePaths>
<routePath>
...
</routePath>
<routePath name="...">
...
</routePath>
</routePaths>
<routeNode>
...
</routeNode>
</documentType>
DOCUMENT TYPE
• Name – unique name that identifies this document type
<name>SampleDocumentType</name>
• Parent – document type from which it inherits attributes
<parent>RiceDocument</parent>
DOCUMENT TYPE
• Description – the primary responsibilities of this document type
<description>Sample document type to demonstrate KEW</description>
• Label – UI name of the document type
<label>The Sample Document Type</label>
DOCUMENT TYPE – POST PROCESSOR
• Responsible for completing business transaction
• Notified on node transition, status change, or action taken
• Specific to a particular set of Document Types
<postProcessorName>
org.kuali.rice.krad.workflow.postprocessor.KualiPostProcessor
</postProcessorName>
DOCUMENT TYPE - SECURITY
• Customize who can view the document type
• Document Search
• Route Log
• Doc Handler Redirection
<security>
<groupName namespace=“SampleApp”>
SampleGroup
</groupName>
</security>
DOCUMENT TYPE - POLICIES
• Enforce policies on the document type
<policies>
<policy>
<name>DEFAULT_APPROVE</name>
<value>true</value>
</policy>
</policies>
DOCUMENT TYPE – SEARCH ATTRIBUTES
• Customization of document search
• Add document data as searchable fields
• Specify search fields of interface*
• Specify result columns to be shown*
• *can be conditional
DOCUMENT TYPE – ROUTE PATH
• Specifies the flow between the route nodes
<routePaths>
<routePath>
<start name=“FirstNode” nextNode=“SecondNode” />
<requests name=“SecondNode” nextNode=“ThirdNode” />
<requests name=“ThirdNode” />
</routePath>
</routePaths>
ROUTE NODES
• Some of the primary types of Routing Nodes include:
• Split Nodes
• Join Nodes
• Simple Nodes
• Request Nodes
• Dynamic Nodes
• Sub Process Nodes
• You can also implement custom Nodes
ROUTE NODES - SPLIT
• A split node is one that is capable of splitting the routing path into multiple
branches
• Branches are executed concurrently
ROUTE NODES - JOIN
• Join nodes complement a split node by allowing the multiple branches of the
routing path to converge
ROUTE NODES – SIMPLE NODE
• Simple nodes are a base type that allows a developer to implement
behaviors based on their own particular processing requirements
SIMPLE NODE EXAMPLES
• EmailNode: Allows sending of email messages
• LogNode: Sends messages to Rice’s logging stream
• SetVarNode: Allows setting of document variables
• RequestsNode: Generates action requests
ROUTE NODES - REQUEST NODES
• Generates ActionRequests that are fed into the action list(s) of a user,
workgroup, or role
• Requires user action to proceed
• Include: approve, disapprove, acknowledge, etc…
• Have an associated Activation Type:
• S (Sequential): An ActionRequest is sent and must be acted upon before
sending the next ActionRequest
• P (Parallel): Multiple ActionRequests are sent at once
• Requests can be generated by a custom Route Module or by the Rules
engine
ROUTE NODES – DYNAMIC NODES
• Dynamic nodes are a more advanced form of developer-implemented node
• They allow for the dynamic modeling of a route path
• This is done by instantiating a set of node instances that will then be fed to
the routing engine
DYNAMIC NODE EXAMPLE:
Hierarchy Routing
ROUTE NODES – SUB-PROCESS
• Sub Process Nodes are named route paths that can be included in a
document type’s primary route path.
• They allow the workflow author to create a route path that can be reused
CUSTOM NODE IMPLEMENTATION
public class EmailNode implements SimpleNode {
public SimpleResult process(RouteContext context, RouteHelper helper) throws Exception {
if (context.isSimulation()) {
// no side-effects!
}
else {
// send off the email
}
return new SimpleResult(true);
}
}
KEW APIS
• WorkflowDocumentActionsService – operations related to actions on
workflow documents
• WorkflowUtilityService – miscellaneous operations
• In Rice 2.0, WorkflowUtilityService was split into the following:
• WorkflowDocumentService – document-related operations
• DocumentTypeService – Document Type-related operations
• ActionListService – retrieve action lists
• RuleService – interact with KEW rules engine
• NoteService – notes and attachments on documents
Workflow Document Actions
• Create
• Route
• Approve
• Save
• Blanket Approve
• Return to Previous Node
• Super User Actions
• Attach XML to document
• Set document title
• Execute Simulation
Using the API (Rice 2.0)
WorkflowDocument document =
WorkflowDocumentFactory.createDocument(“ewestfal”, “MyDocType”);
document.setApplicationContent(“<content>my doc content</content>”);
document.routeDocument(“My custom annotation”);
String documentId = document.getDocumentId();
// after some routing happens...
WorkflowDocument document =
WorkflowDocumentFactory.loadDocument(“somebody”, documentId);
if (document.isApprovalRequested()) {
document.approve(“I approve this!”);
}
RULE ROUTING
• Four key components used for Rule Routing
• Document Type (specifically the Route Nodes)
• Rule Attributes
• Rule Templates
• Routing Rules
• Not to be confused with the capabilities provided by KRMS (new module of
Rice in version 2.0, we will discuss this later)
USING RULES
• Sample Route Node using ‘Rule Template’ Method
<requests name="DocumentNode">
…
<ruleTemplate>DocumentRuleTemplate</ruleTemplate>
</requests>
• Sample Route Node using ‘Named Rule’ Method
<requests name="DocumentNode">
…
<ruleSelector>Named</ruleSelector>
<ruleName>TestRule1</ruleName>
</requests>
ROUTING RULES
•
•
•
•
•
Evaluated against a document to determine who should
receive action requests at a particular node.
Created against a Rule Template.
Rule matching behavior is handled by the Rule Attributes
when the rule is executed.
Defines the principals (users), groups and/or roles who should
receive action requests should the rule fire.
Examples:
• If dollar amount is greater than $10,000 then send an
Approval request to Joe.
• If department is “HR” request an Acknowledgment from the
HR.Acknowledgers workgroup.
KIM RESPONSIBILITY ROUTING
• Leverages Kuali Identity Management module to allow routing to KIM Roles
via “responsibilities” which have been defined on those roles
• Allows for both KIM Permissions and workflow routing to use same KIM
Roles
• Can be used with ‘Rule Routing’ on a single document type but not single
node
RESPONSIBILITIES IN KIM
• Defines a responsibility to take action as part of a workflow process
• Based on:
• Document Type
• Route Node at which the responsibility should be applied
• Specifies:
• The action which should be generated when the responsibility is
triggered (approve, ack, fyi, etc.)
• Request priority
• Force Action flag
• Responsibilities are assigned to roles, all members of the role inherit them
QUALIFIER RESOLVERS
• Used to find qualification data for matching to KIM Role Members
• Data can be located anywhere including external systems
• Can be custom coded java class implementing QualifierResolver
interface
• Some provided options included in Rice
• NullQualifierResolver (Match All Role Members)
• XPathQualifierResolver (User provided XPath Expression)
• DataDictionaryQualifierResolver (KNS Specific)
PEOPLE FLOWS
• New to KEW in Rice 2.0
• Principals, groups, or roles who need to take action in a
prescribed order
• Supports delegation
• Processed as a combination of parallel and sequential
processing
• Acts as a mini People-based workflow
• Integrated with the KRMS rules engine
PEOPLE FLOWS
PEOPLE FLOWS
EXAMPLE BUSINESS PROCESSES
• Using the tools available in KEW, many different types of workflow processes
can be built
• Examples:
• HR Transactions (Hire, Terminate, etc.)
• Timesheet Review and Approval
• Purchasing
• Drop/Add Class
EXAMPLE - HUMAN RESOURCE TRANSACTIONS
EXAMPLE – TIMESHEET REVIEW AND APPROVAL
EXAMPLE - PURCHASING
EXAMPLE – DROP / ADD CLASS
SIS – DROP/ADD – THE RICE WAY
QUESTIONS?
• Learn more at http://rice.kuali.org
• Join the rice.collab@kuali.org mailing list