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)
Flexible Process Definition (Document Types)
Simulation Engine
• Notes and Attachments
• Programmatically extensible
• Frameworks for customization of routing and other pieces of the system
DOCUMENT TYPES
• Document Types allow you to specify content that can be
initiated using KEW
• They are specified using XML markup
• They identify this content by a type name
• Can also include policies and other attributes
• Hierarchical, can inherit attributes from parents
• Most importantly, they define the route path for initiated content
DOCUMENT TYPE DEFINITIONS
• Document Type Name
• Parent (Document Types are Hierarchical)
• Post Processor
• Security
• Policies
• Search Attributes
• Route Path
ANATOMY OF A DOCUMENT TYPE DEFINITION
<attributes>...</attributes>
<documentType>
<name>...</name>
<policies>
<policy>
<parent>...</parent>
<name>...</name>
<description>...</description>
<parent>...</parent>
<description>...</description>
<value>...</value>
<label>...</label>
<label>...</label>
</policy>
<postProcessorName>...</postProcessorName>
<postProcessorName>...</postProcessorName>
</policies>
<docHandler>...</docHandler>
<docHandler>...</docHandler>
<superUserGroupName namespace="...">...</superUserGroupName>
<superUserGroupName
namespace="...">...</superUserGroupName>
<blanketApproveGroupName
namespace="...">...</blanketApproveGroupName>
<blanketApproveGroupName
<defaultExceptionGroupNamenamespace="...">...</blanketApproveGroupName>
namespace="...">...</defaultExceptionGroupName>
<defaultExceptionGroupName
namespace="...">...</defaultExceptionGroupName>
<security>...</security>
<security>...</security>
<notificationFromAddress>...</notificationFromAddress>
<notificationFromAddress>...</notificationFromAddress>
<serviceNamespace>...</serviceNamespace>
<serviceNamespace>...</serviceNamespace>
<attributes>...</attributes>
<attributes>...</attributes>
<policies>
<policies>
<policy>
<policy>
<name>...</name>
<name>...</name>
<value>...</value>
<value>...</value>
</policy>
</policy>
</policies>
</policies>
<routePaths>
<routePaths>
<routePath>
<routePath>
...
...
</routePath>
</routePath>
<routePath name="...">
<routePath
name="...">
...
...
</routePath>
</routePath>
</routePaths>
<routePaths>
</routePaths>
<routeNode>
<routePath>
</documentType>
<routeNode>
... ...
...</routePath>
</routeNode>
</routeNode>
</documentType>
<routePath name="...">
</documentType>
...
</routePath>
</routePaths>
<routeNode>
...
<name>...</name>
<parent>...</parent>
<routePaths>
<routePath>
...
</routePath>
<attributes>...</attributes>
<routePath name="...">
<policies>
...
<policy>
</routePath>
<name>...</name>
</routePaths>
<value>...</value>
<routeNode>
</policy>
...
</policies>
</routeNode>
ROUTE PATH AND ROUTE NODES
<documentType>
...
<routePaths>
<routePath>
...
</routePath>
</routePaths>
<routeNodes>
<start name=“...”>...</start>
<requests name=“...”>...</requests>
...
</routeNodes>
</documentType>
PROCESS DEFINITION - 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
• TODO… add some graphics in here on the KC dynamic node routing
process
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
•
Making an example of the Email Node
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 API
• Consists of two main services:
1.
WorkflowDocumentActions
•
2.
All operations related to a workflow document
WorkflowUtility
•
Implements various query operations
WORKFLOWDOCUMENTACTIONS
• Create
• Route
• Approve
• Save
• Blanket Approve
• Return to Previous Node
• Super User Actions
• Attach XML to document
• Set document title
WORKFLOWUTILITY
• getRouteHeader
• getDocumentType
• getAllActionItems
• isUserInRouteLog
• routingReport (executes the Simulation Engine)
• performDocumentSearch
• ruleReport
• getActiveNodeInstances
• getDocumentStatus
RULE ROUTING
• Four key components used for Rule Routing
• Document Type (specifically the Route Nodes)
• Rule Attributes
• Rule Templates
• Routing Rules
DOCUMENT TYPE (ROUTE NODES)
• 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>
RULE ATTRIBUTES
•
Defines how a Routing Rule evaluates document data
to determine whether or not the rule should fire.
•
Also defines what data is collected on a rule.
•
An attribute typically corresponds to one piece of data
on a document (i.e. dollar amount, department,
organization, account, etc.)
•
Can be written in Java or defined using XML
RULE TEMPLATES
•
•
•
•
•
A composition of Rule Attributes
When a Routing Rule is created, it is created for a
specific Rule Template and Document Type.
Defines what data should be collected and stored in
the rule (via it’s Rule Attributes)
Also used to identify the set of rules to evaluate at a
“Requests” Node
Can also be used to define various other rule
properties (defaults, etc.)
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
• New to Rice 1.0.x
• Leverages Kuali Identity Management module to allow routing to KIM Roles
via KIM Responsibility objects
• 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
DOCUMENT TYPE CONFIGURATION
• Node must be defined using <role> xml tag rather than <requests> tag used
for ‘Rule Routing'
• <role> tag identifies to KEW engine that node will use KIM Responsibility
Routing
• <role> xml tag is used in <routePath> and <routeNodes> elements
QUALIFIER RESOLVERS
• Used to find qualification data for matching to KIM Role Members
• Data can be located anywhere including external systems
• Defined on Node using fully qualified class name
• Single class can be used on multiple document types and multiple nodes
QUALIFIER RESOLVERS (CONT)
• 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)
KIM ‘RESPONSIBILITY’ BUSINESS OBJECT
• KIM specific object
• Very similar to KIM Permission object
• Usually one or more KIM Roles are assigned to a Responsibility
• Each Responsibility has a Namespace value (KR-SYS, KFS-AR, KS-LUM)
but these are not used by KEW routing
• Responsibility has data values associated with it via ‘Detail Value’ elements
RESPONSIBILITY DETAIL VALUES
• KEW uses specific Responsibility Detail Values to find matching
Responsibility objects
• Document Type Name
• Route Node Name
• Responsibility create/edit UI is designed to collect this information
• Can be viewed from the Responsibility Lookup
RESPONSIBILITY DETAIL VALUES (CONT)
• documentTypeName – The KEW document type name that the responsibility
applies to
• routeNodeName – Specific Node Name to use this particular Responsibility
for
• actionDetailsAtRoleMemberLevel – Tells KEW where to find Action Info
(request type, priority, etc)
• required – Notifies KEW if this Responsibility is required to generate at least
one Action Request
KIM ROLES
• Qualification values returned by node’s Qualifier Resolver class are used to
fully qualify Role Members
• The Responsibility Detail Value ‘actionDetailsAtRoleMemberLevel’
determines how Role collects Responsibility ‘Action Info’
• True: Each Role Member will have it’s own ‘Action Info’ data
• False: The ‘Action Info’ data will be set at the Role Level and every Role
Member uses it
PEOPLE FLOWS
• TODO… add slides on people flows here
DESIGNING WORKFLOW PROCESSES
Eric Westfall
ANATOMY OF A 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>
DEFINING ROUTE PATHS
<!-- This section defines the path of the nodes or the "flow" -->
<routePaths>
<routePath>
<start name="Start" nextNode="DepartmentChair" />
<role name="DepartmentChair" nextNode="FinalApprovers" />
<requests name="FinalApprovers" nextNode="ConfirmationEmail" />
<simple name="ConfirmationEmail"/>
</routePath>
</routePaths>
<!-- This section is used to configure each node -->
<routeNodes>
<start name="Start">
<activationType>P</activationType>
</start>
...
</routeNodes>
DESIGNING WORKFLOW PROCESSES
• Next, we’re going to take a look at some Document Type definitions in XML.
• We will look at some of the Document Type definitions you will work with in
the next exercise:
• Simple Document Type with Ad-Hoc Routing
• Routing Rules using Simple Rule Templates
• Parallel Branching using Split Nodes
• Using Conditional Split Nodes
• Using a PostProcessor
DIFFERENT TYPES OF NODES
<routePaths>
<routePath>
<start name="Start" nextNode="DepartmentChair" />
<role name="DepartmentChair" nextNode="FinalApprovers" />
<requests name="FinalApprovers" nextNode="ConfirmationEmail" />
<simple name="ConfirmationEmail"/>
</routePath>
</routePaths>
<routeNodes>
<start name="Start">
<activationType>P</activationType>
</start>
<role name="DepartmentChair">
<activationType>P</activationType>
<qualifierResolver>DepartmentCodeQualifierResolver</qualifierResolver>
</role>
<requests name="FinalApprovers">
<activationType>P</activationType>
<ruleTemplate>FinalApproversTemplate</ruleTemplate>
</requests>
<simple name="ConfirmationEmail">
<from>myemail@localhost</from>
<to>initiator</to>
<testAddress>testemail@localhost</testAddress>
<style>ConfirmationEmail.Stylesheet</style>
<type>edu.iu.uis.eden.mail.EmailNode</type>
</simple>
</routeNodes>