kuali enterprise workflow overview eric westfall

35
KUALI ENTERPRISE WORKFLOW OVERVIEW Eric Westfall

Upload: joleen-harrison

Post on 16-Dec-2015

232 views

Category:

Documents


1 download

TRANSCRIPT

KUALI ENTERPRISE WORKFLOW OVERVIEW

Eric Westfall

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 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 Drop Course

KEW – Core Features

Action List (User’s Work List) Document Searching Document Audit Trail (Route Log) Flexible Process Definition (Document Types) Simulation Engine Notes and Attachments – All workflow documents get

them, even if they don’t want them Programmatically extensible Wide array of pluggable components to customize

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

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

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) {

if (context.isSimulation()) {

// no side-effects!

}

else {

// send off the email

}

return new SimpleResult(true);

}

}

KEW API

Consists of two main services:

1. WorkflowDocumentActions All operations related to a workflow

document

2. 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

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>