eDocLite is a framework designed for rapid development and implementation within an existing Kuali Enterprise Workflow infrastructure. It allows for the development of simple web applications, their forms and routing configurations using XML. Users only have to enter data into the form and then submit it. Rules can be constructed so that the form is then routed to a specific user or KIM Group based on the data entered.
Web pages called eDoc's are generated and are associated with a specific document type definition that provides the overall definition for how the document can be routed. Document types can also exist in hierarchies which provide storage of common information at various levels.
The form uses an XSLT stylesheet to generate the html code. Certain workflow classes make helper data available to the stylesheet programmer and there are several features that can be 'plugged-in' to eDocLite to further enhance its usability in many situations.
Key Ideas:
Rapid implementation and development solution for simpler documents
Easily re-configured
Easily manageable
Entirely web-based from design/development and user perspectives
No java code required for developments; only XML with optional javascript for client side editing (workflow handles execution)
Some validation javascript is automatically generated like regular expression editing and 'required field checking'.
Use the eDocLite Lookup screen to quickly find basic information about eDocLite documents and as the first step in creating a new eDocLite.
You can go to the eDocLite Lookup by:
Click the Main Menu tab
Look in the Workflow section
Click eDoc Lite
On the eDocLite lookup page, users can search for an eDocLite document based on several criteria:
Table 3.2. eDocLite Lookup Attributes
Field | Description |
---|---|
Id | The unique ID number assigned to each document. |
Document Type | The name of the document type, which is specified in the Document Type attribute of an eDocLite. |
Definition | The name of the EDL XML definition. |
Style | The style specified in the EDL XML file is the style attribute of an eDocLite. Generally an EDL XML file has only one definition name which relates to one and only one style name. |
Active Indicator | You have the choice of searching by the active status of an eDocLite. |
You can use the above criteria to limit your search results. A search will produce a list of one or more results that look similar to the following:
Clicking Create Document on any line takes you to the eDocLite document screen where new documents can be created. The line item you choose will result in that document being used as a template for the new one you are creating. More information on this follows in the section called Create New eDocLite Document.
Clicking any underlined Id will take you to the eDocLite Inquiry screen for that document.
Exporting the output list to XML will give you the option of viewing the XML used to produce the list returned from the search.
Standard in KEW there is one eDocLite for electronic routing, and new eDocLites can be added based on business requirements. Some of the functions that eDocLites are used for in business include:
Applicant Monitoring
BLSC Request
Course Change Request
Grade Replacement Request
Internship Contract
Interview Request
Mass Mailing Request
Offer Request
Program Plan Update
REGR Access Request
Removal Of Incomplete
Revenue Producing Activity
SUDS Request Document Type
Search Status
Special Credit Request
Student Trip
User Agreement
Unit Change Request
Vacancy Notice
Vehicle Replacement
Waiver Request
New Course Request
The Inquiry screen displays the same information as is found on a line of the Lookup output, but this screen provides you with the export option. Exporting from the Inquiry screen produces a XML file of the source for the eDocLite document.
To create a new eDocLite document to be routed in KEW, click on Create Document in the row for eDocLite type wanted. It will take users to different forms of eDocLites depending on the document function, but they all have three general parts:
Document header
Document body
Routing action and annotation, and note area
The Document Header contains the following fields:
Table 3.3. Document Header Attributes
Field | Description |
---|---|
Document Type | The name defined by the document creator of this type of eDocLite. |
Document Status | The status of this document based on its routing status. |
Create Date | The date and time this document is created. |
Document ID | The unique system generated ID for this document. |
This portion of the document is where the user identifies the routing and complete business function.
Table 3.4. Document Body Attributes
Field | Description |
---|---|
Title | specifies the actions users are taking on the EDocLite forms, including editing and reviewing. Other general information can be stored here such as contact information, important notes, etc. |
Form | Renders form fields and input areas for the user to complete information required, depends upon the specific eDocLite requirements. |
This area is used to add annotation and choose action to be taken on this eDocLite document. Annotation is the comments associated with the routing process. You can add them to different nodes of the routing process and take actions on an eDocLite by adding annotations. The annotation appears in the route log of eDocLite as comments. Notes are the comments associated with this specific eDocLite form and appear with the form and not in the route log.
Table 3.5. Routing Action and Annotation, and Note Attributes
Field | Description |
---|---|
Set annotation | The area to add annotation. |
Action buttons |
|
create note | Area where users can add notes and attach documents to this eDocLite form. This part keeps track of Author, Date and time, and the Note added. Users have the right to add, edit and delete the notes they create. |
The following is one example of an eDocLite form:
Notes that have been added to an eDocLite document can be edited or deleted.
eDocLites are highly customizable. New eDocLites can be designed for new business and functional requirements. The document header and routing annotation and notes parts will be same or similar, the form will be different.
eDocLites can be designed to include following functions:
Some fields in eDocLite can be set as GlobalReadOnly. With this setting they are disabled and can’t be edited by any user other than the author.
Some fields in eDocLite can be set as ReadOnly, but users with rights can still edit them. After the initiator writes them they are disabled and become locked to some of the users in the routing process. But for users with proper rights in certain nodes in the routing process, the fields will become editable again. These users can take actions on them, such as modify, add, and return to a former routing node.
To accommodate some business requirements, certain fields and notes can be hidden from certain nodes in the routing process. For instance, some administrative notes on a course waiver request will be hidden from students when s/he gets the eDocLite form in the final stage of the routing process.