notes/000-inbox/05月19日 154820.md

我梳理了一下，这块是“URL 封禁/解封”能力，入口是 ProhibitionController.java 的 POST /api/url/ban，回调是 OmsApiDomainController.java 的 POST /action?commandType=banCallBack&version=1。

主流程

/api/url/ban 根据两个配置开关分流：

WG_TOTAL_SWITCH=true，或当前企业在 WG_ENTERPRISE_ID_SWITCH 里时，走统一网管新链路：

1. 从请求头 Tenant-Id 查企业。
2. 把 URLDenyAllowTaskVO.urls 转成统一网管 UrlBanLiftTaskVO.urls。
3. 校验 URL、域名归属、操作类型、重复封禁等。
4. 生成 WG_ 开头的 taskId。
5. 调统一网管/BPM：bpmService.urlBanOrLiftOperate(…)。
6. 下发成功后落库，返回 taskId。

不命中开关时，走旧链路：

1. 生成 WS_ 开头的 itemId。
2. 校验 URL、域名归属、操作类型、重复封禁等。
3. 调旧配管/各平面下发。
4. 落库任务、URL 明细、配管记录、平面下发记录。

统一网管新链路写入的表

在 URLBanLiftServiceImpl.java 里，下发成功后写：

• ban_lift_task
  对应实体 NetworkURLBanLiftTask。记录任务主表：task_id、cp_id、operate。

• ban_lift_url
  对应实体 NetworkBanLiftURL。记录每个 URL：url、task_id、areas、method、forbid_share_cache、operate、status、start_time。初始 status=11，表示进行中。

• ban_lift_task_url
ban_lift_task 和 ban_lift_url 的关联表。

统一网管链路下发失败时，代码里没有保存这几张表，只返回失败。

旧链路写入的表

旧链路在 ProhibitionServiceImpl.java 的 pipeUrlDenyAllowed 里写：

• deny_allow_task
  任务主表，记录 item_id、type、status、start_time、cp_id、task_state 等。

• deny_allow_url
  URL 明细表，记录 url、domain、method、areas。

• deny_allow_task_url
  任务和 URL 的关联表。

• pipe_config_entity
  配管消息记录，保存 message_id、target_name=itemId、type=WANG_SU_DENY/WANG_SU_DENY_RESET 等，用于后续配管回调匹配。

• ban_or_filter_record
  平面下发记录，保存 task_id、distribution_plane、success_plane、error_plane、reason、urls、type=ban/unban。

另外，旧链路会更新 Redis 里的企业每日操作次数限制，不是数据库表。

统一网管回调改哪些表

你贴的 banCallBack 回调只处理统一网管新链路。逻辑在 URLBanLiftServiceImpl.java：

1. 按回调里的 taskId 查 ban_lift_task。
2. 找到该任务下所有 ban_lift_url。
3. 更新每条 URL 的：
   • status
   • operate
   • start_time
   • end_time
4. 再通过 urlBanLiftTaskDao.save(networkURLBanLiftTask) 保存。

所以业务上主要修改的是：

• ban_lift_url

同时因为是通过父对象 ban_lift_task 保存，JPA 可能会触发 ban_lift_task.updated_time 更新；但任务主表没有业务字段被主动改，关联表 ban_lift_task_url 也不会变。

旧链路的回调不是这个接口，它会更新 deny_allow_task 的 success_rate、end_time、status、task_state；但你贴的 banCallBack 不会改 deny_allow_task。