关于规则引擎执行中断恢复

某些场景下需要规则引擎执行实例中断后恢复，例如：

• 工作流审批场景： 在需要人工审批的工作流程中，规则引擎的执行可能需要暂停，直到获得必要的批准。
• 第三方系统异步回调： 在依赖外部系统响应的场景中，规则引擎可能需要等待第三方系统的回调来继续执行。
• 依赖服务不可用： 当规则引擎的执行依赖于外部服务（如数据库、消息队列等），而这些服务暂时不可用时，规则引擎的执行将被中断。

以上要求规则引擎中断恢复场景，又不想引入工作流，RuleGo是一个不错的轻量级方案。RuleGo提供无状态的接口， 支持规则引擎执行中断恢复，即当规则引擎执行中断时，可以恢复到中断前的状态。

以下是具体步骤：

1. 通过规则引擎上下文ctx.DoOnEnd让本次执行实例中断，自定义节点处理或者Functions节点都可以操作上下文。

func OnMsg(ctx types.RuleContext, msg types.RuleMsg)
//处理逻辑
//让本次执行实例执行中断，不执行后续节点，并把当前节点数据通知`OnEnd`回调函数
ctx.DoOnEnd(msg RuleMsg, err error, relationType string)
}

2. 注册规则引擎执行结束回调函数持久化msg以及相关状态（如果需要）：WithOnEnd。

ruleEngine.OnMsg(msg, types.WithOnEnd(func(ctx types.RuleContext, msg types.RuleMsg, err error, relationType string) {
  //持久化当前中断节点数据
  //ctx.GetSelfId() 当前节点ID，用于恢复
  //msg.Id本次执行实例消息ID
  //msg.Data本次执行实例消息数据
  //msg.Type本次执行实例消息类型
  //msg.Metadata本次执行实例消息元数据
  //err.Error()本次执行实例错误信息
  //relationType查找下一个节点的关系
}))

3. 恢复执行，提供上次中断保存的msg、中断节点ID，以及指定relationType查询下一个节点恢复执行。

方式一：使用WithTellNext（简单恢复） 适用于从单个节点恢复，并查找下一个节点继续执行。

// 从 fromNodeId 节点开始，查找 relationTypes 关系的子节点继续执行
ruleEngine.OnMsg(msg, types.WithTellNext(fromNodeId, relationTypes...))

方式二：使用WithStartNode（指定开始节点） 适用于直接指定一个或多个节点开始执行。

// 直接执行 nodeIds 指定的节点
ruleEngine.OnMsg(msg, types.WithStartNode(nodeId1, nodeId2))

方式三：使用WithRestoreNodes（高级恢复） 适用于复杂场景，例如并行网关（Fork）的多个分支同时恢复，或者每个分支需要使用不同的消息上下文。

// 场景1：恢复多个分支，使用相同的消息
ruleEngine.OnMsg(msg, types.WithRestoreNodes(
    types.ExecuteNode("nodeId1"), // 恢复节点1
    types.ExecuteNode("nodeId2"), // 恢复节点2
))

// 场景2：恢复多个分支，每个分支使用独立的消息（例如保存了不同的中间状态）
ruleEngine.OnMsg(defaultMsg, types.WithRestoreNodes(
    types.ExecuteNodeWithMsg("nodeId1", msg1), // 节点1使用msg1
    types.ExecuteNodeWithMsg("nodeId2", msg2), // 节点2使用msg2
))

// 场景3：恢复并查找下一个节点
ruleEngine.OnMsg(msg, types.WithRestoreNodes(
    types.ExecuteNext("nodeId1", "Success"), // 执行nodeId1的Success关系的子节点
))