Salesforce

How Do I Use the Magic xpi Recovery Policies? (Magic xpi 3.x)

« Go Back

Information

 
Created ByKnowledge Migration User
Approval Process StatusPublished
Objective
Description

How Do I Use the Magic xpi Recovery Policies? (Magic xpi 3.x)

Magic xpi’s Recovery system lets you recover data lost due to a crash. A crash can be a full system crash or a single thread crash in a running project. You can define the Recovery policy for each flow during project development. You define the Recovery policy in the Flow Properties dialog box. The Recovery policy is invoked if a flow is executed and does not complete its execution normally. In this case, when any of the flow’s branches are still running, the Recovery policy is executed.

Behavior changes from V2.5

The main difference between the behavior in V2.5 and Magic xpi is that the Recovery process was detached from the Timeout behavior and from the error handling. Recovery is only related to full system crashes and thread crashes.

The Recovery Policies

There are four types of Recovery policy, which are explained in the table below.

Option

Description

None

No Recovery policy.

Abort

  • When a system crash occurs, in the next system start, the abort sequence will run.

  • When a thread crash occurs, the entire flow tree is aborted. If there are running steps, the Server will wait for five minutes. If the running steps exceed the time limit, the thread will be terminated and the Abort Process will take place. If the step terminates execution within this limit, the next steps will not be executed and the Abort Process will take place.

Restart

This option carries out the Abort Process and then restarts the flow when a system crash occurs.

Save Point

The Save Point option lets Magic xpi back up information in a flow up to a defined point. You can define more than one Save Point for a flow. When you select this option, Magic xpi recovers the flow from the last Save Point reached in your flow. You can define Save Points at different points (steps) of your flow so that if a system crash occurs, Magic xpi recovers all the data up to the last Save Point reached. When there are multiple branches in a flow (as shown in the figure below), Magic xpi recovers all the save points reached before the system crash.

Multiple Save Points

When you define more than one Save Point in the same linear branch, Magic xpi recovers the flow from the last-reached Save Point. Any previous save points on the branch are overwritten.

The icon indicates a Save Point in a flow.

Note:

  • Magic xpi saves flow recovery data in files located in the Recovery folder, which is located under the project folder.

  • The RecoveryLocation logical name is available in the Ifs.ini file as follows:

    [MAGIC_IBOLT]RecoveryLocation=%currentprojectdir%Recovery%sl%

  • By default, the recovery data is cleared when the Server starts (recovery files are deleted from [MAGIC_IBOLT]RecoveryLocation). To keep these files, click the Advanced tab and make sure that the Recovery information box in the Clear Mode section is not checked.

How the Recovery Policy Works

Flows contain three types of steps:

  • Linear: Linear flows run within the parent flow context or memory segment. Flow variables and context variables are shared between all the flows within the same context.

  • Parallel: Parallel flows run in a different context and have their own copy of the flow variables and context variables. When the flow is terminated, the context is closed and all the flow variables and context variables used by this flow are erased and no longer exist.

  • Stand-alone: A stand-alone step is executed at the same time as another step in the flow (in the same way as a Parallel step); however, it is executed independently of the flow.

Magic xpi carries out the flow’s Recovery policy in all of the above cases.

Recovery Scenarios

Although it doesn’t matter what type of step is executed for Magic xpi to execute the flow’s Recovery policy, there are different Recovery scenarios that depend on the Recovery policy defined for the flow.

The tables below describe the scenario for each policy.

Abort

Scenario

Behavior at restart

Simple linear flow

Abort Process is executed

Parallel thread

Abort Process is executed

Stand-alone thread

Abort Process is executed

In general, the following actions take place during the Abort Process:

  • Execute Cleanup Recovery Flow

  • Clear the saved Recovery data

  • Delete Local ODS records

  • Delete Lock and Unlock definitions

Restart

Scenario

Behavior at restart

Simple linear flow

Abort Process and Flow Restart are executed

Parallel thread

Abort Process and Flow Restart are executed

Stand-alone thread

Stand-alone thread is restarted as separate thread

Save Point

Scenario

Behavior at restart

Simple linear flow

Recovers from last Save Point

Parallel thread

Recovers from the last Save Point in the branch

Stand-alone thread

Recovers from the last Save Point in the branch

Notes:

  • If the Recovery policy is Save Point but there are no defined Save Points on the flow, the executed Recovery policy will be Restart.

  • The flow is recovered from the last Save Point in the main flow. The Save Points of child flows are not used for recovery.

Example

The following are instructions for creating a flow that illustrates the different Recovery policies in Magic xpi.

  1. Go to your topology. Select the Server, right-click, and choose Properties to open the Magic xpi Server Properties dialog box.

  2. Click the Advanced tab and make sure that the Recovery information box in the Clear Mode section is not checked. Click OK.

  3. Go to a flow in the topology and drag a Directory Scanner component as the first step in your flow.

  4. Click Configuration to open the Component Configuration dialog box. For the Interface property, select Method and then click OK.

  5. In the Direct Access Methods dialog box, select the Lan to Lan method. Configure the method so that the User BLOB holds the file content. Click OK and return to your flow.

  6. Define a flow variable of BLOB type.

  7. Drag a Flow Data service to your flow. Update the flow variable you defined in step 5 with the User BLOB’s value.

  8. Now drag a Delay service to your flow. Define a delay of two minutes.

  9. Drag a Save Message service to your flow that will show the flow variable’s value.

  10. Save and then run the project.

Abort Policy Scenario

  1. In the Flow Properties dialog box, select Abort as your Recovery policy.

  2. Stop the Server once the Delay step is reached in the flow. When you restart the Server, a message is shown in the Monitor saying that the flow was aborted and the process has been terminated.

Restart Policy Scenario

  1. In the Flow Properties dialog box, select Restart as your Recovery policy.

  2. Save and then run the project.

  3. Restart the Server once the Delay step is reached in the flow. You will see that you now have two flows running: one is the Recovery flow and the other is due to the auto start.

You will also see that in the Recovery flow, the message in the Monitor does not hold the file content.

Save Point Policy Scenario

  1. In the Flow Properties dialog box, select Save Point as your Recovery policy.

  2. Define the Flow Data service as a Save Point.

  3. Save and run the project.

  4. Restart the Server once the Delay step is reached in the flow. There are now two flows running: one is the Recovery flow, and the other is created as a result of the auto start.

You will also see that in the Recovery flow, the message in the Monitor holds the file content.

Recovery Policy for a Called Flow

When a flow is invoked by another flow using the Invoke Flow service, the called flow is considered to be a single step in the first flow. Therefore, the called flow has no Recovery policy of its own.

The figure below shows an example flow that describes how this works:

The above flow on the left is called Scan New Order. It has the following attributes:

  • The flow’s Recovery policy is Save Point.

  • The Save Point is defined in the Email New Order step (Step 3).

  • The Call Process Order step (Step 4) calls a new flow. This flow is regarded as one step, no matter how many steps it includes.


Recovery Policy

The called flow is invoked by the Scan New Order flow. Because of this, it does not have a Recovery policy of its own. If a system crash occurs at any point in the called flow, it is as if the crash occurred during the Call Process Order step (Step 4) in the calling flow.

In this case, the defined Recovery policy for the main flow is executed. The Recovery policy for this flow is Save Point, so the Magic xpi Server looks for the most recent Save Point, which is the Email New Order step (Step 3). Based on the flow’s Recovery policy, Magic xpi will run the flow from that point.

Note:

Both the calling flow and the called flow execute the Abort Process above. Only after both flows execute the process, is the defined Recovery policy executed.

Reference
Attachment 
Attachment