Restartable processes refer to business models that are designed in such a way that they can be restarted at any point of their execution without losing or corrupting any data or the model instance status after restart: when restarted, such model instances skip through the activities that were already performed until they reach the status from before the restart. To design such models, you need to make sure that the models rely only on persisted data; the model instance itself must not at any point rely on any data that gets lost when it finishes.

For example, if you interrupt an order-dispatch process at a moment when the order is ready for dispatch, on the restart of the model instance, the process omits the invoicing and payment activities based on the order status and proceeds directly to the dispatch activity.

This design pattern is especially useful when you want to be able to update the underlying models or application. With restartable models you simply

finish the running model instances;
upload the new version of the model;
start up the model instances again.

In the sections below you will learn how to:

Design models that rely on the status for their execution station on persisted business data.
Design an orchestrating model, that will start model instances over the business data anew. It will follow the start of the model instances so you can check if the starting finished successfully.

Designing a Restartable Process

We start from a simple flow that runs over a piece of business data stored in the process variable. The flow has two User activities which signal that the status of the business data changes or is about to change.

In the todo generated by the User activities the user simply submits their Todo.

At this point, the status of the business data is updated to a new status in the User Task assignment. Like this, the status is preserved, even if the model instance is terminated.

Assignment in the User Task that sets the status of the order variable when the user submits the todo

Therefore to make a model instance restartable, change your model as follows:

Persist all data relevant to the flow logic: Store it in Shared Records or their fields.

In the example, we must change the type of the order process variable from a common record to a shared record: every model instance runs for a particular order. The status of the order process is determined by the status field of the order variable.
Adapt the way you acquire the business data so that the process gets the correct data when started.

In the example, this means to initialize the order process variable to one of the following:
- new Order shared record: no business data exists yet; the order is just being placed.
- existing order: the model instance runs over an existing order; the order is passed as a parameter to the model instance.
  
  Initialization of the order process variable
Design the mechanism that skips over to the latest possible flow element when the persisted business data has some value, in the example, the order status value decides whether the default flow or the condition flow of the gateway is taken to the next User Task:
1. Add an exclusive gateway before any element that changes the status of your business data.
2. Define the flow that enters the element as default.
3. Design another flow that will go around the element.
4. Add the required condition on the non-default flow of the gateway.
  
  Restartable mechanism built around a simple flow
Define the orchestrating model which will run a model instance of the order process over each Order instance.

Process that runs a model instance over each order record
Insert the mechanism that will monitor that the starting of the order model instances and the orchestrating model instance succeeded:
1. In the orchestrating process, call watchStarting() on the started model instances. This will activate the monitoring of its start.
```
foreach Order o in findAll(Order) do
  def ModelInstance i := createModelInstance(true, getModel("simpleRestartableProcess"), o, null);
  watchStarting(i);
end
```
2. Add the clearApplicationRestartData() call before the createModelInstance() calls: this will remove the data about the previous model-instance starting.
3. Call watchStarting(thisModelInstance()) after the clearApplicationRestartData() call on the orchestrating model as well; like this you can check if the starting of this instance was successful. Call the function from, for example, the Start assignment of the process. The location of the call does not really matter, however, it must be called from within the first transaction of the model.
  
  Orchestarting process with the start-watching calls on the Start Event

This is a very simple process and in more complex processes, the designing of the skipping might become tedious if not impossible. Consider extracting the skippable elements that change the status of your data to separate processes and create a process that will call them in Reusable Subprocess activities. For a full example, refer to the agile pattern.

To test the model:

Run a few instances of the business model and submit some of the todos to produce some testing data.
Finish all running model instances.
Run the orchestrating model instances.
In Management Console or Management perspective, go to Application Restart and inspect the start monitoring data.