For Software Architects / IT Managers

Any WfMS must deal with the following aspects of workflow automation:

• Control flow. A WfMS must facilitate design of complex business processes. It must handle parallel and sequential tasks, providing a way to "roll back" a business process to a logical quiesce point, etc. Extensive academic research has identified a list of fundamental workflow patterns that are described here in a paper by Bartosz Kiepuszewski. Usually, control flows are designed in graphical editors with drawing features similar to Visio, and then used by the WfMS for each individual case it processes.
• Resource management. WfMS must have a facility for assigning tasks to the resources (systems or people). Basically, it should always have the answer to the following three questions:
  • Who should be assigned to this task?
  • Who is assigned to this task?
  • What tasks are currently assigned to a specified resource?
• Data integration. A business process may take different paths for different situations, e.g. business process may require a credit report for life insurance policies over a certain amount. A WfMS must provide some mechanism for using application-specific data (amount) for making control flow decisions.
• Application integration. A WfMS must provide an architectural roadmap and developer APIs for integrating with custom applications.

Lynx Workflow describes control flow with a new workflow language called YAWL. This language is based on Petri Nets, which is a formal mathematical tool for modeling and analyzing processes (click here for a simple new Petri tutorial). YAWL itself is a result of a rigorous analysis of existing workflow management systems and workflow languages by the academic community. In the course of this analysis, a group of mathematicians in Netherlands and Australia identified an extensive set of workflow patterns and reviewed how most of the leading workflow management solutions support these patterns. Most of the systems supported only subsets of these workflow patterns. Thus, they designed a language that would formally accommodate all of the patterns.

The resource management mechanism built into Lynx Workflow is based on the concepts of case and task, formally defined in YAWL, as well as work item and work list. A work item is an instance of a task that is enabled or performed within a specific case. If the task is executed again, there will be another work item, etc. Work items can be assigned to one or more work lists. Work lists act as proxies for resources. A resource may have different work lists for different purposes. Lynx Workflow provides a facility for managing resources and a built-in functionality for assigning work items to work lists. For more complex cases it provides a powerful and flexible plug-in mechanism for building custom logic for assigning work items. Plug-ins can be written in .NET and may operate on the data within Lynx Workflow database. Alternatively, there is a client-side API for assigning and reassigning work items.

There are two main ways of integrating WfMS with application data.

1. Importing necessary data into the workflow engine - Imported data is then evaluated when making decisions within the WfMS using a custom scripting language. In this case, everything pertaining to the workflow is captured in one place and can be viewed within the WfMS.
2. Exposing the decisions within the workflow to the outside application code - In this case, the development is easier. Decisions within the workflow can be made using custom plug-ins within the workflow engine written in the same language as the rest of the application. There is no need to learn or be limited by the scripting language. Data retrieval may then use APIs developed for the rest of the application.

Insurapro WfMS uses the second approach with developer-friendly APIs for telling the workflow engine which path must be taken.

The model below (http://www.wfmc.org/standards/model2.htm) is provided by the Workflow Management Coalition to illustrate application integration. Here, the model is specifically applied to Insurapro's Lynx Workflow WfMS:

Lynx Workflow provides an API for

• getting the list of active tasks for a given case;
• starting, assigning and completing tasks;
• getting possible workflow paths; and
• selecting a specific path if allowed.

Communication between the client application and the workflow server is done using Microsoft Remoting, with security and some other facilities provided by Genuine Channels library ( http://www.genuinechannels.com). Microsoft Remoting works over a Web Services interface or a straight TCP/IP connection.

In addition to the Workflow Server and client API, Lynx Workflow includes:

• Test Client - A sample application demonstrating API for assigning, starting and completing tasks, as well as making decisions. It is also used for rapid prototyping of an application workflow for potential users, etc.
• Sample workflows - Currently this includes only example for Life Reinsurance Claim.
• Lynx Workflow Modeler - This program is used for creating workflow definitions. It is also used for creating resources and assigning them to the tasks within the workflow. Design-time assignments are the default assignment of work items to resources. In addition to that, Lynx Workflow Modeler has Lynx Workflow Engine built in, so you can actually run and debug your workflow within the editor. You can download a pre-release version of the editor here.

Lynx WfMS is designed to be as open as possible, allowing developers to use its core (workflow engine) as a platform. It provides a set of well-defined services (that are also expandable!) and leaves the rest up to the customer's development team.

---