Browse Prior Art Database

Live recovery for failed activities of a running Activity Plan

IP.com Disclosure Number: IPCOM000023200D
Original Publication Date: 2004-Mar-29
Included in the Prior Art Database: 2004-Mar-29
Document File: 3 page(s) / 61K

Publishing Venue

IBM

Abstract

The article describes a method to restart single targets in an APM plan while the plan is still running.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 58% of the total text.

Page 1 of 3

Live recovery for failed activities of a running Activity Plan

Restarting single targets on a still running APM plan.

   In this article is described a possible solution to the problem of restarting targets on a still running APM plan.

   Assumption: - Active plan was submitted starting from a plan template - Targets of the plan must be specified through a file and each activity must have the same targets (i.e. The targets are specified at plan level). - The name of this file is specified through a variable.

Here is the description of the scenario:

1) The original plan template was submitted paused.
2) The targets are resumed one by one.
3) If the execution of an activity fails on a target it should be possible to restart the execution of the activity and of the conditioned activities on the failed target while the plan in still running.

Here are the proposed steps to achieve the online-restart scenario:
4) After a specified amount of time, "some entity" (script or human being) checks if there are failed targets in some of the activities of the plan(s).

   5) The script collects all the failed targets until that moment, regardless of the activity that they belongs to, and builds a file containing this list of targets

   6) A new instance of the plan is submitted, starting from the same original plan-template, in paused mode. The previous generated file, specifying the targets, is passed as a variable to the new plan.

   7) A plan-customizer-script access APM DB, to read target status on the original plan, and to reflect this in the new submitted plan, as detailed below:

   - For each activity of the original plan the script checks what targets were completed successfully

   - For each of them, a cancel operation is issued on the new submitted plan for the corresponding activity (eventually the update could be done directly on the DB, but this is subject to further verification). This is necessary because that activity already succeeded on that target and should not be resubmitted again.

   - The new plan, once target-status is customized for all the activities, can then be resumed.

Here is an example that clarifies this scenario. A plan contains 4 activities conditioned by target (ST) as depicted below:

ACT1 ACT2 ACT3 ACT4 _____________________________________

t1 t1 t1 t1 t2 t2 t2 t2 t3 t3 t3 t3 t4 t4 t4 t4 t5 t5 t5 t5

1

Page 2 of 3

The plan is submitted paused and then restarted target by target. Target t1 is restarted first. Everything completed successfully. Then target t2 is restarted. In this case there is a failure. After a while even target t3 is restarted and some other failures occurred. Let's assume that the situation is the following:

ACT1 ACT2 ACT3 ACT4 ________________________________________________________________

t1(SUCC) t1(SUCC) t1(SUCC) t1(SUCC) t2(SUCC) t2(SUCC) t2(FAILED) t2(CANC_CND) t3(FAILED) t3(CANC_COND) t3(CANC_COND) t3(CANC_COND) t4(STARTED) t4(REGISTERED) t4(REGISTERED) t4(REGISTERED) t5(WAITING) t5(WAITING) t5(WAITING) t5(WAIT...