WO2001011509A2

WO2001011509A2 - A work flow processing method

Info

Publication number: WO2001011509A2
Application number: PCT/IE2000/000094
Authority: WO
Inventors: Aidan O'leary; James Grimes
Original assignee: Portspring Limited
Priority date: 1999-08-04
Filing date: 2000-08-03
Publication date: 2001-02-15
Also published as: WO2001011509A3; AU6178100A; WO2001011509A8

Abstract

In a client/server architecture, a server executes n rules to generate an initial action object (4) queue. Dependency attributes are used (10) to revise the queue to provide serial and parallel sequencing. Pre-execute plug-ins are executed (11). The clients use filter objects to gather user instructions and select appropriate actions (13). The server executes the actions (15) while automatically spawning notifications (16) according to notification objects. Post-execute plug-ins are then executed. The server completes the work flow by saving the state of a container object.

Description

"A work flow processing method"

INTRODUCTION

Field of the Invention

The invention relates to work flow processing, particularly but not exclusively for purchasing in a corporate organisation.

Prior Art Discussion

Our prior United States Patent Specification No. US5937393 describes an order processing system in which an order is routed to various users in an organisation. This achieves a major reduction in paper handling and allows effective centralised control. Also, United States Patent Specification No. US5970475 (Intelisys) describes a procurement system having a supplier catalog server, a supplier processor server, and a security means to limit transactions to customers and suppliers with pre-arranged relationships. United States Patent Specification No. US5870717 (IBM) also describes a corporate purchasing system, in which there is a focus on handling of catalogues .

Thus, significant developments have been made in the field of corporate purchasing. However, a major problem is that of providing the desired level of versatility in the manner in which work flow processes such as these for corporate purchasing are implemented. Another problem is that of ensuring that there is comprehensive communication of information to staff of the organisation.

It is therefore an object of the invention to provide a work flow processing method and system to provide work flow control in a more versatile manner. Another object is that the method and system provide for more comprehensive communication of work-flow related information to staff of a corporate organisation.

SUMMARY OF THE INVENTION

According to the invention, there is provided a work flow processing method performed by a server and a plurality of clients associated with users in an organisation, the method comprising the steps of:

the server processing an initial queue of action objects instantiated from action classes to determine dependencies associated with said action objects, the dependencies indicating relationships affecting sequence of execution of the action objects,

the server generating a revised queue of action objects according to the dependencies;

the server generating a final queue of action objects according to user instructions; and

the server executing the action objects of the final queue to implement a work flow process.

In one embodiment, the server determines the dependencies according to dependency attributes of the action objects.

In another embodiment, a dependency is a mandatory dependency in which an action object must be executed after another action object. In a further embodiment, a dependency is an optional dependency, in which an action object is executed only if another action object is previously executed.

In one embodiment, the step of user instruction inputting is performed by:

the server transmitting the action objects of the revised queue to clients,

the clients generating user interactivity screens according to filters associated with the action objects, and

the client receiving the user instructions and uploading the action objects to the server.

In one embodiment, the filters are objects linked to the action objects.

In another embodiment, the client limits the effect of user instructions according to user level data retrieved from a database.

In a further embodiment, the server executes pre-execute plug-in functions before executing the actions.

In one embodiment, the pre-execute plug-in functions are executed before download of the action objects to the clients for user instruction input.

In one embodiment, the pre-execute plug-in functions are encoded in pre-execute plug-in objects linked to the action objects.

In another embodiment, the server executes post-execute plug-in functions after executing the actions. In one embodiment, the post-execute plug-in functions are encoded in objects linked to the action objects.

In one embodiment, the initial action object queue is generated by executing a set of rules.

In another embodiment, the rules each have an associated action object and execution of each rule determines if the associated action object should be included in the initial action queue.

In another embodiment, each rule is encapsulated in a rule object.

In a further embodiment, each rule object is a compound object comprising:-

a statement object,

an expression object, and

an operand object.

In one embodiment, the method comprises the further step of the server transmitting notifications to users.

In another embodiment, the notifications are transmitted as the actions are being executed.

In a further embodiment, instructions for the notifications are encoded in a notification object linked to the action object. In one embodiment, a notification object is of the push type in which the instructions require a response from the recipient.

In one embodiment, a notification object is of the dynamic type, which automatically examines the work flow history, generates data for informing users of events, determines required recipients, and transmits notifications with said data to said recipients.

In another embodiment, a notification is of the pre-defined type, in which a message is transmitted to a pre-defined set of users.

In one embodiment, a notification is of the queued type, in which the server makes the queued notifications available for users to access at their initiative.

In one embodiment, each action object is linked to at least one notification object having notification definitions.

In a further embodiment, the action objects are within a work flow container object, the server activates the method using an interface object, and the interface object uses public functions associated with the container object to execute the method.

In one embodiment, the public functions include a create function for creating a container object, and a save function for saving a container object.

According to anther aspect, the invention provides a work flow processing method performed by a server to execute work flow actions in an order, wherein

there is an action object associated with each action;

the server executes a set rules to generate an action object queue. According to another aspect the invention provides a data processing system comprising a server and a client comprising means for performing a method as described above.

DETAILED DESCRIPTION OF THE INVENTION

Brief Description of the Drawings

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:-

Fig. 1 is a high-level flow diagram showing work flow activities;

Figs. 2(a) and 2(b) are together a flow diagram showing a work flow method implemented by a server and clients in a corporate system;

Fig. 3 is a diagrammatic representation of a rule object;

Fig. 4 is a set of diagrams illustrating how objects within a rule object are created; and

Fig. 5 is a more detailed representation of a rule object.

Description of the Embodiments

Referring to Fig. 1 a work flow process comprises actions A, B, and C executed in series; one or any of actions D, E, and F; and an action G. The selected action from D, E, and F depends on action C. Thus, there is a versatile serial/parallel flow according to the nature of the work flow. The process may be implementation of a purchase order in a large organisation with many users having client machines.

The following summarises a work flow processing method 2 carried out by a system comprising a server and at least one client. A work flow container object is created or loaded, and an interface object exposes public functions of the container object to perform the steps set out in Figs. 2(a) and 2(b).

Initially, a series of n Rules 3 are executed. This execution results in a number of associated actions 4 being included in an initial action queue. The second action 4 is by -passed and so is shown by interrupted lines. This is because, while it is associated with Rule2, execution of Rule2 indicates that it is not required for this particular process and so it is not part of the initial action queue. As shown in Fig. 2(a), each action 4 comprises plug-ins 5, dependencies 6, filters 7, and notifications 8.

Step 10 comprises, for each of the initial queue actions 4, reading the dependencies to determine a revised action object queue. In this queue, the action objects are sorted according to dependency relationships. These relationships specify if one action object must be executed before another, it one must follow another, or if one or any of a set must be performed before another.

The server then executes in step 11 the pre plug-ins of the actions of the revised queue. These are described in more detail below.

The revised action queue is then downloaded by the server to a client, which uses the associated filters to generate user interactivity screens in step 12. The client uses these screens in step 13 to interactively determine which actions are to be implemented. The user, as he or she views it, marks actions for completion within the confines of the extent of responsibility stored in a user database accessed by the client. The appropriate final action list is then uploaded in step 14 to the server. In step 15 the server executes the actions and this involves performing the data processing activities encoded in the action objects The actions themselves are, in this embodiment, approval actions and request actions in which a user performs purchasing-related tasks requested in the action.

In step 16 the server "spawns" and sends notifications associated with the actions. For example, managers in an organisation may be notified automatically of all capital purchases having a value greater than a set threshold.

In step 17 the server implements post plug-ins, for example, posting a message to an EDI link.

The server then saves the state of the process 1 as a list of all executed actions in step 18. The save is made to a control database which has tables configured for the particular work flow processing application. The work flow container object is then terminated.

As stated above, there is serial/parallel versatility by use of optional and mandatory action dependencies. The following are examples.

If a capital approval must happen AFTER a capital request then the capital request has a MANDATORY dependency of capital approval.

If a request for financial approval must happen BEFORE a request for capital approval then the capital request is OPTIONALLY dependent on the approval request.

A single action can have a number of dependencies associated with it. In the example illustrated in Fig. 1, A has a mandatory dependency on B because if A is performed, then B must be performed. However, there is an optional dependency for action G whereby if actions D, E, or F can be performed, then G cannot be performed until one or any of the actions D, E, and F have been performed, in any order.

The client-server architecture is programmed in the object oriented methodology. The container object is created from a template container by calling a refresh method. Alternatively, a new object is created from the template using a live object identifier. An entry is made in a work flow processing control database.

The container object is compound, having object oriented classes for:-

rules, actions, notifications, filters, and plug-ins (pre and post).

Referring again to Fig. 2, the only entity which is not an object is the set of dependencies associated with each action. These are attributes of the associated action object.

Regarding the rule objects, each such object is a compound object having a structure as set out in Fig. 3. This structure comprises multiple sets, each comprising a statement object 21, an expression object 22, and an operand object 23. As shown in Fig. 4, each statement object 21 is instantiated from some or all of the statement classes, namely All True, Any True, All False, and Any False classes. Each expression object 22 is instantiated from one of seven expression classes, namely Equal, Greater Than, Less Than, Greater Than or Equal To, Less Than or Equal To, Database, and Member Of classes. Finally, each operand object 25 is instantiated from one of nine operand classes, namely String, Integer, Double, Database, Column, Float, Boolean, Date, and Long classes.

The server creates a rule 3 under user instructions and checks the syntax. It then executes the rule with test data and any required modifications are made. The rule is then cached, and all cached rule objects are linked with the container object.

As stated above, there are both private functions and public functions associated with the container object, and the interface object implements an interface based on the public functions. Thus, in overview, the system comprises:

a work flow container object comprising the rule, action, notification, filter, and plug-in objects, the four public functions, and the private functions, and

an interface object which implements an interface for a requesting system such as a client by calling and activating the four public functions.

In more detail, the public functions are:

CREATE, EXECUTE, SAVE, and LOAD.

The CREATE function creates a new instance of a work flow container object from a template. The LOAD function loads a previously-created container object. The EXECUTE function performs the processing steps 10 to 14 described above. The SAVE function performs the steps 15 to 18 described above. When the user performs a request (via the interface object) on an order, or initialises the workflow in any other way, the workflow plug-ins are activated. For every action that is relevant to the current context, plug-in parameter objects for that action are initialised. This gathers all of the parameters from the client that plug-in classes for any of the available actions might require. If there is a problem gathering any of the parameters (such as for example, if an applet parameter which is needed by one of the plug-ins was never passed in to the applet), a message will be displayed to the user identifying which plug-in the problem was encountered on, and for which action. The plug-ins are executed when the user activates the desired workflow action. Only the plug-ins for the relevant actions are executed. If there is a problem executing a plug-in on the server, it will be reported to the user.

Plug-in classes are loaded and initialised automatically on the server side. It is possible to execute client-side plug-ins by putting functionality in the parameters class and having an associated "empty" plug-in class.

A pre plug-in is executed before the workflow action and the action will only be carried out if the plug-in execution is successful. A use for this is where the database may need to be updated before the action is carried out. A pre plug-in would be used to update the database and only if the database is updated successfully will the action be carried out.

The post plug-in is executed after the workflow action. There is no dependency on successful execution.

A plug-in class setData() method is called and it stores the parameter data established in the plug-in parameter class (and which was serialised on the workflow action).

When the parameters have been set up, the execute() method is called to run the server-side plug-in functionality. To speed the user-apparent plug-in execution time, where the action is not dependent on them. These are executed on a separate thread. The execute method extracts the required data from the parameter data hash table and thus executes the plug-in.

Once the plug-in is executed the getData() method is called to return any resulting data. This functionality is used by pre plug-ins to pass any execution error messages (in reality their resource keys) back to the client for displaying to the user. If errors are encountered in a pre plug-in, neither the workflow action nor any further plug-ins are executed. The error message is passed back to the client by adding the following entry to the return hash table:

returnHashDataput(PeGlobals.getErrorStringKey(),<errorMessageResourceKey>); _returnHashDataput(PeGlobals.getErrorParamsKey(),<object array of error message parameters>); return returnHashData;

The plug-ins are configured using an administration tool which allow users to include the name of the parameter class and the plug-in class in displayed fields and subsequently to initiate creation of the plug-in.

Referring to Fig. 5, the structure of a rule object 3 is shown in greater detail. An interface rule object 50 interfaces with all of the objects within the operand object 23. A database object 41 within the operand object 23 supplies the result. The statement and expression objects 21 and 22 are processed by processing objects 42 (dynamicRule), (rule) 43, and (ruleParser) 44. This diagram illustrates the compound and comprehensive nature of each rule object 3. It will be appreciated that there is considerable processing before the action objects 4 are processed. This accommodates in a simple manner the complex nature of many business processes in large organisations. A change in state of the container object causes a change or process status to be recorded in a work flow control database. This update is performed by a work flow storage object.

Turning again to the action objects 4, the following are the attributes of the action objects:

Action Form: The form associated with the action type. The list of action forms is:

Smp Approve: Approval form

SmpRequest: Request approval form

Smplssue Issues order form

Tracking codes : Tracking codes are associated with each action. The tracking codes are used to update the status of the data being routed. These state changes are recorded in an ORDERSTATUS database table.

Password Verify: An indicator as to whether or not the password checks must be performed upon completion of an action.

Completion Details: The details of who completed the action, comments, data for completion, and who requested the completion. An additional indicator is used to determine if the action is a once off action or if it can happen many times.

Database Updated: A number of helper methods are used to generate the SQL required to update the data with tracking codes, record all state changes and pos any notification details to the database. Dependency list: A list of optional and mandatory dependencies. These are described above. They are attributes of the action objects.

Regarding the notifications, these are spawned by the actions automatically so that there is comprehensive distribution of information throughout an organisation. Also, the actions may be of different types to provide flexibility in their effect on the work flow process.

More particularly, a request notification typically transmits a message requesting a user to do something such as approve a purchase order. A request notification is not user-configurable and instead is pre-set in the work flow object. Typically, this presetting is performed by a supervisor. Such a type of notification may be regarded as a "push" notification in that a message is transmitted to a particular user and the user must respond. A request notification may be a pre -requisite for the work flow passing on to a next action in sequence.

Another type of notification is a dynamic notification in which a notification code examines the work flow object history and, using a set of tags, automatically notifies users of an event. The users which are dynamically selected may, for example, be an originator, a last approver, a last requester, all requesters, for every user associated with the work flow process. An important aspect of a dynamic notification is that it dynamically generates messages for a wide variety of users. Another important aspect is that a reply or an action by the user is not required. It is simply a transfer of information.

A further type of notification is a pre-defined notification which transmits a message to a named user or group of users. Finally, there may be a queued notification which puts a request in a queue for a set of users. This avoids transmitting messages to a large number of users. The requests are simply placed in a queue and users may access them from time to time.

The notifications are implemented as extensions to the action object. The notification class contains the title and body of the notification, together with a type and dynamic tag.

The invention is not limited to the embodiments described but may be varied in construction and detail within the scope of the claims.

Claims

1. A work flow processing method performed by a server and a plurality of clients associated with users in an organisation, the method comprising the steps of:

2. A work flow processing method as claimed in claim 1, wherein the server determines the dependencies according to dependency attributes of the action objects.

3. A work flow processing method as claimed in claim 1 or 2, wherein a dependency is a mandatory dependency in which an action object must be executed after another action object.

4. A work flow processing method as claimed in any preceding claim, wherein a dependency is an optional dependency, in which an action object is executed only if another action object is previously executed.

5. A work flow processing method as claimed in any preceding claim, wherein the step of user instruction inputting is performed by:

the server transmitting the action objects of the revised queue to clients,

6. A work flow processing method as claimed in claim 5, wherein the filters are objects linked to the action objects.

7. A work flow processing method as claimed in claim 5 or 6, wherein the client limits the effect of user instructions according to user level data retrieved from a database.

8. A work flow processing method as claimed in any preceding claim, wherein the server executes pre-execute plug-in functions before executing the actions.

9. A work flow processing method as claimed in claim 8, wherein the pre- execute plug-in functions are executed before download of the action objects to the clients for user instruction input.

10. A work flow processing method as claimed in any of claims 8 or 9, wherein the pre-execute plug-in functions are encoded in pre-execute plug-in objects linked to the action objects.

11. A work flow processing method as claimed in any preceding claim, wherein the server executes post-execute plug-in functions after executing the actions.

12. A work flow processing method as claimed in claim 11, wherein the post- execute plug-in functions are encoded in objects linked to the action objects.

13. A work flow processing method as claimed in any preceding claim, wherein the initial action object queue is generated by executing a set of rules.

14. A work flow processing method as claimed in claim 12, wherein the rules each have an associated action object and execution of each rule determines if the associated action object should be included in the initial action queue.

15. A work flow processing method as claimed in claim 14, wherein each rule is encapsulated in a rule object.

16. A work flow processing method as claimed in claim 15, wherein each rule object is a compound object comprising:-

a statement object,

an expression object, and

an operand object.

17. A work flow processing method as claimed in any preceding claim, wherein the method comprises the further step of the server transmitting notifications to users.

18. A work flow processing method as claimed in claim 17, wherein the notifications are transmitted as the actions are being executed.

19. A work flow processing method as claimed in claims 17 or 18, wherein instructions for the notifications are encoded in a notification object linked to the action object.

20. A work flow processing method as claimed in claim 19, wherein a notification object is of the push type in which the instructions require a response from the recipient.

21. A work flow processing method as claimed in claims 17 or 20, wherein a notification object is of the dynamic type, which automatically examines the work flow history, generates data for informing users of events, determines required recipients, and transmits notifications with said data to said recipients.

22. A work flow processing method as claimed in any of claims 17 to 21, wherein a notification is of the pre-defined type, in which a message is transmitted to a pre-defined set of users.

23. A work flow processing method as claimed in any of claims 17 to 22, wherein a notification is of the queued type, in which the server makes the queued notifications available for users to access at their initiative.

24. A work flow processing method as claimed in any of claims 17 to 23, wherein each action object is linked to at least one notification object having notification definitions.

25. A work flow processing method as claimed in any preceding claim, wherein the action objects are within a work flow container object, the server activates the method using an interface object, and the interface object uses public functions associated with the container object to execute the method.

26. A work flow processing method as claimed in claim 25, wherein the public functions include a create function for creating a container object, and a save function for saving a container object.

27. A work flow processing method performed by a server to execute work flow actions in an order, wherein

there is an action object associated with each action; and

the server executes a set rules to generate an action object queue.

28. A work flow processing method as claimed in claim 27, wherein there is an action object associated with each rule, and execution of each rule determines if the associated action object is to be included in the queue.

29. A work flow processing method as claimed in claims 27 or 28, wherein there is an action object associated with each rule, and execution of each rule determines if the associated action object is to be included in the queue.

30. A work flow processing method as claimed in claim 29, wherein each rule object is a compound object comprising: a statement object;

an expression object; and

an operand object.

31. A computer program product comprising software code for performing the steps of the method of claim 1 when executing on a digital computer.

32. A computer program product comprising software code for performing the steps of the method of claim 27 when executing on a digital computer.

33. A data processing system comprising a server and a client comprising means for performing a method as described in any of claims 1 to 30.