Device and a Method for Processing Events and Actions
A device operating as a finite state machine and provided for processing events and actions relating to at least one object to be moved between an initial and a final state. The device comprising a processing member connected to a memory. The initial and final states are integrated into at least one event-state-action diagram defining said finite state machine. The event-state-action diagram has a matrix structure where each event-state combination forms a matrix position. Actions formed by transitions, processing actions, and timed actions, are stored at the matrix positions. The processing member is further provided for retrieving the actions and for supplying the retrieved actions to an action dispatcher in order to execute the actions. The action dispatcher comprises, for each action of said third set, an execution routine provided for controlling the execution of the action.
The present invention relates to a device operating as a finite state machine and provided for processing events and actions relating to at least one object to be travelled between an initial and a final state, said device comprising a processing member connected to a memory. The invention also relates to a method for processing events and actions.
Such a device and process are for example known as IBM FlexFlow (trademark of IBM), which is a workflow system developed by IBM for interactive internet applications. It is a state machine based workflow system, which formally describes business processes with state charts. The FlexFlow system uses these descriptions to directly control the execution of e-commerce applications. Flexflow has a visual modelling tool to design and modify business process state diagrams. The visual tool generates an XML representation of the process. This XML presentation is compiled and loaded into the FlexFlow database used by the FlexFlow engine. For FlexFlow, events are incoming messages and actions corresponding to tasks which are executed at the level of the application server. Flexflow has been integrated in IBM's WebSphere Commerce suites to build web-applications.
The problem of the prior art device and method is that the reality of processing events and actions is more complex. The way to capture transition events is not straightforward in a distributed environment. Indeed, events are triggered at different places, by different people and by different systems. Not all events are always properly generated and they do not always occur in the correct order. Most systems have difficulties to cope with this situation. Workflow systems, which are used to automate business processes, are not designed for handling such an arbitrary sequence of events. Transitions in workflow systems are “explicit” because they lack the state pattern, where transitions are “implicit”. Workflow systems usually expect to receive events in a particular well-determined sequence with explicit “wait states” until an event can occur. As long as the expected event does not occur, all other events are queued and the process stops.
For example, in the case of the package delivery, events can originate from different sources:
a shipping application used in a warehouse;
scanners used in the warehouse;
handheld scanners used by the courier drivers;
scanners used at the drop-off location;
timer triggers in the central system;
All these sources are distributed over a wide geographic area and will typically communicate with the central system over the Internet, with its imperfection.
In reality it is important to make a distinction between events and transitions, because not all events may necessarily trigger a state transition. At the time at which events are received by the central system, they might indeed be obsolete, and the object to which the event relates, might already be in a further state. The system needs thus to react differently on events based on the current state of the relevant object. In the example of the package delivery one could imagine that there is an action linked to the transition “In transit->delivered to location” which consists in notifying the recipient via a messaging system. The event, which triggers this transition, would be a scan event in a drop-off location. For whatever reason the event may be delayed, for instance because the scanner cannot synchronise. However, the recipient may actually see his package and collect it because he or she is visiting the location. Through a phone call, some operator in a service centre may update the status of the package as “Delivered to user”. Subsequently, if the scanner finally manages to synchronise, the central system should not react on this event in the same way as if the state of the package would be (“in Transit”). As the current state is “Delivered to user” there is no need to notify the end user.
It is an object of the present invention to cope with this complexity by providing a device and a method, which enable to modify the behaviour of the objects by adding new type of events, new states and new actions according to the evolution of the business processes and systems generating the events. The device or method according to the invention should allow to branch anywhere in the process at any time in such a manner as to process events immediately, without having to queue.
The device or method according to the invention has been developed to address problems of real time supply chain event management, due to the specific nature of supply chain processes. It has been built in such a way as to solve real-time event-driven business process management problems where the business object to be monitored and controlled can be modelled by a finite state machine.
For this purpose a device according to the present invention is characterised in that said initial and final state are integrated into at least one event-state-action diagram defining said finite state machine, said memory having an input connected to a state engine editor and being provided for storing said diagram, said state engine editor having an input for receiving object data, identifying said object and said initial and final state, said object data comprising a first set of states, a second set of events and a third set of actions, said third set comprising a first sub-set of processing actions, a second sub-set of timed actions provided to initiate each time at least one predetermined action of said first sub-set after a predetermined time period has lapsed and a third sub-set of transition actions, said state engine editor being provided for forming said diagram by matrix-wise structuring said states of said first set and said events of said second set in order to create at positions within said matrix a state-event combination, said state engine editor being further provided for attributing to at least one state-event combination at least one of said actions of said third set, said processing member having an input for receiving event-messages and being provided for converting a received event-message into one of said events of said second set, said processing member being also provided for monitoring said states in order to recognise an actual state for said object and for selecting within said state diagram upon receipt of one of said event-messages a position within said diagram corresponding to said actual state and said event obtained by said converting, said processing member being further provided for retrieving said actions located at said selected position and for supplying said retrieved actions to an action dispatcher in order to execute said retrieved action, said action dispatcher comprising for each action of said third set an execution routine provided for controlling said execution of said action. The use of an event-state-action diagram defined in a finite state machine enables to work with deterministic finite state machines thereby imposing a single transition for a state-event combination. The matrix organisation not only permits to establish a combination between the events and the states but also to attribute actions to such a combination. Not only this provides an operational flexibility, but also enables to add events and states without deviating from the diagram concept. Since the actions can be processing actions as well as timed or transition actions, a large flexibility is offered. Moreover, the timed actions allow the finite state machine to reach a subsequent or final state even if some expected events are not received or not received at an expected time. The use of event-state-action diagrams further gives the processing member the possibility to process event-messages by recognising the occurred event in the received message and select, by using the actual state, those actions attributed to the actual event-state combination.
A first preferred embodiment of a device according to the present invention is characterised in that said state engine editor is provided for attributing to each state-event combination, comprising said initial state, an action selected among said third sub-set. In such a manner care is taken that a transition from the initial state wilt be performed.
A second preferred embodiment of a device according to the present invention is characterised in that said actions belonging to said third set and said events of said second set are predetermined. In such a manner care is taken that for each action or each event there is an execution routine.
Preferably each diagram is identified by a description thereof and a reference to the object to which it belongs. This enables a more flexible processing.
A third preferred embodiment of a device according to the present invention is characterised in that each transition action of said third sub-set comprises a reference to an event of said second set, a source and a target state as well as a reference to said diagram to which it belongs. The presence of a target state enables the correct execution of the state transition.
A preferred embodiment of a method according to the present invention is characterised in that said objects are classified by object types, each object being identified by a definition and a description of the object type to which it belongs, and wherein a plurality of event-state-action diagrams are formed for each object, each diagram corresponding to one of said object types, said monitoring further comprising a selection of at least one of said diagrams based on said object type. This enables to use several diagrams for a same object.
The invention will now be described in more details with reference to the annexed drawings illustrating a preferred embodiment of a device and a method according to the present invention. In the drawings:
FIGS. 6 to 12 illustrate examples of editors for events, processing actions, timed actions, state diagrams, states and event-action-state diagrams respectively;
In the drawings a same reference has been allotted to a same or analogous element.
The present invention relates to a device and method for processing events, in particular business process events, which occur in an arbitrary order. Following the occurrence of an event, appropriate actions are triggered in real time, based on the current state of the business object on which the events apply. The method is based on a finite state machine design pattern. From a macro point of view, the method is nondeterministic i.e. the same events will not necessarily lead to the same actions. Moreover, the device allows dealing with changes in the business model, adding new objects, new state diagrams, new events, new states, new transitions and new actions as the situation evolves, which is usually the case in business environments.
A business process is usually described as a sequence of steps and actions, with a clear start and an end. The output of one step provides the input for the next step. Different methods have been developed to model business processes. Software tools have been developed to support the information flows related to business processes. While traditionally, enterprise applications were developed to support the actions taken and information processed with a particular step in the process, it is only recently that methods and tools have been developed to support the whole process and the exchange of information between different enterprise applications (example: transfer of information from the ordering system to the billing system and subsequently to the accounting system). More specifically, workflow systems allow to model graphically the different steps in the process and to connect the output of one step with the input of the next step in the process. These tools usually allow software coding to implement business logic and do data manipulations.
The inconvenience with workflow systems is that the process flow has always to go through a predetermined path connecting subsequent steps to reach the end of the process in a sequential and deterministic way. Each step in the process is not aware of the whole process. A step receives input from its predecessor, does some processing and provides input to its successor. In reality, processes do not always work this way and workflows are not always the most natural way to represent business interactions between individuals, organisations and systems.
The aim of business processes is to manipulate or transform a business object (like an order, a shipment, a parcel or any business transaction), which is handed over between different individuals, locations, organisations or systems until completion of the transaction. The business objects can be physical (e.g. a parcel) or electronic (e.g. an electronic message). The behaviour of such an object can be modelled with a state diagram or a finite state machine. During its lifecycle the object will go through different states. Actions are linked to a particular state of the object. As soon as an object arrives in a certain state, appropriate actions can be taken.
The challenge is to maintain the consistency between the real physical state of the object and the virtual state as maintained by the information system and to take the actions linked to valid state transitions in an appropriate way. During the lifecycle of the object, different agents on remote systems will publish events on the actual or current state of the object. Due to the nature of the distributed network like the Internet, the published events do not always arrive on time at the central information system. There may be a delay between the moment at which the event occurred and the moment it was received by the device. Events may arrive in the wrong order and there may be many occurrences of the same event. In other words, the generation of events is non-deterministic.
In order to explain the problem to be solved, a real example from the parcel distribution industry will be taken. Packages are shipped from a source, corresponding to an initial state, to a destination, corresponding to a final state, within a certain time frame. The shipment can be seen as a business transaction with a package as a business object to be monitored by the device according to the invention in order to ensure the proper completion of the business transaction and take appropriate actions where needed, like notifying the expeditor that the package will be late or notifying the recipient that the package has arrived. During its transportation, the package will go through different states.
An example of a package state diagram is shown in
In the present invention a state design pattern or finite state machine is used for modelling the package delivery process or the behaviour of a package object. If the method enables to follow the package delivery process flow in real time, the method can also easily feed different systems, which are involved in such a process for monitoring and controlling purposes. For example:
a track and trace web site showing the current state of the package;
a messaging system to notify a recipient indicating that a package can be collected;
a billing system to register billing records;
an alerting system to notify any exception in the process (package late or misrouted);
a data warehouse for service level calculations.
Such actions can be taken when a transition to a subsequent state occurs or after a time out within a certain state (for example, package too long “In transit” or too long in “Delivered to location”).
The device and method according to the present invention have been developed to address problems of a real time supply chain event management, due to the specific nature of supply chain processes, but have been built in such a way as to solve real-time event-driven business process management problems, where the business object to be monitored and controlled can be modelled by a finite state machine.
The state engine editor 11 is provided to create event-state-action diagrams, which are related to object types. The device allows to operate with several object types and to create a diagram for each object type. It is also possible to create several event-state-action diagrams per object type. The processing member is provided to create, even on runtime, actual event-state-action diagrams for effective real objects and to process a plurality of diagrams in real time. Each running diagram being associated to one running object of which the actual state is monitored.
The creation of such an event-state-action diagram is realised by the state engine editor 11, which has an input for receiving object data identifying the object to be processed as well as the initial and final state for that object. Once the event-state-action diagram is created for the object to be considered, it is stored in the memory 2. When the diagram is stored in the memory it can be retrieved by the processing member 1 in order to be processed. The processing member will react on event-messages circulating on the message bus 6.
The state engine processor 8 is built on the concept of a finite state machine. This concept is illustrated with reference to an example shown in
The use of the matrix set-up enables a flexible build-up of the diagram because the number of rows and columns is as if to say unlimited. Modifications are implemented by adding or deleting rows or columns or by modifying the attributed events. Moreover the diagram makes it possible to treat incoming events in an unrelated order.
In the example shown in
It should also be noted in the example that both, event c and event d, will allow a transition from state A to state D, but the associated actions are different. Therefore they are considered as two different transitions within the same state diagram.
An example of an end use of such an application is in a package delivery business. In such a business the state of a package (the relevant object) may change before the state engine receives or can react on an event. E.g., the change of the state of a package to “ready for pick up” is an event, which typically triggers an action to notify the customer. However, if before such a notice is sent, the state of the package changes from “Ready for pick-up” to “Delivered” then the state engine determines not to send such a notice. Thus, the state engine responded to the same event differently based on the actual state of the package.
The state engine editor is preferably formed by a graphical user interface (GUI) for creating and modifying events-states-actions diagrams. It preferably generates an XML description of the diagram, which can then be loaded in the memory 2.
A further distinction can be made between two types of actions:
generic actions, which can be invoked for any type of object. The code logic of these actions uses only the parameters of the triggering event, and not a logic specific to the object embodied in the event;
object specific actions, which can only be invoked from state machines relating to the same object type as the embodied object.
The implementation of these methods may use logic, which is specific to the type of the embodied object. An example of such an object specific action is an action referring to a tracking number of a parcel.
For forming the diagrams, the state engine editor will use the editors of which an example is given in the FIGS. 6 to 12. The state engine editor allows to define and modify all entities of the state machine.
On the top there are three selections:
definitions of basic entities, object types, events, actions, timed actions, state diagrams and states;
definition of diagrams, for each state and for each event, transitions and actions to be performed;
repository, save and load XML schema's in the editor, and load the active schema into the memory.
The screen layouts are self explanatory and directly in line with the definition of the XML file in
It should be noted that events and object types are closely linked to each other. Event messages will always embody the associated object and will be applied only to the running state machine diagrams associated with the embodied object. The name of the event and the embodied object type serve as interface specification between the process designers and the designers of the messaging system, transporting the event messages and/or the object classes and/or databases of the application server. The name of the action serves as interface specification between the process designer and the designer of the method implementing the action and running on the application server. The object type is not mandatory for actions. If the object type is not specified, the action can be applicable on all state machines, for all type of objects.
Like actions, timed actions can be generic for all object types or specific to one object type. A timed action specifies a timeout variable and one or more generic or object type specific actions, which will be invoked upon expiration of the timer. The action list allows multiple selections.
The state diagram screen in the entities menu is for the declaration of the state diagram names and the link to the related object type. These declarations are needed to create the states. The same object type may have different state diagrams. The instantiation of an object may also have different state machines running in parallel, but not necessarily. This will depend on the events causing the transitions. The state machines, executing actions for the same object, may have different triggering events. However, the different running diagrams relating to a same object shall be different from each other.
For each diagram selected in the upper left table of
The device according to the present invention is provided for processing a plurality of diagrams relating to a same object and also for processing a plurality of diagrams for a plurality of objects. The use of object types will enable the selection of a diagram, since the incoming event-message will comprise an indication of the object type.
The part formed by the runtime and historical data is not in the XML definition, but is used by the state engine to maintain the instances of the running state machine and log their associated events, state changes, actions and timed actions:
Object (50)
Running State Diagram (51)
Event History (52)
State History (53)
Action History (54)
Timed Action History (55)
The relations between these tables mirror the definition tables kept in the memory of the device. One can see that one object may have several running state diagrams (51; each corresponding to a different state machine). A running state diagram has always one current state, corresponding to the possible states linked to the state diagram definition. An event is always related to one object, which is embodied in the event. State history, action history, timed action history records are always related to one running state diagram and one instance of a triggering event (Event History table). In case an object type should have different state diagrams, the same triggering event may be applicable to different running state diagrams and hence generating different transitions which will lead to different records in the state, action and timed action history tables, all linked to the same triggering event in the event history table.
The device according to the present invention allows alteration of existing state diagrams, even for state machines with running instances. In order to support change management, a version control mechanism has been introduced. In case a state diagram has changed, new reference identifiers are generated for the entities where needed, so that running instances are still linked to a previous version and can continue to function normally until a final state is reached. New instances will be linked to the new version of the diagram.
The operation of the device as well as the application of the method will now be further described with reference to the
at least one object to be managed by the device (known by its type and unique identifier)
the events to which the device will subscribe (known by their name and embodied objects)
the processing actions to be executed by the device according to the rules defined in the editor (known by their name and type, generic or object specific).
Once these elements are supplied to the device, the event-state-action diagram(s) is (are) formed and the processing of the events can start. For forming the event-state-action diagram(s) use is made of the state diagram definition 42. The matrix framework of the diagram is built up with the supplied events and the different states to be occupied by the embodied object during its traveling from the initial to the final state. At those state-event combinations where actions are required, the processing actions are attributed. The state diagram definition 42 is only used during the diagram build-up. Thereafter the running state diagram 51 is used upon processing of the events and actions.
Upon receipt (20) of an event-message traveling on the message bus (6;
Once the state diagram for the embodied object is found, the current state is also recognised since the device memorises for each running diagram, the actual state thereof. The actual state in combination with the received event indicates a location in the matrix forming the diagram. As described here before, at this matrix location the actions to be executed, if any, are stored. If a transition action has to be executed, the device will search (26) in the transition table in order to find a record with a reference to the current state diagram definition of the loop and, as triggering event, a reference to the processed event and, as source state, a reference to the same state as the current state of the running state diagram corresponding to the current state diagram definition of the loop and having a reference to the embodied object. Such a transition record will always be unique, per definition of the deterministic nature of the finite state machine at design time. If such transition record is found, the device will process one or more of the three action types, depending on the actions indicated at the addressed matrix location:
state change and cancel related open timers, if the target state is different from the source state (27);
processing actions, which will execute the code of the related pre-determined actions (28) by means of the action dispatcher (10,
timed actions, which will initiate the timers (29).
Every action is recorded in respectively the state, action and time action history tables for further reference and analysis.
The device also comprises a scheduler (9,
Claims
1. A device operating as a finite state machine and provided for processing events and actions relating to at least one object to be moved between an initial and a final state, said device comprising a processing member connected to a memory, wherein said initial and final state are integrated into at least one event-state-action diagram defining said finite state machine, said memory having an input connected to a state engine editor and being provided for storing said at least one diagram, said state engine editor having an input for receiving object data, identifying said object and said initial and final state, said object data comprising a first set of states, a second set of events and a third set of actions, said third set comprising a first sub-set of processing actions, a second sub-set of timed actions provided to initiate each time at least one predetermined action of said first sub-set after a predetermined time period has lapsed and a third sub-set of transition actions, said state engine editor being provided for forming said diagram structured as a matrix of said states of said first set and said events of said second set in order to create, at positions within said matrix, a state-event combination, said state engine editor being further provided for attributing to at least one state-event combination at least one of said actions of said third set, said processing member having an input for receiving event-messages and being provided for converting a received event-message into one of said events of said second set, said processing member being also provided for monitoring said states in order to recognize an actual state for said object and for selecting within said state diagram, upon receipt of one of said event-messages, a position within said diagram corresponding to said actual state and said event obtained by said converting, said processing member being further provided for retrieving said actions located at said selected position and for supplying said retrieved actions to an action dispatcher in order to execute said retrieved action, said action dispatcher comprising for each action of said third set an execution routine provided for controlling said execution of said action.
2. A device as claimed in claim 1, wherein said state engine editor is provided for attributing to each state-event combination, comprising said initial state, an action selected from among said third sub-set.
3. A device as claimed in claim 1, wherein said state engine editor is provided for attributing to each state-event combination, comprising said final state, only actions belonging to said first or second sub-set.
4. A device as claimed in claim 1, wherein said actions belonging to said third set are predetermined.
5. A device as claimed in claim 1, wherein said events belonging to said second set are predetermined.
6. A device as claimed in claim 1, wherein each diagram is identified by a description thereof and a reference to the object to which it belongs.
7. A device as claimed in claim 1, wherein each state is identified by a description thereof and a reference to the diagram to which it belongs.
8. A device as claimed in claim 1, wherein each event is identified by a description thereof and a reference to the object to which it belongs.
9. A device as claimed in claim 1, wherein each action is identified by a description thereof.
10. A device as claimed in claim 1, wherein said state engine editor is provided for forming said diagrams with an XML description.
11. A device as claimed in claim 1, wherein each transition action of said third sub-set comprises a reference to an event of said second set, a source and a target state as well as a reference to said diagram to which it belongs.
12. A device as claimed in claim 1, wherein said first sub-set comprises a first class of generic actions and a second class of specific actions identified by a reference to the object to which it belongs.
13. A method for processing, within a finite state machine, events and actions relating to at least one object to be moved between an initial and a final state, wherein said method comprises:
- receiving object data identifying said at least one object and said initial and final state, said object data comprising a first set of states, a second set of events and a third set of actions, said third set comprising a first sub-set of processing actions, a second sub-set of timed actions provided to initiate each time at least one predetermined action of said first sub-set after a predetermined time period has lapsed and a third sub-set of transition actions;
- forming at least one event-state-action diagram defined in a final state machine pattern of said finite state machine by structuring said states of said first set and said events of said second set as a matrix in order to create at positions within said matrix, each time, a state-event combination;
- integrating said initial and final state into said diagram;
- attributing to at least one state-event combination at least one of said actions of said third set;
- receiving event-messages relating to said at least one object and converting a received event-message into one of said events of said second set;
- recognizing said at least one object into said received event-message;
- monitoring said states in order to recognize an actual state for said recognized object and selecting within said state diagram upon receipt of one of said event-messages a position within said diagram corresponding to said actual state and said event obtained by said converting;
- retrieving said actions located at said selected position and executing said retrieved action by processing an execution routine provided for controlling said execution of said retrieved action.
14. A method as claimed in claim 13, wherein said at least one object includes plural objects, said objects classified by object types, each object being identified by a definition and a description of the object type to which it belongs, and wherein a plurality of event-state-action diagrams are formed for each object, each diagram corresponding to one of said object types, said monitoring further comprising a selection of at least one of said diagrams based on said object type.
15. A method as claimed in claim 14, wherein said object types are predetermined.
16. A method as claimed in claim 13, wherein said at least one object includes a plurality of objects, and for each of the plurality of objects, at least one dedicated event-state-action diagram is formed, said event-messages comprising an object identifier, said monitoring further comprising a selection of at least one of said diagrams based on said identified object.
17. A method as claimed in claim 14, wherein said at least one object includes a plurality of objects, and for each of the plurality of objects, at least one dedicated event-state-action diagram is formed, said event-messages comprising an object identifier, said monitoring further comprising a selection of at least one of said diagrams based on said identified object.
18. A method for processing, within a finite state machine, events and actions relating to at least one object to be moved between an initial and a final state, wherein said method comprises:
- receiving object data identifying said at least one object and said initial and final state, said object data comprising a first set of states, a second set of events and a third set of actions, said third set comprising a first sub-set of processing actions, a second sub-set of timed actions provided to initiate each time at least one predetermined action of said first sub-set after a predetermined time period has lapsed and a third sub-set of transition actions;
- forming at least one event-state-action diagram defined in a final state machine pattern of said finite state machine by structuring said states of said first set and said events of said second set as a matrix in order to create at positions within said matrix, each time, a state-event combination;
- integrating said initial and final state into said diagram;
- attributing to at least one state-event combination at least one of said actions of said third set;
- receiving event-messages relating to said at least one object and converting a received event-message into one of said events of said second set;
- recognizing said at least one object into said received event-message;
- monitoring said states in order to recognize an actual state for said recognized object and selecting within said state diagram upon receipt of one of said event-messages a position within said diagram corresponding to said actual state and said event obtained by said converting;
- retrieving said actions located at said selected position and executing said retrieved action by processing an execution routine provided for controlling said execution of said retrieved action;
- wherein said at least one object includes plural objects, said objects classified by object types, each object being identified by a definition and a description of the object type to which it belongs, and wherein a plurality of event-state-action diagrams are formed for each object, each diagram corresponding to one of said object types, said monitoring further comprising a selection of at least one of said diagrams based on said object type;
- wherein said object types are predetermined; and
- wherein said at least one object includes a plurality of objects, and for each of the plurality of objects, at least one dedicated event-state-action diagram is formed, said event-messages comprising an object identifier, said monitoring further comprising a selection of at least one of said diagrams based on said identified object.
19. A device as claimed in claim 2, wherein said state engine editor is provided for attributing to each state-event combination, comprising said final state, only actions belonging to said first or second sub-set.
20. A device as claimed in claim 19, wherein said actions belonging to said third set are predetermined.
Type: Application
Filed: Feb 11, 2005
Publication Date: Nov 15, 2007
Inventors: Stephane Odent (Enghien), Dimitri Van de Putte (Vorst), Dominique Vernier (Uccle)
Application Number: 10/589,260
International Classification: G06F 9/46 (20060101);