kuali rice and enterprise workflow may 22, 2008 david elyea
TRANSCRIPT
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: