Kuali Enterprise Workflow Kuali Days May 2008 Eric Westfall -
Indiana University
Slide 2
Kuali Enterprise Workflow What is KEW? The Building Blocks of
Workflow Developing a Workflow Document eDoc Lite Deployment and
Integration IUs Kuali Rice Implementation Moving Forward
Slide 3
What is KEW?
Slide 4
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
Slide 5
KEW Core features Action List (Users 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
Slide 6
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
Slide 7
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
Slide 8
The Building Blocks of Workflow
Slide 9
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
Slide 10
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
Slide 11
Rule Attribute 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
Slide 12
Role Attribute A special type of Rule Attribute which allows
for routing to a Role When executed, resolves to a set of users
and/or workgroups who should receive action requests. Used to
resolve Roles from external systems or databases for routing
purposes. Examples: Fiscal Officer, Dean, Supervisor, etc.
Slide 13
Rule Template 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 its 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.)
Slide 14
Routing Rule 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 users,
workgroups 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.
Slide 15
Post Processor Receives events as the process is executed
Status Change Node Transition Action Taken by User Usually used to
commit the business transaction once all approvals have been
gathered
Slide 16
Searchable Attribute 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 using Xpath.
Slide 17
Developing a Workflow Document
Slide 18
KFS Routing Example Well 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 checks needed But first,
lets look at the steps required to build and configure a document
that uses KEW
Slide 19
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
Slide 20
Building the Document
Slide 21
Defining the Disbursement Voucher Routing Process for
Disbursement Voucher is defined as follows Ultimately defined in
XML and imported
Slide 22
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
Slide 23
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 //document/campusCode =
wf:ruledata('campusCode')
Slide 24
Creating Rules For all Nodes except Account Review, we create
rules to define who the document should route to
Slide 25
Creating Rules Screenshot of DV Rules
Slide 26
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
Slide 27
Route Log of a Disbursement Voucher
http://www.kualitestdrive.org Route Log
Slide 28
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.)
Slide 29
eDoc Lite
Slide 30
Sometimes you need integration to a big client app, with a
sophisticated interface. Sometimes you need simple documents, with
simple routing. The latter is where eDoc Lite comes in. eDoc Lite
is a simple, form-based system that runs entirely within a
Standalone Rice Server, and can be created with no java, just
XML.
Slide 31
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
Slide 32
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
Slide 33
eDocLite EDL Form
Slide 34
eDocLite Summary Makes creating a workflow-enabled application
based on a simple form easy No Java development required No
application to deploy
Slide 35
Deployment and Integration
Slide 36
There are multiple ways to deploy and integrate applications
with Kuali Rice Bundled Kuali Rice software is bundled into your
application Standalone a standalone server is deployed In addition,
when deploying a standalone server, the following client
integration options are available, most relate to the KEW module
Embedded KEW workflow engine is embedded into your application KEW
Java Thin Client Web Services for KEW and, eventually, KIM eDoc
Lite
Slide 37
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
Slide 38
Bundled Mode Diagram
Slide 39
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
Slide 40
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
Slide 41
KEW Java Thin Client Diagram
Slide 42
Embedded KEW Embedded KEW allows you to configure a workflow
engine embedded in your application but still use a standalone rice
server This allows for the following: 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
Slide 43
Embedded KEW Diagram
Slide 44
KEW Web Services There are a few web service endpoints that are
exposed from Kuali Rice KEW has a subset of its 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
Slide 45
Bringing it all Together Leveraging the KSB and the previous
examples, its 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
Slide 46
The Whole Picture
Slide 47
In Practice: Indiana Universitys Kuali Rice Implementation
Indiana Universitys 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!
Slide 50
Indiana Universitys 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
Slide 51
Slide 52
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 Routed1,164,870
Requests Generated6,012,216 Actions Taken2,913,709 Route Nodes
Processed5,405,701
Slide 53
Moving Forward
Slide 54
Upcoming Work Version 0.9.3 of Kuali Rice is currently under
development Following changes are 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)
Slide 55
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
Slide 56
Questions? Questions from the audience. Rice web site:
http://rice.kuali.orghttp://rice.kuali.org Eric Westfall
[email protected]