今天讨论的Customizing the Task Provider，表面上看是一组位于SPRO里的 Customizing 配置，真正进入 SAP Gateway 的运行机制以后会发现，它解决的是一个很典型的企业级集成问题，我们的 SAP 系统里可能同时存在多种能够产生待办任务的业务组件，而前端工作台并不希望知道这些任务究竟来自哪个 Workflow Engine、哪个业务应用或者哪套内部实现。前端希望面对的是统一的任务模型，Gateway 则需要在后端建立一套统一的任务接入机制。这就是 Task Provider Framework 存在的背景。SAP 官方把这套 Framework 划分为两个非常关键的组成部分，Generic Worklist和Push Framework。其中Generic Worklist负责从已经激活的 Task Provider 中收集当前用户能够看到的工作项，并将这些工作项组合成统一的 Inbox 视图。Push Framework负责从已经激活并完成配置的 Provider 中收集通知，再把通知发送到 SAP Gateway 系统。这两个组件看起来都在处理 Task，但它们解决的问题并不相同。可以把Generic Worklist理解成任务的读取通道。当某个用户打开统一工作列表时，系统需要回答一个很实际的问题，当前登录用户究竟有哪些任务需要处理。不同业务 Provider 对任务的保存方式可能完全不同。有的任务来自 SAP Business Wo