houhuan
2bc7460f1f
- 添加FastAPI应用基础结构，包括主入口、路由和模型定义
- 实现Webhook接收端点(/webhook/{namespace})和健康检查(/health)
- 添加管理后台路由和模板，支持端点、目标、渠道和模板管理
- 包含SQLite数据库模型定义和初始化逻辑
- 添加日志记录和统计服务
- 包含Dockerfile和配置示例文件
- 添加项目文档，包括设计、流程图和验收标准
51 lines
2.9 KiB
Markdown
51 lines
2.9 KiB
Markdown
# 规则引擎逻辑重构计划：支持多级条件与流程编排
|
||
|
||
您说得非常对。目前的扁平化规则（单层 `if-match-then-action`）在处理“组合条件”时会导致规则数量爆炸，配置极其繁琐且难以维护。
|
||
|
||
**核心问题**：现在的结构是“单层匹配”，无法表达“先判断A，再判断B”的逻辑。
|
||
**您的需求**：
|
||
1. **第一层（事件分类）**：先根据 `event_define_no` 判断业务类型（微信支付/退款/投诉），决定用哪个**模板**。
|
||
2. **第二层（渠道分发）**：再根据 `remark` 判断归属（门店002/003），决定推给哪个**渠道**。
|
||
|
||
为此，我将对系统进行深度的逻辑重构，引入**“规则组（Rule Group）”**和**“条件链（Condition Chain）”**的概念，但为了保持用户界面的直观性，我设计了更符合您直觉的 **“流程树（Flow Tree）”** 方案。
|
||
|
||
## 方案设计：嵌套式规则引擎
|
||
|
||
### 1. 数据模型升级 (DB)
|
||
* **ProcessingRule 表变更**：
|
||
* 新增 `parent_rule_id` (Integer, nullable): 允许规则嵌套。子规则只有在父规则匹配成功后才会执行。
|
||
* 此变更实现了“树状结构”。
|
||
|
||
### 2. 核心逻辑升级 (Engine)
|
||
* **递归匹配**：
|
||
* 引擎首先查找所有 `parent_id` 为空的**根规则**。
|
||
* 如果根规则匹配成功（例如 `event_define_no == pay.wx_scaned`）：
|
||
* 执行根规则挂载的动作（例如：设置模板变量 `pay_method="微信"`）。
|
||
* **继续检查其子规则**。
|
||
* 子规则（例如 `remark == imcgcd03`）匹配成功：
|
||
* 执行子规则挂载的动作（例如：推送到 `渠道003`）。
|
||
* 动作执行时，会**继承**父规则上下文中设置的变量（如模板ID或变量）。
|
||
|
||
### 3. 用户界面重构 (UI)
|
||
* **端点详情页**：
|
||
* 不再是扁平列表，而是**树形展示**。
|
||
* 在每个规则卡片内部，增加“**添加子规则**”按钮。
|
||
* 视觉上通过缩进或连线表示层级关系。
|
||
* 支持**拖拽排序**（优先级调整）。
|
||
|
||
## 实施步骤
|
||
1. **数据库迁移**：为 `ProcessingRule` 添加 `parent_rule_id` 字段。
|
||
2. **后端逻辑**：重写 `engine.py` 的 `process` 方法，改为递归处理。
|
||
3. **前端交互**：重写 `endpoint_detail.html`，使用递归模板渲染规则树。
|
||
4. **无损更新**：编写 SQL 脚本或逻辑，确保现有数据平滑迁移到新结构（现有规则都视为根规则）。
|
||
|
||
这样，您的配置流程将变为：
|
||
1. **根规则**：`event_define_no == pay.wx_scaned`
|
||
* 动作：设置变量 `pay_type="微信"`（**不需要指定渠道**）
|
||
* **子规则 A**：`remark == imcgcd02`
|
||
* 动作：推送到 `渠道002`（**复用父级的模板设置**）
|
||
* **子规则 B**：`remark == imcgcd03`
|
||
* 动作：推送到 `渠道003`
|
||
|
||
这完美符合您的思维模型。
|