将Activiti任务从旧流程迁移到新流程 [英] Migrating Activiti tasks from old process to new process
问题描述
我有一个用于某些业务流程的Activiti项目。
I have an Activiti project for some business process.
问题与迁移有关。现有流程有一些未完成的任务。我想通过添加新步骤来修改现有流程。
The problem is about migration. An existing process has some unfinished tasks. I want to modify the existing process by adding a new step.
现在，当我创建一个新任务时，将根据更新后的过程来处理此新任务。未完成的任务将按照旧流程进行处理。
Now, when I create a new task, this new task will be processed according to the updated process. And unfinished tasks will be processed according to the old process.
让我们以以下示例为例： https://spring.io/blog/2015/03/08/getting-started-with-activiti-and- spring-boot
Let's take the following example: https://spring.io/blog/2015/03/08/getting-started-with-activiti-and-spring-boot
在此示例中，考虑以下行：
In this example, consider the following line:
taskVariables.put("telephoneInterviewOutcome", true);
假设我有一些业务逻辑代码，在其中检查该变量的值，例如：
Assume that, I have some business logic code where I check the value of this variable such as:
if (taskVariables.get("telephoneInterviewOutcome") == true) {...}
现在假设，我想将此变量从Boolean修改为Enum。现在，我还需要更新我的业务逻辑：
Now assume that, I want to modify this variable from Boolean to Enum. Now, I need to update my business logic as well:
if (taskVariables.get("telephoneInterviewOutcome") == SOMEENUM) {...}
现在，我的业务逻辑代码需要根据手头任务的过程。如果任务属于流程的版本1，则我将使用第一个语句，否则使用第二个语句：
Now, my business logic code needs to be branched according to the version of the process of the task at hand. If the task belongs to version 1 of the process, then I will use the first statement, else the second one like that:
if (getProcessVersion(task) == 1) {
if (taskVariables.get("telephoneInterviewOutcome") == true) {...}
} else {
if (taskVariables.get("telephoneInterviewOutcome") == SOMEENUM) {...}
}
问题这种方法的优点是，业务逻辑代码将随着流程的更新而增长。这将在生产过程中导致许多错误。
The problem with this approach is that the business logic code will grow as the processes are updated. This will cause lots of bugs during production.
这个问题还有其他解决方法吗？如何在不更改业务逻辑代码的情况下解决此问题？
Is there any other solution to this problem? How can I solve this problem without changing business logic code?
推荐答案
您所描述的是任何流程的关键难题之一长期运行的实现。我实施的许多流程的使用时间都超过了12个月，因此您始终必须考虑流程模型的演变。
What you describe is one of the key pain points of any Process Implementation that is long running. Many processes I have implemented live in excess of 12 months, so you always have to consider the process model evolution.
Philippe提出了一些降低风险的好技术，但即使将业务逻辑从集成中分离出来并将决策点外部化到规则引擎并不总是能让您到达需要的地方。
Philippe raised some good techniques to reduce the risk, but even separating business logic from integrations and externalizing decision points to a rules engine doesn't always get you where you need to be.
您是添加任务和更改的示例变量的类型是经典情况，在这种情况下，如果您不分支，在新的流程模型中，我们喜欢称之为运行中的流程将完全失败。
You're example of adding a task and changing the type of a variable are classic cases where what we like to call "in flight" processes will simply fail in the new process model if you don't branch.
其他典型的例子是无法初始化新流程需要的变量，以及无法在飞行中成功添加决策逻辑。
Other classic examples are failure to initialize a variable that the new process needs and addition of decision logic that can never succeed for the in flight processes.
通常，有几种方法处理流程演变：
In general there are a few ways to handle process evolution:
-
让旧流程完成其原始流程并在新流程上启动新流程。显然，这仅在某些情况下有效，但这是最简单的方法。运行时间很长的进程往往不会落入这个桶中。
Let old processes finish their original flow and start new processes on the new flow. Obviously this only works for some cases, but is the simplest approach. Very long running processes tend to not fall in this bucket.
将所有数据外部化到一个外部记录系统，并最小化该进程本身中保存的数据（保留引用，而不保留数据本身）。这是Phillipe提出的观点的延伸。遵循此最佳实践意味着您的流程逻辑并没有紧密地绑定到数据，而是仅绑定到影响流程流程的决策。外部化用于制定这些决策的规则，决策和服务，您可以自由地修改流程逻辑，而对运行中的流程影响较小。
Externalize all data to an external system of records and minimize data that is held within the process itself (keep references, not the data itself). This is an extension on the points Phillipe makes. Following this best practice means that your process logic is not as tightly bound to the data, instead it is bound simply to the decisions that influence the flow of the process. Externalize the rules and decisions and services called to make these decisions and you are much more free to modify process logic with less impact on in-flight processes.
添加将业务逻辑纳入流程中以专门处理机上。这是您在问题中引用的方法。这是可行的，但正如您所说的，可能会成为维护的噩梦。
Add business logic into the process to specifically handle in-flights. This is the approach you cite in your question. It is viable, but as you say, can become a maintenance nightmare.
在被调用的子流程中使用 a来定义安全区域或里程碑。定义明确的界面。这样，您可以以受控方式更改流程的各个部分。显然，对于要替换的段中具有令牌的实例，该怎么办？如果要为此部分部署新模块，则需要随着时间流逝释放这些实例，或者提前计划并阻止进程进入子进程。
Define "safe zones" or milestones in your process by using called sub processes with a well defined interface. This way you can change out segments of a process in a controlled manner. Obviously what happens to instances that have tokens inside a segment to be replaced? You need to either bleed these instances out over time or plan ahead and stop processes from entering a sub process if a new module for this segment is about to be deployed.
然后是以上所有内容的组合（这是现实生活中经常发生的情况）。
And then there are combinations of all of the above (which is what tends to happen in real life).
不容易解决方案，尽管某些BPMS系统具有可帮助识别潜在升级问题的工具，但仍然取决于良好的体系结构，计划和测试。
No easy solution, although some BPMS Systems have tooling that helps identify potential upgrade issues, but still it comes down to good architecture, planning and testing.
这篇关于将Activiti任务从旧流程迁移到新流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
