/
Build an Advanced Document Workflow

Build an Advanced Document Workflow

Jun 09, 2009

Overview

The purpose of this tutorial is to:

  • Help clients with little or no programmer resources to gain expertise in developing lightweight complex department-wide workflows

  • Help clients to move from a paper-based form paradigm to an electronic form paradigm

  • Help clients to progress to building workflows that facilitate complex business processes.

In this tutorial we will use eDocLite to facilitate a business process called Request Firewall Change which is owned by IET Application Development. This time the process involves more responsible parties and more levels of decision making (yikes!!!).

Instead of creating Users and Work Groups ourselves, we will leave that task to the administrators of the identity management system. We can expect all Users to already be present in the system. Work Groups can be specific to workflows, so we can expect to request that these be created by the system administrators.

Also, instead of expanding on the workflow in the Simple Document Workflow tutorial, we will build a brand new workflow. Whereas the previous tutorial has a "get-your-feet-wet" flavor, we will give this one the "little-fish-in-the-big-pond" treatment. This means we will act as though there are several departments (tens of or hundreds of) at UCD who are already using eDocLite for all kinds of document workflows and therefore, we must use naming conventions that will prevent our work from colliding with other departments' work and do so without confusing us at the same time.

In this case, there may be several other departments who:

  • administer their own firewalls

  • have a "Firewall Request Change" process that differs from IET Application Development's process

  • have work groups that have the same name as IET's work groups, but may or may not have the same responsibilities

We will employ a development cycle that closely follows the eDocLite dependency hierarchy:

Naming Conventions

Workflow Component

Naming Convention

Parent Document Type

<namespace>.<workflow name>.ParentDocType

Child Document Type

<namespace>.<workflow name>.ChildDocType

eDocLite Form Definition

<namespace>.<workflow name>.Form

Rule Attribute

<namespace>.<workflow name>.<rule attribute name>.RuleAttribute

Rule Template

<namespace>.<workflow name>.<rule template name>.RuleTemplate

Rule

<namespace>.<workflow name>.<rule name>.Rule

XML Files

Naming Convention

Parent Document Type

<namespace>.<workflow name>.ParentDocType.xml

Child Document Type

<namespace>.<workflow name>.ChildDocType.xml

eDocLite Form

<namespace>.<workflow name>.Form.xml

Rule Attributes

<namespace>.<workflow name>.RuleAttributes.xml

Rule Templates

<namespace>.<workflow name>.RuleTemplates.xml

Rules

<namespace>.<workflow name>.Rules.xml

Development Cycle

  1. Model the Business Process

  2. Model the Form Details

  3. Model the Document Workflow

  4. Create Validation Checklists

  5. Procure Work Groups

  6. Create Workflow Components

    • Create the Parent Document Type

    • Create the Child Document Types

    • Create the eDocLite Form

      • Create the Definition

      • Create the Stylesheet

    • Create Rule Attributes

    • Create Rule Templates

    • Create Rules

  7. Implement Workflow Components

  8. Simulate the Business Process