Kuali Enterprise Workflow

1. Kuali Enterprise Workflow Eric Westfall (Indiana University) Andrew Hollamon (University of Arizona)

2. Overview • What is KEW? • KEW Core Features • KEW Roadmap • 2.2, 2.3, 2.4 • EDoc Lite Overview & Example • KFS Workflow Overview & Example

3. What is KEW? • Kuali Enterprise Workflow is 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 • Can also be used to orchestrate business processes. • “Nodes” in the route path can execute custom code • Composed of a set of services, APIs, and GUIs

4. KEW Core features • User Work Queue (Action 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 customizable to plug into Institutional user and groups solutions • Routing Rules • Email Notification

5. KEW Core features • Notes with attachments • Wide array of pluggable components to customize routing by process • Where to route document • Indexing of document data for searching • Email Notification Customization • Customization of Action List • Customization of Routing Rules • EDocLite • Framework for creating simple documents quickly • Will see more of EDocLite later

6. KEW Core features • Plug-in Architecture • Packaging and deployment of routing components to the KEW Server at runtime • Institutional Customization • All processing is Transactional • JTA used for multi-datasource transactions • Can run in J2EE appservers • Can run in Servlet Containers • In non-J2EE environment, can use JOTM to provide JTA transactions

7. KEW 2.3.x • Release 2.3 of KEW focused on architecture enhancements • Embedded Mode • Integration using a standard JAR library • Client+KEW Transaction Integration via JTA • Routing Components deployed locally (no server-side plugin-ins required) • KEW web app can also be bundled • Improved Performance

8. KEW 2.3.x • Kuali Service Bus (KSB) • Service Registry • Service Discovery and Invocation API • Reliable Messaging • Scalability and Failover • Synchronous/Asynchronous Messaging • Queue/Topic Style Messaging • http://ksb.kuali.org • Support for multiple deployment topologies • Let’s look at some examples

9. Thin Client (2.2.x) • Only model available in past versions of KEW • KEW Deployed to central server • Either a single server or clustered • Java clients integrate via web services using a thin Java client API that wraps web service calls • Non-Java clients communicate directly with web service endpoints • Institutions plug custom user and/or workgroup services into KEW using an institutional plug-in • Applications deploy routing components (Post Processors, Rule Attributes, Custom Route Nodes, etc.) as application plug-ins on the server(s).

10. Thin Client (2.2.x)

11. Thin Client (2.2.x) • Advantages • “Simple” web services API used for communication • Relatively simple configuration • Disadvantages • No transaction support over web services • Web services can be slow • Cumbersome plug-ins must be deployed to the server(s) in order to execute Post Processors and other routing components • All processing burden is placed on the central server • Can be alleviated by clustering

12. Embedded Mode (2.3.x) • Client Applications run embedded workflow engine pointing to KEW database • All routing components are deployed in the client application (no plug-ins required) • A KEW server is deployed that hosts Action List, Document Search, Route Log and other KEW screens • Institution user and workgroup services deployed to KEW server using an institutional plugin • Client application and embedded engine access user and workgroup services over the KSB • KEW server accesses client application services needed by Action List, Rule Entry, etc. via the KSB

13. Embedded Mode (2.3.x)

14. Embedded Mode (2.3.x) • 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 • Great for Enterprise deployment, still a single KEW web app but scalability is increased because of multiple Workflow Engines • Disadvantages • Can only be used by Java clients • More library dependencies than the Thin Client model • Requires client access to KEW database

15. Bundled Mode (2.3.x) • Same as Embedded Mode except that the entire KEW application is embedded into client application, not just the engine • Web Application (Action List, Doc Search, Rules, Workgroups, etc.) • Workflow Engine • User and Workgroup Services • Application Routing Components (no plug-ins required) • Can bundle an app like this for convenience but still retain the ability to seamlessly deploy in Embedded Mode in a “production” environment

16. Bundled Mode (2.3.x)

17. Bundled Mode (2.3.x) • Advantages • All the advantages of Embedded Mode • No need to deploy a standalone KEW server • Ideal for development or “quickstart” applications • Application can be bundled with KEW for ease of development/distribution but can switch to Embedded Mode for deployment in an Enterprise environment • Disadvantages • Not desirable for Enterprise deployment where more than one application is integrated with KEW • More library dependencies than the Thin Client model and Embedded Mode (additional web libraries)

18. Flexible Topologies • Leveraging the KSB and the previous examples, it’s possible to utilize multiple strategies for KEW integration and deployment • Examples: • Some clients running as Thin Clients • Some clients leveraging code deployed in plug-ins on the KEW server • Multiple KEW servers deployed in a cluster for scalability • Some clients integrating directly with web service endpoints • Some clients running in Embedded Mode

19. Flexible Topologies

20. KEW 2.4.x • Upcoming Release - Fall 2007 • Workgroups • Decentralized Routing • Nested Workgroups • Delegation • More Natural Delegation Model • Global Removal/Replacement of Users in Workgroups and Rules • Roles • Associate Users with business data in a Role (i.e. Dean for School “X”, Bursar for Campus “Y”) • KEW can route to these Roles

21. KEW 2.4.x • Document Search Enhancements • Improved customization of Document Search • Search execution • Validation • Result set processing • Visual layout of fields • Rice • KEW is a component of Rice • Some useful portions of KEW extracted into Rice core • KSB • Configuration system • Resource Loading • JTA support • http://rice.kuali.org

22. eDoc Lite – Overview • Sometimes you need integration to a big client app, with complicated and dynamic routing. • Sometimes you need simple 1-2 page documents, with simple routing. • The latter is where eDoc Lite comes in. • eDoc Lite is a simple, form-based system that runs entirely within workflow, and can be created with no java, just XML.

23. eDoc Lite – Details • Simple form creation and presentation • Using XML against a Schema for form fields layout • Using your own custom XSLT for presentation • Simple validation rules • Regular Expression • Validate Against List • Custom Validators • Required/Not-Required • JavaScript Validation

24. eDoc Lite – XML Definition • XML Definition

25. eDoc Lite – XML Definition • XML Field Defs w/ Validations

26. eDoc Lite – Form Demo • XML Embedded Style (XSL)

27. eDoc Lite – Route Log • Screenshot of eDoc Lite Route Log

28. eDoc Lite – Why? • Integrating with an ERP system is hard. • Sometimes you have simpler needs. • Particularly outside of central IT. • ie, a point solution to some unit’s need • or just a simple business process • Doesn’t require Java programmers !!!! • Can be modified at runtime • Can be built and modified by someone outside of Central IT (if trained a bit)

29. KFS Routing Example • Picture is worth a thousand words, and a live demo is worth a thousand power point slides. • We’ll show here a concrete (and relatively complex) example of a document routing in KFS (Kuali Financial System)

30. KFS Routing Example • Using Disbursement Voucher document • Used to disburse funds (ie, pay someone) • Since its real money, there is a lot of approvals and checks needed

31. KFS Routing Example • Screenshot of DV Routing Config

32. KFS Routing Example • Screenshot of filled-in DV document

33. KFS Routing Example • Explanation of routing types • Account Review (ie, Fiscal Officer) • Org Review • Employee Indicator • Tax Control Code • Alien Indicator • Payment Reason • Payment Reason + Campus Code • Campus Code • Alien Indicator + Payment Reason • Payment Method

34. KFS Routing Example • Screenshot and Explanation of Account Review Configuration

35. KFS Routing Example • Screenshot and Explanation of Org Review Configuration

36. KFS Routing Example • Screenshot and Explanation of Employee Indicator

37. KFS Routing Example • Screenshot and Explanation of Tax Control Code Configuration

38. KFS Routing Example • Screenshot and Explanation of Alien Indicator Configuration

39. KFS Routing Example • Screenshot and Explanation of Payment Reason Configuration

40. KFS Routing Example • Screenshot and Explanation of Campus Code Configuration

41. KFS Routing Example • Screenshot of Route Log of Completed Doc

42. KFS Routing Example • Conclusions • Can be simple or complex • Can always fire or can conditionally fire • Can be complex java routing, or simple field/value based routing logic • Latter can be updated by a non-technical user • Unlimited potential, but can also be simple where that’s all that is needed

43. Questions? Questions from the audience. Eric Westfall ewestfal@indiana.edu Andrew Hollamon hollamon@arizona.edu