kuali rice and enterprise workflow may 22, 2008 david elyea

Kuali Rice and Enterprise Workflow

May 22, 2008

David Elyea

Outline

1. Kuali Rice Overview2. Kuali Enterprise Workflow

1. What is KEW?2. Building Blocks of Workflow3. Developing a Workflow Document4. eDoc Lite5. Institutional Customization

3. Deployment and Integration4. Example: IU’s Kuali Rice Implementation5. Moving Forward6. Questions & More Examples

Kuali Rice Overview

What is Kuali Rice?

• Kuali Rice is a suite of middleware and framework components

• Made up of several, possibly standalone and swappable, components

• Applications become a “Rice Client Application” by easily integrating with this middleware

Goals of Kuali Rice

• The vision for Kuali is a plug and play module by module approach to software

• Kuali started as financials, but has evolved into a suite of administrative software (KFS, KRA, KS)

• A lot of functionality in Kuali systems– Keeping the Kuali code base as small as possible

without impacting quality is key

• Highly productive development environment– For Kuali projects– For non-Kuali projects

Goals continued

• A common and consistent architecture– Allow developers to understand other rice-enabled

projects– Infrastructure would not need to be reinvented on

each project - focus on functionality!– Rice team can focus on IT standards, like SOA, that

will benefit the entire Kuali software suite– Adoption of other Kuali modules feasible

• Generic enough for non-Kuali applications

Technologies Used

• Struts• Spring• JTA (JOTM)• OJB• Quartz• XFire (old version of CXF)• Groovy• XML

Version Introduction

• Latest Stable Release: 0.9.2.1– Discussion focused on this version– Used by KFS TestDrive example– Used by several institutions currently

implementing Rice

• Current IU Implementation: 0.9.1.3

• Current Development: 0.9.3

• Next Development Version: 0.9.4

Kuali Rice Components

• KNS Kuali Nervous System• KIM Kuali Identity Management• KOM Kuali Organization Management• KEN Kuali Enterprise Notification• KSB Kuali Service Bus• KEW Kuali Enterprise Workflow

Kuali Nervous System

• Web-based Application Framework• Data Model Driven (Data Dictionary) • Provides reusable code, shared services,

integration layer, and a development strategy• Provides a common look and feel through a

screen drawing framework• A document-centric (business process) model

with workflow as a core concept

Kuali Nervous System, Cont.

• More Core Concepts / Features– Transactional documents– Maintenance documents– Inquiries– Lookups– Business Rules– Data Dictionary

Kuali Identity Management

• Still under development• Once development is complete, will retrofit

existing Kuali Rice modules to take advantage of it– Replace current user and workgroup services that are

currently implemented as part of KEW– Replace authentication/authorization which is

currently part of KEW

• Keeping it simple to start• Will maintain information about persons, groups,

roles, etc.

Kuali Identity Management, cont.

• Goals:– Clean and consistent service interfaces used by all

Kuali apps; generic enough for non-Kuali apps– Leverage KNS to provide a reference implementation

for services; workflow-enabled management application

– Flexibility for dynamic attributes associated with IdM entities (persons, groups, roles, etc)

– Pluggable integration with other IdM products

Kuali Organization Management

• Still under development• Provide a common set of service APIS for

Organization and Unit Hierarchy Management• Provide an out-of-the-box reference

implementation for managing these data structures

• Goal of becoming the shared infrastructure application for managing organizations and their hierarchies for all Kuali applications

Kuali Enterprise Notification

• Works with the Action List to provide a single place for all institution-related communications– Workflow items come from KEW– Non-workflow items from KEN

• Non-workflow example items– Overdue library book– A concert on campus– Graduation checklists for seniors

• Provides a secure and controlled environment for notifying the masses

Kuali Enterprise Notification, cont.

• Eliminate sifting through email

• Communication broker which provides any combination of action list, text messages, email, etc...

• Audit trail just as in KEW (Route Log)

• User preferences for notification types

• End user interfaces

– Viewing notification details

– Maintaining the system (admin)

– Sending messages (admin)

Kuali Service Bus

• Service Registry to enable applications and services on the bus to interact with other applications and services

• Provides synchronous service invocation

• Provides asynchronous messaging

• Provides flexible security

• Provides Quality of Service (QoS)

• Light Weight – keep it simple

Kuali Enterprise Workflow

What is KEW?

• Kuali Enterprise Workflow is a module of Kuali Rice which provides 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

KEW Core features

• Action List (User’s Work 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 group services– Will be replaced by KIM in the future

• Rules Engine• Email Notification

KEW Core features

• Notes and attachments• Wide array of pluggable components to

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

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

KEW Core features

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

the Rice Standalone 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 other JTA implementation to provide JTA transactions

The Building Blocks of Workflow

Document Type

• Specification for a document that can be created in KEW

• Contains identifying information as well as policies and other attributes

• Defines the Route Path executed for a document of that type (Process Definition)

• Hierarchical - children can inherit certain attributes from their parents

• Defined in XML

Route Node

• Represents a “step” in the routing process of a document type.

• Defines the behavior of the document when it reaches that node

• Examples:– Simple: do some arbitrary work– Requests: generate action requests using a Route

Module or the Rules engine– Split: split the route path into one or more parallel

branches– Join: join one or more branches back together– Sub Process: execute another route path inline– Dynamic: generate a dynamic route path

Rule Attribute

• Defines how a Routing Rule evaluates document data to determine whether or not the rule data matches the document data

• 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 (with matching done by XPath)

• Can have multiple GUI fields defined in a single attribute

Role Attribute

• A special type of Rule Attribute which allows for routing to a “Role”

• Used when data on users or workgroups that must be routed to is stored in an external system

• Examples: Fiscal Officer, Dean, Supervisor, Professor, etc.

• Already Existing Role Attributes in KEW– Initiator Role: used to retrieve the user defined as

the initiator on the document– Routed By User Role: used to retrieve the user who

physically routed the document (may not be the initiator)

Rule Template

• A composition of Rule Attributes• Adding a ‘Role’ attribute to a template allows for

the use of the Role on any rules created against the template

• When rule attributes are used for matching on rules, each attribute is associated with the other attributes on the template using an implicit ‘and’ logic qualifier

• Can be used to define various other aspects to be used by the rule creation GUI such as rule data defaults (effective dates, ignore previous, available request types, etc)

Routing Rules

• Configured via a GUI (or imported from XML)• Created against a Rule Template and a Document

Type• The Rule Template and it’s list of Rule Attributes define

what fields will be collected in the Rule GUI• Rules define the users, workgroups and/or roles

who should receive action requests• Available Action Request Types that Rules can route

– Complete– Approve– Acknowledge– FYI

Routing Rules

• During routing, Rule Evaluation Sets are “selected” at each node. Default is to select by Document Type and Rule Template defined on the Route Node

• Rules match (or ‘fire’) based on the evaluation of data on the document and data contained on the individual rule

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

Post Processors

• Associated with a Document Type• Often used to “Finalize” the business

transaction represented by the workflow process

• Sends events to clients at various points in the document routing process– KEW status changes– Node transitions– Actions taken by users

Searchable Attributes

• Responsible for extracting and indexing document data for searching

• Allows for custom fields to be added to Document Search for documents of a particular type

• Configured as an attribute of a Document Type

• Can be written in Java or defined in XML by using Xpath to facilitate matching

Plug-ins

• A plug-in is a packaged set of code that can be deployed into the standalone server method of deploying Rice

• Usually contain classes only used in routing such as custom rule or searchable attributes but can contain client application specific services

• Usually used only by clients being implemented by the ‘Thin Client’ method

Workflow Document Example

KFS Routing Example

• We’ll discuss an 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

verifications 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 KNS 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

Route Log of a Disbursement Voucher

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

KFS Routing Example - Summary

• Summary– 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.)

eDoc Lite

eDoc Lite

• A simple, form-based system that runs entirely within Workflow, and can be created with no java, just XML.

• Typically used for simple documents with simple route paths

• Can be integrated with larger applications usually with a database layer post processor component

eDoc Lite - Details

• Simple form creation and presentation– XML definition of form fields– Use your own custom XSLT for presentation

• Simple validation rules– Regular Expression– Custom Validators– Required/Not-Required– JavaScript Validation

• Security– Achieved through XSLT integration with KEW

APIs

Building Blocks of an eDoc Lite

• Every eDoc Lite consists of 4 pieces:– Field Definitions – defines what fields the

EDL has, what type, validations, etc.– Stylesheet – an XSLT stylesheet that renders

the EDL for the user– Document Type – defines the workflow

process for the EDL– EDL Association – associates each of the 3

pieces above to form an eDoc Lite

Handling EDL Data

• Since EDL uses KEW for it’s routing. You can implement Post Processors to write your EDL data to a database.

• There is one already available which can be used out of the box to write to:– EN_EDL_DMP_T– EN_EDL_FIELD_DMP_T

• This data can then be replicated or extracted to other environments to be used by reporting or user processes

eDoc Lite Architecture

eDocLite – EDL Form

eDocLite – Summary

• Makes creating a workflow-enabled application based on a simple form easy

• No Java development required

• No application to deploy

Institutional Customization

Customizing Kuali Rice at your Institution

• There are many ways to customize your Standalone Rice installation, including but not limited to:– Integration with institution’s identity services– Integration with institution’s authentication

mechanisms (i.e. CAS)– Development and deployment of shared

routing components

KEW Institutional Plug-in

• Uses already existing Plug-in architecture in KEW to allow Institution wide customizations

• Can be used to override services using a custom Resource Loader implementation

• Only one institutional plug-in can be defined

Deployment and Integration

Deployment and Integration

• Rice Deployment Options– Bundled – Kuali Rice software is “bundled” into your

application– Standalone – a standalone server is deployed

• Standalone Server Client Integration Methods– Embedded KEW – workflow engine is embedded into

your application– KEW Java Thin Client– Web Services – for KEW and, eventually, KIM– eDoc Lite

Bundled Mode

• All Kuali Rice modules are embedded into the client application, including the Web Application

• Does not require the deployment of a standalone Rice server

• Ideal for development or “quickstart” applications

• This is not desirable for Enterprise deployments of Kuali Rice

Bundled Mode Diagram

Standalone Rice Server

• The Standalone Rice Server allows you to run a central Kuali Rice application that can be integrated with multiple clients

• Facilitates a single KEW Action List, Document Search, etc.

• Allows for a shared KSB Service Registry• Supports multiple integration options for

clients:– KEW Java Thin Client– Embedded KEW– Web Services

KEW Java Thin Client

• Allows for a Java client application to integrate with the KEW module of Rice

• Uses Java Serialization over HTTP• All workflow processing happens on the

standalone server• If the workflow processing requires custom

code (i.e. Post Processors), then plug-ins need to be developed and deployed to the server

KEW Java Thin Client Diagram

Embedded KEW

• Embedded KEW allows you to configure a workflow engine embedded in your application but still use a standalone rice server

• Allows for the following advantages:– Integration of database transactions between

client application and embedded KEW (via JTA)– Fast - Embedded client talks directly to database– No need for application plug-ins on the server– Still a single KEW web app but scalability is

increased because of multiple Workflow Engines

Embedded KEW Diagram

KEW Web Services

• There are a few web service endpoints that are exposed from Kuali Rice

• KEW has a subset of it’s API available using this integration method

• The KSB allows for exporting of services onto the bus using SOAP Web Services

• In the future, we hope to add more web service endpoints to Kuali Rice… for example, KIM is being designed with web service remoting in mind

Bringing it all Together

• Leveraging the KSB and the previous examples, it’s possible to utilize multiple strategies for Kuali Rice/KEW integration and deployment

• Examples:– Some clients running as Thin Clients– Some clients leveraging code deployed in plug-ins on

the standalone server– Multiple servers deployed in a cluster for scalability– Some clients integrating directly with web service

endpoints– Some clients running in Embedded Mode– Numerous eDoc Lite applications

The Whole Picture

In Practice:Indiana University’s Kuali Rice

Implementation

Indiana University’s Kuali Rice Implementation

• KEW Thin Clients– HR (PeopleSoft)– ERA– EPIC– TK– SIS (PeopleSoft)

• KEW Embedded Clients– IUF– Travel (coming soon)– KFS (coming soon)

Indiana University’s Kuali Rice Implementation

• eDoc Lite clients– Office of Affirmative Action– Grad and Undergrad Course Remonstrance– Safeword Card Requests– OVPR Internal Funding– OVRPA Conflict of Interests– Purchasing Conflict of Interests– Student Information Systems - Special Credit– IU Health Center– UITS Unit Change Request– …and more on the way!

Indiana University’s Kuali Rice Implementation

• Institutional Customizations– Integration with our LDAP-based User

Repository (EDS)– Integration with Active Directory for reading

group and role information– Integration with our CAS installation for

authentication– Custom component for authenticating with our

Email servers (requires SSL)– Various shared routing components deployed

in a plug-in

PeopleSoft Integration - SIS

• Uses Thin Client Integration with a Plug-in

• Integration Points– Direct database table manipulation– PeopleSoft Enrollment engine is called using

PeopleSoft Component Interface

• Largest used document types are ‘Add Course’ and ‘Drop Course’

PeopleSoft Integration – HR

• Uses Thin Client Integration with a Plug-in• Integration Points

– Java client integrating with KEW uses a custom database (no direct application connection)

– Users view screens in HR java client and when PeopleSoft data must be updated users are redirected to PeopleSoft screens which have buttons to pull in data from custom database

• PeopleSoft Component Interface was not used as the SIS group used it due to CI being buggy back when HR first integrated with KEW at IU

PeopleSoft Integration – HRApplication in Development

• Will be a fully Rice Enabled Application (including use of the KNS module of Rice)

• Will run Embedded KEW connecting with IU’s Standalone Rice Server and using KSB exposed Services from IU Institutional Plug-in

• Redesign Features/Enhancements– Will use KNS to read PeopleSoft database tables directly– Custom KNS Lookup implementations to leverage

PeopleSoft effective dating in some objects– All documents will be Transactional Documents to allow for

custom GUI control (no Maintenance)– Developers are attempting to design custom automation of

the currently manual user screen redirection

Statistics

• 24 x 7 x 365 (minus maintenance)• HTTP Requests per Month - 45,084,367• Users – 156,675• Document Types – 96• Workgroups – 1,610• Rules – 9,097

During The Last Year:

Documents Routed 1,164,870

Requests Generated 6,012,216

Actions Taken 2,913,709

Route Nodes Processed 5,405,701

Moving Forward

Upcoming Work

• Version 0.9.3 of Kuali Rice is currently under development

• Changes planned for KEW– Refactoring to forward all notifications to KEN– Remove legacy package names (edu.iu.*)

• Add support to the KNS for defining workflow processes in the Data Dictionary

• Laying groundwork for 0.9.4 tasks (module refactoring)

Upcoming Work, cont.

• Version 0.9.4 of Kuali Rice will concentrate of reducing internal duplication and consolidating services

• KEW will be retrofitted to use KIM• Numerous changes will be made to have

KEW leverage the KNS– Remove duplicate Lookup framework– Rewrite Document Search as a Lookup– Rewrite Rule document to use KNS– Remove duplicate Notes/Attachments system– and more…

More Information

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

KEW web site: http://kew.kuali.org

Rice Message List:

kuali-rice@googlegroups.com