1. Kuali Rice and Enterprise Workflow May 22, 2008 David Elyea

2. Outline 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

3. Kuali Rice Overview

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

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

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

7. Technologies Used Struts Spring JTA (JOTM) OJB Quartz XFire (old version of CXF) Groovy XML

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

9. Kuali Rice Components KNSKuali Nervous System KIM Kuali Identity Management KOMKuali Organization Management KENKuali Enterprise Notification KSBKuali Service Bus KEWKuali Enterprise Workflow

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

11. Kuali Nervous System, Cont. More Core Concepts / Features –Transactional documents –Maintenance documents –Inquiries –Lookups –Business Rules –Data Dictionary

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

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

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

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

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

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

18. Kuali Enterprise Workflow

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

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

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

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

23. The Building Blocks of Workflow

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

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

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

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

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

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

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

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

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

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

34. Workflow Document Example

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

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

37. Building the Document

38. Defining the Disbursement Voucher Routing Process for Disbursement Voucher is defined as follows Ultimately defined in XML and imported

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

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

41. Creating Rules For all Nodes except Account Review, we create rules to define who the document should route to

42. Creating Rules Screenshot of DV Rules

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

44. Route Log of a Disbursement Voucher http://www.kualitestdrive.org Route Log

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

46. eDoc Lite

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

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

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

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

51. eDoc Lite Architecture

52. eDocLite – EDL Form

53. eDocLite – Summary Makes creating a workflow-enabled application based on a simple form easy No Java development required No application to deploy

54. Institutional Customization

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

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

57. Deployment and Integration

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

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

60. Bundled Mode Diagram

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

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

63. KEW Java Thin Client Diagram

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

65. Embedded KEW Diagram

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

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

68. The Whole Picture

69. In Practice: Indiana University’s Kuali Rice Implementation

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

71. 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!

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

73. 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’

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

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

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

78. Moving Forward

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

80. 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…

81. More Information Rice web site: http://rice.kuali.org KEW web site: http://kew.kuali.org Rice Message List: kuali-rice@googlegroups.com