FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention:
Automated Workflow Manager Applicant:
TATA Consultancy Services Limited
A company Incorporated in India under The Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India
The following specification particularly describes the invention and the manner in which it is to be performed.

Field of the Invention
The present invention generally relates to a dynamic, flexible and an agile tool for workflow automation to meet changing needs in organizational business models, and more particularly to a workflow system wherein a workflow engine and a execution platform is provided for on-the fly configuration of workflow without the need to redeploy the application.
Background of the Invention:
Several business processes in an organization may involve people participation by way of initiation, approvals or reviews to manage flow of tasks and data involved. These process solutions may demand change with their proprietary systems and data architecture to adapt them to change in resources, people and procedure who may be employed with advanced technological solutions. The need to make such processes easily adaptable to meet changing needs in business models is indispensable.
Long and complex workflow solutions, once created, are difficult to modify and they are also incapable to keep pace with the speed at which the technology advances. Consequently, a workflow solution to keep the flow smooth and efficient in order to drive agility and business benefits is needed.
Typically many organizations have dynamic workflow needs and if the workflow system itself is not dynamic, it would be painstakingly to adapt to the changing workflow. There can be multiple problems faced by an organization when it comes to automating the business process. The major shortcoming is that at any time a process changes, extensive efforts are required along with additional resource consumption in terms of modeling or re-modeling the workflow or in coding and re-deploying the new workflow into production environment. Workflows were introduced to address these problems. However, another major constraint was to develop a workflow application system which can support all sort of developed workflow patterns like parallel routing, multi choice routing, conditional forwarding, escalation etc. The solution further required standardizing of business data that dynamically changes along with the process.
Also, most of the workflow tools available in the market serve to provide only the workflow functionality and there is a need for a parent application. And the other tools which offer an

execution platform provide the service only in a hosted model (SaaS) and not as an application that can be deployed at the end users location.
Further, imperfections associated with developed workflow application system were accounting of SLA's and turnaround times for the workflows including the business calendar; enablement of user subscription for work flow items based on business data filtering; batch import of work items and integrated search of work items. As evident, manual workflow management will pose a challenge, being intensive in terms of time, cost, effort and resources.
Therefore, a system and a method for providing a workflow management solution which comprises of a defined workflow definition and an engine to adequately model the dynamically changing business field are highly desirable. Also such system shall comprise both workflow modeling and business data modeling capabilities which can enable ease of configuration in a real time business environment offering ease of use.
Object of the Invention:
In accordance with the present invention, a web based solution for workflow modeling and an execution environment to realize the dynamically modeled workflow is provided.
It is an object of the present invention to provide dynamic on-the-fly configuration of workflow without need to redeploy the existing workflow application.
Another objective of the present invention is to combine workflow processing techniques and interpretation of data definitions, to produce an expansive and agile workflow model.
It is an object of the invention to provide support for various workflow patterns including Linear, Parallel (Forking), Multi-choice routing, Looping, Conditional Forward and Escalation Workflow Patterns.
In another aspect of the present invention, business data definition is customized that can be linked to any workflow to automate the data flow process.
In yet another aspect, generic design of workflow forms is provided with the ability to add or modify business fields to the form dynamically without any code change or without requiring re-deployment of the application.

It is another object of the present invention to provide an execution platform inclusive of work item, inbox, history etc.
One of the objectives of the present invention is to generate alerts for workflow actions and for data changes in case of parallel work flows.
Yet another objective of the present invention is to enable static and dynamic form validation for the workflow forms.
In another aspect of the present invention, multi tenant support is provided
Summary of the Invention:
The present invention is directed to a system and method for providing workflow automation across an enterprise application. The solution provides both a workflow engine that will automate the processes and a highly user friendly interface that can help users create their own business data on the fly without coding. In one aspect of the invention, the process can be executed and visualized within the same application interface without redeploying the application for a change in the workflow pattern. The present invention, thus, provides an execution platform that can be deployed at the user end's location to realize the workflow configuration without requiring re- model ing of the workflow process since the workflow relevant information is stored directly in a relational database.
According to one general aspect, the data modeler component of the present invention facilitates dynamic creation of business data fields in the form of attributes as key value pairs which holds all the information about all the fields in the process in a tabular format. The change in the workflow pattern or order does not require changes in business filed by way of altering the table definitions in any way. Thus the flexibility in modeling the business data fields is dynamically achieved while supporting multiple routing patterns during execution of a workflow process,
In another aspect of the present invention, the workflow process can be executed and visualized on any other existing application that is capable of interfacing with the workflow engine directly.
These and other aspects, features and advantages of the present invention will be described or become apparent from the following detailed description of preferred embodiments, which is to be read in connection with the accompanying drawings.

Brief Description of the Drawings:
Fig. 1 illustrates implementation of flexible workflow management system according to exemplary embodiment of the present invention.
Fig. 2 is a block diagram of a process model of workflow architecture for executing an activity instance according to one aspect of the present invention.
Fig. 3 A & 3B illustrates deployment of the workflow engine with any existing application server according to an embodiment of the present invention.
Fig. 4 depicts the storage of workflow relevant information in accordance with one general embodiment of the present invention.
Figs. 5A-5D show examples of various workflow patterns as supported by the workflow engine during execution of any process instance based on routing definition and criterion.
Detailed Description of the Invention:
Before the present method, system and communication enablement are described, it is to be understood that this invention is not limited to the particular methodologies, and hardware and network described, as these may vary within the specification indicated. It is also to be understood that the terminology used in the description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope of the present invention, which will be limited only by the appended claims. The words "comprising," "having," "containing," and "including," and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only trie listed item or items. Further it is to be noted that the terms "performance testing" and "load testing" are interchangeable. Further terms "enterprise application" and "web application" are interchangeable. The disclosed embodiments are merely exemplary methods of the invention, which may be embodied in various forms.
As used in this application, the terms "component/module" and "system" and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component/module may be, but is not limited to being, a process running on a processor, a processor, an object, an instance, an executable, a thread of execution, a program, and/or a computer. By way of

illustration, both an application running on a computer and the computer can be a component. One or more components/modules may reside within a process and/or thread of execution and a component /module may be localized on one computer and/or distributed between two or more computers.
The present invention is directed to an easily configurable network enabled automated workflow management system that provides web based workflow solutions in a dynamic production environment and facilitates monitoring of the workflow processes in real time. Further, the present invention makes the dynamically changing workflow processes easily adaptable to meet changing needs in business models in the enterprise environment, thereby keeping the flow smooth and efficient by driving agility and deriving business benefits.
The solution proposed in the present invention involves people participation- as with initiation, approvals or reviews which otherwise becomes painstaking if changing business models in the dynamic business environment are not made adaptable to changing workflows. The present invention helps in workflow automation. It provides both a workflow engine to automate the process and also a highly user friendly interface that can help business users create their own business data on the fly without coding. Furthermore, the solution minimizes the effort, cost, risk associated with manual workflow management and enables to gain from the increased productivity and facilitate greater collaboration across the enterprise.
Workflows in many organizations involve complicated processes with parallel, conditional, multi-choice, backward and other flows or routing patterns. Besides, business processes change quiet often and workflows are in frequent need of modification. Manual workflow management poses a challenge being intensive in terms of time, cost, effort and resources. Automating routine workflows brings in uniformity and enhances productivity.
FIG. 1 shows the implementation of flexible workflow management system on a screen display according to an embodiment of the invention. The system 100 for workflow automation comes with a workflow engine that serves as a black box for any existing application. The workflow system 100 is a web enabled complete human workflow modeling and execution platform. In other words, the system 100 of the present invention provides a modeling and execution platform along with the workflow engine to provide a configurable workflow application, with form designers involving zero development effort.

The workflow system thus provides a workflow development environment complete with the framework, tools and components necessary to create customized workflow solutions that integrate seamlessly with existing IT infrastructures. For the deployment of these solutions, the workflow system provides a uniform and scalable support infrastructure within the enterprise through a web-based interface. Unlike other workflow solutions which are window-based, the workflow system is web-based which means that the workflow system is accessible from a web browser.
Some key features of the workflow application system that provides for configuration or design of the business processes along with an execution engine, as presented in Fig. 1 includes: configuration of processes completely with work steps, role assignments and routings; ability to support configuration of all complex workflow patterns as specified by Workflow Management Coalition (WFMC) standards; design generic forms for the process; capable of changing process steps and flows without hampering existing process transactions; real time monitoring and validation through dynamic generation of dashboards; a scalable solution capable of handling all workflow patterns- linear, parallel (forking), multi-choice routing, looping, conditional forward, escalation workflow patterns; facilitating easy creation and modification of the process model with zero coding or programming efforts; automatic notification by way of alerts of the workflow actions to be taken in a route and also for data changes in case of a parallel flow; accessibility from external systems like web browsers via web services and an execution interface which allows the user to create customized data field definitions associated with a task or an activity for realizing the workflow configuration in real time by inter- engaging with the workflow engine or existing applications and the execution platform being inclusive of work item inbox, history etc; enables process versioning; avails role based privileges for process steps (or user based or weighted round robin work allocation among resources); providing integrated business or holiday calendar management and reporting framework beside providing multi tenant support on the same platform across an enterprise.
The workflow system 100 provides a workflow process run time depiction which empowers business groups to collaboratively plan, automate, track, and improve business processes. The workflow system is not only a model of the workflow, but is a development environment/tool for developing the workflow system/model. The workflow system empowers

the end user in developing and manipulating workflow processes. It allows the knowledge worker to define sufficiently meaningful workflow processes without any knowledge of programming. The knowledge worker does not need to write a single line of code in order to add to or develop the workflow system. This results in a streamlined, scalable and agile solution easily integrable with existing systems. It thus increases productivity and reduces costs.
The already existing solution systems catering to workflow needs are available but these are heavy weight in terms of the time to set up and go live and also with the ease of configuration. Also for certain business processes, these solutions prove to be overkill. Either the process of configuring the workflow is difficult or bringing in a change into the existing workflow is not instant. The workflow has to be remodeled and the application has to be redeployed with th e new workflow. On the contrary, in the present invention, on-the-fly configuration of workflows without redeploying the application is easily achieved. Usually in the other tools, the workflow model has to be exported into the resident application and the application be redeployed for a change in the workflow. With the present invention, since the workflow information is stored directly in a relational database, there is no need for recompile / redeploy whenever there is a change in workflow.
Referring to Fig. 2, the workflow system 100 comprises of a workflow engine 101, an application interface which provides an execution platform 102, a storage medium in the form of database 103, a user 104 and an external system 105 with which the system 100 is integrated in real time using web services. The system 100 in itself provides an execution platform 102 and hence the need for another resident application to realize the workflow is eliminated.
The workflow engine 101 forms the integral part of the proposed system 100 in the invention. It is a plug-in component that that exposes all the functionalities of a typical workflow tool. It collects the process definitions and properties in a set of tables and it is using this information the engine is able to automate the flow. The workflow related information like the Steps that constitutes the flow, the routes that make the workflow, the rules that decide the route, the roles that can act on these steps, the users that belong to the role, etc. are collected as a part of the workflow configuration. At runtime, the Workflow engine 101 uses these configurations and determines the next step in the workflow where the item has to be parked.

The Workflow Engine 101 is available as a deployable Enterprise Java Bean (EJB) in the form of a Jar file (shown as a File system 106) which can be deployed on any J2EE compliant Application server. The relational database is managed at the storage medium 103 by Java Persistence API 107. The system 100 utilizes the functionalities of the Core engine via Remote Method Invocation (RMI) calls. Any application needing a workflow capability can use the Workflow engine in a similar way.
In the preferred embodiment, the web based system 100 comprises of the following components: a deployable workflow engine capable of being integrated with any existing application server, wherein the said engine stores at a storage medium 103, the modeled process routing definitions, predefined routing rules, routing types and other workflow process related information to determine the order in which the scheduled instances of activities can be routed and enacted for automating the workflow process; and
an execution platform 102 that inter engages with the workflow engine 101 to realize the
configurable workflow application by generating customized data definition fields and process
related metadata information that is dynamically modeled using a key identifier associated
with the said data fields and a validation mechanism operable to track the sequence of
constraint specific instances of activities.
The workflow engine 102 resides on an application server within a communicating network
and is Java based.
The execution platform 103 adds the business data on top of the Workflow Engine 102. The
data model of the interface 103 facilitates dynamic creation of business fields called as
attributes. The administrator at any time can go and add, delete or modify an attribute
dynamically.
Unlike conventional applications, the business fields are not stored in a columnar format in the RDBMS. Rather, the fields are stored in a form of Key-Value pairs. A table in the schema holds information about all the data fields in the process. The run time values for the data fields are stored in columns; they are stored as rows with the key representing an identifier to the field and the value storing the run-time data for the field. Thus any new addition or deletion of a business field will not alter the table definition in any way, but just add a new row

in case of a new field or delete an existing row in case the field is deleted. This way flexibility in the modeling the business field dynamically is achieved.
The execution interface platform 102 handles the dynamic business field definition and relies on the Workflow Engine 101 to cater the workflow needs. The Workflow Engine 102 supports multiple routing patterns like Serial flows, Parallel flows, Escalation flows, Conditional Forwards, Backward flows and auto approvals. All these configurations are provided by the administrator and they are stored in a set of tables.
When a step in the workflow is initiated, it is assumed to be the first step in the workflow and the engine 101 tries to find the next step in the workflow from the process model that was configured by the administrator. There could be more than one possible outgoing route from a given step in a process route. In the preferred embodiment of the invention, the required step is identified by the string called Routing Criterion.
The selection of Routing Criterion could also be automatic with the help of predefined routing rules called Decision Logic. The Decision Logic is English like language written in a scripting language called the Apache Velocity Script. This routing rule can be written to include the fields in any combination of logical, comparison and other String functions to give out a Routing Criterion which can be used to determine the flow, in case there is more than one outward route from a given step. Thus the actor on the step need not always know which route to choose; rather the business data could drive the workflow dynamically.
Once the process is modeled by way of customizing the data fields and processes and other related metadata information using key pair identifier, the process can be executed and visualized either within the execution platform 103 of the system 100 or with any application that will interface with the Workflow Engine 101 directly. The Workflow Engine 101 can be either deployed in an application server as shown in Fig. 3A or it can also be included in the class-path of an application and used similar to any other library as depicted in Fig. 3B.
Fig. 4 depicts the storage of workflow relevant information in accordance with one genera! embodiment of the present invention. The tables in which the workflow engine 101 stores the process metadata can either exist in a different database schema or even co-exist along with

the other application tables in the same database schema. This provides the flexibility for calling applications to manipulate the workflow data if there is a need for the same.
The database schema 103 also maintains the User based and the role based information either in the Workflow Engine schema 101 or in the application's schema with just a database view in the workflow engine schema pointing to the application schema's database tables. This approach gives added flexibility of storing the user and role information in one place.
The Workflow Engine 101 supports three different work allocation strategies as discussed above. A work item can be configured to go to a role pool. In this case the work item is available for all the users tagged to the role pool. Hence when an actor decides to act on a role pool item, he will have to claim the item to bring it to his bucket. A claimed item is no longer available for view / acting for others in the role pool. A user can also release the item back to the role pool in case he does not want to act on that item. Now the released item is once again available for all the users in the role pool.
A second work allocation strategy is where an item is directly put to a users bucket. The Workflow Engine 101 will accept the user and assign the item to the passed user directly.
The third work allocation strategy is a weighted round robin based allocation where the work item is allocated to the least loaded user. The load of a user is a product of the number of items the user has in his bucket and the weight of each item, which is assigned by the process administrator for every step in the workflow.
The decision logic or the predefined routing rule for determining the next route in the workflow is also stored in the database 103. Since this rule is stored in the database only and not outside the application, there would be no need for redeployment of the application when the administrator modified any of the rules. The rule will be applicable on the fly. Since the apache velocity language is very flexible and powerful, one can also write any functions using the scripting language to achieve complex business rules. However if a new function is written using the Velocity script, this would require a redeployment of the application.
There are two means to store the business data. In case the components of the system 100 is used as it is, the business data can be created and stored in the execution platform 102

directly. Whereas applications can also maintain and store the business data and just pass on the necessary business data with which workflow decisions are to be made, to the Workflow Engine 101. The Workflow engine 101 stores the business data in form of abstract keys. The workflow engine 101 provides provision for storing 30 business keys in accordance with one of the embodiments of the present invention. Each business process can store its necessary data into the business keys. All the keys are of string data type. The calling application can thus store any data in the keys and then convert them back to the required data type. Thus the keys can hold any data as long as the application maps what keys contain what values, per process. This avoids the need for creating numerous columns, one for every business field.
The Workflow engine 101 is one of the main components of the present invention and can cater various workflow patterns for various business scenarios. A process routing definition is a route in the workflow, which will decide the flow and pattern of a process route. All the routing definition modeled in the tool can have only one step as the completed step (From Step). The completed step indicates the task that is currently being acted upon. The other end of the routing definition (To Steps) can have one or more steps.
One of the exemplary embodiments of the present invention describes a method of automating the workflow process in a dynamic production environment through execution of the sequence of instances of activity of the process flow model across an enterprise application within a communication network wherein the said method comprises the processor implemented steps of:
defining and storing one or more data field definitions, routing definitions, routing rules, routing constraints and other related metadata information to trigger workflow processing;
specifying the routing constraints to assign predefined values to valid subsets of the instance of activities;
determining the subset of activity instance scheduled for enactment based on routing criteria and associated routing constraints;

analyzing the defined workflow related information and subset of activity instances received via signals from the storage medium of workflow engine to produce therefrom workflow models on said network equipment; and
initiating a workflow based on the analyzed information and workflow model so generated, The execution platform 102 of the system 100 provides the additional functionality of defining dynamic business fields over the workflow to provide a complete execution platform. The administrator can control what business fields should be viewable and editable across different workflow steps. The tool allows creation of various input elements as business fields like Text Box, Text area, Single Select box, Multi Select box, Radio buttons, Check boxes, Attachments, Date fields, etc. The Administrator can define a business field and also specify the screen representation for the business field. This information is stored in the database 103. When rendering the screens for the process steps, this configuration is read and the screen is dynamically rendered. Thus if the administrator changes any of the routing rules, it can be rendered dynamically on screen without a need to redeploy the application.
The business fields provide the facility to define dependant combos, where the choice (value) of one of the select box determines the values of another select box. Follow-Up fields can also be configured where an answer (value) for a particular business field triggers display of one or more fields on screen. Given a list of values for a business field, the administrator can configure what subset of values should be displayed for a given workflow step. This is done after specifying the routing constraints which assigns predetermined values to the valid subsets.
Also certain business conditions require the business fields to be assigned some default values based on the steps reached in the workflow or as determined by the routing constraints. This can be achieved on the execution platform 102 by specifying the default values for the business fields against the routing definitions. Hence when a route is taken, the default values configured for that routing definition using routing constraints are assigned to the business fields automatically.
Thus once the valid subset of an activity or task is received from the storage medium workflow model for the process route is generated thereon. This initiates the workflow for the particular process route and automates the workflow process.

Different workflow patterns can be supported by the alternative embodiments of the present invention. This can be viewed in light of Fig. 5A- 5D.
Fig. 5A illustrates a linear workflow pattern wherein one current step leads to only one next step in the process flow. This is modeled with a routing definition having only one From Step and one To Step. When an item is completed, an entry is made to only one next item.
A parallel flow or forking referred in Fig. 5B is a scenario where one completed step can lead to many next steps. This is modeled as a routing definition with one completed step (From Step) and two or more pending steps (To Step). In a parallel flow multiple work items are created for the different steps in the flow and allocation for each of the step is made based an the step configuration by the administrator. Also in case of a parallel flow, at runtime, the flow need not necessarily go to all the parallel steps modeled, but based on some rules; it can be only put to a sub set of the configured parallel steps. The routing rules can also be configured to manage the merging of the parallel steps. The administrator, based on the business scenario can configure whether all the parallel steps need to be completed or only a sub set of the parallel steps need to be completed, to proceed further with the flow. This gives control over merging the parallel flows to continue the flow forward.
A backward flow as shown in Fig. 5 C is a flow where the current step leads to one of the already taken steps in the workflow. This flow could be used in scenarios which involve a rejection flow, or sending the item back to an already taken step. In case of a backward flow, the work item can be configured to go either to the same person who acted on the item in the previous run or the item can be put the role pool again.
Another workflow pattern that the Engine 101 supports is a Conditional forward flow illustrated in Fig. 5 D where a new work item (step) has to be assigned to a same user who acted upon some previous step in the workflow. For say, in this case, the task D is put to the same person who acted upon Task B. Here the administrator configures the To Step of the routing definition with an additional previous step. It is the actor of this previous step that the new work item is put to.

Similarly Escalation flows are useful in scenarios where a step has to be completed within a given SLA. The Process Administrator can configure a timeline for a step within which it has to be acted upon. If there is a breach in the SLA, then the administrator can also model an escalation flow for that step, in which case the item will be escalated from the defaulted step to another step as modeled by the administrator. Yet another pattern, escalation with option is a flow where the item is retained with the defaulter and also an additional item is put a new step that the administrator can model, in this case, if one of the step is acted upon (either the defaulter, or the actor to whom the item is escalated to) then the other step will be made obsolete and the flow will continue normally from then on.
Whenever an item is completed or acted upon, the engine 101 updates that task or the activity and tries to find all the available outgoing routes (routing definitions) from that completed task.
The foffowing are conditions and the actions that the engine may encounter or take:
There are no outgoing routes from the current task: This is the simplest scenario where there
are no further actions to be taken and the engine completes the workflow here.
There is a routing definition with one next step in the forward direction wherein the engine creates a new item for the next step in the pending state. It also does the allocation to the step based on the configuration.
There is also a routing definition with multiple next steps in the forward direction and there is no pending step override configured. In such a case, the engine creates one work item per next step for all the available next steps in the routing definition and marks them all pending. Further, there is a routing definition with multiple next steps in the forward direction and there is a pending step override configuration available. The pending step override configuration is used in cases, where only a subset of the configured parallel steps is to be taken. The workflow engine evaluates the pending step override logic and gets the subset of steps for which the items has to be created for and makes entry in the workflow transaction table for these items.
There are many outgoing routing definitions in which the engine evaluates the decision logic of the completed step and arrives at one routing definition. This routing definition is

considered as the outgoing route and new work items are created based for the next step{s) of this selected routing definition, based on the applicable routing rules.
There is a routing definition with one next step in the backward direction. In this case, the workflow engine creates an entry for the next step which is actually one of the already taken steps in the workflow. A backward flow is ideal for scenarios which would need a set of steps to be taken repeatedly, ideally for rejection and repeat workflows. Hence the set of steps that were acted in the previous run should be nullified and new entries should be created for the steps that are being repeated.
There is a routing definition with one next step and the direction is 'Forward with Options'. In this case, the To Step' has an additional configuration where the user of some previous step in the workflow is chosen, to whom the next step is also sent. Here the engine gets all the completed items for that particular transaction and tries to find the user who acted upon that step which was provided along with the To Step'. Then a new item is created and allocated to this person who also acted upon that selected To Step'.
There is a routing definition with one next step and the direction is Escalation. In this case the engine marks the current status item that was defaulted to 'E' and creates a new entry for the step which is marked as the step to which the item has to be escalated to. This new item is always put to the role pool.
There is a routing definition with one next step and the direction is Escalation with Copy. In this case the engine still retains the current item that is defaulted. It also creates an entry for that step which is marked as the step to which the item has to be escalated to. Now there are two items pending, one with the defaulter and the other with the role to which the item has been escalated to.
Thus, it can be observed that various routing definition directions influence the workflow engine's determination of a route.
The Engine 101 also supports a delegation feature. If an actor for any reason is not able to act on an assigned work item, he has the choice of passing on an individual item to another actor of his choice. The actor is shown a list of users who are tagged to the same set of roles

that is privileged to do the current step and the actor can select one user to delegate the item to. The process administrator can configure whether the step can be delegated by the current actor or not. He can override this setting at any time dynamically. It is based on this setting that the option of delegation is either enabled or disabled to the current actor.
The Engine 101 also provides a feature of putting an assigned work item on hold. An actor can put an item on hold when he feels that he would not be able to proceed with the item for want of some information. Usually the time taken by an actor to act on the item is calculated by the difference between the completion time and entry time of a given work item. In case the item is held by an actor, the held time is not accounted against the actor. This would be useful in computing the productivity of an individual. This can also be used to calculate the Turnaround Time (TAT) of the work items. An actor can put an item on hold any number of times. Whether a work item can be held or not can be configured by the administrator. It is based on this setting, at the runtime; the 'Put on Hold' option is made available to the actor. Every time the item is held and released back to his bucket, the timestamps are captured and this data can be used to calculate the Turnaround Time and the productivity time.
The Engine 101 provides a Proxy feature where individual users can configure proxies for given time duration. A user has the option of configuring proxy users for all the steps in a workflow that is entitled to act upon. He could select individual steps in the workflow and specify the time duration and the user who will act as proxy for the specified duration. Now all the items assigned to the actual user for that step in the specified time duration will also be available for the user acting as the proxy. Either of the users can act on the item and the information is captured.
The Engine101 also provides a mailing feature, which will be used to send mails to actors. The escalation and mailing features are handled by a component called the Quartz scheduler. The scheduler is a component that does some configured activity in repeated intervals of time. Whenever a work item is created, the engine checks if there are any escalations configured for that item. If so the engine notifies the quartz scheduler to create a thread which wilt escalate the item in case the SLA is breached. The thread is alive until the item is acted upon. In case the item is acted before the SLA, the thread is killed. In case the item breached the SLA, the thread executes and escalates the item. In case of the mailing

component, the thread runs repeatedly at the configured time interval and sends the necessary mails to the SMTP server.
The Workflow Engine 101 has an auto approval feature where the item will be automatically acted upon after the time limit configured by the process administrator. The working is similar to the escalation feature, where a thread is created when an item is created for the step that has auto approval configured. If the item is acted before the configured time limit, the item moves to the next step. If the item is not acted until the configured time limit, the thread takes

control and automatically moves the item to the next step as configured in the routing definition.
The Workflow Engine 101 exposes the above functionalities as Java APIs. Any application can utilize these functions by passing the necessary parameters. There are APIs available for various functionalities like creating a new workflow; routing a workflow from one step to another; getting the work items pending directly with a person; getting the work items pending with the role pool of a person; claiming a work item from a role pool; terminating a work item or delegating a work item.
The Workflow Engine 101 also provides a process copy feature where an existing process definition can be copied to another process definition with the same name. However the start and end date of the new process should not overlap with the existing process. This feature can be used to version processes. Whenever a workflow is initiated, the engine will create an instance for that process which is active based on the current date.
The various configurable properties of workflow tasks, as discussed above, like whether the task can be reassigned, delegated, held, assigned to a proxy and all other properties are stored directly in the database 103 and not along with a model in the application as most of the other tools do. Hence whenever there is a change in the configuration, the application can read this change directly from the database 103 and dynamically cater the change instead of a need for redeploying the application.
The system 100 also contains a feature where at the end of every step in a workflow, a web service can be invoked. The process administrator can configure the web service details for every step. Once the step is acted upon, the configured web service will be invoked. The

details of the business fields will be made available to the web service by the execution platform 102 of the system 100. The web service can be utilized to write any arbitrary functionality using the business data like updating an external database or system.
The system also provides an SLA based alert feature. Every process step can be specified an SLA limit. When the work item crosses the SLA, corresponding color codes are displayed along with the item. The administrator can configure the time duration after which the item should be shown with an Amber color indicator and the time duration after which the item should be shown with a Red color indicator.
Further, the system is also multi-tenant which is capable of hosting different clients. Each client can have one or more processes and business entities. However one client will not know the existence of the other. All the processes, users, roles and business entities of one client will not be visible to the other clients within the same deployment. This feature can be utilized when a single hosted application needs to be deployed to multiple clients and each client should be kept shielded from all other clients.
A system and method has been shown in the above embodiments for the effective implementation of a network-enabled automated workflow system that is integrated with a intelligent workflow engine and an execution platform. While various preferred embodiments have been shown and described, it will be understood that there is no intent to limit the invention by such disclosure, but rather, it is intended to cover all modifications and alternate constructions falling within the spirit and scope of the invention, as defined in the appended claims. For example, the present invention should not be limited by software/program, computing environment, or specific computing hardware.
Although the present invention has been shown and described with respect to several preferred embodiments thereof, various changes, omissions and additions to the form and detail thereof, may be made therein, without departing from the spirit and scope of the invention.

We claim:
1) An easily configurable web based system for automating the workflow process in a
dynamic production environment across an enterprise application within
a communication network, wherein the said system comprises of:
a deployable workflow engine capable of being integrated with any existing application server, wherein the said engine stores at a storage medium, the modeled process routing definitions, predefined routing rules, routing types and other workflow process related information to determine the order in which the scheduled instances of activities can be routed and enacted for automating the workflow process; and an execution platform that inter engages with the workflow engine to realize the configurable workflow application by generating customized data definition fields and process related metadata information that is dynamically modeled using a key identifier associated with the said data fields and a validation mechanism operable to track the sequence of constraint specific instances of activities.
2) An easily configurable web based system as claimed in claim 1, wherein the workflow process related information is stored directly in a relational database at the storage medium.
3) An easily configurable web based system as claimed in claim 1, wherein workflow engine processes, instances of activity attributes and the predefined routing rules to determine an order in which the scheduled activities can be enacted.
4) An easily configurable web based system as claimed in claim 1, wherein the modeled process routing definitions, predefined routing rules, routing types and other workflow process related information including the role based information forms the part of workflow configuration depicted in a tabular format.
5) An easily configurable web based system as claimed in claim 1, wherein the execution platform inter engages with the workflow engine to realize the configurable workflow application by including the workflow engine in the class path of another application via RMI calls.

6) An easily configurable web based system as claimed in claim 1, wherein the workflow engine is available as a deployable Enterprise Java Beans (EJB) on any J2EE complaint application server.
7) An easily configurable web based system as claimed in claim 1, wherein the order in which the scheduled instances of activities can be routed and enacted is determined by a routing criterion based on predefined routing rules in the form of decision logic.
8) An easily configurable web based system as claimed in claim 1, wherein the decision logic is defined in Apache Velocity Script.
9) An easily configurable web based system as claimed in claim 1, wherein the workflow engine is capable of supporting linear, parallel, multi-choice routing, looping, conditional forward, backward and escalation workflow patterns.
10) An easily configurable web based system as claimed in claim 1, wherein the workflow engine supports role based or user based or weighted round robin based work allocation approach for effective resource utilization in an automated workflow management system.
11) An easily configurable web based system as claimed in claim 1, wherein the process versioning is enabled by means of a workflow engine by copying existing process definition to another process definition without allowing the start and end dates of the two initiated processes to overlap.
12) An easily configurable web based system as claimed in claim 1, wherein the system provides the flexibility to execute and visualize the process on the same application server.
13) A method of automating the workflow process in a dynamic production environment through execution of the sequence of instances of activity of the process flow model across an enterprise application within a communication network, the said method comprising the processor implemented steps of:

defining and storing one or more data field definitions, routing definitions, routing
rules, routing constraints and other related metadata information to trigger workflow
processing;
specifying the routing constraints to assign predefined values to valid subsets of the
instance of activities;
determining the subset of activity instance scheduled for enactment based on routing
criteria and associated routing constraints;
analyzing the defined workflow related information and subset of activity instances
received via signals from the storage medium of workflow engine to produce
therefrom workflow models on said network equipment; and
initiating a workflow based on the analyzed information and workflow model so
generated.
14) A computer implemented method of automating the workflow process, wherein the step of defining routing rules is based on predefined routing criteria to determine the flow and pattern of an instance in a workflow process.
15) A computer implemented method of automating the workflow process, further comprising the step of storing one or more data field definitions, routing definitions, routing rules, routing constraints and other related metadata information in a workflow database as workflow process configuration tables.
16) A light weight pluggable tool operable to integrate with existing application server and modeled workflow configurations to create a workflow process model, the said tool comprising of a data modeler that models the data fields dynamically by creating and defining the said fields and assigning run time value to each of the said fields in the form of key value pairs v/ithin the table.
17) A light weight pluggable tool as claimed in claim 16, wherein the run time values for each data field are stored as rows of the table along with an identifier in the form of key.
18) A light weight pluggable tool as claimed in claim 16, wherein the data fields enables defining of dependent combos where the subset of any value for a data field is

assigned a predetermined value to trigger next following sequence of activity in a workflow process.
19) A light weight pluggable tool as claimed in claim 16, wherein the tool is operable to activate subset of any value for a data field by outputting the predetermined assigned value for display to a user, and is further operable to accept the selected value for subset from the user.
20) A light weight pluggable tool as claimed in claim 16, wherein the tool is capable of hosting multiple users utilizing the same platform and keeping the said users shielded of their identity from each other at the same time.