Process Instance Migration Proposal Long running process may have an extended lifecycle that, in such a period, inevitably process definition tweaks will be required for reasons that might be related to business needs or even bug fixes. For that it's important to offer users a mechanism to move their active running instances from one version to the next
The routing problem will be achieved by the transport tier and signal manager and it is not within the scope of this proposal. (How to signal a specific container which contains the process instance or how the signal reaches its destination within the container). This document describes the process called migration for moving one process version to another in a native cloud environment. Constraints This section enumerates which are the restrictions we have: 1. Deployments: We do not have servers anymore. We are working with immutable images. We need to get rid of the idea of deployment 1. Avoid use of multiple versions in the same image. Having the definitions of the old processes should not be needed anymore. 1. Avoid in memory processing migration. This ends up being very slow and really hard to optimize. Architecture The solution proposed relies on 3 different base concepts: - Process Instance Migration Plan File (MP): a file containing source and target process definitions and its versions plus a node mapping between sources and targets. - Process Instance Migration Subsystem (PIM): component that takes a MP and process state as inputs migrate to outputs. As any other subsystem will throw an event. - Process Instance Marshalling Decorator: An instrumentation approach happening during unmarshalling of the process that can modify the process instance state. The dependency structure will look like this: [image: image.png] The interaction will work like this: [image: image.png] This leads to two things: 1. Get rid of in memory bulk process instance migration. It will be done effectively during next operation and eventually being consistent. (we do it during unmarshalling using a process marshaller extension point) 1. Get rid of all the process definitions involved in the migration in the same container (we have the migration plan) There are some requirements to achieve this. 1. We need to supply a migration plan with information known by the user, otherwise it won’t be possible to build the file. 1. Process marshaller decorator should be really fast. (We need to remove any computational work during unmarshalling) (just replacing UUID should be enough. Code assessment This section describes what are the problems found in the current based code does not allow to make this happen. If we revisit the current Migration Manager in v7 the main problem is that the system requires some computation because it needs to convert the internal identifiers of any workflow element and then replace to the new ones. This internal representation enforces two things: - the deployment of the old process definition as a container in v7, as we need to match the id and then move one to the other. The internal representation depends on an algorithm of how workflow is being parsed and processed. - Requires the computation step to make lookups through the process definitions and compute them to the new ones. Removing the internal representation of the node and node instance will cause: - No computation required: There won’t be any need for this step. The computation step would be replaced entirely by the migration plan (as it will be self-contained and not split by migration plan and internal representation). - No old process definition required. This does not require anymore as it is being replaced as well by the migration plan and algorithm.
