Workflow

Throughout iMIS, there are many examples of workflow processes:

• Processing orders through order entry, confirmation, approval, shipping, shipping notification, invoicing
• Processing a member application
• Signing up an exhibitor and following and tracking the process through the various contracts and order requirements
• Processing opportunities
• Issue Management
• Marketing campaigns
• Timed responses to inactivity
• Multi-part mailings: Letters and labels to go with the letters

These are examples of what we will call process workflow and generally are thought of as persistent workflows, which might take a few minutes, days, or even months to complete.

Workflows typically:

• Have an ownership structure.
• Are related to a specific parent object, like an order, complaint, and so on.
• Have a set of tasks that must be executed according to business rules.

To deal with this pattern of needs on a consistent basis, iMIS provides a Workflow Engine.

There are two primary components of the workflow engine:

• Process Definition Rules – Process definitions list all of the tasks for the workflow as well as the rules as to when the tasks are to be executed, and what the subsequent actions are to be initiated upon task completion. Tasks need not all execute serially. For instance, a workflow might have a step that requires approval from multiple sources, not necessarily sequentially.

• Workflow Instances – Workflow instances are the actual workflows in action. Workflows might carry their own process definition rules within, or might simply refer to the standard definition for the workflow type. When rules are carried by the workflow, they might be constructed or modified dynamically by applications. Workflow instances have one or more owners with specific roles.

As workflows progress and workflow rules are interpreted, work items (or tasks) are generated. Tasks are generally assigned to specific individuals or process queues. Automatic processes are executed without human intervention. People-oriented queues show as tasks to your users. Tasks are never deleted; they are only marked complete. Tasks record time and, in some cases, effort for completion. The analysis of task data performance data can be a good source of information for process improvement.

The workflow itself can carry state data, document attachments, references to customers and their roles.

Workflows can run totally off their static definitions, or be created or modified by runtime processes.

Workflows are always used for system processes such as print invoices, print AR statements, and so on. Since workflows are extensible, field users can add or subtract steps to these processes. Workflows are used to move most all of the older hard-coded processes like print invoice, convert order, do due billing run from hard-coded processes to extensible processes and allow installers to mold these processes to customer needs in a consistent way.

Workflows can be executed in a number of environments. They can run silently in the background as queues of work are worked off by the workflow engine’s background and scheduled processes, or can be run interactively. In the interactive situation, a standard dialog, similar to an installer dialog, will display progress and asks for intervention as required.

An initial implementation of the workflow engine exists in Process Manager. However, that implementation did not implement business rules or automatic application execution.

Another common pattern in iMIS is the situation in which there is a list of objects (1-n), where you would like a particular process to be performed across the list. Refer to the table for examples of this pattern.

Though there are many occurrences of this pattern, perhaps it would be helpful to isolate our study of this problem to the single situation of an ad hoc query tool. Typical tasks could include:

• Creating a query that selects a particular group of customers
• Sending something to the list: perhaps an email, a letter, a fax, or add them to a marketing campaign (a subscription group)
• Naming or editing our own letter or email template
• Scheduling for subsequent execution

We would also like to be able to carry out these types of processes over time on or to new types of processes, without having to update our query selection tool constantly.

Our implementations that deal with this pattern are known as Process engines. Process engines are generally services, encapsulated in objects that are sub classed upon the base Process Engine.

Process Engines must inherit the base process engine class and provide a few basic services (methods).

• On demand, they must supply a visual template editor which is sub classed from the Process Engine Template base class. The template editor interacts to select or define a template specific to the type of process. For instance:
  • Crystal reports template editor allows a user to specify the location of a crystal report and any parameters that will be needed to execute the report.
  • Mail merge process engines specify or define on the fly a mail-merge template.
  • A multi-output process engine may specify the rules about when to choose which media type and what letter templates will be used. A multi-output process engine is an application that receives an initial input then delegates subsets of the input list downstream to other process engines.
• Provides standard methods to execute a process, monitor progress, log errors, and report results.

Process Engine objects are frequently bound to query objects. Template Process Engine objects (such as a process engine for Crystal Reports but no report specified), and specific process engines (such as a process engine for a specific Crystal report), are generally persisted in document libraries with or without bound query objects that, in term, provides a catalog of available processes to users and administrators. In fact, process engines bound to query objects present a major part of the iMIS application to user, especially for the standard and ad hoc reports users use continuously.

Process Engine objects with bound query objects are frequently queued as tasks within a workflow for subsequent execution. Multiple process object tasks can be included into a single workflow for report sets or multi-step processes.

• Crystal reports
• XSL/HTML reports
• Email system
• Word Merge
• Create subscription group from query
• Add people to marketing campaign (same as above)
• Register people from query
• Multi-output process engine

• Data-oriented web pages
• Reports and the report catalogs
• Dues billing run definitions