1.通用工作清单配置

通用工作清单（Universal Worklist，UWL）是SAP NetWeaver架构之上系统的待办工作平台。通过配置不同系统的连接器，UWL可以集中地显示多个平台不同的工作流待办，包括流程任务、警告、提醒等内容。通常情况下，通用工作清单更多地应用于BPM的待办清单，用户登录SAP企业门户后就可以查看属于自己的待办事项，并通过UWL提供的功能查看待办明细。单击待办标题，也可以打开对应的业务处理页面（包括Web Dynpro开发页面、ERP系统的GUI页面或是其他第三方系统的页面）处理相关业务，如图7-23所示。

图7-23 通用工作清单

从配置角度来看，通用工作清单是企业门户中一个默认提供的门户视图，参考中文目录在门户内容中的“门户内容/由SAP提供的内容/最终用户目录/标准门户用户/iView/com.sap.netweav⁃er.bc.uwl.iviews/通用工作清单”。门户配置人员可以通过查看或修改该视图的属性对通用工作清单进行一些简单个性化设置，如图7-24所示。

图7-24 通用工作清单的属性

在系统的标准角色中，用户核心角色“pcd：portal_content/every_user/general/eu_core_role”已经添加了通用工作清单视图的增量链接，因此普通用户添加了该角色，就可以在门户页面中看到通用工作清单。对于一些个性化的用户需求，也可以新建自定义的门户角色，并添加UWL视图形成自己的主页目录结构，如图7-25所示。

图7-25 标准角色配置

通用工作清单作为工作项目收件箱或任务列表，是用户访问工作流“TODO”列表的渠道，包含了下列优点：

1）“统一”的收件箱，接收所有的任务。

2）使用单一固定的处理页面。

3）方便使用，同时也支持客户化的定制。

4）支持多渠道访问。

5）与SAP NetWeaver平台集成，通过门户集中访问。

2.通用工作清单API实例

SAP在新版本中已经公开了部分UWL的API，以供开发者通过代码的方式读取待办数据，同时通过BPEM开发包中的“TaskInstanceManager”类，也可以读取待办。

从实际调用的情况来看，UWL的API构造的各种参数较为复杂，需要对方法的输入/输出结构有很好的掌握。相对而言，使用BPEM的API调用的过程比较简单，方法默认做了权限处理，只能查询登录用户的待办，对于大数据量的待办清单查询，BPEM API的效率要优于前者。下面分别通过两个实例具体介绍两种方法的使用和相关代码。

开发实例：

1）编辑任意一个Web Dynpro工程的视图，创建两个按钮并创建按钮的默认动作，如图7-26所示。

图7-26 运行效果

2）使用UWLAPI的参考代码：

3）部署并运行应用后测试按钮，打印的内容与待办清单的显示条目一致，如图7-27所示。

图7-27 提示消息

4）第二个按钮使用BPEM API，参考代码如下：

5）部署并运行应用后测试按钮，打印的内容与“UWL API”按钮一致，条目没有排序，如图7-28所示。(www.daowen.com)

注：使用API的Web Dynpro工程，只有依赖UWL与BPEM的标准组件包，才能引用相关的API并调用，包括“tc/kmc/bc.uwl/api”“tc/bpem/facade/ear”以及“tc/je/userman⁃agement/api”，如图7-29所示。

图7-28 提示消息

图7-29 需要依赖的开发组件

3.客户化工作清单

由于实际的项目中客户往往提出大量的个性化、定制化的需求，如待办清单中需要显示一些业务数据等，这样SAP标准的通用待办清单的功能就大大受限，需要自定义的待办清单来适应这种增强。通过平台提供的API，可以从代码端获取后台的待办数据，并自定义待办清单来满足特殊的业务场景。

开发实例：

1）自定义开发的工作清单功能区。图7-30中的工作清单通过API读取并打印了待办标题。BPM中的待办标题是可以通过变量的形式动态设置的，动态设置的标题存储于标准表中，通过标题中的关键字可以实现标准表与自定义表的关联，从而显示与待办相关的业务数据，如图7-30所示。

图7-30 自定义工作清单示例

2）自定义开发的工作清单内容区。数据库设计中会定义一张与标准表实例一一对应的流程表。自定义的流程表中可以包括除流程属性外的所有业务关键数据，当流程启动时，会在自定义表中插入一条流程数据，同时流程主键会随着流程上下文在流程中传递，每一个待办任务结束并产生下一个待办时，流程主键都会包含在新的待办标题中，最终通过解析标题数据得到流程关键值，并关联自定义表将流程属性与业务数据显示在通过Web Dynpro开发的自定义工作清单中。页面元素通过选项卡集以及表格的形式对待办清单以及待办任务重点信息进行展示，如图7-31所示。

图7-31 自定义流程表示例

3）其中标题使用的是流程流转中的动态变量，即在任务的属性定义中将任务名称修改为变量“{taskName}”，而在上方变量定义处，将该变量与流程“UIRequest”中上下文的特性进行映射，任务的名称（待办的标题）就可以通过程序的上下文进行自定义设置，如图7-32所示。

图7-32 自定义任务配置

4）另外，流程清单中的公司代码、部门代码通过与自定义表的数据关联获取，流程标识是自定义流程实例表的主键值，而标准任务标识是BPM标准表中生成的任务主键值，通过BPEM的API在初始化时编写待办获取逻辑，参考代码如下：

代码说明：从编写的逻辑上可以看出，每遍历一次通过API读取的结果集都要通过建立数据库连接，访问与数据库获取流程相关的业务数据，当数据量较大时，程序运行效率会降低。由于数据源的特殊性使得开发人员无法保证能够直接通过数据表关联的形式读取数据，因此考虑建立临时表或主键值集合的形式去优化整个查询过程是一个合理的方案。若采用临时表的方案，逻辑处理更为简洁，效率更高，但需要额外的表空间，是典型的通过空间换取时间的做法。相关开发步骤如下：

1）调用API并循环结果集时，只是往临时表里批量插入数据，数据包括标准表信息。

2）通过临时表直接关联查询自定义流程表并填充自定义待办清单对应的结点数据，采用集合的形式在第一步通过字符串拼接流程ID，同时填充已有的数据至结点，随后通过SQL IN的集合查询方法一次性查询所有业务数据。

3）再次遍历Node，并赋值通过第二步批量查询的流程数据。

通过上面的步骤可以看到，建立临时表的方式在步骤上比之前分析的两种方式都简单，但效率却是最低，最后一种集合查询的方法对于数据量不是很大的情况下可以使用。另外，从上面的例子中可以看出，通过BPM的API读取的待办数据并没有按照某一条件进行排序，对于排序的需求可以根据不同的查询方式，通过SQL语句中的排序逻辑来实现。

4）由于流程的标题通过程序的上下文进行定义，因此在流程启动时千万不要忘记初始化流程标题，并且每一级结束的按钮方法代码中根据流程启动配置更新任务标题，如图7-33所示。

图7-33 自定义代码

5）实例运行后的待办清单，如图7-34所示。

图7-34 运行效果