在 SAP FioriMy Inbox这类工作流应用里，有一个很容易被忽略的性能场景。页面上明明没有任何待办任务，用户刷新一次，系统访问一次后台，再刷新一次，系统又访问一次后台。对于单个用户而言，这几次请求几乎感觉不到成本，可一旦企业里有几百甚至几千名用户同时使用My Inbox，大量空结果请求依然会不断穿过SAP Gateway，进入任务路由和后端工作流系统。真正消耗资源的地方，往往并不是返回的那几个字节，而是为了确认结果为空而完成的整条调用链。Task Gateway Service Settings里提供的Result and Time-Interval Driven Routing，正是针对这一类情况设计的一层性能保护机制。SAP 官方对Task Gateway的定位非常明确。Task Gateway Service是消费端应用访问各种任务的统一入口，它使用OData将不同任务提供方返回的任务组织成统一视图。SAP 标准实现可以处理来自SAP Business Workflow等任务提供方的任务，同时允许进一步接入其他任务提供方。这件事在理解性能问题时非常重要。因为一个My Inbox页面展示出来的任务列表，看起来只是一个简单列表，但其后面可能存在多层结构。前端发出任务查询，SAP Gateway Foundation接收OData请求，