从某种意义来说，模型的设计只是为流程定义了一个流转的框架，经过对实际业务流程的分析，大部分的任务步骤都是通过“用户动作”（Human Activity）操作完成的，如审核和确认等动作。从逻辑角度来看，用户动作的内容是通过任务的定义和配置来实现的；而从用户的使用角度来看，每一个任务对应的就是每一个用户在登录客户端系统后看到的“待办任务”。

使用开发工具可以很方便地在一个BPM工程中，通过右击的新建菜单创建一个流程以及对应结点的任务，如图7-5所示。

1.属性配置

当打开一个任务时，会看到任务包含了概览、特性和动作、角色、用户文本以及时间常量等几个选项卡，如图7-6所示。

图7-5 流程模型目录结构

图7-6 不同的选项卡

●在概览中，可以定义任务的基本信息，可以选择是否需要邮件通知对应任务的待办接收人，可以选择当前任务的优先级（将显示在用户的待办清单中），可以绑定任务对应Web Dynpro程序的接口视图，但视图中必须有事件触发动作，用于触发工作流继续流转。由于Web Dynpro程序决定了用户在打开待办时可以看到以及处理业务时的页面，因此必须绑定，如图7-7所示。

●在特性和动作中，可以配置自定义的特性，并且可以使用一些模板提供的逻辑表达式，还可以配置自定义的动作，如图7-8所示。

图7-7 概览选项卡

图7-8 特性和动作选项卡

●在角色中，可以定义当前任务的处理人、定义例外用户以及定义任务的管理员，如图7-9所示。

●在用户文本中，可以定义一些特定文本的变量，用于任务的名称或者说明信息中，当然这些文本也可以使用流程中传递的上下文特性作为参数，动态地生成特殊文本，如图7-10所示。

图7-9 拥有者选项卡

(www.daowen.com)

图7-10 用户文本选项卡

●在时间常量中，可以指定任务的延迟触发时间以及任务的过期时间，避免用户收件箱中出现待办任务过量堆积，如图7-11所示。

2.所有者配置

在任务的属性配置中，Web Dynpro接口视图的定义非常重要，因为视图的绑定决定了用户处理业务的页面选择以及实际体验；而在确定接口视图之后，最为重要的则是任务的所有者配置，因为所有者的配置决定了哪些人有可能会收到任务、哪些人不会收到任务以及哪些人有权限可以对任务进行终止或转发，即分为了“潜在所有者”“排除所有者”以及“任务管理者”3种类型，如图7-12所示。

图7-11 时间常量选项卡

图7-12 所有者配置

在3种类型的所有者配置选项卡，都包含了以下两种方式进行所有者的指派：“Choose one or more UME principles”，可以理解为UME实体；“Use an expression”使用表达式。在选中“Choose one or more UME principals”单选按钮后，发现其实不仅可以绑定用户，还可以绑定指定的组、角色或用户，如图7-13所示。

除了绑定静态的UME实体以外，SAP也允许通过表达式动态获取审批人。而在各类的实施项目中，发现绑定静态对象的情况很少存在，这可能是因为配置的不灵活而带来较大的工作量，容错率非常低。相对而言，表达式的情况有多种，一种是将整个审批规则封装成一个过程，在表达式中直接调用这个过程，常见的如使用EJB实体；另外一种是表达式直接读取流程上下文中的某一个变量，这个变量已经存在了审批规则过程调用后的结果。

图7-13 配置UME实体界面

直接调用过程的形式将整个审批规则工作配置化，实施者只需要配置任务属性而省去了代码级别的开发。绑定变量的方法简单、直接，但调用规则的过程却需要Web Dynpro程序来实现，从一定程度上增加了项目开发的工作量。由于通过Task直接调用过程，往往会遇到不能回滚的尴尬，当新的任务生成时会执行通过规则获取审批人的逻辑，一旦执行当中出现异常，新的任务就可能会生成失败。最终的结果是即使能够通过后台监控错误原因，但流程实例本身也会因为异常不能回滚，这种异常情况往往对流程任务处理者来讲是致命的，他们通过表象不能判断流程的实际走向，最终的处理方式也只能是重新提报等。相反，直接绑定变量的方式却因为代码级别的原因使开发人员能够合理地处理异常，回滚已经执行的操作。

当然不管是通过表达式调用服务，还是绑定某一个动态的执行者变量，区别仅在于执行审批规则逻辑的时间顺序，执行审批规则的过程是必须要有的。审批规则对应于流程任务处理者的取人逻辑，每一个任务生成之前都要通过适应于客户需求本身的审批规则，而现在人们已经把这个过程模块化，模块置于任务生成之前，模块的输出是该任务精确的执行者。值得一提的是，每一个规则背后都包含了对该客户或公司组织架构的深层次理解与分析，对于不同的公司、不同的业务模块来讲，它们的审批规则都是不同的，或者说人们还无法抽象出一种规则，使它应用于所有的业务场景，但规则的设计却有一个最终的目的——配置化的灵活、简单与扩展。当企业的组织架构出现调整，当员工的岗位级别发生变动时，规则能够通过简单的配置来灵活地应对这种变化，使BPM流程本身也具备更强的业务兼容性。

下面归纳了几种常用的设计原型：

1）自定义配置审批人：通过自定义配置表来配置每一个流程结点的审批人，配置表直接指定具体岗位或人员。配置表的属性一般包含流程标识（ID），任务标识，所有与审批相关的业务类型、业务数据字段，员工标识。对于一个具体的流程实例，通过已知的流程标识、任务标识、业务类型涉及的业务数据来获取相关的审批人。这种方法适用于大部分通过业务类型数据不同指定不同审批人的情况，并且配置表已经具体到员工标识，通过配置表可以实现较多特殊情况的审批规则，配置较为灵活，但由于配置的过程对所有细分的情况都有涵盖，初始化的配置会带来很大的工作量，而且对于审批规则调整的适应性不高，企业人员体系的变化或者岗位调动都会给维护带来较大的工作量。

2）通过角色获取审批人：通过角色的方式配置审批规则，相当于对审批级别做了分类，在整体审批级别层次较为清晰、审批层次对应的人员集合较为固定的情况下比较适用。例如，一个集团所有流程的审批最多就是三级，三个级别对应了固定的专岗人员，那就可以建立三个角色，每一个角色导入这些专岗人员。实际的审批过程是从角色当中取人，然后针对这些人员组合做进一步过滤。这种方法的优点是整个配置过程简单，初始化与维护都不会有很大工作量，但这种方式只是针对较为简单的审批场景，对于复杂的业务类型审批往往不能够满足要求。

3）与HR系统（模块）的集成：审批规则的设计与ERP中的HR系统集成是比较好的一种方式，一方面，由于审批人的数据源就是来源于HR本身，因此不用关心因为人员级别的变化而带来的影响；另一方面，HR已有的数据配置也大大减少了初始化的配置工作量。例如，企业本身实施的SAP人力资源模块（Human Resource，HR），针对流程标识，任务标识的配置可能就是“组织-职位-员工”（Organisations-Positions-Employees，O-S-P）的一种，在不指定具体员工的情况下，组织和职位下的人员都来自SAP HR数据，组织或岗位下的人员调整都不会对流程的实时审批产生影响。当然采用这种设计的前提是要对企业的HR系统有很好的调研与理解，而且审批规则确实与HR的体系关联很大，同时HR提供系统接口也是必然，这样会带来一定的接口集成的工作。