Edoclite and Managing Client Engagements What is Edoclite? How is it used at IU? Development Process?

Overview 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. Various parts of the form may be invisible at certain points to certain people depending on the forms design and purpose.

eDoc Lite 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

Terms and capability Action List (User’s Work List) Document Searching Document Audit Trail (Route Log) Flexible routing definition (in Document Type) Splits, Joins, Parallel branches, Sub processes, Dynamic process generation Uses Workflows Rules Engine Notification

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

Workgroups Workgroup is a name given to a group of people or even a single person. Workgroups are named and the people in a workgroup share the same responsibility. Therefore any member may respond to the form. Clients maintain their own workgroup membership. Existing ADS groups can be used.

Routing Rules Configured via a GUI (or imported from XML) 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

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) Can have multiple GUI fields defined in a single attribute Rules match (or ‘fire’) based on the evaluation of data on the document and data contained on the individual rule.

Rule Examples 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.

Edoclite Creation No Java coding is usually required. Instead XSLT is used to paint the web page and implement form logic. No database field definitions needed. Optional Javascript code can add enhance editing or other client side functionality.

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

Building an Edoclite Identify the form fields. Define a document type to hold certain attributes for the form, such as the documents name, and route paths. Identify form data that will drive routing. Mock up the form. Implement routing and routing rules. Ultimately defined in XML and imported

Features Simple validation rules Regular Expression Custom Validators Required/Not-Required JavaScript Validation Security Achieved through XSLT integration with KEW APIs

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

eDocLite – EDL Form

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