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
• Email 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
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
• 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
http://ksb.kuali.org
• 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)
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)
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)
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
– http://rice.kuali.org
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
[email protected]
Andrew Hollamon
[email protected]