Kuali Rice

1. Rapid Development of Workflow-enabled Forms using eDocLite Kuali Rice

2. eDocLite Overview • A tool for building simple forms quickly • Ideal for quickly turning paper-based forms into electronic forms backed by Kuali Enterprise Workflow • GUI transaction saved as each person involved adds their data or approval. • The transaction is defined on a web page consisting of html markup called a form. • Most of the data on the form is selected or entered. • Certain sections can be shown/hidden based on the user who is interacting with the form.

3. eDocLite Overview • eDocLite acts as a client built on top of KEW, all the common features of a KEW document are available such as: • Document Search • Action List • Email Notifications • Route Log • Document type Definition • Rule Templates • Rule Attributes • Routing Rules • Essentially, eDocLite documents are just KEW documents • The user interface piece is the real value-added component

4. eDocLite Overview • Created with no Java, just XML and optionally some Javascript. • Uses a library of XSLT templates that greatly ease the HTML that is produced. • Can be integrated with larger applications, often by using a database layer post processor component • Internally, eDocLite uses a series of “processors” that build up the XML that is ultimately transformed by the XSL stylesheet

5. eDocLite Architecture

6. Picture of an eDocLite

7. eDoclite Document Type • Flexible routing definition: • Simple, Splits, Joins, Sub processes • Route Node – Represents a ‘step’ in the routing process. Defines the behavior of the document when it reaches that node: • Simple: ie: A workgroup of people receive notification to open the document and take some action. • Split: split the route path. ie: certain people should get a custom email based on some form data. • Join: join the route paths. • Sub Process: ie: group other nodes together into a sub-process. (for re-use in another branch) • eDocLite Documentation Guide https://test.kuali.org/confluence/x/2wHwB

8. Routing Rules • Configured via a GUI (or ingested from XML) • Rules define the users, groups and/or roles who should receive action requests • Available Action Request Types that Rules can route • - Complete – (technically like ‘Approve’, functionally lets a user know to complete the form like after a ‘Save’). • - Approve • Acknowledge • FYI

9. Rules how implemented • A Routing Rule evaluates document data to determine if it matches predefined rule data. • Can be written in Java or defined using XML (with matching done by XPath) • Rule attributes can define what fields are used in the rule. • Rules match (or ‘fire’) based on the evaluation of data on the document and data contained on the individual rule. • Example: Route to workgroup defined in this rule when dollar amount on form is > $10,000.

10. Database under eDocLite • No Database changes required! • Even when Doctype specifies EDLDatabasePostProcessor, field Title and Value are stored in a table by Key, Value. • Independence from Database changes eases eDocLite development significantly. • Custom PostProcessors allow for updates to other Databases.

11. Attachments and Notes • ATTACHMENTS: • Each user may save ‘Attachments’ (files of any type). • Multiple Attachments are allowed. • KEW configuration allows the storage location of Attachments to be defined. • NOTES: • Each user may save ‘Notes’ which are textual information. • Multiple Notes are allowed.

12. eDocLite Creation Process • Part of implementing eDocLite is determining how it fits into your institution. • We will describe our process for creating eDocLite documents at Indiana University. • Determine with client users if proposal is within scope of eDocLite’s capabilities. • Some things that may be too heavy for eDocLite to handle: • Client requires their database to be used to pull data from. • WEB 2.0 or AJAX • Not a whole lot of support for complex page flow.

13. eDocLite Creation Process • If eDocLite is a viable solution: • Identify proposed Routing: • What fields will be involved. • Where will these fields get their values from. • Can certain nodes be bypassed (fall past them) based on rules? • Is ad hoc routing (via principal name or group name) needed? • Identify entity naming convention. Normally it is helpful to name each entity within the eDocLite with: • A high level qualifier • A second level qualifier that is specific to this eDoc.

14. eDocLite Creation Process • Identify if any special PostProcessing requirements exist and if so, determine the specifications for this Java code. • PostProcessing may, for example, update the user’s database. • Identify if a Parent or Root Document Type can contain the routing. • This is useful when multiple child eDocLites will use a common routing scheme.

15. eDocLite Creation Process • Capture client’s proposed form fields. • Each Field Title • Each Field’s potential value • Correlate each to a HTML type • Determine what type of editing can/should be performed. • Required • Regex (Regular Expressions) • Custom Validator (Javascript) (automatic invocation) • Custom Function (Javascriptfuction passed into existing out of the box templates library (called widgets.xml) • Validate that client user has javascript turned on

16. eDocLite Creation Process • Follow in-house standards - For Example: • Use a standard symbol like a red asterisk when fields ‘require’ entry. • Use standard colors and css types • Place buttons, Notes, Attachments in a common place. • Common format for Date entries. • Make use of built in capabilities like: • XPATH for cross field validations • Regex to edit user input • Pass custom function Javascript name to existing widgets XSLT templates that can execute it and thus provide extra functionality. • Use the standard Buttons templates whenever possible.

17. eDocLite Creation Process • Begin generation of the prototype: • Enter the necessary Document type, Rule Template and Rule Attribute definitions, Rule Routing rule (ingest them). • Create the EDL definition by cloning one that already works. (see https://test.kuali.org/confluence/x/2wHwB ) • Using an xml friendly editor, add fields in the EDL portion, then begin to modify an existing working stylesheet. • Save your work and ingest very often! • Click the create document available on the KEW Edoclite link to initiate the eDoc to see your stylesheet work transformed as HTML.

18. eDocLite Creation Process • Learning curve can be greatly reduced by first reviewing the code for the eDocLite Example that comes out of the box, then examining examples that IU (and perhaps others) have attached to the eDocLite confluence Documentation page. • There is a chronological order that eDocLite components should be ingested. • We keep the components in files alphabetically named so their order of ingestion is maintained. (details on eDocLite Documentation page). • To migrate an eDoclite these files can then be ingested to new test environments or Production.

19. eDoclite Reporting • Besides the GUI, and 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 – out of box – that writes data to • KREW_EDL_DMP_T • KREW_EDL_FLD_DMP_T • These capture each field and value on each pass thru KEW. • To implement, specify <postProcessorName>org.kuali.rice.kew.edl.EDLDatabasePostProcessor</postProcessorName> in the Doctype.

20. Special Features • Drop Down Selection Depends On: • Type select_refresh allows the values in a select dropdown to be restricted by a selection of another dropdown. • Example: • Campus selection drives values in School • School selection drives values in Department etc. • KEW Class WorkflowFunctions • Additional methods can be added • Example existing method: isAtNode() • Edoclite1.js is out of the box supporting Javascript. It works together with Widgets.xml

21. eDocLite – Summary • No Java development required • No Database changes required • No application to deploy • Enables rapid development of Workflow-enabled Forms: • Common look and feel • Easy to maintain and implement

22. Examples – eDocLite @ IU • Safeword Card Request • Office of the Vice President for Research • Internal Funding Request • Conflict of Interests • University Graduate School – Course Remonstrance • IU Health Center – Electronic Appointment Requests • Dean of Faculties – Office of Affirmative Action • Bloomington Registrar • Bulletin • Documentation • Student System – Special Credit Request • Purchasing Contracts • Account Management System • University College – Request for Absence • Security Office • Motor Pool Request • Oncourse (Sakai) Administrator Request

23. What does the future hold? • eDocLite was developed as part of KEW before the Kuali Rice project was created • Contains a lot of overlap with certain pieces of the KNS • RefactoreDocLite to use more of the KNS • Add better support for integrating with external databases • Pre-load data • Populate drop-down menus

24. What does the future hold? • Continued improvements to existing eDocLite XSL templates • Improved scripting support to facilitate more complex logic • Cornell University implemented an Adobe-based solution which has a lot of similarities to eDocLite • Will be contributed for the Kuali Rice 1.1 release

25. Questions? • Web Site: http://rice.kuali.org • Docs: http://rice.kuali.org/docs/1.0.1 • Email: rice.collab@kuali.org