Method and apparatus for handling edge-cases of event-driven disposition

• US 8,515,924 B2
• Filed: 06/30/2008
• Issued: 08/20/2013
• Est. Priority Date: 06/30/2008
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation, ServiceNow Incorporated
• Original Assignee: International Business Machines Corporation
• Inventors: Paknad, Deidre, Raynaud-Richard, Pierre, Pogodin, Andrey
• Primary Examiner(s): BURKE, JEFF A
• Application Number:
  US12/165,085
• Publication Number:
  US 20090327375A1
• Time in Patent Office: 1,877 Days
• Field of Search: 707/694
• US Class Current: 707/694
• CPC Class Codes: G06F 16/125 characterised by the use of retention policies retention policies for HSM systems G06F16/185

Abstract

Retention of data is managed and data holds are enforced. At least one event consumer data source contains data that is subject to a retention schedule that defines rules for the disposition of the data. An enterprise retention management (ERM) application accepts at least one hold request that defines at least a portion of the data that must be held from disposition. A disposition request is also accepted by the ERM that comprises an instruction to dispose of at least a portion of the data based on the rules within the retention schedule. The disposition request is filtered to dispose of the portion of data identified in the disposition request minus the held data, which comprises disposition survivor data. An event-driven disposition mechanism disposes of the disposition survivor data as soon as possible after the disposition survivor data is released from hold or unlocked.

Claims

1. A computer implemented method for managing retention of data and for enforcing data holds, comprising the steps of:

providing at least one event consumer data source containing data, wherein the data is subject to a retention schedule defining rules for the disposition of the data;

providing an enterprise retention management (ERM) application, wherein the at least one event consumer is coupled with the ERM;

accepting at least one hold request in the ERM, wherein the hold request defines at least a portion of the data that must be held from disposition, forming held data;

accepting a disposition request in the ERM, wherein the disposition request comprises an instruction to dispose of at least a portion of the data based on the rules within the retention schedule;

filtering the disposition request, without the need for approval from an operator, forming a filtered request comprising an instruction to dispose of a portion of data comprising the portion of data identified in the disposition request minus the held data, said held data comprising disposition survivor data;

executing the filtered request; and

providing an event-driven disposition mechanism for disposing of said disposition survivor data in an immediately subsequent disposition cycle after said disposition survivor data is released from hold or unlocked, wherein the step of providing an event-driven disposition mechanism further comprises;

providing a file system connector that is responsible for putting files on hold and storing a list of files on hold in a connector database;

once said connector receives a disposition request, said connector attempting to delete all files matching said disposition request criteria, unless said files are identified as being on hold in said connector database;

wherein if a file on hold is identified during said disposition request, said connector persisting a current disposition request into said database and periodically trying to re-execute said request until there are no files matching the request criteria that remain on hold;

thereafter deleting said request from said connector database; and

informing said disposition mechanism logic whether an event consumer is disposition survivor-safe or unsafe in response to a configuration service request, said response to said configuration service request comprising any or all of the following parameters;

a consumer disposition survivor-safe (disposition survivor-unsafe) flag that is set to indicate whether the consumer is disposition survivor-safe or unsafe;

a reminder frequency (reminder period) parameter that is set to indicate how often a reminder should be sent to the event consumer; and

a maximum disposition transaction lifespan parameter that is set to indicate for how long the ERM should remind the event consumer about disposition and/or for how long a disposition survivor-safe event consumer attempts to get rid of disposition survivors.

2. The method of claim 1, said event consumer comprising a disposition survivor-safe consumer, wherein said event consumer can dispose of disposition survivor data without external help.

3. The method of claim 2, further comprising the steps of:

implementing a disposition survivor-safe connector on top of a data source that prevents said connector from deleting a document, even if said connector does not know that said document is on hold, said data source comprising a data source database;

said connector persisting a current disposition request into said connector database and periodically trying to re-execute said request until there are no files matching the request criteria that remain on hold is said data source database; and

thereafter deleting said request from said connector database.

4. The method of claim 1, said event consumer comprising a disposition survivor-unsafe consumer that cannot dispose of disposition survivors.

5. The method of claim 4, wherein disposition survivor-unsafe event consumers cannot manually initiate additional attempts to dispose of disposition survivors.

6. The method of claim 1, said event consumer comprising a retention-capable survivor that can enforce retention schedules and that only requires a disposition triggering event to effect disposition.

7. The method of claim 6, wherein for retention-capable consumers said ERM starts sending reminders after an estimated time of first disposition attempt.

8. The method of claim 6, wherein for retention-capable consumers said ERM sends a scheduled disposition request immediately after it receives an event.

9. The method of claim 1, said event consumer comprising a simple consumer that cannot enforce retention schedules and that requires immediate disposition requests to be dispatched to it at the time of disposition.

10. The method of claim 9, wherein for simple event consumers reminders are sent periodically after initial disposition request has been issued.

11. The method of claim 1, said disposition mechanism implementing the step of:

in response to a reminder, said consumer re-executing a disposition attempt, and disposing of disposition survivors that were released from hold since an initial disposition request of a last disposition reminder.

12. The method of claim 1, wherein said ERM overwrites and/or resets default values provided by said configuration service.

13. The method of claim 1, wherein said configuration service comprises a user interface and/or configuration files.

14. The method of claim 1, said disposition mechanism implementing the steps of:

said ERM calculating a time when an event consumer should have started an initial disposition attempt if it acts according to a retention schedule;

said ERM waiting for a reminder frequency period; and

thereafter said ERM issuing a reminder.

15. The method of claim 14, wherein a disposition reminder request has the same format as an immediate disposition request;

and wherein said disposition reminder request contain information necessary to perform a disposition attempt.

16. The method of claim 1, further comprising the step of:

handling changing triggering event types in retention schedules;

wherein if an event type changes in a retention schedule, said ERM performs any of the following;

stops sending disposition reminders to disposition survivor-unsafe event consumers;

sends a new retention schedule to retention-capable consumers; and

notifies an ERM administrator that an event type coming from an event producer may not longer match a retention schedule associated with a route.

17. The method of claim 1, further comprising the step of:

handling changing disposition periods in retention schedules for simple consumers once an event is inside the ERM, but has not yet been propagated to an event consumer by;

calculating a new time if an immediate disposition request is presented;

if a newly calculated time is in future, doing nothing; and

issuing an immediate disposition request immediately if a newly calculated time happened in the past.

18. The method of claim 17, further comprising the step of:

said ERM periodically checking whether an event is ready to be forwarded to an event consumer by comparing a current date time with a date time calculated based on an event occurrence date and retention rules;

wherein said ERM may change retention rules without the need to recalculate anything in event tables.

19. The method of claim 17, further comprising the step of:

said ERM calculating a disposition time upfront, and recalculating said disposition time each time a retention schedule has changed for a disposition transaction that refer to said retention schedule.

20. The method of claim 1, further comprising the step of:

handling changing disposition periods in retention schedules after an immediate disposition request has been sent to a simple consumer, wherein if a new disposition time is in future, the ERM refrains from sending reminders until a new disposition time comes; and

wherein if a new disposition time is in the past, the ERM continues sending reminders.

21. The method of claim 1, said event consumer further comprising a simple disposition survivor-safe consumer;

wherein in response to a configuration service request, said disposition survivor-safe consumer specifies a maximum disposition transaction lifespan, which comprises a maximum period after which said disposition survivor-safe consumer stops attempting to dispose of remaining disposition survivors;

wherein if said period is not specified, it can be treated by the ERM as infinity, or the ERM imposes its own maximum disposition transaction lifespan for the disposition survivor-safe consumer;

wherein once a retention time in a retention schedule is changed, and the new time happens to be in future, the ERM identifies all disposition transactions where disposition survivor-safe consumers are involved and for which a maximum disposition transaction lifespan is in the future and an immediate disposition request has already been sent;

wherein disposition survivor-safe consumers involved in such transactions receive a stop disposition message from the ERM, which contains identifiers of disposition transactions that must be stopped;

wherein when a new disposition time is due for each of these transactions, the ERM re-issues an immediate disposition request;

wherein once a retention time in a retention schedule is changed, and a new time happens to be in past, the ERM identifies all the disposition transactions affected by this retention schedule; and

wherein if no immediate disposition request has been issued within this transaction yet, the ERM issues such a request.

22. The method of claim 1, further comprising the step of:

handling changing disposition periods in retention schedules after an immediate disposition request has been sent to a retention-capable consumer.

23. The method of claim 1, further comprising the steps of:

providing a retention-capable disposition survivor-safe consumer that can store and understand retention schedules and manage the disposition of disposition survivors;

wherein, when the retention period changes, the ERM propagates a new retention schedule to said retention-capable disposition survivor-safe consumer if the retention-capable disposition survivor-safe consumer is involved in any disposition transaction whose start time plus maximum disposition transaction lifespan is in the future, wherein the propagation of a new retention schedule is assigned an increased execution priority; and

the retention-capable disposition survivor-safe consumer is expected to act accordingly.

24. The method of claim 1, further comprising the step of:

providing a retention-capable disposition survivor-unsafe consumer, wherein when a retention period has changed and the retention-capable disposition survivor-unsafe consumer involved in any disposition transaction whose start time plus maximum disposition transaction lifespan is in the future, the ERM;

sends a new retention schedule to the retention-capable disposition survivor-unsafe consumer and expects the retention-capable disposition survivor-unsafe consumer to start its initial disposition attempts according to the new schedule;

calculates a disposition time according to the new schedule;

if a new estimated time of first disposition attempt plus reminder frequency period is still in future, refrains from sending reminders; and

otherwise, the ERM starts sending reminders.

25. The method of claim 1, further comprising the step of:

the ERM either propagating only events that entered the ERM after a route has been established, and/or the ERM also propagating old events to a newly established route.

26. The method of claim 25, further comprising the step of:

dynamically configuring ERM behavior on an application level and applying all routes created afterwards, or deciding ERM behavior during route setup by offering a user to propagate old events and allowing said user to choose particular events that must be propagated.

27. An apparatus for managing retention of data and for enforcing data holds, comprising:

at least one event consumer data source containing data, wherein the data is subject to a retention schedule defining rules for the disposition of the data;

an enterprise retention management (ERM) application, wherein the at least one event consumer is coupled with the ERM;

at least one connector comprising an interface between Said ERM and said at least one event consumer, wherein said at least one connector comprises a plurality of processing modules for performing operations on said data sources, said at least one connector further comprising;

a module for accepting at least one hold request in the ERM, wherein the hold request defines at least a portion of the data that must be held from disposition, forming held data;

a module for accepting a disposition request in the ERM, wherein the disposition request comprises an instruction to dispose of at least a portion of the data based on the rules within the retention schedule;

a module for filtering the disposition request, forming a filtered request comprising an instruction to dispose of a portion of data comprising the portion of data identified in the disposition request minus the held data, said held data comprising disposition survivor data;

a module for executing the filtered request;

an event-driven disposition mechanism for disposing of said disposition survivor data in an immediately subsequent disposition cycle after said disposition survivor data is released from hold or unlocked; and

a module for informing said disposition mechanism logic whether an event consumer is disposition survivor-safe or unsafe in response to a configuration service request, said response to said configuration service request comprising any or all of the following parameters;

a consumer disposition survivor-safe (disposition survivor-unsafe) flag that is set to indicate whether the consumer is disposition survivor-safe or unsafe;

a reminder frequency (reminder period) parameter that is set to indicate how often a reminder should be sent to the event consumer; and

a maximum disposition transaction lifespan parameter that is set to indicate for how long the ERM should remind the event consumer about disposition and/or for how long a disposition survivor-safe event consumer attempts to get rid of disposition survivors.