在一套已经运行 SAP Business Workflow 的 ECC 系统里，经常会遇到这样一个现象，业务审批工作项已经成功创建，在SBWP或 Workflow Runtime 中也能查到对应的 Work Item，但消费端应用迟迟收不到新的任务通知。此时如果只盯着 OData Service、RFC Destination 或 SAP Gateway 的系统别名排查，很容易把问题查偏。在经典的 SAP Gateway Workflow 架构里，Workflow Work Item 从 ECC 后端产生，并不会自动变成消费应用能够收到的 Task Notification。中间还存在一段周期性的后台处理链路，承担这段工作的核心就是两个 ABAP Report。RSWNSEL/IWWRK/R_WF_ITEM_SELECTION_GW这两个程序不是两个彼此独立的定时任务。更准确地理解，它们组成了一个有明确先后关系的两阶段流水线。前面的RSWNSEL负责从 SAP Business Workflow 一侧选择需要继续处理的 Work Item，后面的/IWWRK/R_WF_ITEM_SELECTION_GW再消费这些已经被选择出来的 Workflow Item，并生成或发送面向 SAP Gateway 消费端的任务通知。SAP 官方资料仍然把Running Scheduled Reports放在 SAP Gateway Workflow 的配置链路中，前一阶段包括 Workflow Notification、Typ
在一套已经运行 SAP Business Workflow 的 ECC 系统里，经常会遇到这样一个现象，业务审批工作项已经成功创建，在SBWP或 Workflow Runtime 中也能查到对应的 Work Item，但消费端应用迟迟收不到新的任务通知。此时如果只盯着 OData Service、RFC Destination 或 SAP Gateway 的系统别名排查，很容易把问题查偏。在经典的 SAP Gateway Workflow 架构里，Workflow Work Item 从 ECC 后端产生，并不会自动变成消费应用能够收到的 Task Notification。中间还存在一段周期性的后台处理链路，承担这段工作的核心就是两个 ABAP Report。RSWNSEL/IWWRK/R_WF_ITEM_SELECTION_GW这两个程序不是两个彼此独立的定时任务。更准确地理解，它们组成了一个有明确先后关系的两阶段流水线。前面的RSWNSEL负责从 SAP Business Workflow 一侧选择需要继续处理的 Work Item，后面的/IWWRK/R_WF_ITEM_SELECTION_GW再消费这些已经被选择出来的 Workflow Item，并生成或发送面向 SAP Gateway 消费端的任务通知。SAP 官方资料仍然把Running Scheduled Reports放在 SAP Gateway Workflow 的配置链路中，前一阶段包括 Workflow Notification、Typ
