Kuali Enterprise Workflow Eric Westfall (Indiana University) Andrew Hollamon (University of Arizona)

Overview What is KEW? KEW Core Features KEW Roadmap –2.2, 2.3, 2.4 EDoc Lite Overview & Example KFS Workflow Overview & Example

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 Can also be used to orchestrate business processes. –“Nodes” in the route path can execute custom code Composed of a set of services, APIs, and GUIs

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 customizable to plug into Institutional user and groups solutions Routing Rules Notification

KEW Core features Notes with attachments Wide array of pluggable components to customize routing by process –Where to route document –Indexing of document data for searching – 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 All processing is Transactional –JTA used for multi-datasource transactions Can run in J2EE appservers Can run in Servlet Containers –In non-J2EE environment, can use JOTM to provide JTA transactions

KEW 2.3.x Release 2.3 of KEW focused on architecture enhancements Embedded Mode –Integration using a standard JAR library –Client+KEW Transaction Integration via JTA –Routing Components deployed locally (no server-side plugin-ins required) –KEW web app can also be bundled –Improved Performance

KEW 2.3.x Kuali Service Bus (KSB) –Service Registry –Service Discovery and Invocation API –Reliable Messaging –Scalability and Failover –Synchronous/Asynchronous Messaging –Queue/Topic Style Messaging – Support for multiple deployment topologies –Let’s look at some examples

Thin Client (2.2.x) Only model available in past versions of KEW KEW Deployed to central server –Either a single server or clustered Java clients integrate via web services using a thin Java client API that wraps web service calls Non-Java clients communicate directly with web service endpoints Institutions plug custom user and/or workgroup services into KEW using an institutional plug-in Applications deploy routing components (Post Processors, Rule Attributes, Custom Route Nodes, etc.) as application plug-ins on the server(s).

Thin Client (2.2.x)

Advantages –“Simple” web services API used for communication –Relatively simple configuration Disadvantages –No transaction support over web services –Web services can be slow –Cumbersome plug-ins must be deployed to the server(s) in order to execute Post Processors and other routing components –All processing burden is placed on the central server Can be alleviated by clustering

Embedded Mode (2.3.x) Client Applications run embedded workflow engine pointing to KEW database All routing components are deployed in the client application (no plug-ins required) A KEW server is deployed that hosts Action List, Document Search, Route Log and other KEW screens Institution user and workgroup services deployed to KEW server using an institutional plugin Client application and embedded engine access user and workgroup services over the KSB KEW server accesses client application services needed by Action List, Rule Entry, etc. via the KSB

Embedded Mode (2.3.x)

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 –Great for Enterprise deployment, still a single KEW web app but scalability is increased because of multiple Workflow Engines Disadvantages –Can only be used by Java clients –More library dependencies than the Thin Client model –Requires client access to KEW database

Bundled Mode (2.3.x) Same as Embedded Mode except that the entire KEW application is embedded into client application, not just the engine –Web Application (Action List, Doc Search, Rules, Workgroups, etc.) –Workflow Engine –User and Workgroup Services –Application Routing Components (no plug-ins required) Can bundle an app like this for convenience but still retain the ability to seamlessly deploy in Embedded Mode in a “production” environment

Bundled Mode (2.3.x)

Advantages –All the advantages of Embedded Mode –No need to deploy a standalone KEW server –Ideal for development or “quickstart” applications –Application can be bundled with KEW for ease of development/distribution but can switch to Embedded Mode for deployment in an Enterprise environment Disadvantages –Not desirable for Enterprise deployment where more than one application is integrated with KEW –More library dependencies than the Thin Client model and Embedded Mode (additional web libraries)

Flexible Topologies Leveraging the KSB and the previous examples, it’s possible to utilize multiple strategies for KEW integration and deployment Examples: –Some clients running as Thin Clients –Some clients leveraging code deployed in plug-ins on the KEW server –Multiple KEW servers deployed in a cluster for scalability –Some clients integrating directly with web service endpoints –Some clients running in Embedded Mode

Flexible Topologies

KEW 2.4.x Upcoming Release - Fall 2007 Workgroups –Decentralized Routing –Nested Workgroups Delegation –More Natural Delegation Model Global Removal/Replacement of Users in Workgroups and Rules Roles –Associate Users with business data in a Role (i.e. Dean for School “X”, Bursar for Campus “Y”) –KEW can route to these Roles

KEW 2.4.x Document Search Enhancements –Improved customization of Document Search Search execution Validation Result set processing Visual layout of fields Rice –KEW is a component of Rice –Some useful portions of KEW extracted into Rice core KSB Configuration system Resource Loading JTA support –

eDoc Lite – Overview Sometimes you need integration to a big client app, with complicated and dynamic routing. Sometimes you need simple 1-2 page documents, with simple routing. The latter is where eDoc Lite comes in. eDoc Lite is a simple, form-based system that runs entirely within workflow, and can be created with no java, just XML.

eDoc Lite – Details Simple form creation and presentation –Using XML against a Schema for form fields layout –Using your own custom XSLT for presentation Simple validation rules –Regular Expression –Validate Against List –Custom Validators –Required/Not-Required –JavaScript Validation

eDoc Lite – XML Definition XML Definition

eDoc Lite – XML Definition XML Field Defs w/ Validations

eDoc Lite – Form Demo XML Embedded Style (XSL)

eDoc Lite – Route Log Screenshot of eDoc Lite Route Log

eDoc Lite – Why? Integrating with an ERP system is hard. Sometimes you have simpler needs. Particularly outside of central IT. –ie, a point solution to some unit’s need –or just a simple business process Doesn’t require Java programmers !!!! Can be modified at runtime Can be built and modified by someone outside of Central IT (if trained a bit)

KFS Routing Example Picture is worth a thousand words, and a live demo is worth a thousand power point slides. We’ll show here a concrete (and relatively complex) example of a document routing in KFS (Kuali Financial System)

KFS Routing Example Using Disbursement Voucher document –Used to disburse funds (ie, pay someone) –Since its real money, there is a lot of approvals and checks needed

KFS Routing Example Screenshot of DV Routing Config

KFS Routing Example Screenshot of filled-in DV document

KFS Routing Example Explanation of routing types –Account Review (ie, Fiscal Officer) –Org Review –Employee Indicator –Tax Control Code –Alien Indicator –Payment Reason –Payment Reason + Campus Code –Campus Code –Alien Indicator + Payment Reason –Payment Method

KFS Routing Example Screenshot and Explanation of Account Review Configuration

KFS Routing Example Screenshot and Explanation of Org Review Configuration

KFS Routing Example Screenshot and Explanation of Employee Indicator

KFS Routing Example Screenshot and Explanation of Tax Control Code Configuration

KFS Routing Example Screenshot and Explanation of Alien Indicator Configuration

KFS Routing Example Screenshot and Explanation of Payment Reason Configuration

KFS Routing Example Screenshot and Explanation of Campus Code Configuration

KFS Routing Example Screenshot of Route Log of Completed Doc

KFS Routing Example Conclusions –Can be simple or complex –Can always fire or can conditionally fire –Can be complex java routing, or simple field/value based routing logic Latter can be updated by a non-technical user –Unlimited potential, but can also be simple where that’s all that is needed

Questions? Questions from the audience. Eric Westfall Andrew Hollamon