US20070266394A1 - Device and a Method for Processing Events and Actions - Google Patents

Device and a Method for Processing Events and Actions Download PDF

Info

Publication number
US20070266394A1
US20070266394A1 US10/589,260 US58926005A US2007266394A1 US 20070266394 A1 US20070266394 A1 US 20070266394A1 US 58926005 A US58926005 A US 58926005A US 2007266394 A1 US2007266394 A1 US 2007266394A1
Authority
US
United States
Prior art keywords
state
event
actions
action
diagram
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/589,260
Inventor
Stephane Odent
Dimitri Van de Putte
Dominique Vernier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
RelayStar NV SA
Original Assignee
RelayStar NV SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by RelayStar NV SA filed Critical RelayStar NV SA
Priority to US10/589,260 priority Critical patent/US20070266394A1/en
Priority claimed from PCT/EP2005/050620 external-priority patent/WO2005078611A1/en
Assigned to RELAYSTAR SA reassignment RELAYSTAR SA ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PUTTE, DIMITRI VAN DE, ODENT, STEPHANE V., VERNIER, DOMINIQUE
Assigned to RELAYSTAR SA reassignment RELAYSTAR SA CORRECTIVE ASSIGNMENT TO CORRECT THE THIRD ASSIGNOR'S EXECUTION DATE PREVIOUSLY RECORDED ON REEL 018210, FRAME 0613. ASSIGNOR HEREBY CONFIRMS THE ASSIGNMENT OF THE ENTIRE INTEREST. Assignors: VAN DE PUTTE, DIMITRI, VERNIER, DOMINIQUE, ODENT, STEPHANE V.
Publication of US20070266394A1 publication Critical patent/US20070266394A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • 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.
  • 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.
  • events can originate from different sources:
  • timer triggers in the central system
  • the recipient may actually see his package and collect it because he or she is visiting the location.
  • some operator in a service centre may update the status of the package as “Delivered to user”.
  • 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.
  • 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.
  • a device 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
  • 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.
  • 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.
  • FIG. 1 shows a package state diagram using a standard ULM notation
  • FIG. 2 shows schematically an example of the device according to the present invention
  • FIG. 3 illustrates a finite state machine
  • FIG. 4 illustrates an example of an event-state-action diagram
  • FIG. 5 illustrates an example of an XML definition for an event-state-action diagram
  • FIGS. 6 to 12 illustrate examples of editors for events, processing actions, timed actions, state diagrams, states and event-action-state diagrams respectively;
  • FIG. 13 illustrates a correlation in an entity relationship diagram
  • FIG. 14 illustrates by means of a flowchart a method according to the present invention.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • the package will go through different states.
  • FIG. 1 An example of a package state diagram is shown in FIG. 1 , using the standard UML (Unified Modelling Language) notation for finite state machines.
  • the UML notation uses the pairs “event/action” on the transition arrow to describe the behaviour of the objects, the event triggers the transition and the action results from it.
  • a package is “created”, for instance, when a tracking number has been generated by a shipping application and a label printed. This package can still be cancelled, as shown by the transition “created->cancelled”.
  • the shipment will be confirmed, a consignment note or manifest will be printed with all the details of the packages to be shipped and a shipping file will eventually be sent to the courier.
  • the package is then in the state “Manifested” awaiting the courier to collect it.
  • the package goes in the state “In Transit”, meaning that it is on its way.
  • the package might never arrive, arrive at a wrong destination (misrouting) or simply arrive late. In this case, the package goes into an “In exception” state. This might be a final state as the package may really be lost. Normally the package will arrive at destination, which could be a drop-off point. It will stay there until the final recipient will come and collect it.
  • 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 messaging system to notify a recipient indicating that a package can be collected
  • 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.
  • FIG. 2 shows schematically an embodiment of a device according to the present invention.
  • the device comprises a processing member 1 connected to a memory 2 .
  • the latter is also connected to a state engine editor 11 comprising an editing module 3 , an XML formatter and a loader 5 .
  • the processing member has an input connected to a message bus 6 provided for transferring event-messages.
  • the processing member comprises an event-receiving element 7 connected to a state engine processor 8 .
  • An output of the state engine processor 8 is connected to an action dispatcher 10 and a further output of the state engine processor is connected to a timed action generator 9 , having a trigger signal output connected to the action dispatcher.
  • 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.
  • 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.
  • the event-state-action diagram is created for the object to be considered, it is stored in the memory 2 .
  • the processing member 1 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 FIG. 3 .
  • the finite state machine of FIG. 3 comprises four states A, B, C and D of which A is the initial state and D the final state, C and B being intermediate states.
  • the states are grouped in a first set grouping a finite number of states.
  • a transition from one state to another is caused by an event. It should however be noted that not each event will cause a transition. Different events may cause the same transition, in case a different behaviour (different actions) is desired based on the triggering event.
  • One event can only cause one transition from a source state to a target state. When an event occurs, eventually a transition is made and actions are triggered.
  • the events are grouped in a second set grouping a finite number of events.
  • the actions are grouped in a third set grouping a finite number of actions.
  • the third set comprises a first sub-set of processing actions, such as for example sending a receipt message.
  • the third set further comprises a second sub-set of timed actions, which are actually timers triggering action(s) upon expiration of a predetermined time period. When the state of an object changes, all running timers (or timed actions) of this object are cancelled.
  • the third set comprises a third sub-set of transition actions triggering a transition from the actual state to the target state.
  • FIG. 4 shows an event-state-action diagram based on the example of FIG. 3 .
  • This model allows to define, modify, monitor and control business processes in a very efficient way.
  • the method enables to easily create new state machines, add or modify states, events and actions.
  • the event-state-action diagram is formed by the state engine editor 11 .
  • the state engine editor 11 uses the matrix set-up illustrated in FIG. 4 .
  • the received object data comprise the events, selected among the second set and the states selected among the first set.
  • the events are organised row-wise and the states column-wise. Consequently matrix positions are created, which each time corresponds to a state-event combination.
  • the state engine editor is further provided for attributing to at least one state-event combination at least one of said actions of the third set.
  • the attribution of the actions is i.a. determined by the initial and final state of the object, by the path to be traveled from the initial to the final state as well as by the events, which could occur.
  • 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.
  • a normal flow of events could be state A to state C with event a and then to state D with event c.
  • state A is the actual state and that event a is missed.
  • event c the object will move to state D.
  • the same actions (actions 4 and 5 ) can be taken as if they would originate from state C.
  • An additional action (action 6 ) is then taken, which could be for instance a warning message to notify that event a has been missed. If the relevant object later receives a notification of event a, it will not take the same actions associated with the transition, i.e. state A to state C, as they are not relevant in the context of state D, except for action 1 .
  • 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.
  • the state of a package (the relevant object) may change before the state engine receives or can react on an event.
  • 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.
  • the state engine determines not to send such a notice.
  • 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 .
  • FIG. 5 shows an XML definition for the events-states-actions diagrams.
  • the specification of this XML file can be considered as a “Business Process State Engine Language” or BPSEL, which has similarities with other Business Modeling language, but is much simpler.
  • BPSEL Business Process State Engine Language
  • the objects are classified by object types. This classification enables to attribute specific diagrams to each object type. For each object type a definition is stored in the memory. A unique reference identifier is attributed to each object type, as well as a name.
  • a description of the object types is also stored. All these data enable a uniform definition of the object, thus leading to an efficient processing.
  • a definition is also stored for the diagram.
  • the diagram, the states, the events, the actions, all have a unique reference identifier, a name and a description.
  • the timed actions all have a predetermined time period indicating at which time they should trigger.
  • the transition actions have a reference to a triggering event, the source state and diagram as well as a reference to the target state to be reached upon occurrence of the transition.
  • 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.
  • FIG. 6 shows the basic screen of the editor as it appears in a standard HTML browser.
  • the screen layouts are self explanatory and directly in line with the definition of the XML file in FIG. 5 .
  • the object type screen is simply a declaration, and the indication of the object classes and/or databases of the application server.
  • the designer can select an object type on the basis of the received object data and attribute a name and a description to the selected object type.
  • the icons “new”, “update” and “delete” provide to the designer the possibility either to create a new object type or to update or amend existing object types.
  • a box is further provided for introducing a predetermined amount of names and associated descriptions.
  • FIG. 6 relates to object types, FIG. 7 to events, FIG. 8 to actions, FIG. 9 to timed actions, FIG. 10 to state diagrams, FIG. 11 to states and FIG. 12 to diagrams.
  • 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.
  • 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.
  • 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.
  • object types will enable the selection of a diagram, since the incoming event-message will comprise an indication of the object type.
  • FIG. 13 illustrates an Entity-Relationship Diagram (ERD) for processing an event-state-action diagram.
  • the ERD comprises a first part, which forms the memory content and a second part formed by the runtime and historical data. From this ERD it can be derived that an event ( 40 ) is always related to one object type ( 41 ). In other words, if there is no object type considered, no events can happen.
  • a state diagram definition ( 42 ) is always related to one object type ( 41 ) and has at least one state ( 43 ) by default, which is “none” and corresponds to the initial state of the finite state machine.
  • An object type ( 41 ) may have more than one state diagram definition ( 42 ).
  • a state ( 43 ) is always related to a state diagram definition ( 42 ).
  • An action ( 44 ) is optionally related to one object type ( 41 ). Without object type reference, the action ( 44 ) is considered as a generic action, which can be used in all state diagrams, regardless of the object type.
  • a timed action ( 45 ) is optionally related to one object type ( 41 ). Without object type reference, the timed action is considered as a generic action, which can be used in all state diagrams, regardless of the object type.
  • a timed action ( 45 ) is linked to at least one action ( 44 ).
  • a transition ( 46 ) is always related to one state diagram definition ( 42 ), and is always characterised by one triggering event, one source state and one target state, which can be the same as the source state.
  • Each record in the transition table corresponds to one cell of the event-state-action diagram as described in FIG. 5 .
  • a transition may have none or several associated actions and timed actions.
  • 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:
  • 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).
  • 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.
  • a version control mechanism has been introduced.
  • 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.
  • At least one object to be managed by the device (known by its type and unique identifier)
  • the event-state-action diagram(s) is (are) formed and the processing of the events can start.
  • the state diagram definition 42 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.
  • the processing member Upon receipt ( 20 ) of an event-message traveling on the message bus ( 6 ; FIG. 2 ) the processing member will save ( 21 ) the event present in the event-message into the event history table ( 52 ) with a link to the embodied object.
  • the embodied object is recognised by analysing the event-message, which comprises an identifier for the embodied object.
  • the object table ( 50 ) is filled with the embodied objects, so that whenever an event message with an embodied object occurs on the message bus, there is always a valid record in the object table for the embodied object. If the received event-message comprises an object, which is not present in the object table, an error message will be generated.
  • the device will process ( 22 ) by means of a loop the received event for each state diagram definition record linked to the object type of the embodied object.
  • the loop there will be checked ( 23 ) in the running state diagram table if there is already a record with a reference to the current state diagram definition of the loop and a reference to the embodied object. If no record is found, the transition table is searched ( 24 ) to find whether there is a record with a reference to the current state diagram definition of the loop and a reference to the event being processed by the device and a reference to the source state “None”.
  • a new record is created ( 25 ) in the table running state diagram, with a link to the embodied object, a link to the current state diagram definition of the loop and a link (the current state) to the state “None” which is linked to the same state diagram definition. If such a transition from “None” with the processed event is not found, the device will loop ( 30 ) to the next state diagram definition. In other words during step 24 there is checked if a new running state diagram has to be created for the embodied object.
  • 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.
  • the actions to be executed, if any, are stored.
  • 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:
  • the action dispatcher comprises for each action of the third set an execution routine provided for controlling said execution of said retrieved action(s);
  • 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 , FIG. 2 ), which will automatically execute the processing actions linked to the timed actions after expiration of the timer as specified in the timed action table.

Abstract

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.

Description

  • 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:
  • FIG. 1 shows a package state diagram using a standard ULM notation;
  • FIG. 2 shows schematically an example of the device according to the present invention;
  • FIG. 3 illustrates a finite state machine;
  • FIG. 4 illustrates an example of an event-state-action diagram;
  • FIG. 5 illustrates an example of an XML definition for an event-state-action diagram;
  • FIGS. 6 to 12 illustrate examples of editors for events, processing actions, timed actions, state diagrams, states and event-action-state diagrams respectively;
  • FIG. 13 illustrates a correlation in an entity relationship diagram; and
  • FIG. 14 illustrates by means of a flowchart a method according to the present invention.
  • 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 FIG. 1, using the standard UML (Unified Modelling Language) notation for finite state machines. The UML notation uses the pairs “event/action” on the transition arrow to describe the behaviour of the objects, the event triggers the transition and the action results from it. A package is “created”, for instance, when a tracking number has been generated by a shipping application and a label printed. This package can still be cancelled, as shown by the transition “created->cancelled”. Typically, at the end of the day or at the end of a packaging cycle, the shipment will be confirmed, a consignment note or manifest will be printed with all the details of the packages to be shipped and a shipping file will eventually be sent to the courier. The package is then in the state “Manifested” awaiting the courier to collect it. Once the package has been collected it goes in the state “In Transit”, meaning that it is on its way. The package might never arrive, arrive at a wrong destination (misrouting) or simply arrive late. In this case, the package goes into an “In exception” state. This might be a final state as the package may really be lost. Normally the package will arrive at destination, which could be a drop-off point. It will stay there until the final recipient will come and collect it.
  • 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.
  • FIG. 2 shows schematically an embodiment of a device according to the present invention. The device comprises a processing member 1 connected to a memory 2. The latter is also connected to a state engine editor 11 comprising an editing module 3, an XML formatter and a loader 5. The processing member has an input connected to a message bus 6 provided for transferring event-messages. The processing member comprises an event-receiving element 7 connected to a state engine processor 8. An output of the state engine processor 8 is connected to an action dispatcher 10 and a further output of the state engine processor is connected to a timed action generator 9, having a trigger signal output connected to the action dispatcher.
  • 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 FIG. 3. The finite state machine of FIG. 3 comprises four states A, B, C and D of which A is the initial state and D the final state, C and B being intermediate states. The states are grouped in a first set grouping a finite number of states. A transition from one state to another is caused by an event. It should however be noted that not each event will cause a transition. Different events may cause the same transition, in case a different behaviour (different actions) is desired based on the triggering event. One event can only cause one transition from a source state to a target state. When an event occurs, eventually a transition is made and actions are triggered. The events are grouped in a second set grouping a finite number of events. The actions are grouped in a third set grouping a finite number of actions. The third set comprises a first sub-set of processing actions, such as for example sending a receipt message. The third set further comprises a second sub-set of timed actions, which are actually timers triggering action(s) upon expiration of a predetermined time period. When the state of an object changes, all running timers (or timed actions) of this object are cancelled. Finally the third set comprises a third sub-set of transition actions triggering a transition from the actual state to the target state.
  • FIG. 4 shows an event-state-action diagram based on the example of FIG. 3. This model allows to define, modify, monitor and control business processes in a very efficient way. The method enables to easily create new state machines, add or modify states, events and actions. Based on the received object data identifying the object, the event-state-action diagram is formed by the state engine editor 11. For this purpose the state engine editor 11 uses the matrix set-up illustrated in FIG. 4. The received object data comprise the events, selected among the second set and the states selected among the first set. The events are organised row-wise and the states column-wise. Consequently matrix positions are created, which each time corresponds to a state-event combination. The state engine editor is further provided for attributing to at least one state-event combination at least one of said actions of the third set. The attribution of the actions is i.a. determined by the initial and final state of the object, by the path to be traveled from the initial to the final state as well as by the events, which could occur.
  • 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 FIGS. 3 and 4, it can be seen how the state engine would behave in case it misses an event. A normal flow of events could be state A to state C with event a and then to state D with event c. Suppose that state A is the actual state and that event a is missed. Upon receipt of event c, the object will move to state D. The same actions (actions 4 and 5) can be taken as if they would originate from state C. An additional action (action 6) is then taken, which could be for instance a warning message to notify that event a has been missed. If the relevant object later receives a notification of event a, it will not take the same actions associated with the transition, i.e. state A to state C, as they are not relevant in the context of state D, except for action 1.
  • 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. FIG. 5 shows an XML definition for the events-states-actions diagrams. The specification of this XML file can be considered as a “Business Process State Engine Language” or BPSEL, which has similarities with other Business Modeling language, but is much simpler. As can be seen in FIG. 5, the objects are classified by object types. This classification enables to attribute specific diagrams to each object type. For each object type a definition is stored in the memory. A unique reference identifier is attributed to each object type, as well as a name. A description of the object types is also stored. All these data enable a uniform definition of the object, thus leading to an efficient processing. As can be further seen in FIG. 5 a definition is also stored for the diagram. The diagram, the states, the events, the actions, all have a unique reference identifier, a name and a description. To each diagram there is also attributed a reference of the object type on which the diagram applies. To each state, there is also attributed a reference of the diagram, to which the state belongs. The timed actions all have a predetermined time period indicating at which time they should trigger. The transition actions have a reference to a triggering event, the source state and diagram as well as a reference to the target state to be reached upon occurrence of the transition.
  • 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. FIG. 6 shows the basic screen of the editor as it appears in a standard HTML browser.
  • 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 FIG. 5. The object type screen is simply a declaration, and the indication of the object classes and/or databases of the application server. The designer can select an object type on the basis of the received object data and attribute a name and a description to the selected object type. The icons “new”, “update” and “delete” provide to the designer the possibility either to create a new object type or to update or amend existing object types. A box is further provided for introducing a predetermined amount of names and associated descriptions. As is indicated in the FIGS. 6 to 12, FIG. 6 relates to object types, FIG. 7 to events, FIG. 8 to actions, FIG. 9 to timed actions, FIG. 10 to state diagrams, FIG. 11 to states and FIG. 12 to diagrams.
  • 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 FIG. 12, all possible states are displayed in the lower left table. For the selected source state, one can see all existing triggering events on which the state machine needs to act upon. It should be noted that not all possible events need to be configured and that a state transition is not always mandatory. The target state may be the same as the source state. In the upper right panel (Transition Editor) one can create, modify or delete transition by specifying, for each origin state, the triggering event, the target state and one or more generic or object specific actions and/or timed actions. The actions lists allow multiple selections.
  • 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.
  • FIG. 13 illustrates an Entity-Relationship Diagram (ERD) for processing an event-state-action diagram. The ERD comprises a first part, which forms the memory content and a second part formed by the runtime and historical data. From this ERD it can be derived that an event (40) is always related to one object type (41). In other words, if there is no object type considered, no events can happen. A state diagram definition (42) is always related to one object type (41) and has at least one state (43) by default, which is “none” and corresponds to the initial state of the finite state machine. An object type (41) may have more than one state diagram definition (42). So for example in the case of a parcel, one state diagram could be related to the billing of the object and another state diagram could be related to the travel path of the parcel. A state (43) is always related to a state diagram definition (42). An action (44) is optionally related to one object type (41). Without object type reference, the action (44) is considered as a generic action, which can be used in all state diagrams, regardless of the object type. A timed action (45) is optionally related to one object type (41). Without object type reference, the timed action is considered as a generic action, which can be used in all state diagrams, regardless of the object type. A timed action (45) is linked to at least one action (44). The state engine editor (3) will ensure consistency of object types (41) between timed actions (45) and actions (44). A transition (46) is always related to one state diagram definition (42), and is always characterised by one triggering event, one source state and one target state, which can be the same as the source state. Each record in the transition table corresponds to one cell of the event-state-action diagram as described in FIG. 5. A transition may have none or several associated actions and timed actions.
  • 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 FIGS. 13 and 14. For the operation of the device, three elements need to be known and supplied to the device:
  • 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; FIG. 2) the processing member will save (21) the event present in the event-message into the event history table (52) with a link to the embodied object. The embodied object is recognised by analysing the event-message, which comprises an identifier for the embodied object. The object table (50) is filled with the embodied objects, so that whenever an event message with an embodied object occurs on the message bus, there is always a valid record in the object table for the embodied object. If the received event-message comprises an object, which is not present in the object table, an error message will be generated. The device will process (22) by means of a loop the received event for each state diagram definition record linked to the object type of the embodied object. In the loop there will be checked (23) in the running state diagram table if there is already a record with a reference to the current state diagram definition of the loop and a reference to the embodied object. If no record is found, the transition table is searched (24) to find whether there is a record with a reference to the current state diagram definition of the loop and a reference to the event being processed by the device and a reference to the source state “None”. If such a record is found, a new record is created (25) in the table running state diagram, with a link to the embodied object, a link to the current state diagram definition of the loop and a link (the current state) to the state “None” which is linked to the same state diagram definition. If such a transition from “None” with the processed event is not found, the device will loop (30) to the next state diagram definition. In other words during step 24 there is checked if a new running state diagram has to be created for the embodied object.
  • 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, FIG. 2). For this purpose, the action dispatcher comprises for each action of the third set an execution routine provided for controlling said execution of said retrieved action(s);
  • 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, FIG. 2), which will automatically execute the processing actions linked to the timed actions after expiration of the timer as specified in the timed action table.

Claims (20)

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.
US10/589,260 2004-02-12 2005-02-11 Device and a Method for Processing Events and Actions Abandoned US20070266394A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/589,260 US20070266394A1 (en) 2004-02-12 2005-02-11 Device and a Method for Processing Events and Actions

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US10/779,343 2004-02-12
US10/779,343 US7421546B2 (en) 2004-02-12 2004-02-12 Intelligent state engine system
EP04103665.8 2004-07-29
EP04103665A EP1564666A1 (en) 2004-02-12 2004-07-29 A device and a method for processing events and actions.
PCT/EP2005/050620 WO2005078611A1 (en) 2004-02-12 2005-02-11 A device and a method for processing events and actions.
US10/589,260 US20070266394A1 (en) 2004-02-12 2005-02-11 Device and a Method for Processing Events and Actions

Publications (1)

Publication Number Publication Date
US20070266394A1 true US20070266394A1 (en) 2007-11-15

Family

ID=34701417

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/779,343 Expired - Fee Related US7421546B2 (en) 2004-02-12 2004-02-12 Intelligent state engine system
US10/589,260 Abandoned US20070266394A1 (en) 2004-02-12 2005-02-11 Device and a Method for Processing Events and Actions

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/779,343 Expired - Fee Related US7421546B2 (en) 2004-02-12 2004-02-12 Intelligent state engine system

Country Status (3)

Country Link
US (2) US7421546B2 (en)
EP (2) EP1564666A1 (en)
WO (1) WO2005078612A1 (en)

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080120574A1 (en) * 2006-11-21 2008-05-22 Heredia Damion A Business Process Diagram Visualization Using Timeline-Based Heat Maps
US20080120153A1 (en) * 2006-11-21 2008-05-22 Nonemacher Michael N Business Process Diagram Data Collection
US20080120573A1 (en) * 2006-11-21 2008-05-22 Gilbert Phil G Business Process Diagram Visualization Using Heat Maps
US20080172669A1 (en) * 2007-01-12 2008-07-17 Carefx Corporation System capable of executing workflows on target applications and method thereof
US20100100518A1 (en) * 2008-10-16 2010-04-22 International Business Machines Corporation Rules-Based Cross-FSM Transition Triggering
US7957992B2 (en) * 2006-11-21 2011-06-07 International Business Machines Corporation Modification of a diagram for business process optimization
US20120296892A1 (en) * 2011-05-19 2012-11-22 International Business Machines Corporation Graphically displaying lifecycle information of a governed object in a service registry in combination with the policies asserted for the lifecycle states
US20130111019A1 (en) * 2011-10-28 2013-05-02 Electronic Arts Inc. User behavior analyzer
US8463925B1 (en) * 2007-10-08 2013-06-11 Empirix Inc. Table driven event processing of multiple stateful protocols in a high performance network stack framework
US20130151477A1 (en) * 2011-12-08 2013-06-13 Symantec Corporation Systems and methods for restoring application data
WO2015053906A1 (en) * 2013-10-08 2015-04-16 Crowdstrick, Inc. Event model for correlating system component states
EP2958061A1 (en) * 2014-06-20 2015-12-23 Asset S.r.l. Method of developing an application for execution in a workflow management system and apparatus to assist with generation of an application for execution in a workflow management system
US9489271B1 (en) * 2012-03-29 2016-11-08 Veritas Technologies Llc User interface for restoring databases
US20170228253A1 (en) * 2016-02-10 2017-08-10 Salesforce.Com, Inc. Throttling Events in Entity Lifecycle Management
US9767264B2 (en) 2014-05-23 2017-09-19 Ricoh Company, Ltd. Apparatus, method for controlling apparatus, and program
US20180075082A1 (en) * 2016-09-13 2018-03-15 Oracle International Corporation Determining a chronological order of transactions executed in relation to an object stored in a storage system
US20180101557A1 (en) * 2016-10-10 2018-04-12 AlphaPoint Finite state machine distributed ledger
US9992018B1 (en) 2016-03-24 2018-06-05 Electronic Arts Inc. Generating cryptographic challenges to communication requests
US10427048B1 (en) 2015-03-27 2019-10-01 Electronic Arts Inc. Secure anti-cheat system
US10459827B1 (en) 2016-03-22 2019-10-29 Electronic Arts Inc. Machine-learning based anomaly detection for heterogenous data sources
US10460320B1 (en) 2016-08-10 2019-10-29 Electronic Arts Inc. Fraud detection in heterogeneous information networks
US10877740B2 (en) 2017-12-29 2020-12-29 Asg Technologies Group, Inc. Dynamically deploying a component in an application
US11055067B2 (en) 2019-10-18 2021-07-06 Asg Technologies Group, Inc. Unified digital automation platform
US11086751B2 (en) 2016-03-16 2021-08-10 Asg Technologies Group, Inc. Intelligent metadata management and data lineage tracing
US11172042B2 (en) 2017-12-29 2021-11-09 Asg Technologies Group, Inc. Platform-independent application publishing to a front-end interface by encapsulating published content in a web container
US11179639B1 (en) 2015-10-30 2021-11-23 Electronic Arts Inc. Fraud detection system
US11269660B2 (en) 2019-10-18 2022-03-08 Asg Technologies Group, Inc. Methods and systems for integrated development environment editor support with a single code base
TWI767106B (en) * 2018-04-09 2022-06-11 開曼群島商創新先進技術有限公司 Method, device and device for configuring payment process and executing payment process
US11474837B2 (en) 2018-04-09 2022-10-18 Advanced New Technologies Co., Ltd. Method and apparatus for efficient programming of electronic payment processing
US11582284B2 (en) 2017-11-20 2023-02-14 Asg Technologies Group, Inc. Optimization of publication of an application to a web browser
US11599504B2 (en) 2016-10-27 2023-03-07 Oracle International Corporation Executing a conditional command on an object stored in a storage system
US11611633B2 (en) 2017-12-29 2023-03-21 Asg Technologies Group, Inc. Systems and methods for platform-independent application publishing to a front-end interface
US11693982B2 (en) 2019-10-18 2023-07-04 Asg Technologies Group, Inc. Systems for secure enterprise-wide fine-grained role-based access control of organizational assets
US11762634B2 (en) * 2019-06-28 2023-09-19 Asg Technologies Group, Inc. Systems and methods for seamlessly integrating multiple products by using a common visual modeler
US11849330B2 (en) 2020-10-13 2023-12-19 Asg Technologies Group, Inc. Geolocation-based policy rules
US11847040B2 (en) 2016-03-16 2023-12-19 Asg Technologies Group, Inc. Systems and methods for detecting data alteration from source to target
US11886397B2 (en) 2019-10-18 2024-01-30 Asg Technologies Group, Inc. Multi-faceted trust system

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4591279B2 (en) * 2005-08-19 2010-12-01 ソニー株式会社 Information processing apparatus, information processing method, recording medium, and program
CN101097619A (en) * 2006-06-27 2008-01-02 国际商业机器公司 System and method for monitoring business flowpath
US20080177556A1 (en) * 2007-01-19 2008-07-24 Long Fung Cheng Business object status management
US8612271B2 (en) 2008-10-02 2013-12-17 Certusview Technologies, Llc Methods and apparatus for analyzing locate and marking operations with respect to environmental landmarks
CA2897462A1 (en) 2009-02-11 2010-05-04 Certusview Technologies, Llc Management system, and associated methods and apparatus, for providing automatic assessment of a locate operation
CA2692110C (en) * 2009-02-11 2015-10-27 Certusview Technologies, Llc Providing a process guide to a locate technician
CA2885962A1 (en) 2009-06-25 2010-09-01 Certusview Technologies, Llc Methods and apparatus for assessing locate request tickets
US20110137808A1 (en) 2009-12-04 2011-06-09 3Pd Analyzing survey results
CA2787185A1 (en) * 2010-01-19 2011-07-28 Whatsnexx Marketing Automation Inc. System and method for designing and executing subject-state engine workflows
US10235333B1 (en) * 2014-04-11 2019-03-19 Twitter, Inc. Managing consistency models in a distributed database
US11580472B2 (en) * 2015-05-14 2023-02-14 Palantir Technologies Inc. Systems and methods for state machine management
US10726032B2 (en) 2015-12-30 2020-07-28 Palantir Technologies, Inc. Systems and methods for search template generation
CN108255525B (en) * 2016-12-28 2020-08-25 比亚迪股份有限公司 Control method and device based on rail transit
US10839022B1 (en) 2017-07-24 2020-11-17 Palantir Technologies Inc. System to manage document workflows
US11088926B2 (en) 2017-09-01 2021-08-10 Futurewei Technologies, Inc. Instantiation of cloud-hosted functions based on call to function graph

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5790898A (en) * 1992-09-14 1998-08-04 Yamatake-Honeywell Co., Ltd. Information processing apparatus using finite state machine
US6041306A (en) * 1996-12-05 2000-03-21 Hewlett-Packard Company System and method for performing flexible workflow process execution in a distributed workflow management system
US6105087A (en) * 1998-06-10 2000-08-15 Hewlett-Packard Company Event recognition by a state machine whose state is dependent upon historical information
US6138171A (en) * 1996-11-14 2000-10-24 Alcatel Usa Sourcing, L.P. Generic software state machine
US20020032590A1 (en) * 2000-03-28 2002-03-14 International Business Machines Corporation E-market architecture for supporting multiple roles and reconfigurable business porcesses
US6467078B1 (en) * 1998-07-03 2002-10-15 Nec Corporation Program development system, method for developing programs and storage medium storing programs for development of programs
US6519642B1 (en) * 1997-01-24 2003-02-11 Peregrine Force, Inc. System and method for creating, executing and maintaining cross-enterprise processes
US20030050881A1 (en) * 2001-09-11 2003-03-13 International Business Machines Corporation Method and apparatus for creating and managing complex business processes
US20030050789A1 (en) * 2001-09-12 2003-03-13 International Business Machines Corporation Method and apparatus for monitoring execution of a business process managed using a state machine
US20030050886A1 (en) * 2001-09-11 2003-03-13 International Business Machines Corporation Method and apparatus for managing the versioning of business objects using a state machine
US20030050813A1 (en) * 2001-09-11 2003-03-13 International Business Machines Corporation Method and apparatus for automatic transitioning between states in a state machine that manages a business process
US20030074090A1 (en) * 2001-09-28 2003-04-17 Zdenek Becka System and method for improving operational efficiency through process automation
US6598225B1 (en) * 1999-03-29 2003-07-22 International Business Machines Corporation System, method, and program for utilizing a software state machine carrying out the process flow of a software program
US20030187743A1 (en) * 2002-02-07 2003-10-02 International Business Machines Corp. Method and system for process brokering and content integration for collaborative business process management
US20030191679A1 (en) * 2002-04-08 2003-10-09 Fabio Casati Method and system for event management in business processes
US20030195789A1 (en) * 2001-03-30 2003-10-16 Yen Scott Shyh Guang Method for incorporating human-based activities in business process models
US6665648B2 (en) * 1998-11-30 2003-12-16 Siebel Systems, Inc. State models for monitoring process
US20030237027A1 (en) * 2002-06-24 2003-12-25 International Business Machines Corporation Method, apparatus, and program for a state machine framework
US20040002918A1 (en) * 2002-06-26 2004-01-01 International Business Machines Corporation Business event triggered, policy-driven payment management

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6889194B1 (en) * 1995-06-01 2005-05-03 United Parcel Service Of America, Inc. Method and system for preparing an electronic record for shipping a parcel
AU5904700A (en) 1999-07-01 2001-01-22 Microsoft Corporation Workflow as data-transition driven, scriptable state machines
CN1639716A (en) * 2000-03-28 2005-07-13 邮票商业公司 Apparatus, systems and methods for online, multi-parcel, multi-carrier, multi-service parcel returns shipping management
US6968328B1 (en) 2000-12-29 2005-11-22 Fair Isaac Corporation Method and system for implementing rules and ruleflows
US20020198787A1 (en) * 2001-06-20 2002-12-26 Techno Mecca, Inc. Company and college online book ordering system, also known as cobos

Patent Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5790898A (en) * 1992-09-14 1998-08-04 Yamatake-Honeywell Co., Ltd. Information processing apparatus using finite state machine
US6138171A (en) * 1996-11-14 2000-10-24 Alcatel Usa Sourcing, L.P. Generic software state machine
US6041306A (en) * 1996-12-05 2000-03-21 Hewlett-Packard Company System and method for performing flexible workflow process execution in a distributed workflow management system
US6519642B1 (en) * 1997-01-24 2003-02-11 Peregrine Force, Inc. System and method for creating, executing and maintaining cross-enterprise processes
US6105087A (en) * 1998-06-10 2000-08-15 Hewlett-Packard Company Event recognition by a state machine whose state is dependent upon historical information
US6467078B1 (en) * 1998-07-03 2002-10-15 Nec Corporation Program development system, method for developing programs and storage medium storing programs for development of programs
US6665648B2 (en) * 1998-11-30 2003-12-16 Siebel Systems, Inc. State models for monitoring process
US6598225B1 (en) * 1999-03-29 2003-07-22 International Business Machines Corporation System, method, and program for utilizing a software state machine carrying out the process flow of a software program
US20020032590A1 (en) * 2000-03-28 2002-03-14 International Business Machines Corporation E-market architecture for supporting multiple roles and reconfigurable business porcesses
US20030195789A1 (en) * 2001-03-30 2003-10-16 Yen Scott Shyh Guang Method for incorporating human-based activities in business process models
US20030050886A1 (en) * 2001-09-11 2003-03-13 International Business Machines Corporation Method and apparatus for managing the versioning of business objects using a state machine
US20030050813A1 (en) * 2001-09-11 2003-03-13 International Business Machines Corporation Method and apparatus for automatic transitioning between states in a state machine that manages a business process
US20030050881A1 (en) * 2001-09-11 2003-03-13 International Business Machines Corporation Method and apparatus for creating and managing complex business processes
US20030050789A1 (en) * 2001-09-12 2003-03-13 International Business Machines Corporation Method and apparatus for monitoring execution of a business process managed using a state machine
US20030074090A1 (en) * 2001-09-28 2003-04-17 Zdenek Becka System and method for improving operational efficiency through process automation
US20030187743A1 (en) * 2002-02-07 2003-10-02 International Business Machines Corp. Method and system for process brokering and content integration for collaborative business process management
US20030191679A1 (en) * 2002-04-08 2003-10-09 Fabio Casati Method and system for event management in business processes
US20030237027A1 (en) * 2002-06-24 2003-12-25 International Business Machines Corporation Method, apparatus, and program for a state machine framework
US20040002918A1 (en) * 2002-06-26 2004-01-01 International Business Machines Corporation Business event triggered, policy-driven payment management

Cited By (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8527311B2 (en) 2006-11-21 2013-09-03 International Business Machines Corporation Business process diagram visualization using heat maps
US9606772B2 (en) * 2006-11-21 2017-03-28 International Business Machines Corporation Business process diagram data collection
US20080120153A1 (en) * 2006-11-21 2008-05-22 Nonemacher Michael N Business Process Diagram Data Collection
US7953619B2 (en) * 2006-11-21 2011-05-31 International Business Machines Corporation Business process diagram visualization using timeline-based heat maps
US7957992B2 (en) * 2006-11-21 2011-06-07 International Business Machines Corporation Modification of a diagram for business process optimization
US8041588B2 (en) 2006-11-21 2011-10-18 International Business Machines Corporation Business process diagram visualization using heat maps
US20080120574A1 (en) * 2006-11-21 2008-05-22 Heredia Damion A Business Process Diagram Visualization Using Timeline-Based Heat Maps
US20080120573A1 (en) * 2006-11-21 2008-05-22 Gilbert Phil G Business Process Diagram Visualization Using Heat Maps
US20080172669A1 (en) * 2007-01-12 2008-07-17 Carefx Corporation System capable of executing workflows on target applications and method thereof
US8463925B1 (en) * 2007-10-08 2013-06-11 Empirix Inc. Table driven event processing of multiple stateful protocols in a high performance network stack framework
US8095494B2 (en) 2008-10-16 2012-01-10 International Business Machines Corporation Rules-based cross-FSM transition triggering
US20100100518A1 (en) * 2008-10-16 2010-04-22 International Business Machines Corporation Rules-Based Cross-FSM Transition Triggering
US20120296893A1 (en) * 2011-05-19 2012-11-22 International Business Machines Corporation Graphically displaying lifecycle information of a governed object in a service registry in combination with the policies asserted for the lifecycle states
US10176237B2 (en) * 2011-05-19 2019-01-08 International Business Machines Corporation Graphically displaying lifecycle information of a governed object in a service registry in combination with the policies asserted for the lifecycle states
US20120296892A1 (en) * 2011-05-19 2012-11-22 International Business Machines Corporation Graphically displaying lifecycle information of a governed object in a service registry in combination with the policies asserted for the lifecycle states
US9529777B2 (en) * 2011-10-28 2016-12-27 Electronic Arts Inc. User behavior analyzer
US20130111019A1 (en) * 2011-10-28 2013-05-02 Electronic Arts Inc. User behavior analyzer
US10193772B1 (en) 2011-10-28 2019-01-29 Electronic Arts Inc. User behavior analyzer
US9372762B2 (en) * 2011-12-08 2016-06-21 Veritas Technologies Llc Systems and methods for restoring application data
US20130151477A1 (en) * 2011-12-08 2013-06-13 Symantec Corporation Systems and methods for restoring application data
US9489271B1 (en) * 2012-03-29 2016-11-08 Veritas Technologies Llc User interface for restoring databases
WO2015053906A1 (en) * 2013-10-08 2015-04-16 Crowdstrick, Inc. Event model for correlating system component states
US9477835B2 (en) 2013-10-08 2016-10-25 Crowdstrike, Inc. Event model for correlating system component states
US9767264B2 (en) 2014-05-23 2017-09-19 Ricoh Company, Ltd. Apparatus, method for controlling apparatus, and program
EP3598357A1 (en) * 2014-06-20 2020-01-22 Asset S.r.l. Method of developing an application for execution in a workflow management system and apparatus to assist with generation of an application for execution in a workflow management system
EP2958061A1 (en) * 2014-06-20 2015-12-23 Asset S.r.l. Method of developing an application for execution in a workflow management system and apparatus to assist with generation of an application for execution in a workflow management system
US11040285B1 (en) 2015-03-27 2021-06-22 Electronic Arts Inc. Secure anti-cheat system
US11654365B2 (en) 2015-03-27 2023-05-23 Electronic Arts Inc. Secure anti-cheat system
US10427048B1 (en) 2015-03-27 2019-10-01 Electronic Arts Inc. Secure anti-cheat system
US11179639B1 (en) 2015-10-30 2021-11-23 Electronic Arts Inc. Fraud detection system
US11786825B2 (en) 2015-10-30 2023-10-17 Electronic Arts Inc. Fraud detection system
US10437635B2 (en) * 2016-02-10 2019-10-08 Salesforce.Com, Inc. Throttling events in entity lifecycle management
US20170228253A1 (en) * 2016-02-10 2017-08-10 Salesforce.Com, Inc. Throttling Events in Entity Lifecycle Management
US11847040B2 (en) 2016-03-16 2023-12-19 Asg Technologies Group, Inc. Systems and methods for detecting data alteration from source to target
US11086751B2 (en) 2016-03-16 2021-08-10 Asg Technologies Group, Inc. Intelligent metadata management and data lineage tracing
US10459827B1 (en) 2016-03-22 2019-10-29 Electronic Arts Inc. Machine-learning based anomaly detection for heterogenous data sources
US9992018B1 (en) 2016-03-24 2018-06-05 Electronic Arts Inc. Generating cryptographic challenges to communication requests
US10460320B1 (en) 2016-08-10 2019-10-29 Electronic Arts Inc. Fraud detection in heterogeneous information networks
US20180075082A1 (en) * 2016-09-13 2018-03-15 Oracle International Corporation Determining a chronological order of transactions executed in relation to an object stored in a storage system
US11726979B2 (en) * 2016-09-13 2023-08-15 Oracle International Corporation Determining a chronological order of transactions executed in relation to an object stored in a storage system
US10747744B2 (en) 2016-10-10 2020-08-18 AlphaPoint Distributed ledger comprising snapshots
US10621157B2 (en) 2016-10-10 2020-04-14 AlphaPoint Immediate order book failover
US10789239B2 (en) * 2016-10-10 2020-09-29 AlphaPoint Finite state machine distributed ledger
US10866945B2 (en) 2016-10-10 2020-12-15 AlphaPoint User account management via a distributed ledger
US20180101557A1 (en) * 2016-10-10 2018-04-12 AlphaPoint Finite state machine distributed ledger
US11599504B2 (en) 2016-10-27 2023-03-07 Oracle International Corporation Executing a conditional command on an object stored in a storage system
US11582284B2 (en) 2017-11-20 2023-02-14 Asg Technologies Group, Inc. Optimization of publication of an application to a web browser
US11611633B2 (en) 2017-12-29 2023-03-21 Asg Technologies Group, Inc. Systems and methods for platform-independent application publishing to a front-end interface
US10877740B2 (en) 2017-12-29 2020-12-29 Asg Technologies Group, Inc. Dynamically deploying a component in an application
US11567750B2 (en) 2017-12-29 2023-01-31 Asg Technologies Group, Inc. Web component dynamically deployed in an application and displayed in a workspace product
US11172042B2 (en) 2017-12-29 2021-11-09 Asg Technologies Group, Inc. Platform-independent application publishing to a front-end interface by encapsulating published content in a web container
US11474837B2 (en) 2018-04-09 2022-10-18 Advanced New Technologies Co., Ltd. Method and apparatus for efficient programming of electronic payment processing
TWI767106B (en) * 2018-04-09 2022-06-11 開曼群島商創新先進技術有限公司 Method, device and device for configuring payment process and executing payment process
US11762634B2 (en) * 2019-06-28 2023-09-19 Asg Technologies Group, Inc. Systems and methods for seamlessly integrating multiple products by using a common visual modeler
US11550549B2 (en) 2019-10-18 2023-01-10 Asg Technologies Group, Inc. Unified digital automation platform combining business process management and robotic process automation
US11693982B2 (en) 2019-10-18 2023-07-04 Asg Technologies Group, Inc. Systems for secure enterprise-wide fine-grained role-based access control of organizational assets
US11755760B2 (en) 2019-10-18 2023-09-12 Asg Technologies Group, Inc. Systems and methods for secure policies-based information governance
US11775666B2 (en) 2019-10-18 2023-10-03 Asg Technologies Group, Inc. Federated redaction of select content in documents stored across multiple repositories
US11269660B2 (en) 2019-10-18 2022-03-08 Asg Technologies Group, Inc. Methods and systems for integrated development environment editor support with a single code base
US11055067B2 (en) 2019-10-18 2021-07-06 Asg Technologies Group, Inc. Unified digital automation platform
US11886397B2 (en) 2019-10-18 2024-01-30 Asg Technologies Group, Inc. Multi-faceted trust system
US11849330B2 (en) 2020-10-13 2023-12-19 Asg Technologies Group, Inc. Geolocation-based policy rules

Also Published As

Publication number Publication date
WO2005078612A1 (en) 2005-08-25
EP1564666A1 (en) 2005-08-17
EP1723584A1 (en) 2006-11-22
US7421546B2 (en) 2008-09-02
US20050182638A1 (en) 2005-08-18
WO2005078612A8 (en) 2005-12-15

Similar Documents

Publication Publication Date Title
US20070266394A1 (en) Device and a Method for Processing Events and Actions
US7788319B2 (en) Business process management for a message-based exchange infrastructure
Son et al. Automatic simulation model generation for simulation-based, real-time shop floor control
Eshuis et al. Comparing Petri net and activity diagram variants for workflow modelling–a quest for reactive Petri nets
US6763353B2 (en) Real time business process analysis method and apparatus
US7873940B2 (en) Providing packages for configuring software stacks
US7971187B2 (en) Configurable software stack
EP2031507B1 (en) Systems and/or methods for location transparent routing and execution of processes
CN102467701A (en) Event-based orchestration in distributed order orchestration system
Baumgrass et al. BPMN extension for business process monitoring
CN101432715A (en) Process encoding
CN109214776A (en) A kind of thermoelectricity EPC general contract of civil engineering management overall process total factor control platform
Pufahl et al. Batch activity: enhancing business process modeling and enactment with batch processing
Eshuis et al. An execution algorithm for UML activity graphs
McGinnis et al. Formalizing ISA-95 level 3 control with smart manufacturing system models
WO2005078611A1 (en) A device and a method for processing events and actions.
Pandya Review of modelling techniques and tools for decision making in manufacturing management
Walzer et al. Event-driven manufacturing: Unified management of primitive and complex events for manufacturing monitoring and control
US8862698B2 (en) Method and system for automated deployment of processes to a distributed network environment
CN113419829A (en) Job scheduling method, device, scheduling platform and storage medium
Zappia et al. LiSEP: a lightweight and extensible tool for complex event processing
Chowdhary et al. Enterprise integration and monitoring solution using active shared space
Bruno Business process modeling based on entity life cycles
Wuennenberg et al. Towards Data Management and Data Science for Internal Logistics Systems using Process Mining and Discrete-Event Simulation
Marazakis et al. Workflow Management Systems: State-of-the-Art

Legal Events

Date Code Title Description
AS Assignment

Owner name: RELAYSTAR SA, BELGIUM

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ODENT, STEPHANE V.;PUTTE, DIMITRI VAN DE;VERNIER, DOMINIQUE;REEL/FRAME:018210/0613;SIGNING DATES FROM 20060731 TO 20060809

AS Assignment

Owner name: RELAYSTAR SA, BELGIUM

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE THIRD ASSIGNOR'S EXECUTION DATE PREVIOUSLY RECORDED ON REEL 018210, FRAME 0613;ASSIGNORS:ODENT, STEPHANE V.;VAN DE PUTTE, DIMITRI;VERNIER, DOMINIQUE;REEL/FRAME:018354/0948;SIGNING DATES FROM 20060731 TO 20060809

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION