Rapid Development of Workflow-enabled Forms using eDocLite

Kuali Rice

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.

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

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

eDocLite Architecture

Picture of an eDocLite

eDoclite Document TypeFlexible 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

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

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.

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.

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.

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.

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.

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.

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 (Javascript fuction passed into existing out of the

box templates library (called widgets.xml)• Validate that client user has javascript turned on

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.

eDocLite Creation ProcessBegin 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.

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.

eDoclite ReportingBesides 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.

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

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

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

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– Refactor eDocLite to use more of the KNS

• Add better support for integrating with external databases– Pre-load data– Populate drop-down menus

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