Merge remote-tracking branch 'ztcloud/test' into dev

docs/iWork集成说明.md

@@ -1,6 +1,6 @@
 # iWork 统一集成使用说明
 
-本文档介绍如何在 System 模块中使用项目已实现的统一 iWork 流程发起能力（controller + service + properties）。内容包含：配置项、调用方式（内部 Java 调用 & 外部 HTTP 调用）、请求/响应示例、错误处理、缓存与 Token 生命周期、典型问题与排查步骤。
+本文档介绍如何在 System 模块中使用项目已实现的统一 iWork 流程发起能力（controller + service + properties）。内容包含：配置项、调用方式（内部 Java 调用 & 外部 HTTP 调用）、请求/响应示例、错误处理、缓存与 Token 生命周期、业务回调分发与重试、流程日志查询，以及典型问题与排查步骤。
 
 ---
 
@@ -12,7 +12,10 @@
 - 提供 Service 层 `IWorkIntegrationService`，供其它模块以 Spring Bean 注入方式直接调用。
 - 使用 `IWorkProperties` 绑定 `application.yml` 中 `iwork` 的配置项。
 - Token / 会话采用本地 Caffeine 缓存缓存（按 appId + operatorUserId 缓存 session），并在到期前按配置提前刷新。
-- 使用统一配置的 appId、公钥以及默认流程编号，无需再维护多套凭证。
+- 使用统一配置的 appId、公钥以及默认流程编号，无需再维护多套凭证，所有调用强制使用配置的 appId，不再接受请求覆盖。
+- 全链路以 requestId 作为唯一业务标识（发起返回、作废入参、日志查询、回调与重试均基于 requestId），workflowId 仅用于指定 iWork 模板。
+- 支持业务回调标识 bizCallbackKey（字符串，≤255），发起时提交，回调时按标识分发业务回调并带自动重试与手工重试入口。
+- 回调与日志记录会保存截断后的原始回调请求/响应文本（无需脱敏），无业务附件或处理异常时标记失败。
 
 ---
 
@@ -47,6 +50,10 @@ iwork:
   token:
     ttl-seconds: 3600               # token 有效期（秒）
     refresh-ahead-seconds: 60       # 在到期前多少秒认为需要刷新
+  callback:
+    retry:
+      max-attempts: 3               # 业务回调自动重试次数（默认 3 次，可调整）
+      delay-seconds: 5              # 业务回调自动重试间隔秒数（默认 5 秒，可调整）
   client:
     connect-timeout: 5s
     response-timeout: 30s
@@ -55,10 +62,11 @@ iwork:
 说明：
 
 - `base-url` 为 iWork 网关的基础地址，不能留空。
-- `app-id` 与 `client-public-key` 共同构成注册/申请 token 所需的凭据信息，由配置统一提供，不再支持多套切换。
-- `workflow-id` 提供全局默认流程编号，单次调用也可通过 `workflowId` 覆盖。
+- `app-id` 与 `client-public-key` 共同构成注册/申请 token 所需的凭据信息，由配置统一提供，不再支持多套切换，系统强制使用配置的 appId，忽略请求中的 appId。
+- `workflow-id` 提供全局默认流程编号，仅用于向 iWork 指定流程模板；流程标识、查询、补偿、回调与重试一律使用 requestId，不再以 workflowId 标识业务。
 - 请求头键名固定为 `app-id`、`client-public-key`、`secret`、`token`、`time`、`user-id`，无需在配置中重复声明。
 - `org.*` 配置负责 iWork 人力组织 REST 代理：`token-seed` 为与 iWork 约定的标识，系统会自动将其与毫秒时间戳拼接并计算 MD5 生成 `key`，无需额外传递 token。
+- `callback.retry.*` 控制业务回调的自动重试次数与间隔，默认为 3 次、5 秒，可按需调整。
 
 ---
 
@@ -102,7 +110,7 @@ Controller 暴露的 REST 接口：
 ## 请求 VO 说明（重要字段）
 
 - IWorkBaseReqVO（公用字段）
-  - `appId` (String)：为兼容历史接口保留，系统始终使用配置项 `iwork.app-id`。
+  - `appId` (String)：仅保留字段，系统强制使用配置项 `iwork.app-id`，忽略请求值。
   - `operatorUserId` (String)：在 iWork 内部代表操作人的用户编号（可为空，框架会使用 `properties.userId`）。
   - `forceRefreshToken` (Boolean)：是否强制刷新 token（例如遇到 token 错误时强制刷新）。
 
@@ -117,7 +125,7 @@ Controller 暴露的 REST 接口：
   - `success` / `message`：调用成功标志与提示信息。
 
 - IWorkWorkflowCreateReqVO（统一用印流程发起）
-  - `workflowId` (String)：流程模板 ID，必填，不再回退到配置。
+  - `workflowId` (String)：流程模板 ID，必填，通常由配置 `iwork.workflow-id` 提供；仅用于向 iWork 指定模板，不再作为业务标识。
   - `jbr`：用印申请人（iWork 人员 ID，必填）。
   - `yybm`：用印部门 ID（必填）。
   - `fb`：用印单位/分部 ID（必填）。
@@ -128,10 +136,11 @@ Controller 暴露的 REST 接口：
   - `xyywjUrl`：用印材料附件 URL（必填）。
   - `yysx`：用印事项（必填）。
   - `ywxtdjbh`：业务系统单据编号（必填，同时用于生成流程标题“用印-{ywxtdjbh}”）。
+  - `bizCallbackKey` (String)：业务回调标识，≤255 字符，回调时按该标识分发到对应业务回调入口（可选但推荐）。
   - 额外字段不再支持，Service 会根据以上字段自动补齐固定流程类型 (`lclx=2979600781334966993`) 与签署动作 (`qsdz=CORPORATE`)。
 
 - IWorkWorkflowVoidReqVO（作废）
-  - `requestId` (String)：流程请求编号（必填）。
+  - `requestId` (String)：流程请求编号（必填，唯一标识）。
   - `reason`、`extraParams`、`formExtras` 等用于传递作废原因或额外字段。
 
 - IWorkFormFieldVO（表单字段）
@@ -188,8 +197,9 @@ public class MyService {
 
 说明：
 
-- 若需使用特定凭证，可设置 `req.setAppId("my-iwork-app")`。
-- 若需覆盖默认流程模板，可调用 `req.setWorkflowId(123L)` 指定。
+- 无需设置 appId，系统强制使用配置项 `iwork.app-id`。
+- `workflowId` 通常来自配置 `iwork.workflow-id`，也可在请求中指定模板编号，但流程标识一律以返回的 requestId 为准。
+- 可设置 `bizCallbackKey` 以便回调时分发到对应业务处理；建议在发起后立即记录响应中的 requestId 及 bizCallbackKey。
 - 若希望以特定 iWork 操作人发起，可设置 `req.setOperatorUserId("1001")`。
 
 ---
@@ -202,7 +212,6 @@ public class MyService {
 curl -X POST \
   -H "Content-Type: application/json" \
   -d '{
-    "appId":"my-iwork-app",
     "identifierKey":"loginid",
     "identifierValue":"zhangsan"
   }' \
@@ -238,19 +247,20 @@ curl -X POST -H "Content-Type: application/json" -d '{
   "yysy":"与客户合同用印",
   "xyywjUrl":"https://files.example.com/contract.pdf",
   "yysx":"合同用印",
-  "ywxtdjbh":"DJ-2025-0001"
+  "ywxtdjbh":"DJ-2025-0001",
+  "bizCallbackKey":"seal-flow-callback"
 }' https://your-zt-server/admin-api/system/integration/iwork/workflow/create
 ```
 
 > 说明：外部仍以 JSON 请求调用本服务，系统在向 iWork 转发时会自动将负载转换为 `application/x-www-form-urlencoded` 表单（含 `requestName`、`workflowId`、`mainData` 等字段）。
+> 响应的 `data.requestId` 为唯一业务标识，请在业务侧保存；appId 始终取配置；`xyywjFileName` 不存储。
 
 1. Void workflow
 
 ```bash
 curl -X POST -H "Content-Type: application/json" -d '{
   "requestId":"REQ-001",
-  "reason":"作废原因",
-  "appId":"my-iwork-app"
+  "reason":"作废原因"
 }' https://your-zt-server/admin-api/system/integration/iwork/workflow/void
 ```
 
@@ -259,34 +269,98 @@ curl -X POST -H "Content-Type: application/json" -d '{
 ## 核心逻辑与细节
 
 1. 基础参数解析
+appId：始终取配置 `iwork.app-id`，忽略请求值。
+主标识：全链路仅使用 `requestId`（发起返回、作废入参、日志查询、回调分发、重试都基于 requestId）。
+模板：`workflowId` 仅用于选择 iWork 模板，不作为业务标识。
+业务回调标识：`bizCallbackKey`（字符串，≤255），发起时提交，回调按该标识分发到具体业务回调入口。
+附件文件名：`xyywjFileName` 不存储也不参与处理；仅使用 `xyywjUrl`。
 
-  系统始终使用 `application.yml` 中配置的 `app-id` 与 `client-public-key` 与 iWork 通信。
-  请求体中的 `appId` 字段仅为兼容历史调用而保留，框架内部不会使用该值做切换。
-
-1. Workflow 模板解析
-
-  调用时优先使用请求体中的 `workflowId`。
-  若未显式传入，则回退到全局 `iwork.workflow-id`，若仍为空则抛出 `IWORK_WORKFLOW_ID_MISSING`。
-
-1. 注册 + RSA + Token
-
-    - 在首次或 token 过期时，会按以下步骤获取 session：
+  调用时可在请求体中指定 `workflowId` 以选择模板；若未显式传入，则回退到全局 `iwork.workflow-id`，若仍为空则抛出 `IWORK_WORKFLOW_ID_MISSING`。
+POST `/system/integration/iwork/workflow/create`：发起用印流程，返回 `requestId`。
+POST `/system/integration/iwork/workflow/void`：作废流程，请求需携带 `requestId`。
+POST `/system/integration/iwork/callback/file`（上游回调）：接收 iWork 回调，校验 `requestId`，若缺 `bizCallbackKey` 则记录失败但不中断附件保存；下载并落库附件，记录回调日志（截断原文），并在提供 `bizCallbackKey` 时通过 RocketMQ 分发业务回调（自动/手工重试）。
+POST `/system/integration/iwork/log/page`：分页查询用印回调日志（requestId / 业务单号 / bizCallbackKey / 状态 / 时间段）。
+POST `/system/integration/iwork/log/retry`：手工重试业务回调，需权限，入参 `requestId`（状态为失败/超重试时可用）。
         1. 向 iWork 的 `register` 接口发起请求（Headers 包含 appId 与 clientPublicKey）。
         2. 从注册响应中获取 `secret` 与 `spk`（服务端公钥），使用本地的 client 公钥做 RSA 加密（`spk` 用于加密），得到加密后的 secret 与 encryptedUserId。
-        3. 使用注册返回的密钥申请 token（apply-token），token 会被按 `ttl-seconds` 缓存。
-
-    - `IWorkIntegrationServiceImpl` 中维护一个 Caffeine `sessionCache`，缓存 key 为 `appId::operatorUserId`。
+发起：`workflowId`、`jbr`、`yybm`、`fb`、`sqsj`、`yyqx`、`xyywjUrl`、`yysx`、`ywxtdjbh` 必填；`bizCallbackKey` 可选但建议提供；appId 忽略。
+作废：`requestId` 必填；`reason` 可选。
+回调：若无法找到业务附件（或不存在），标记用印失败并记日志，不抛出未捕获异常；记录原始回调文本（截断）。
     - 当 token 接近到期（`refresh-ahead-seconds`）时会在下一次请求触发刷新。
 
-1. 请求构造
-
-    - 用户解析、作废等场景继续以 `application/json` 调用 iWork。
-    - 用印流程发起在转发至 iWork 时改为 `application/x-www-form-urlencoded` 表单，请求正文包含 `requestName`、`workflowId` 及字符串化后的 `mainData`，与 iWork 网关当前要求保持一致。
-        - 认证 Header：由 `IWorkProperties.Headers` 中的常量控制，固定键名为 `app-id`、`client-public-key`、`secret`、`token`、`time`、`user-id`。
+1) 发起：校验必填 → 使用配置 appId 与模板 workflowId → 申请/缓存 token → 以 form-urlencoded 调 iWork → 返回 `requestId`，记录发起日志状态。
+2) 回调（/callback/file）：校验 requestId + bizCallbackKey → 校验租户/必备字段 → 下载/保存附件（若缺业务附件则直接标记失败并记日志）→ 写入回调日志，保存原始回调请求/响应（截断）→ 通过 RocketMQ 发送业务回调消息（topic=`SYSTEM_IWORK_BIZ_CALLBACK`，tag=`bizCallbackKey`）。
+3) 业务处理 & 结果上报（跨模块/跨进程）：业务模块订阅 `SYSTEM_IWORK_BIZ_CALLBACK` 对应 tag 处理后，将结果发布到 `SYSTEM_IWORK_BIZ_CALLBACK_RESULT`（tag 同 bizCallbackKey，携带 requestId / bizCallbackKey / success / errorMessage / payload / attempt / maxAttempts），system 模块消费结果并更新日志，失败且未超限时由 system 端按配置延迟重试再次投递回调消息。
+4) 重试：默认 3 次、间隔 5 秒，可配置（`iwork.callback.retry.*`），手工重试仍使用 `/log/retry`，由 system 模块重新投递 MQ 消息。
+5) 手工重试：需具备 iWork 模块权限；根据 requestId 将任务重新投递至回调分发器，不增加自动重试计数，可在日志详情中发起。
 
 1. 响应解析
+`CREATE_PENDING` / `CREATE_SUCCESS` / `CREATE_FAILED`
+`CALLBACK_PENDING` / `CALLBACK_SUCCESS` / `CALLBACK_FAILED`
+`CALLBACK_RETRYING` / `CALLBACK_RETRY_FAILED`
 
-    - 实现里对响应成功的判定比较宽松：检查 `code`、`status`、`success`、`errno` 等字段（支持布尔、字符串 ‘0’/‘1’/‘success’）以判断是否成功，并解析常见的 message 字段 `msg|message|errmsg`。
+---
+
+## 用印流程日志与业务回调
+
+### 范围与标识
+
+- appId：始终取配置 `iwork.app-id`，忽略请求值。
+- 主标识：全链路仅使用 `requestId`（发起返回、作废入参、日志查询、回调分发、重试都基于 requestId）。
+- 模板：`workflowId` 仅用于选择 iWork 模板，不作为业务标识。
+- 业务回调标识：`bizCallbackKey`（字符串，≤255），发起时提交，回调按该标识分发到具体业务回调入口。
+- 附件文件名：`xyywjFileName` 不存储也不参与处理；仅使用 `xyywjUrl`。
+
+### 入口（REST）
+
+- POST `/system/integration/iwork/workflow/create`：发起用印流程，返回 `requestId`。
+- POST `/system/integration/iwork/workflow/void`：作废流程，请求需携带 `requestId`。
+- POST `/system/integration/iwork/callback/file`（上游回调）：接收 iWork 回调，校验 `requestId`，若缺 `bizCallbackKey` 则记录失败但不中断附件保存；下载并落库附件，记录回调日志（截断原文），并在提供 `bizCallbackKey` 时通过 RocketMQ 分发业务回调（自动/手工重试）。
+- POST `/system/integration/iwork/log/page`：分页查询用印回调日志（requestId / 业务单号 / bizCallbackKey / 状态 / 时间段）。
+- POST `/system/integration/iwork/log/retry`：手工重试业务回调，需权限，入参 `requestId`（状态为失败/超重试时可用）。
+
+### 必填/校验要点
+
+- 发起：`workflowId`、`jbr`、`yybm`、`fb`、`sqsj`、`yyqx`、`xyywjUrl`、`yysx`、`ywxtdjbh` 必填；`bizCallbackKey` 可选但建议提供；appId 忽略。
+- 作废：`requestId` 必填；`reason` 可选。
+- 回调：若无法找到业务附件（或不存在），标记用印失败并记日志，不抛出未捕获异常；记录原始回调文本（截断）。
+
+### 处理流程（摘要）
+
+1) 发起：校验必填 → 使用配置 appId 与模板 workflowId → 申请/缓存 token → 以 form-urlencoded 调 iWork → 返回 `requestId`，记录发起日志状态。
+2) 回调（/callback/file）：校验 requestId + bizCallbackKey → 校验租户/必备字段 → 下载/保存附件（若缺业务附件则直接标记失败并记日志）→ 写入回调日志，保存原始回调请求/响应（截断）→ 通过 RocketMQ 发送业务回调消息（topic=`SYSTEM_IWORK_BIZ_CALLBACK`，tag=`bizCallbackKey`）。
+3) 业务处理 & 结果上报（跨模块/跨进程）：业务模块订阅 `SYSTEM_IWORK_BIZ_CALLBACK` 对应 tag 处理后，将结果发布到 `SYSTEM_IWORK_BIZ_CALLBACK_RESULT`（tag 同 bizCallbackKey，携带 requestId / bizCallbackKey / success / errorMessage / payload / attempt / maxAttempts），system 模块消费结果并更新日志，失败且未超限时由 system 端按配置延迟重试再次投递回调消息。
+4) 重试：默认 3 次、间隔 5 秒，可配置（`iwork.callback.retry.*`），手工重试仍使用 `/log/retry`，由 system 模块重新投递 MQ 消息。
+5) 手工重试：需具备 iWork 模块权限；根据 requestId 将任务重新投递至回调分发器，不增加自动重试计数，可在日志详情中发起。
+
+### 状态字面量（示例）
+
+- `CREATE_PENDING` / `CREATE_SUCCESS` / `CREATE_FAILED`
+- `CALLBACK_PENDING` / `CALLBACK_SUCCESS` / `CALLBACK_FAILED`
+- `CALLBACK_RETRYING` / `CALLBACK_RETRY_FAILED`
+
+> 实际实现可根据需要细化，唯一标识均为 requestId。
+
+### 重试与配置
+
+- 自动重试：默认 `maxAttempts=3`、`delaySeconds=5`，可配置（示例键：`iwork.callback.retry.max-attempts`、`iwork.callback.retry.delay-seconds`）。
+- 手工重试：权限校验（沿用 iWork 模块权限前缀）；仅在失败/超重试状态下开放。
+- 幂等：按 requestId + bizCallbackKey 进行幂等检查，成功后不再重复分发，除非手工强制重试。
+
+### 日志存储
+
+- 表：`system_iwork_seal_callback_log`（示例字段）
+  - `requestId`（PK）、`businessCode`(ywxtdjbh)、`bizCallbackKey`、`status`、`retryCount`、`lastErrorMessage`、`fileUrl`、`fileId`、`businessFileId`、`requestBody`、`responseBody`、`rawCallback`（截断保存原文）、`lastCallbackTime`、`creator`、`createTime`、`updateTime`。
+- 字段要点：
+  - `rawCallback`：保存回调原始文本，截断存储（无需脱敏，不注明上限）。
+  - 无业务附件或保存失败：写 `status=CREATE_FAILED` / `CALLBACK_FAILED` 并记录错误原因。
+
+### 查询与展示
+
+- 分页：沿用 `PageParam` 约束，`pageNo` 默认 1、`pageSize` 默认 10、上限 10000，仅分页浏览不支持导出。
+- 查询条件：`requestId`、`businessCode`(ywxtdjbh)、`bizCallbackKey`、`status`、时间范围（createTime / lastCallbackTime）。
+- 列表字段：requestId、业务单号、bizCallbackKey、状态、重试次数、最后错误、更新时间。
+- 详情：展示截断的回调原文（请求/响应）、错误原因、附件信息；提供“手工重试”按钮（需权限）。
 
 ---
 
@@ -326,8 +400,8 @@ curl -X POST -H "Content-Type: application/json" -d '{
 
 ## 小结与建议
 
-- 在配置中补齐 `iwork.app-id`、`iwork.client-public-key`、`iwork.user-id`、`iwork.workflow-id` 等关键字段。
-- 优先在本地通过 `IWorkIntegrationService` Java API 调试，成功后再通过 Controller 的 REST 接口对外暴露。
-- 若遇到请求失败，查看应用日志（`[iWork]` 前缀的日志）与 iWork 网关返回 body，定位是注册、申请 token，还是业务接口（user-info/create/void）失败。
+- 在配置中补齐 `iwork.app-id`、`iwork.client-public-key`、`iwork.user-id`、`iwork.workflow-id` 等关键字段，并按需配置回调重试参数（默认 3 次，5 秒间隔）。
+- 优先在本地通过 `IWorkIntegrationService` Java API 调试，成功后再通过 Controller 的 REST 接口对外暴露；发起后请记录返回的 requestId（唯一标识）与 bizCallbackKey。
+- 若遇到请求失败，查看应用日志（`[iWork]` 前缀的日志）与 iWork 网关返回 body；若业务回调失败，可在日志页面查看截断原文并按权限发起手工重试。
 
 文档已生成并保存到：`docs/iWork集成说明.md`。

docs/数据总线用户使用指南.md

@@ -0,0 +1,202 @@
+# 数据总线（Databus）用户使用指南
+
+> **适用范围**：`zt-module-databus-server`（管理与运行时）、`zt-module-databus-api`（对外协议），面向已部署 `ztcloud` 后端 + `zt-vue-element` 前端的环境。文档区分 **业务管理员** 与 **第三方开发者** 两类读者，帮助您从零到一完成配置、发布与调用。
+
+## 1. 角色视角与总体流程
+
+| 角色 | 核心目标 | 关键系统入口 |
+| --- | --- | --- |
+| 业务管理员 | 在后台可视化界面中定义/编排 API，配置凭证、限流、访问日志，并确保版本可控 | 后台路径：`系统管理 → 数据总线`（或直接访问 `/#/databus`）|
+| 第三方开发者 | 按照后台下发的 `apiCode + version + appId`，满足安全约束后调用统一网关，解析响应并接入自身系统 | 对外入口：`{protocol}://{host}{basePath}/{apiCode}/{version}`（默认 Base Path `/admin-api/databus/api/portal`）|
+
+完整流程示意：
+1. **管理员初始化**（执行 DM8 脚本、开通菜单与权限）。
+2. **管理员在“API 定义”中建模**（步骤、变换、策略、版本发布）。
+3. **管理员为业务方创建凭证**（`ZT-App-Id`、密钥、IP 白名单、匿名用户等）。
+4. **第三方拿到凭证后发起调用**（签名 → 加密 → 发送 → 解密响应）。
+5. **管理员通过限流/日志功能持续运维**，必要时回滚版本或刷新缓存。
+
+## 2. 通用准备事项
+
+### 2.1 服务与配置
+
+- **运行中服务**：`zt-server` 网关、`zt-module-databus-*` 相关微服务、Redis（用于 nonce、防重放、限流计数）。
+- **关键配置**（摘自 `application.yml`）：
+  - `databus.api-portal.base-path`：默认 `/admin-api/databus/api/portal`，如需兼容旧系统可保留 `/databus/api/portal` 别名。
+  - `allowed-ips/denied-ips`：无白名单时留空即放行全部；建议第三方出口 IP 全量登记。
+  - `security`：`signature-type（MD5/SHA256）`、`encryption-type（AES/DES）`、`nonce-ttl`、`allowed-clock-skew-seconds`、是否强制请求/响应加密。
+  - `enable-tenant-header`：如开启多租，会自动从 `ZT-Tenant-Id`（可自定义）透传。
+
+### 2.2 数据库与菜单初始化（DM8）
+
+| 场景 | 脚本（目录 `sql/dm/`） | 说明 |
+| --- | --- | --- |
+| 初始化菜单与按钮权限 | `统一外部网关菜单_20251010.sql` | 建立“数据总线”一级菜单及 API/凭证/策略/访问日志页面的所有操作权限，支持重复执行。 |
+| 访问日志菜单补充 | `数据总线API访问日志菜单权限_20251028.sql` | 若已执行主菜单脚本仍找不到访问日志入口，可追加该脚本。 |
+| API 版本历史表 | `数据总线API版本历史表结构_备忘录模式_20251030.sql` | DM8 兼容语法，包含索引与字段注释，确保支持版本快照/回滚。 |
+| 访问日志表 | `数据总线API访问日志表结构_20251028.sql` | 记录追踪 ID、请求/响应、步骤结果等，供后台“访问日志”页面检索。 |
+| 示例/演示数据 | `../mysql/databus_sample_data.sql`（MySQL） | 可作为建模参考，字段一致，迁移到 DM 时仅需替换数据类型即可。 |
+
+> **执行顺序建议**：先运行菜单脚本 → 赋予管理员角色对应按钮权限 → 执行表结构脚本 → 根据需要导入示例数据。
+
+## 3. 业务管理员操作路线
+
+### 3.1 角色与权限校验
+
+1. 通过 DM8 脚本写入菜单/按钮后，将 `数据总线` 相关权限分配给目标角色（如 `system_admin`）。
+2. 确认角色拥有以下最少权限：`databus:gateway:*`、`databus:credential:*`、`databus:policy:*`、`databus:gateway:access-log:query`。
+
+### 3.2 创建 API 定义
+
+进入 **数据总线 → API 定义**，按以下步骤操作：
+
+1. 点击“新建”填写基础信息：`API 编码 (apiCode)`、`版本 (version)`、`描述`、`HTTP Method`、`URI Pattern`（运行期仅用于文档，可自由描述）。
+2. 选择 **认证策略** 与 **限流策略**：默认策略可复用，也可在对应菜单先新建。
+3. 选择 **状态 = 草稿**，避免未完成配置就被调度。
+
+> **提示**：Start/End 步骤系统会自动校验唯一性，必须至少存在一条 Start 与 End 步骤。
+
+### 3.3 配置编排步骤与变换
+
+1. 在 API 详情页新增步骤：
+   - **类型**：HTTP / RPC / Script / Start / End。
+   - **目标地址**：HTTP 需写 `METHOD http://host/path`，并按需填写 Header/Body 映射表达式。
+   - **映射表达式**：支持 JSON 表达式，常用写法示例同 `databus_sample_data.sql` 中 `JSON::(...)`。
+   - **重试/超时**：以 JSON 形式配置 `maxAttempts`、`delayMs`。
+2. 配置步骤级或 API 级 **Transform**：
+   - 场景示例：请求前补链路追踪 ID（`REQUEST_PRE`）、响应前组装统一结构（`RESPONSE_PRE`）。
+   - 校验规则：同一 `phase` 仅允许一条记录。
+
+### 3.4 版本与发布
+
+1. **保存即可生成版本快照**：系统会在 `databus_api_version` 中写入 JSON 快照并标记 `is_current=1`。
+2. **调试**：在 API 列表点击“调试”，通过 `POST /databus/gateway/invoke` 模拟真实请求，可自带 Header/Body。
+3. **上线**：修改 `状态=ONLINE` 后保存，系统自动刷新运行时 Flow。若需全量刷新，可在列表右上点击“刷新缓存”。
+4. **回滚**：在“版本历史”侧栏选择目标版本 → 点击“回滚”，系统将历史快照恢复为现有配置并重新发布。
+
+### 3.5 凭证与策略运营
+
+1. **客户端凭证**：
+   - 进入“客户端凭证” → 新建 → 生成 `appId`、密钥、签名/加密算法。
+   - 可绑定匿名用户（后台会在调用时自动模拟该用户登录）。
+   - 支持 IP 白名单、描述及状态维护。
+2. **限流策略**：
+   - 在“限流策略”菜单中新增 `FIXED_WINDOW` 类型，配置 `limit`、`windowSeconds`、`keyTemplate`。
+   - 常见做法：`${apiCode}:${header.X-Client-Id}`，以不同客户端维度做计数。
+
+### 3.6 监控与排障
+
+1. **访问日志**：菜单路径“访问日志”，支持按 `traceId / apiCode / 时间` 检索详情，字段对应 `databus_api_access_log`。
+2. **常见问题定位**：
+   - 401 → 校验凭证/签名/时间戳。
+   - 429 → 限流策略触发，可在日志中观察 `status=1`/`errorCode=API_RATE_LIMIT_EXCEEDED`。
+   - 5xx → 检查步骤 `stepResults` 中的 `error` 描述、Integration Flow 日志。
+
+## 4. 第三方开发者操作路线
+
+### 4.1 凭证申请
+
+向业务管理员提供以下信息：调用系统名称、出口 IP 列表、是否需要匿名账号、预期调用 API 列表。管理员创建凭证后会得到：
+
+- `ZT-App-Id`
+- `encryptionKey` + `encryptionType`（AES/DES）
+- `signatureType`（MD5/SHA256）
+- 可选：匿名内部用户、租户 ID
+
+### 4.2 网络与安全要求
+
+- 请求必须来自允许的 IP，且使用 HTTPS（推荐）或可信的内网段。
+- 时间戳与服务器偏差 ≤ `allowed-clock-skew-seconds`（默认 300 秒）。
+- `nonce` 在 `nonce-ttl-seconds` 内不得重复（默认 600 秒，服务器使用 Redis 去重）。
+- 若开启 `require-body-encryption`，请求体必须是 **加密后再 Base64 编码** 的字符串。
+
+### 4.3 构建请求的 7 个步骤
+
+| 步骤 | 动作 | 关键点 |
+| --- | --- | --- |
+| 1 | 生成 `timestamp` | `long` 类型毫秒值；建议每次现取。 |
+| 2 | 生成 `nonce` | ≥8 位随机字符串，推荐 `UUID` 去掉 `-`。 |
+| 3 | 准备明文 Body | JSON 文本，记为 `plainBody`。GET 请求仍建议传空 JSON `{}`，以便签名。 |
+| 4 | 计算签名 | 将 `appId`、`timestamp`、`nonce`、`plainBody`（或 Query）按 key 排序拼接 `key=value`，使用约定算法得出 `signature`。 |
+| 5 | 加密 Body | 以凭证密钥对 `plainBody` 执行 AES/DES 加密，再 Base64（需与服务端配置一致）。 |
+| 6 | 组装请求头 | 至少包含 `ZT-App-Id`、`ZT-Timestamp`、`ZT-Nonce`、`ZT-Signature`、`Content-Type`，可附带 `ZT-Tenant-Id`、`X-Client-Id`。 |
+| 7 | 发送请求 | URL = `{basePath}/{apiCode}/{version}`，HTTP 方法与后台配置一致；响应若被加密需反向解密。 |
+
+#### 请求示例（伪代码）
+
+```text
+POST https://gw.example.com/admin-api/databus/api/portal/order.create/v1
+Headers:
+  ZT-App-Id: demo-app
+  ZT-Timestamp: 1732070400000
+  ZT-Nonce: 0c5e2df9a1
+  ZT-Signature: 8e377...
+  X-Client-Id: mall
+Body (Base64)：Q2hhcnNldGV4dC1CYXNlNjQgZW5jcnlwdGVkIGJvZHk=
+```
+
+#### 响应处理
+
+1. 读取 HTTP 状态与 `code/message/traceId` 字段。
+2. 若后台开启响应加密，需使用同一密钥解密得到真正的 `response` JSON。
+3. 保留 `traceId` 以便与管理员对齐日志。
+
+### 4.4 常见故障排查
+
+| 症状 | 常见原因 | 自助检查 |
+| --- | --- | --- |
+| 401 + `签名校验失败` | 拼接顺序错误 / 对象未序列化一致 | 确认按字典序拼接 `key=value`，body 使用明文。 |
+| 401 + `请求到达时间超出` | 客户端时间漂移 | 同步 NTP，或在发送前刷新服务器时间。 |
+| 401 + `重复请求` | `nonce` 重复或被重放 | 确保每次生成唯一随机串。 |
+| 403 | IP/应用被禁用 | 让管理员检查凭证状态、白名单。 |
+| 429 | 限流策略触发 | 调整并发或与管理员协商提升 `limit`。 |
+| 5xx + `步骤执行失败` | 后端步骤调用异常 | 提供 `traceId`，管理员可在访问日志中查看 `stepResults` 详细报错。 |
+
+## 5. 策略、监控与日志
+
+### 5.1 限流与审计
+
+- 策略以 JSON 存储在 `databus_policy_rate_limit`，字段：`limit`（次数）、`windowSeconds`（窗口秒）及可选 `keyTemplate`。
+- 当前默认策略实现为 **Redis 固定窗口**：Key 格式 `databus:api:rl:{apiCode}:{version}:{X-Client-Id}`。
+- 触发限流时返回 `HTTP 429`，日志中 `status=1` 且 `errorCode=API_RATE_LIMIT_EXCEEDED`。
+- 如需关闭限流，管理员可在 `application.yml` 中设置 `databus.api-portal.enable-rate-limit=false` 或在 API 上解除策略绑定。
+- 审计日志由 `ApiGatewayAccessLogger` 写入 `databus_api_access_log`，可结合 ELK/BI 做分析。
+
+### 5.2 访问日志使用
+
+1. **建表**：执行 `sql/dm/数据总线API访问日志表结构_20251028.sql`（已含主键、索引、字段注释）。
+2. **后台入口**：`数据总线 → 访问日志`，需 `databus:gateway:access-log:query` 权限。
+3. **常见字段解释**：
+   - `REQUEST_*`：存储原始请求；如启用请求加密，会记录解密后的明文。
+   - `STEP_RESULTS`：JSON 数组，展示每个步骤的 `elapsed`、`request/response`、`error`，用于定位链路问题。
+   - `TRACE_ID`：可与链路追踪或日志平台联动。
+4. **TODO**：如目标环境尚未执行该表脚本，请尽快在 DM 数据库运行，以免访问日志页面无法查询。
+
+## 6. 演示数据与调试建议
+
+- 使用 `sql/mysql/databus_sample_data.sql` 可一次性生成：
+  - 3 个示例 API（聚合查询 / 用户画像 / 快速登录）。
+  - 对应的步骤、变换、限流策略、发布记录。
+- 若目标环境为 DM，可参考该脚本结构，将 `AUTO_INCREMENT` 改为手动 ID、`datetime` 改 `timestamp`，即可导入。
+- 通过示例数据，管理员可演练以下操作：
+  1. 打开 API 列表验证导入内容；
+  2. 使用“调试”通过管理端发起调用，确认步骤链路；
+  3. 让第三方按照真实流程调用，观察访问日志、限流表现。
+
+## 7. 附录：常用 REST 接口速查
+
+| 模块 | 方法 | 路径 | 用途 |
+| --- | --- | --- | --- |
+| API 定义 | GET | `/databus/gateway/definition/page` | 列表检索 |
+|  | POST | `/databus/gateway/definition` | 新建/更新 API（PUT 更新） |
+|  | DELETE | `/databus/gateway/definition/{id}` | 删除并注销 Flow |
+| API 版本 | GET | `/databus/gateway/version/list?apiId=` | 历史版本 |
+|  | PUT | `/databus/gateway/version/rollback` | 回滚 |
+| 客户端凭证 | POST | `/databus/gateway/credential/create` | 创建凭证 |
+| 限流策略 | POST | `/databus/gateway/policy/rate-limit` | 创建/更新策略 |
+| 调试/刷新 | POST | `/databus/gateway/invoke` | 管理端调试 |
+|  | POST | `/databus/gateway/cache/refresh` | 全量刷新 Flow |
+| 日志 | GET | `/databus/gateway/access-log/page` | 查看访问日志 |
+
+---
+如仍有未覆盖的业务场景，可在 `docs/数据总线模块大致功能与调用介绍.md` 中查阅更底层的架构说明，再结合本文步骤完成落地。祝使用顺利！