In my early posts, I mentioned both BPM and Rule Engine. In conjunction with these topics, today I’m going to talk about workflow systems. Workflow is an application technology that automates some functions thus eliminates to do recurring mundane tasks again and again. These repetitive tasks usually require user actions in absence of workflow system. Workflow is the streamlining (orchestrating) of business process steps according to some rules. Business steps are defined as workflow activities and workflow system runs these activities triggerred by business events.
Workflow systems may be in stand-alone or add-on form. In stand-alone workflow systems, workflow may cover the business process execution (Usually called BPM). In add-on type, workflow is triggered by external business events. Workflow system should be as loosely-coupled as possible and be flexible enough to add any type of new flow definitions. I know some workflow products are just built-in approval systems. Workflow is a technology beyond approval system. It may be only one function of workflow system.
Is workflow system a mandatory part of a business application? Simply no. We can add custom features that provide similar functions with workflow systems. However every time business process or people changes, we need to change whole application source code, this is a very fragile solution.
Let’s list some of the advantages of adding a workflow system to our applications whether you build or buy it.
Advantages of Using Workflow System
1- It enables us to define flexible business processes and change it any time we want. We can manage processes, execute them and monitor their status. In add-on workflow type, it adds a new business process layer on top of existing static application processes.
2- It facilitates “Push” technology. User tasks are brought in front of them by workflow messages. In this way, they don’t have to control new data periodically via navigating many application screens. Users don’t necessarily need to receive emails or phone calls form other users on the same business process flow. They can receive workflow messages instantly when processes occurs. Thus, business process runs faster. For example, customer representative doesn’t forget to send new sales order information to the planning department since it is automatically notified by workflow system via email.
3- It may help to EAI (Enterprise Application Integration) tasks. Let’s assume that we have a third party CRM application and workflow system runs in our ERP system. We may need to enter customer order information to the CRM system. In this case, we can add a triggering workflow action definition to automate to enter sales orders to the CRM system as soon as it is entered to the ERP system.
4- It eliminates repetitive user tasks that are performed in some certain events. For example, in your bug tracking system, you may want to notify developers when you approve new trouble tickets to resolve. By just defining a workflow action for your approval event, workflow system automatically sends email alerts to the associated developers for you.
5- Workflow system alert messages may ease to access and do some jobs. Workflow system should generate system messages as well as email messages. Email messages are useful when related user is not online in the system. For example, HR department want to hire a candidate and entered his CV to the system and waits an approval from the related department manager. If workflow system generates an email message for approval, it should be very easy to approve without requiring to login and navigate to the related candidate record. In our implementation, when manager clicks approval button, it is automatically approved.
Structure of Workflow System
Definitions and Instances: There are 2 basic elements in a workflow system; definitions and execution instances. Every workflow definition is composed of some activities. These activities reside on a flow path. Activities are forwarded in some conditions. Execution flow from one activity to another is triggered by some events. Workflow activity execution information (state) is held as workflow instances separate from definitions. These execution instances hold some activity parameters (state) thus we can remember what to forward when an event is received by workflow engine. “Workflow Engine” manages instances and their lifecycles.
Activity Actions: Every workflow activity may be registered for some type of actions by the users with some criteria. In our ERP system, we made it very easy for users to register workflow activities and choose their actions. For example, a user may register an email alert to the “Order Closed” activity of “Order Processing” workflow. User may want to know if deadlines are conformed. This user may want to receive emails only if sales order total price is bigger than 10000 bucks.
Activity States: Workflow activities may have some states like; Initial, Started, Completed, Suspended and Terminated. An activity may need many events to pass “Completed” state. For example, “Sales Order Fulfilled” activity may need some “Procurement” and “Production” events for that sales order. We should also consider the execution cancellation. Let’s say customer cancelled his order. Then this workflow passes to the “Terminated” state when receiving “SalesOrder” cancel event.
Programmatic Activities: In our workflow system custom actions may be programmed as well. We designed our workflow system so that its states and actions are programmed within rule definitions. I mentioned earlier that our programmatic rules are java codes which are dynamically compiled in run-time. This gives us great flexibility when managing activity states. I see in many workflow products that have some simple “Yes”-“No” branch conditions but real requirements are far from that including many comparisons and checks.