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

• Parent – document type from which it inherits attributes

<name>SampleDocumentType</name>

<parent>RiceDocument</parent>

DOCUMENT TYPE

• Description – the primary responsibilities of this document type

• Label – UI name of the document type

<label>The Sample Document Type</label>

<description>Sample document type to demonstrate KEW</description>

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

SIS – DROP/ADD – THE RICE WAYEXAMPLE – DROP / ADD CLASS

QUESTIONS?

• Learn more at http://rice.kuali.org

• Join the rice.collab@kuali.org mailing list