Rice web site Kuali Wiki

Document Sample
Rice web site Kuali Wiki Powered By Docstoc
					Kuali Rice and Enterprise Workflow

           May 22, 2008

            David Elyea

1. Kuali Rice Overview
2. Kuali Enterprise Workflow
     1.   What is KEW?
     2.   Building Blocks of Workflow
     3.   Developing a Workflow Document
     4.   eDoc Lite
     5. Institutional Customization
3.   Deployment and Integration
4.   Example: IU’s Kuali Rice Implementation
5.   Moving Forward
6.   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
                        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
  – 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:
  – Discussion focused on this version
  – Used by KFS TestDrive example
  – Used by several institutions currently
    implementing Rice
• Current IU Implementation:
• 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
  – 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,
• 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
  – 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
• 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,
• Eliminate sifting through email
• Communication broker which provides any
  combination of action list, text messages, email,
• 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
• 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
    – 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,
•   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
•   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
                          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
• 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
• 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
• Can be written in Java or defined in XML
  by using Xpath to facilitate matching

• 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

• 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
  – 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
• Routing Process for Disbursement Voucher is
  defined as follows

• Ultimately defined in XML and imported
                 Rule Attributes and Rule
• 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
• Example: Campus Code
       //document/campusCode = wf:ruledata('campusCode')
                           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
•   Resolution of responsible parties is handled by Java code which looks at the account
    numbers on the document
                  Route Log of a Disbursement
• http://www.kualitestdrive.org
• Route Log
                KFS Routing Example -
• 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
             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:
• 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

• 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
• Can be used to override services using a
  custom Resource Loader implementation
• Only one institutional plug-in can be
Deployment and Integration
                  Deployment and Integration

• Rice Deployment Options
  – Bundled – Kuali Rice software is “bundled” into your
  – 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
• Does not require the deployment of a
  standalone Rice server
• Ideal for development or “quickstart”
• 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
  – 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
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
• 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
   – Some clients running in Embedded Mode
   – Numerous eDoc Lite applications
The Whole Picture
         In Practice:
Indiana University’s Kuali Rice
             Indiana University’s Kuali Rice
• 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
• 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
• 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
  – 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 – HR
                    Application 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

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

Shared By: