WO2007130621A2 - Work item event procession - Google Patents
Work item event procession Download PDFInfo
- Publication number
- WO2007130621A2 WO2007130621A2 PCT/US2007/010918 US2007010918W WO2007130621A2 WO 2007130621 A2 WO2007130621 A2 WO 2007130621A2 US 2007010918 W US2007010918 W US 2007010918W WO 2007130621 A2 WO2007130621 A2 WO 2007130621A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- event
- queuing table
- events
- failover
- monitor
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2358—Change logging, detection, and notification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
- G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
Definitions
- one or more stateless front-end applications connects to a single, state-full, backend.
- Events such as requests to access, modify, and remove various objects, are received at the front-end application, and are passed along to the backend.
- multiple requests seeking access to the same object are received simultaneously, or nearly so.
- any such conflicting requests are addressed by locking down an object while it is being accessed.
- the object handler lacks a means of determining when a new event is received.
- the event dispatching mechanism cannot differentiate between an event that is already being processed, and one awaiting processing.
- a system failure results in a significant loss of time, as no record is retained of what events have been processed, are currently being processed, and remain to be processed.
- a technology which, among other things, monitors the flow of events between a front-end application and a backend server.
- the requests are queued up in a queuing table.
- the queuing table By ordering the queuing table according to the type of objects that are processed within the same batch, the process becomes more efficient.
- the event dispatching mechanism By incorporating a flag which is set when a new event is received, the event dispatching mechanism becomes aware of new events, without having to poll the queuing table. Flagging the events within the queuing table itself identifies which events are already being processed, as opposed to those events which still need to be processed.
- a failover "event,” and an associated monitor allows the backend to detect system failures for selected events that are "in process”; by storing a "good” version of the queuing table, and maintaining the failover "event” on subsequent updates, the . system can recover from a failure with minimal loss.
- a new event is sent to the backend.
- the new event has an associated event type.
- a new event flag is set based on its associated event type, indicating that a new event of that particular event type has been received.
- the new event is added to the queuing table.
- Events are selected from the queuing table in groups, sometimes based upon the event type, and having an expiration time set to a time in the past, for processing. Each event in the processing group is marked, so that the system will prevent another business application from processing the same events in parallel.
- the events are either deleted or updated, and if not deleted the processing mark is removed.
- a failover event is added to the queuing table, for example when one or more events are selected for processing.
- the failover guard event has an expiration timer.
- a failover event is monitored, and if the expiration timer lapses, a system failure has occurred, and the system needs to be restored.
- the expiration timer can be reset, for example by successfully accessing the queuing table during processing.
- a "good" state of queuing table is stored, so that if the expiration timer lapses, the queuing table can be restored to a known good version.
- a good version of the queuing table can be stored when, for example, the expiration timer is created.
- Figure 1 is a block diagram of an exemplary computing system upon which embodiments may be implemented.
- Figure 2 is a block diagram of a computing environment, in accordance with one embodiment.
- Figure 3 is a block diagram of a backend, in accordance with one embodiment.
- Figure 4 is a block diagram of a work item event monitor, in accordance with one embodiment.
- Figure 5 is a flowchart of a method of utilization of a work item event monitor, in accordance with one embodiment.
- Figure 6 is a flowchart of a method of a method of failure recovery, in accordance with one embodiment.
- Computing devices such as computing system environment 10, typically include at least some form of computer readable media.
- Computer readable media can be any available media that can be accessed by a computing device.
- Computer readable medium may comprise computer storage media and communication media.
- Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data.
- Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computing device.
- Vacation media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signals such as a carrier wave or other transport mechanism and includes any information delivery media.
- modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
- communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
- Some embodiments may be described in the general context of computer- executable instructions, such as program modules, executed by one or more computers or other devices.
- program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
- functionality of the program modules may be combined or distributed as desired in various embodiments.
- a work item event monitor is described below.
- the work item event monitor in some embodiments, operates on the backend of a server application, such as a web server or portal server environment. The monitor reconciles multiple competing requests from stateless front-end applications to the state-full objects available through the backend.
- the work item event monitor uses a queuing table to track events received from the front-end applications which have not yet been delivered to the appropriate objects in the backend.
- the work item event monitor in some embodiments, also serves as an event dispatching mechanism. By monitoring and modifying this queuing table in a number of ways, as described herein, the work item event monitor, in some embodiments, can inform objects about new events in a timely manner, can track whether a particular event has been or needs to be delivered, can recover from server system failure, and can make the queuing table more efficient.
- an exemplary system for implementing embodiments includes a general purpose computing system environment, such as computing system environment 10.
- computing system environment 10 typically includes at least one processing unit 12 and memory 14.
- memory 14 may be volatile (such as RAM), non- volatile (such as ROM, flash memory, etc.) or some combination of the two.
- This most basic configuration is illustrated in Figure 1 by dashed line 16.
- computing system environment 10 may also have additional features/functionality.
- computing system environment 10 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in Figure 1 by removable storage 18 and non-removable storage 20.
- Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
- Memory 14, removable storage 18 and nonremovable storage 20 are all examples of computer storage media.
- Computing system environment 10 may also contain communications connection 22 that allow it to communicate with other devices. Communications connection 22 is an example of communication media.
- Computing system environment 10 may also have input device(s) 24 such as a keyboard, mouse, pen, voice input device, touch input device, etc.
- Output device(s) 26 such as a display, speakers, printer, etc. may also be included. All these devices are well known in the art and need not be discussed at length here.
- system 200 is depicted, in accordance with one embodiment. While system 200 is depicted as containing certain features, it is understood that system 200 is only exemplary. In other embodiments, system 200 may contain additional, fewer, or different features than those depicted. Further, in some embodiments, listed features may be separated into multiple distinct elements, or combine into fewer elements.
- system 200 depicts multiple stateless front-end applications 210, 211, 212 interfacing with a single state-full backend 220.
- both the front-end applications and the backend may be implemented on a single computer system, such as computing system environment 10.
- one or more of the front-end applications may be running remotely, and accessing backend 220 via a network connection, e.g., multiple web clients accessing a single web server.
- front and applications 210, 211, and/or 212 communicate with backend 220 in other ways.
- Backend 220 shown is connected to data store 230.
- data store 230 is a database, e.g., an SQL database.
- data store 230 is implemented in other ways.
- backend 220 is depicted as containing certain features, it is understood that backend 220 is only exemplary. In other embodiments, backend 220 may contain additional, fewer, or different features than those depicted. Further, in some embodiments, listed features may be separated into multiple distinct elements, or combine into fewer elements.
- backend 220 contains a queuing table 221.
- Queuing table 221 is used by backend 220, in some embodiments, to retain the events received from the front- end applications until they can be delivered to the objects in data store 230. In some such embodiment, queuing table 221 is also used to order these requests, to make for more efficient processing.
- Backend 220 is also depicted as containing several batch tables 222, 223, and 224.
- events received from the front-end applications, as well as events generated by backend 220 are sorted into several batch types. Some or all of these batch types may have an associated batch table within backend 220. These batch tables can be used to store additional information needed to process events. Other embodiments omit the batch tables.
- Figure 3 depicts queuing table 221 and batch tables 222 through 224 as being part of backend 220, it is understood that these tables may be stored, in some embodiments, in any location accessible to backend 220. For example, these tables may be stored in data store 230.
- Figure 3 also depicts data store 230, connected to backend 220.
- Data store 230 is shown as containing an object of the workflow type, workflow object 231.
- the efficiency of the system, and in particular efficient handling requests depend substantially upon what order events are passed out of the queuing table and to the intended objects.
- the queuing table, or the index to the tune table is ordered so as to speed this process.
- One approach to queuing tables is to order the table by the time in which an event is to be processed. For example, when an event is passed from the front-end to the backend, it will often have an appended requested processing time. This processing time can indicate a priority, or level of urgency, for the request. For example, a real-time application seeking data from the backend, in real-time, may request that its events be handled quickly; meanwhile, events received from another, non-real-time, front-end application may be less urgent, and so have a longer available processing time.
- the queuing table or the index to the queuing table, is ordered by batch type. In this way, all jobs of a particular batch type are grouped together, and are then processed together. By ordering the queuing table according to the type of objects that are processed within the same batch, these embodiments gain a level of efficiency lacking in other approaches.
- this problem is better addressed by monitoring events as they are added to the queuing table.
- the work item event monitor running on the backend monitors events as they are added to the queuing table. If the event is of particular batch type, e.g., an event for a workflow object, the work item event monitor updates a signal or flag, indicating that a new event of this type has been added. In some embodiments, this flag is available to the event handler for that particular object.
- the flag is a simple Boolean type, indicating whether there is a new event of this type, or not. In other embodiments, a more complicated flag system is utilized. [0040] In some embodiments, the new event flag is located in the batch table for the appropriate batch type, e.g., the new event flag indicating a new workflow event is part of the batch table for the workflow object type. In other embodiments, the flag is located elsewhere.
- Another question raised by the queuing table approach is how an event dispatching mechanism determines whether an event has been passed to the appropriate event handler.
- the approach used to address this question is to mark events within the queuing table itself.
- the event dispatching mechanism passes through the queuing table, identifying work items to be executed now. In some embodiments, this is accomplished by finding all work items related to a particular batch type, in the manner described above, with a processing time that has expired, or is about to expire. Passing through the queuing table in this manner will identify both events that have not been processed, and also events that are currently being processed.
- events which are currently being prcoessed need to be screened out.
- this is addressed by tagging work items in the queuing table, to indicate that they have already been passed to an event handler.
- this tagging is in the form of a simple Boolean flag, indicating whether or not a particular event has already been addressed.
- events are marked with an identifier, e.g., a globally unique identifier or GUID.
- identifier e.g., a globally unique identifier or GUID.
- events are marked in such a way as to convey additional information.
- other methods are used to identify events which have already been passed to the appropriate event handler.
- this approach is inverted, in that the absence of a tag or mark indicates whether a particular event has already been addressed.
- untagged events are marked when they are selected for processing. For example, if events of the workflow type are to be processed, any event of the workflow type already tagged is ignored, while untagged events are tagged and passed to the event handler.
- this is a two- step process: first untagged events are marked, and then the newly tagged events are selected. In other embodiments, including other data storage environments, this process may require fewer or additional steps.
- events may not be removed from the queuing table when processing is complete. This situation can occur for various reasons, e.g., the event will require further processing at a later time, in order to be properly completed.
- the tag indicating that the event is currently being processed is removed.
- the work item event monitor incorporates such a failure and recovery mechanism.
- the work item event monitor identifies system failure, and can revert to a previous version of the queuing table, when the system as known to be stable.
- this is accomplished by adding an event of the fai lover type to the queuing table.
- This event in some embodiments, is generated by the work item event monitor. In other embodiments, other mechanisms may be response before the creation of this event.
- the failover event is added to queuing table, and is set to expire at a predetermined time, e.g., in 15 minutes from the time it was added. In some embodiments, whenever the queuing table has been touched, e.g., whenever work items within the queuing table are selected for processing and tagged with a processing DD, the expiration time for the failover event is reset.
- a failover guard module examines the queuing table every so often, e.g., every five minutes, and watches for failover events. If an expired failover event is detected, the work item event monitor knows that some system failure has occurred. In some embodiments, the system reverts to the state it was in when the failover guard module last successful checked the queuing table. In other embodiments, the system reverts to the state it was in when last the failover event was reset.
- the failover event is deleted when the last batch in the queuing table has been processed.
- multiple failover events are utilized, each associated with a different batch type.
- a failover event is added when a new batch enters the queuing table, and that failover event is deleted when processing for that batch is finished.
- the expiration time for the failover event and the frequency of operation of the failover guard module will vary with different embodiments. In some embodiments, these times are user configurable, such that a system administrator may determine the frequency at which these checks are performed.
- FIG. 4 a block diagram of a work item event monitor is depicted, in accordance with one embodiment. While work item event monitor 400 is depicted as having specific components arranged in a specific fashion, is understood that work item event monitor 400 is intended to be exemplary, and not exclusionary. In other embodiments, a work item event monitor will have different components, and/or components arranged in a different fashion.
- work item event monitor 400 is run as part of a backend server, e.g., backend 220. In other embodiments, work item event monitor 400 may be running at an alternative location. [0054] Work item event monitor 400 is shown as having an input module 410.
- Input module 410 allows work item event monitor 400 to receive events from front-end applications, e.g., front-end 210.
- Work item event monitor 400 also has an output module 490, which is used in some embodiments to dispatch events to the appropriate event handlers, e.g., an object in data store 230.
- Work item event monitor 400 is also shown as having a queuing table 420.
- Queuing table 420 is used to queue up events received from front-end applications.
- Work item event monitor 400 is also depicted as having a number of batch tables 425a through 425n. In some embodiments which include these batch tables, each batch tables associated with particular batch type, as used to store information pertaining to the handling of events for that batch type.
- Work item event monitor 400 incorporates new event monitor 430, which monitors input received from input module 410, and identifies new events.
- Work item event monitor 400 includes queue order module 435.
- Queue order module 435 in some embodiments, arranges events in queuing table 420 for increased efficiency. In other embodiments, queue order module 435 modifies an index file to queuing table 420.
- Work item event monitor 400 also includes event dispatching module 440.
- Event dispatch module 440 accesses queuing table 420, and identifies events to be handled. As shown, event dispatching module 440 incorporates several of timer jobs 441a through 441n. In some embodiments, each batch type has a separate associated timer job 441. In other embodiments, different numbers of timer jobs 441 are utilized.
- Work item event monitor 400 also includes failover guard module 450. Failover guard module 450 monitors queuing table 424 expired failover events.
- FIG. 5 a flowchart 500 of a method of utilization of a work item event monitor is depicted, in accordance with one embodiment.
- steps are exemplary. That is, embodiments of the present invention are well suited to performing various other (additional) steps or variations of the steps recited in flowchart 500. It is appreciated that the steps in flowchart 500 may be performed in an order different than presented, and that not all of the steps in flowchart 500 may be performed.
- a work item event monitor receives a new event.
- front end 210 submits an event to backend 220, which is received by input module 410.
- a new event flag is updated.
- a new event flag corresponds to the type of work item event received. For example, if the event received is of the workflow type, new event monitor 430 would update the flag in the batch table 425 corresponding to the workflow type.
- new event monitor 430 passes the received event queuing table 420.
- the queuing table is ordered based upon batch type. In some embodiments, all events of the same batch type and with the same, or similar, expiration time are grouped together. For example, if work item event monitor 400 receives several events of the workflow type with expiration times in the past, these events will be grouped to be processed together.
- events are selected for processing.
- events are selected from the queuing table based upon job type and expiration time.
- only events which are not currently being processed are selected, e.g., only events not marked as already being processed are selected.
- event dispatching module 440 selects all events, of the workflow type, and which are not already marked as being processed, and which are scheduled to execute now from queuing table 420.
- event selection is triggered by a timer.
- multiple timers are utilized, and a particular event type may have its own timer.
- timer job 441a which is associated with the workflow type, triggers the selection of workflow type events whenever it resets or expires.
- a single timer is utilized.
- event selection is triggered by other methods.
- step 560 the events selected are marked as being processed.
- this step can be implemented in a number of points.
- event dispatching module 440 identifies the selected workflow events in queuing table 420 by marking them with a GUID.
- the selected events are passed to the appropriate event handler.
- the events selected by event dispatching module 440 are passed to output module 490 for processing.
- FIG. 6 a flowchart 600 of a method of failure recovery by utilizing a failover guard is presented, in accordance with one embodiment.
- steps are disclosed in flowchart 600, such steps are exemplary. That is, embodiments of the present invention are well suited to performing various other (additional) steps or variations of the steps recited in flowchart 600. It is appreciated that the steps in flowchart 600 may be performed in an order different than presented, and that not all of the steps in flowchart 600 may be performed.
- a failover event is added to the queuing table.
- the mechanism for adding this event varies in different embodiments.
- a failover event is added whenever a new event is added to the queuing table.
- the failover event is added when a batch of events are selected for processing. For example, when a new event is received by input module 410, passed to new event monitor 430, added to queuing table 420, and a plurality of events are selected for processing in batch table 425, a failover event is added to queuing table 420 [0070] With reference now to step 620 and Figure 4, the failover event is updated.
- the failover event is added to the queuing table with a preset expiration time. If the failover event is allowed to expire, this indicates the system has failed in some way.
- the failover event is updated before it expires, and the expiration time is reset.
- the failover event is updated whenever the queuing table is accessed.
- a failover event is updated when the queuing table is accessed for the event type the failover event is associated with.
- the failover event is updated by a failover event guard, as discussed previously.
- the failover event is deleted.
- the failover event is deleted when the batch related to the failover event has finished processing. In some other embodiments, this occurs when no events remain in the queuing table. For example, when the queuing table 420 is empty except for the failover event, the failover event is deleted. In some embodiments, this is accomplished by the failover guard module 450. In other embodiments, this task is performed by event dispatching module 440. In other embodiments, other means are used to remove the failover event from the queuing table.
- the failover event is removed when no more events of the related event type remain in the queuing table.
- steps 650, 660, and 670 are looped, and run alongside step 620. In other embodiments, the steps may be performed in a different sequence.
- the queuing table is periodically checked for expired failover events.
- failover guard module 450 monitors queuing table 420, checking queuing table 420 for expired failover events and every five minutes. If a failover event is present in the queuing table and has expired, the system knows that events remain in the queuing table, but no successful access of the queuing table has occurred since last the failover event was updated.
- step 660 and Figure 4 if no expired failover events occOT, the present state to queuing table is stored.
- a failover guard module 450 checks queuing table 420 and finds no expired failover events, the current state of queuing table 420 is known to be good, and is stored.
- the state of the queuing table is backed up every time the failover event is successfully updated, e.g., whenever the queuing table is accessed during processing, the failover event is updated, and the present state of the queuing table is backed up.
- step 670 and Figure 4 if an expired failover event is located in the queuing table, the queuing table is returned to the stored state. If, for example, failover guard module 450 detects an expired failover event in queuing table 420, queuing table 420 needs to return to the last stored "good" state, e.g., the last state in which the failover event was updated. In some embodiments, the work item event monitor performs additional actions if an expired failover event is detected.
Abstract
Description
Claims
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200780016111XA CN101438275B (en) | 2006-05-05 | 2007-05-04 | Work item event procession |
KR1020087027144A KR101365840B1 (en) | 2006-05-05 | 2007-05-04 | Work item event procession |
JP2009509756A JP2009536403A (en) | 2006-05-05 | 2007-05-04 | Work item event processing |
EP07794576A EP2021948A4 (en) | 2006-05-05 | 2007-05-04 | Work item event procession |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/418,864 | 2006-05-05 | ||
US11/418,864 US7877757B2 (en) | 2006-05-05 | 2006-05-05 | Work item event monitor for procession of queued events |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2007130621A2 true WO2007130621A2 (en) | 2007-11-15 |
WO2007130621A3 WO2007130621A3 (en) | 2007-12-27 |
Family
ID=38662616
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2007/010918 WO2007130621A2 (en) | 2006-05-05 | 2007-05-04 | Work item event procession |
Country Status (8)
Country | Link |
---|---|
US (1) | US7877757B2 (en) |
EP (1) | EP2021948A4 (en) |
JP (1) | JP2009536403A (en) |
KR (1) | KR101365840B1 (en) |
CN (1) | CN101438275B (en) |
CL (1) | CL2007001254A1 (en) |
TW (1) | TW200821863A (en) |
WO (1) | WO2007130621A2 (en) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8909748B1 (en) | 2006-06-22 | 2014-12-09 | Emc Corporation | Configurable views of context-relevant content |
US8898264B1 (en) | 2006-06-22 | 2014-11-25 | Emc Corporation | Linking business objects and documents |
US8380736B2 (en) * | 2010-05-21 | 2013-02-19 | Microsoft Corporation | De-duplication in billing system |
US8898078B2 (en) | 2010-05-21 | 2014-11-25 | Microsoft Corporation | Scalable billing with de-duplication in aggregator |
US20130290385A1 (en) * | 2012-04-30 | 2013-10-31 | Charles B. Morrey, III | Durably recording events for performing file system operations |
CN107229455B (en) * | 2016-03-24 | 2019-09-17 | 阿里巴巴集团控股有限公司 | A kind of method for processing business, apparatus and system |
KR102224771B1 (en) | 2019-04-24 | 2021-03-08 | 주식회사 티맥스티베로 | Method to manage database failure |
KR102247247B1 (en) * | 2019-06-05 | 2021-05-03 | 주식회사 티맥스티베로 | Method to manage database |
US20230153084A1 (en) * | 2021-11-15 | 2023-05-18 | SymOps, Inc. | System and method for processing events |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6242251A (en) | 1985-08-20 | 1987-02-24 | Matsushita Electric Ind Co Ltd | Event scheduling method |
Family Cites Families (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5634127A (en) | 1994-11-30 | 1997-05-27 | International Business Machines Corporation | Methods and apparatus for implementing a message driven processor in a client-server environment |
US5754857A (en) | 1995-12-08 | 1998-05-19 | Sun Microsystems, Inc. | Distributed asynchronous workflow on the net |
US6212529B1 (en) | 1996-11-13 | 2001-04-03 | Puma Technology, Inc. | Synchronization of databases using filters |
EP0854431A3 (en) | 1997-01-20 | 2001-03-07 | International Business Machines Corporation | Events as activities in process models of workflow management systems |
US5978836A (en) | 1997-07-28 | 1999-11-02 | Solectron Corporation | Workflow systems and methods |
US6320882B1 (en) * | 1997-09-29 | 2001-11-20 | Nortel Networks Limited | Method and apparatus for handling multiple real-time service events |
US6115646A (en) | 1997-12-18 | 2000-09-05 | Nortel Networks Limited | Dynamic and generic process automation system |
US6505228B1 (en) | 1998-07-22 | 2003-01-07 | Cisco Technology, Inc. | Dynamic determination of execution sequence |
US6535905B1 (en) | 1999-04-29 | 2003-03-18 | Intel Corporation | Method and apparatus for thread switching within a multithreaded processor |
US6668281B1 (en) | 1999-06-10 | 2003-12-23 | General Interactive, Inc. | Relationship management system and method using asynchronous electronic messaging |
US6662199B1 (en) | 2000-01-04 | 2003-12-09 | Printcafe Systems, Inc. | Method and apparatus for customized hosted applications |
US20020032692A1 (en) | 2000-09-08 | 2002-03-14 | Atsuhito Suzuki | Workflow management method and workflow management system of controlling workflow process |
GB0029226D0 (en) | 2000-11-30 | 2001-01-17 | Ebbon Dacs Ltd | Improvements relating to information systems |
US7174534B2 (en) | 2001-01-22 | 2007-02-06 | Symbol Technologies, Inc. | Efficient system and method for running and analyzing multi-channel, multi-modal applications |
US7240324B2 (en) | 2001-02-28 | 2007-07-03 | Hewlett-Packard Development Company, L.P. | Event-based scheduling method and system for workflow activities |
US20020138321A1 (en) | 2001-03-20 | 2002-09-26 | Applied Materials, Inc. | Fault tolerant and automated computer software workflow |
EP1402436B1 (en) | 2001-05-12 | 2005-03-02 | International Business Machines Corporation | Signaling events in workflow management systems |
US7454751B2 (en) | 2001-06-07 | 2008-11-18 | Intel Corporation | Fault-tolerant system and methods with trusted message acknowledgement |
WO2003014927A2 (en) | 2001-08-08 | 2003-02-20 | Trivium Systems Inc. | Scalable messaging platform for the integration of business software components |
US8549048B2 (en) | 2001-12-19 | 2013-10-01 | Emc Corporation | Workflow database for scalable storage service |
US8271882B2 (en) | 2002-04-24 | 2012-09-18 | Sap Ag | Processing life and work events |
JP3864251B2 (en) * | 2002-12-06 | 2006-12-27 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Message processing apparatus, message processing method, and message processing program |
US20040162741A1 (en) | 2003-02-07 | 2004-08-19 | David Flaxer | Method and apparatus for product lifecycle management in a distributed environment enabled by dynamic business process composition and execution by rule inference |
US20050022164A1 (en) | 2003-02-25 | 2005-01-27 | Bea Systems, Inc. | Systems and methods utilizing a workflow definition language |
EP1625499A2 (en) * | 2003-05-16 | 2006-02-15 | Sap Ag | Business process management for a message-based exchange infrastructure |
US6985920B2 (en) * | 2003-06-23 | 2006-01-10 | Protego Networks Inc. | Method and system for determining intra-session event correlation across network address translation devices |
EP1711885A4 (en) | 2003-07-11 | 2010-06-09 | Computer Ass Think Inc | System and method for creating and using self describing events in automation |
SE526532C2 (en) | 2003-08-27 | 2005-10-04 | Unirox Wireless Technology Ab | Procedure, server and computer software product for remote management of Web service workflows |
US7409587B2 (en) * | 2004-08-24 | 2008-08-05 | Symantec Operating Corporation | Recovering from storage transaction failures using checkpoints |
US7296008B2 (en) * | 2004-08-24 | 2007-11-13 | Symantec Operating Corporation | Generation and use of a time map for accessing a prior image of a storage device |
CN1318971C (en) * | 2003-11-18 | 2007-05-30 | 神达电脑股份有限公司 | Method of raising data storage device integrated working efficiency under multitask operating environment |
US7779421B2 (en) * | 2005-06-30 | 2010-08-17 | Ebay Inc. | Business event processing |
-
2006
- 2006-05-05 US US11/418,864 patent/US7877757B2/en active Active
-
2007
- 2007-05-01 TW TW096115492A patent/TW200821863A/en unknown
- 2007-05-03 CL CL2007001254A patent/CL2007001254A1/en unknown
- 2007-05-04 CN CN200780016111XA patent/CN101438275B/en active Active
- 2007-05-04 WO PCT/US2007/010918 patent/WO2007130621A2/en active Application Filing
- 2007-05-04 KR KR1020087027144A patent/KR101365840B1/en active IP Right Grant
- 2007-05-04 JP JP2009509756A patent/JP2009536403A/en not_active Withdrawn
- 2007-05-04 EP EP07794576A patent/EP2021948A4/en not_active Withdrawn
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6242251A (en) | 1985-08-20 | 1987-02-24 | Matsushita Electric Ind Co Ltd | Event scheduling method |
Non-Patent Citations (1)
Title |
---|
See also references of EP2021948A4 |
Also Published As
Publication number | Publication date |
---|---|
CN101438275A (en) | 2009-05-20 |
EP2021948A4 (en) | 2009-12-16 |
CN101438275B (en) | 2012-07-04 |
US7877757B2 (en) | 2011-01-25 |
CL2007001254A1 (en) | 2008-01-18 |
EP2021948A2 (en) | 2009-02-11 |
WO2007130621A3 (en) | 2007-12-27 |
KR101365840B1 (en) | 2014-02-21 |
TW200821863A (en) | 2008-05-16 |
US20070261063A1 (en) | 2007-11-08 |
JP2009536403A (en) | 2009-10-08 |
KR20090005367A (en) | 2009-01-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7877757B2 (en) | Work item event monitor for procession of queued events | |
US9787706B1 (en) | Modular architecture for analysis database | |
US8938421B2 (en) | Method and a system for synchronizing data | |
JP5075736B2 (en) | System failure recovery method and system for virtual server | |
US6980988B1 (en) | Method of applying changes to a standby database system | |
US20070255682A1 (en) | Fault tolerant facility for the aggregation of data from multiple processing units | |
US11221785B2 (en) | Managing replication state for deleted objects | |
JP5705871B2 (en) | Resolving locks on distributed persistent instances | |
US20080115128A1 (en) | Method, system and computer program product for implementing shadow queues for recovery of messages | |
JP2003296171A (en) | Electronic business form management method and program | |
US9514176B2 (en) | Database update notification method | |
CN111708755A (en) | Data migration method, device, system, electronic equipment and readable storage medium | |
US20040122871A1 (en) | Fail over resource manager access in a content management system | |
CN116501783A (en) | Distributed database data importing method and system | |
US20210303413A1 (en) | Tagging application resources for snapshot capability-aware discovery | |
CN110647570B (en) | Data processing method and device and electronic equipment | |
US8386503B2 (en) | Method and apparatus for entity removal from a content management solution implementing time-based flagging for certainty in a relational database environment | |
CN101046822A (en) | Centralized management of data nodes | |
US11853229B2 (en) | Method and apparatus for updating cached information, device, and medium | |
JP2013186765A (en) | Batch processing system, progress confirmation device, progress confirmation method and program | |
JP5466740B2 (en) | System failure recovery method and system for virtual server | |
CN113377606A (en) | Platform for automated management and monitoring of in-memory systems | |
CN111464580B (en) | Method and device for selecting main server | |
US8433699B1 (en) | Object identity and addressability | |
US20050108194A1 (en) | System for verifying a state of an environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 5838/CHENP/2008 Country of ref document: IN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 200780016111.X Country of ref document: CN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2009509756 Country of ref document: JP Ref document number: 1020087027144 Country of ref document: KR |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2007794576 Country of ref document: EP |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07794576 Country of ref document: EP Kind code of ref document: A2 |