Kuali Enterprise Workflow

1
Kuali Enterprise Workflow

• Kuali Days May 2008
• Eric Westfall - Indiana University

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

3
What is KEW?
4
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

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

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

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

8
The Building Blocks of Workflow
9
Document Type

• 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

10
Route Node

• 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

11
Rule Attribute

• 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

12
Role Attribute

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

13
Rule Template

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

14
Routing Rule

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

15
Post Processor

• 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

16
Searchable Attribute

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

17
Developing a Workflow Document
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

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

20
Building the Document
21
Defining the Disbursement Voucher

• Routing Process for Disbursement Voucher is
  defined as follows
• Ultimately defined in XML and imported

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

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

ltfieldEvaluationgt ltxpathexpressiongt
//document/campusCode wfruledata('campusCode')
lt/xpathexpressiongt lt/fieldEvaluationgt
24
Creating Rules

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

25
Creating Rules

• Screenshot of DV Rules

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

27
Route Log of a Disbursement Voucher

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

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

29
eDoc Lite
30
eDoc Lite

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

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

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

33
eDocLite EDL Form
34
eDocLite Summary

• Makes creating a workflow-enabled application
  based on a simple form easy
• No Java development required
• No application to deploy

35
Deployment and Integration
36
Deployment and Integration

• 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

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

38
Bundled Mode Diagram
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

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

41
KEW Java Thin Client Diagram

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

43
Embedded KEW Diagram

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

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

46
The Whole Picture

47
In PracticeIndiana Universitys Kuali Rice
Implementation
48
Indiana Universitys Kuali Rice Implementation

• KEW Thin Clients
• HR
• ERA
• EPIC
• TK
• SIS
• KEW Embedded Clients
• IUF
• Travel (coming soon)
• KFS (coming soon)

49
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!

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

51
(No Transcript)
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

53
Moving Forward
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)

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

56
Questions?

• Questions from the audience.
• Rice web site http//rice.kuali.org
• Eric Westfall
• ewestfal_at_indiana.edu