Workflow Rules Extender

Rules Extenders

Common Knowledge provides a set of Rules Extenders which provide various formats for the representation of business rules. The full set of Rules Extenders includes the following:

  • Decision Tables
  • Decision Trees
  • Decision Grids
  • Workflow
  • Rete Rules
  • Script
  • ActiveScript

Declarative Rules

Declarative programming is where problems are described (or conditions on a solution are described) and the computer finds a solution. Often it involves the separation of "facts" from operations on the facts. This is generally contrasted with imperative programming where the computer is supplied with an algorithm that specifies, step-by-step, what it must do in order to solve the problem.

The intention of declarative programming is that declarative languages are easier to explain to non-programmers. This enables expert users, or business-minded users, to be incorporated into the development process. Therefore it is desirable to represent an organisation’s business rules in a declarative format whenever this format is intuitive and accessible to business users.

Business Rules

Common Knowledge now includes a powerful Workflow Rules Extender. This extender allows business rules designers to architect solutions from powerful combinations of both declarative and time and sequence dependant rules. The Workflow Rules Extender provides a graphical editor for defining process flows which can incorporate other rules representations as well as external actions.

Figure 1 – Common Knowledge Workflow Editor Screenshot

Traditionally, rules management systems have focused on declarative representations of business rules, using formats such as decision tables, decision trees and production rules (rete-rules). Unlike the traditional approach using a procedural language representation, a declarative approach allows business rules to be represented in a more understandable and maintainable format. Whilst the best systems will always represent as many business rules as possible in a declarative format, declarative rule formats have a number of limitations relating to the representation of the timing, sequencing and rule inter-dependencies aspects of business rule solutions. These limitations can be overcome by providing for the concept of a "flow" through the system, and defining how rules and actions fit into this flow. This "flow" is often termed "workflow" or "rules-flow".

Considerations of flow within business rules are now being recognised by various authors, commentators, methodologists and product vendors in the field of business rules systems. The responses to this are, however, somewhat varied. Some authors will recommend including flow directly into the definition of the business rules whilst others advocate the restriction of rules representations to declarative formats only. Likewise, some business rules management systems will include facilities for defining basic rule-flows, whilst other vendors will recommend that this be co-ordinated by a dedicated workflow management system. There will be compromises with whichever approach is taken so it is important to make careful consideration of the needs of your particular problem when deciding which approach to adopt.

WfMC Reference Model

The Workflow Reference Model, of the Workflow Management Coalition, defines the following five interfaces to a workflow engine:

  • Process Definition Interface – between process definition and modelling tools and workflow engine.
  • Workflow Client Application – API for client applications to request services from the workflow engine.
  • Invoked Application Interface – allows WFE to invoke a variety of applications.
  • Workflow Interoperability Interface – for one workflow engine to interact with other workflow engines.
  • Administration & Monitoring Interface – for monitoring and control functions of the workflow engine.

Background to Workflow Management Systems

To understand these issues more fully, it is worth having a quick look at current workflow management systems. The term "workflow" can be easily confused when discussing information systems. This confusion stems from the wide variety of workflow-related terminology and concepts used by vendors, consultants and industry analysts. This in turn, is a consequence of the relative immaturity of the technology, the lack of standardisation and the variety of ways in which a business process can be described. This paper will not attempt to clarify all current workflow terms, rather, we will borrow enough terms as is necessary to explain how a business rules system can be made to satisfy the core workflow requirements of a typical information system.

Let us consider the following definitions:

  • Workflow: A Workflow is very general concept describing how to model a process.
  • Workflow Management System: A Workflow Management System (WFMS) is a software component that takes as input a formal description of business processes and maintains the state of the processes' executions, thereby delegating activities amongst people and applications.

The first of these definitions is quite clearly a very general description of what workflow can be. This is however a useful definition for us to use as it encompasses most of the explanations of workflow that you are likely to hear from industry commentators. With this definition, we can define workflow models for problems as low-level as the definition of a multi-step mathematical function, or as high-level as an enterprise-wide system for processing customer enquiries. Much of the industry commentary tends to centre around the higher-level enterprise processes, often referring to "Business Process Management". Workflow and Business Process Management tend to have overlapping meanings. Workflow is the preferred term used by technical software developers when denoting a series of related interactions between people and a computer system. Business Process Management has a more broad scope, often covering non-technical issues like analysis organizational impact, from the viewpoint of a manager.

Usages of WFMS's can generally be classified as one of the following three types:

  • Enterprise Application Integration (EAI) - A large enterprise will commonly possess a number of disparate applications, each dedicated to a separate functional area. The enterprise may, however, want to combine the functionality of these dedicated applications into a larger organisational business process. This requirement is the purpose of many WFMS's that focus heavily on these integration aspects.
  • Co-ordinating people-related tasks - Some WFMSs accompany the process definition tools with easy creation of simple client forms. This approach can deliver high value where the business process involves a lot of people related tasks.
  • Embedded workflow engine - With this approach, the workflow engine is embedded within another application. The WFMS is not directly visible to the end-user. The main purpose of this approach is to enable better maintainability and reuse within applications that employ complex workflow-related logic.

Other Rule Extenders

Workflow can be integrated with the following Common Knowledge Rules Extenders (and all others):

Decision Tables

An intuitive, tabular format that provides a highly-maintainable and logical organisation of rules

Decision Trees

Useful for illustrating decision points and outcomes within a decision-making process.

Rete

Rete algorithm for production system rules.

Scripts

Procedural logic is sometimes needed when rule requirements do not easily match one of the more standard rule formats.

Flowcharts

Flowcharting is a technique for creating pictorial representations to describe a process that is being designed or analysed. A typical flowchart is one that describes the steps in assembling a piece of furniture; or the steps to take during an emergency evacuation.

Flowcharts allow people to better visualise, or find flaws in, a given process. Flow charts also tend to provide people with a common language for discussing and understanding processes.

State-maps

State-maps are also known as state charts, state transition diagrams, or finite state machine diagrams. These are a familiar technique for describing a system and have been around since the 1960s. They are often useful in modelling reactive systems and are found to be useful in areas such as electrical engineering, computer science, philosophy, biology and logic. State-maps depict the states that the system can exist in, the transitions that occur between system states and, the events that cause a transition to occur.

Procedural Logic vs. Flow Diagrams

Much control-flow logic that is traditionally implemented in procedural programming languages may also be implemented using flow diagrams:

for i in 1 to NumAccounts
do
    GetAccount(i);
    PrintAcctStatement(i);
end;

For example, looping control structures may be implemented in a flow chart, providing a visual and more intuitive representation of the logic.

Flow diagrams implement many of the same control-flow logic structures used in programming languages, such as branching, looping and switching.

Aspects of Workflow Implemented in Common Knowledge

It is important to recognise that the Common Knowledge Workflow Rules Extender is not intended to act as an enterprise workflow management system. Rather, it is designed to fulfill the role of an embedded workflow and ruleflow engine within a host system that has a complex set of business rules requirements. Common Knowledge incorporates workflow into rule definitions in order to better represent rules that are utilised by a business during its operations. A dedicated WFMS is generally the solution of choice when an organisation needs off-the-shelf workflow capabilities, including: administration and monitoring of the workflow; pre-built forms for accessing the workflow; and plug-and-play integration with a large array of other software products. Often, however, an organisation's requirements are not centered around these facilities but are focused on the ability to automate a complex business process that is governed by many and varied constraints. Common Knowledge excels at representing and automating this category of requirements.

The Common Knowledge Workflow Rules Extender provides a flexible and feature-rich tool for defining a large variety of complex process flows. In addition to this, the Workflow Rules Extender can be combined with any other Common Knowledge Rules Extender (rules representation) to produce powerful hybrid solutions. For example, a set of Workflow rules could be defined to model a business process that incoporates a Decision Tree for deciding the direction of the process flow at a decision point in the flow. However, the tool’s capabilities also go beyond the rich expressive-power available in the process definition. Flexible integration with other systems can be achieved by combining Workflow with Common Knowledge Channels to enable bidirectional communication with external systems and parties. A range of Channel types are supported by Common Knowledge (examples include SMTP-POP3 E-Mail, Socket, and Microsoft Message Queue).

The Common Knowledge Workflow Rules Extender also provides a feature-rich graphical environment for creating workflow process definitions, including a large palette of tools that can be readily assembled into models that cover a wide range of process types. These processes may range from very low-level processes to very high-level processes. Four useful categorisations of process types are shown below with a sample of the Workflow rules created to illustrate each.

Flowchart: A process-flow model that emphasises the decision-making paths that guide someone through a particular process.

Figure 2 – Portion of a  Payment Request Flowchart

Workflow: A set of activities and events that occur during the execution of a business process.

Figure 3 – Example of a Loan Approval workflow process

Statemap: A model describing a system that exist in only one particular state at any given time, and moves from one state to another in response to certain external events.

Figure 4 –Statemap of Basic Oxygen Steelmaking (BOS) process

Ruleflow: Used to define control over the sequence of rule execution and chaining.

Figure 5 – Portion of an Insurance Quotation Ruleflow

The same Workflow Rules Extender can be used to create each of the above types of Workflow rules. The Workflow Rules Extender provides tools to model workflows using a variety of control-flow patterns. By adopting this control-flow perspective on workflow, Common Knowledge provides a base set of tools that can be used to build powerful combinations of complex flows.

Another point worth noting is that workflow can provide an intuitive alternative to using procedural scripting in your business rules. Business rule designers sometimes encounter requirements that are difficult to represent using declarative rule representations. Often these problems are related to the control of execution logic and can thus be solved by using procedural scripting languages. The downside to this approach is that these business rules are now represented in a format that is not intuitive to business-oriented users of the rules system. In this situation workflow can represent an effective alternative. The business rules can be incorporated into a workflow process definition that is graphical and, therefore, more intuitive to the business-minded users of the rules. The rules will have greater visibility to a wider range of people and will become more maintainable and understandable as a result.

Terminology Used In Workflow Rules Extender

Before examining the tools provided with the Workflow Rules Extender in detail, it is worth taking a look at the main terms that are used when describing Common Knowledge Workflow rules.

Nodes: A Workflow has one or more Start Nodes and one or more End Nodes. Individual activities (such as evaluating expressions or performing business tasks) are represented by specialised Nodes which are connected to one or more other nodes by Connections, ultimately originating from a Start Node and leading to an End Node. The specialised Nodes provided with the Workflow Rules Extender implement the control-flow patterns needed to build workflow models. Additionally, custom actions can be attached to nodes in the workflow.

Connections: Connections are unidirectional and an arrow on one end of a connection indicates the direction in which the workflow process flows from one node to the next. State information can flow along these connections and additionally, custom actions can be configured to execute upon transitions occurring along a connection.

Tokens: Tokens represent the data (state information) that flows through a workflow or drives the workflow and can range in type from a simple value such as an integer to a complex object such as an XML document. Tokens flow along connectors between nodes. Data can be explicitly read from, or written to tokens during execution of the workflow.

Commands: Each node supports a set of one or more commands, including the Default command which is supported by all nodes. When a Connection is made to a Node, the target Command must be specified. The Default command instructs a node to perform its normal processing with the given token. More sophisticated nodes may support additional commands such as a Reset or Clear command for nodes that maintain state.

Node Types in Workflow Rules Extender

The Common Knowledge Workflow Rules Extender supports more than thirty types of Workflow nodes that can be used to assemble complex workflow models. The nodes are grouped into the following categories: Workflow, Expression, Operators and Realtime. The following section describes a subset of the nodes available in each category in order to illustrate some of the functionality that is provided by the Workflow Rules Extender.

Workflow Nodes

These nodes represent traditional aspects of business processes such as parallel flows, decision points and activity synchronisation.

Task: The Task node represents an external task for which acknowledgement of completion is required before Workflow execution continues.

Split: The Split node allows a single Workflow path of execution to be split into multiple paths.

Merge: The Merge node allows multiple Workflow paths of execution to be merged into a single path.

Expression Nodes

These nodes can be combined together to form complex expressions, formulae and calculations.

Expression: The Expression node evaluates an arbitrary expression. The result of the expression can be assigned to the Token if the AssignToToken property is set to true.

Average: The Average node calculates the average value of all received Workflow tokens and outputs the result (as a token).

Operator Nodes

The Operator category of nodes consists of four sub-categories: Arithmetic, Logical, Comparison and Bitwise. These nodes represent a set of low-level operators that can be used to build more complex function definitions.

Binary Arithmetic: The Binary Arithmetic node performs an arithmetic operation on two or more Workflow token values and outputs the result (as a token).

Binary Comparison: The Binary Logical node performs a logical operation on two or more Workflow token values and outputs the result (as a token).

Real-time Nodes

A set of nodes useful typically suited to real-time systems such as those used in the manufacturing industry.

Signal Generator: The Signal Generator node outputs a series of Workflow tokens whose values are generated based on a selected waveform (such as sin, square, sawtooth etc). Each value is a sample taken at a regular interval in the waveforms cycle.

Analogue Alarm: The Analogue Alarm node provides an alarming mechanism for analogue (floating point) values provided by incoming Workflow tokens. The Analogue Alarm node may output a Workflow token indicating a particular analogue alarm state.

Standalone Rule Execution

All types of Rule Extenders in Common Knowledge support standalone execution. This means the business rules may be developed, tested and debugged independently of any host application that they will subsequently be integrated with. This separation encourages a structured and layered approach to the design of rules bases systems.

Execution of Rule Extenders in Common Knowledge is a highly-interactive process that includes the following features:

  • Colour highlighting of execution paths.
  • Interactive debugging including the ability to set breakpoints and step through rules.
  • Display of changing values of variables during execution.
  • Prompting for input values during execution.
  • Logging of reasons for rule activation.
  • Ability to simulate actions by external programs.

Capabilities of Workflow Rule Extender

Whilst the strengths of the Workflow Rules Extender are made visibly apparent through the interactive graphical workflow editor, these strengths are further demonstrated through the ability to combine Workflow definitions with existing Common Knowledge Rules Extenders such as Decision Tables and Rete Rules. Following are a number of additional points of consideration that will help in better understanding the enormous potential of the Workflow Rules Extender.

Standalone Execution: Like all other Rules Extenders in Common Knowledge, Workflows can be fully executed, standalone within the Common Knowledge Studio environment. Within Studio's run-time simulator/executor, environment conditions can be set up, external system actions can be simulated, data values can be logged and the run-time execution flow can be observed. This provides an extremely powerful feedback mechanism when analysing, developing or debugging workflow processes. The rules can then be deployed with the host system along with the Common Knowledge Rules Engine.

Figure 6 – Common Knowledge Studio mid-way through executing a Workflow

Process Definition Model: The Workflow Rules Extender is based on a generic "token flow" model for describing the underlying workflow process. This implies that it can be used to represent many types of "flow" models including workflows, rule-flows, flowcharts, function charts and state-maps. This allows combinations of flow diagrams and other Common Knowledge Rules Extenders to be used to construct powerful hybrid rules based process models.

Large Range of Nodes: As previously demonstrated, the Workflow Rules Extender provides a large range of nodes (currently in excess of thirty) from which workflows can be built. These nodes implement a wide array of basic control-flow mechanisms, ensuring they can be combined to represent most process flow scenarios.

Persistence: The Workflow Rules Extender includes the ability to persist the state of Workflows across time to ensure no information or state is lost between restarts of the application or machine. Through advanced features of the Common Knowledge Rules Engine API, you can elect to persist the Workflow state to a database, a file, or custom data store mechanism.

Channels: A Channel is a Common Knowledge element that can be used to define the attributes of a connection to an external point of communication or interaction. Channels can be likened to a "pipe" through which information can be sent from Common Knowledge to external systems or received by Common Knowledge from external systems. Channels can be accessed from all Rule Extenders in Common Knowledge, and they are particularly useful with Workflow due to the likely need for the Workflow to interact with other systems or people. The following Channel types are provided as standard with Common Knowledge:

  • MSMQ Channel - for integration with Microsoft Message Queue.
  • SMTP-POP3 E-mail Channel - for sending/receiving for e-mail.

These Channels provide the base mechanisms that would be required to build integration capabilities for most likely required integration scenarios. Object Connections will continue to implement more Channels as their need is identified. In addition, OEM Partners and Systems Integrators may elect to implement their own Channels with the assistance of Object Connections.

Summary

The Workflow Rules Extender of Common Knowledge provides a format for representing the timing, sequencing and dependency aspects of business rules that are not easily represented using declarative formats. The Workflow Rules Extender is intended to act in the role of an embedded workflow engine within a system that needs the ability to internally model and manage complex flow based business rules requirements. The Workflow Rules Extender is based on a generic "token flow" model that enables the construction of many types of Workflow models including flowcharts, workflows, function diagrams, state-maps and rule-flows. It includes a large range of node types for building such models, as well as Channels for integration with external systems and third-parties. The primary power of the Workflow Rules Extender is its ability to combine with the other Common Knowledge Rules Extenders in order to provide powerful hybrid business rule solutions. These solutions can be executed standalone within Common Knowledge Studio as an aid to development and testing. The Workflow Rules Extender provides an intuitive and configurable mechanism for representing and automating the “process” aspects of the business rules of an organisation.