Kuali Enterprise Workflow

Eric Westfall (Indiana University)

Aaron Hamid (Cornell University)

Overview

• Core Features

• Highlights of Recent Work

• Architectural Evolution of KEW

• Integration Options

• KFS Workflow Overview & Example

• EDocLite Overview & Example

• Roadmap

What is KEW?

• Kuali Enterprise Workflow is a content-based routing engine.– Documents created from process definitions (Document Types)

and submitted to the workflow engine for routing– Routing decisions made based on the content of the Document

• It has traditionally been used for business transactions in the form of electronic documents that require approval from multiple parties. For example:– Transfer of Funds– Requisition– Hire/Terminate Employee– Timesheet– Drop Course

• Composed of a set of services, APIs, and GUIs• Part of the Kuali Rice framework

KEW Core features

• User Work Queue (Action List)• Document Searching• Document Audit Trail (Route Log)• Flexible process definition (Document Type)

– Splits, Joins, Parallel branches, Sub processes, Dynamic process generation

• Basic User and Group support– Can be overridden and customized to plug into

Institutional user and groups solutions

• Rules Engine• Email Notification

KEW Core features

• Notes and attachments• Wide array of pluggable components to

customize routing by process– Where to route document– Indexing of document data for searching– Email Notification Customization– Customization of Action List– Customization of Routing Rules

• EDocLite– Framework for creating simple documents quickly– Will see more of EDocLite later

KEW Core features

• Plug-in Architecture– Packaging and deployment of routing components to

the KEW Server at runtime– Institutional Customization

• Transactional Processing– JTA can be used for multi-datasource transactions

• Can run in J2EE appservers• Can run in Servlet Containers

– In non-J2EE environment, can use JOTM or (coming soon) Atomikos to provide JTA transactions

Highlights of Recent Work

• Enhancements to Workgroups– Nesting– Custom Attributes and Routing

• Custom Document Search– More configurable search options (wildcarding,

case sensitivity)– Support for range-based searches– Ability to implement custom search generators

and result set processors by Document Type

Highlights of Recent Work

• KEW has been re-architected as a Rice module• KEW code has been merged into the Rice code

base• Some pieces of KEW extracted into Rice core or

other modules– Kuali Service Bus– Configuration System– JTA support– Resource Loading

Architectural Evolution of KEW

• KEW has gone through many architectural changes in it’s lifetime

• Most recently:– Support for using an Embedded Engine– Creation of the Kuali Service Bus– Re-architected as a Rice module and merged

into the Kuali Rice framework (Kuali Rice version 0.9.1)

Architectural Evolution of KEW

Architectural Evolution of KEW

Architectural Evolution of KEW

Integration Options

• There are numerous options for integrating a client application with KEW– Web Service APIs– Thin Java Client– KEW APIs against an Embedded Engine – Create a Kuali Rice application using the KNS– EDocLite

KFS Routing Example

• We’ll show here a concrete example of a document routing in the Kuali Financial System

• Using Disbursement Voucher document– Used to disburse funds (i.e., pay someone)– Since its real money, there are a lot of approvals and

checks needed

• But first, let’s look at the steps required to build and configure a document that uses KEW

Steps

• Build the document– KFS uses Rice and the KNS to build their documents– Beyond the scope of this discussion– Can learn more about this at the Kuali Rice session

• Create Document Type and Process definition in KEW– Identifies the route path of the document

• Define Rule Attributes and Rule Templates– Defines what data will be used for routing and how rules

can analyze that data to make routing decisions

• Create Routing Rules

Building the Document

Defining the Disbursement Voucher

• Routing Process for Disbursement Voucher is defined as follows

• Ultimately defined in XML and imported

Rule Attributes and Rule Templates

• Rule Attributes and Templates are defined for each of the “Nodes” in the defined Process

• Account Review - a special Role attribute which decides who the Fiscal Officer is based on accounts attached to document

• Org Review - an attribute which climbs the Org hierarchy when evaluating rules

• Employee Indicator, Tax Control Code, Payment Method, etc. are defined in XML and use XPath to analyze document content and evaluate rules

Using XPath for Rule Evaluation

• The KNS handles serializing documents to XML and making XML available to KEW

• XPath expressions can be configured on attributes in KEW to evaluate rules based on this XML

• Example: Campus Code

<fieldEvaluation> <xpathexpression> //document/campusCode = wf:ruledata('campusCode') </xpathexpression></fieldEvaluation>

Creating Rules

• For all Nodes except Account Review, we create rules to define who the document should route to

Creating Rules

Screenshot of DV Rules

Account Review Configuration

• There is a special type of rule which points to the Fiscal Officer Role for Account Review

• Resolution of responsible parties is handled by Java code which looks at the account numbers on the document

Quick Demo of Disbursement Voucher

• http://www.kualitestdrive.org• Route Log

KFS Routing Example - Conclusions

• Conclusions– Can be simple or complex– Process definition is defined– Rule Attributes and Templates are Created– Rules are Configured– For more complex routing logic, routing

components may need to be implemented– For simpler routing logic, out-of-the-box

components can be used (i.e. XPath eval.)

eDocLite - Overview

• Simple, form-based system

• Hosted entirely within KEW

• No Java required, just XML

• Useful for small forms, and RAD prototyping

• Supports customizable UI and validation

eDocLite – UI Customization

• UI can be customized by registering an XSLT stylesheet with the EDL form

• Custom layout; standard rendering via EDL tags

• Security and other logic in XSLT via KEW API

eDocLite – XSLT

eDocLite – Validation

• JavaScript-based

• Required/not-required

• List of valid choices (drop down)

• Regular expression

• Custom JavaScript validation

eDocLite - Validation

eDocLite – Custom Validation

eDocLite – How To

• Create your DocumentType definition

• Create the EDL form definition

• Map EDL form fields to workflow attributes if necessary

• Implement custom JavaScript validation if desired

• Register custom XSLT stylesheet

eDocLite – Demo

• Office of Affirmative Action “Interview Request” form

SchoolAffirmative Action

Officer(s)

Vice Chancellor for Academic Affairs and

Dean of Faculties

School Acknowledgement

Initiator Acknowledgement

Initiator

eDocLite – Form Definition

eDocLite – EDL Lookup

eDocLite – EDL Form

eDocLite – Logic in XSLT

eDocLite – Logic in XSLT

eDocLite – Conclusion

• Makes creating a workflow app based on a simple form easy

• No Java development required

• No application to deploy

KEW - Roadmap

• Reorganization of Rice APIs– -api, -impl, -web– APIs published as web services

• Reuse of KNS in other modules• Rule enhancements• Integration of KEN• Java Persistence Architecture• Apache CXF

eDocLite – Rule expressions

• Ability to define a rule which evaluates a BSF expression

Growing KEW

Areas for growth:

• process definition

• engine features

• graphical tool support

• documentation and developer support

• upgrade/migration process

BPEL

Business Process Execution Language

• “Programming in the large”

• Structured, imperative programming

• Orchestration of web services

• Extensible language plug-in model

• Industry and tool support

BPEL for Workflow?

Pro:

• Process definition

• Tool support

• BPEL4People

• Possibility of reusing an existing engine implementation

• Existing support community

BPEL for Workflow?

Con:

• Verbose/complicated process definition

• Not built for workflow

• New development required:– Build on top of KEW engine– Use existing BPEL implementation– Write our own

Other options

• Continue to enhance KEW engine– Better pluggability of nodes– Enhance core engine– Enhance process definition language

• Build GUI tool for KEW– Use existing tool and convert results– Build a new tool (Eclipse GEF)

• Other process definition languages

Questions?

Questions from the audience.

Rice web site: http://rice.kuali.org

Eric Westfall

ewestfal@indiana.edu

Aaron Hamid

arh14@cornell.edu