July 17th, 2013

本文介绍Remedy Approval Server的设计,旨在启发程序员或架构师的业务抽象能力。Remedy的审批引擎具有其特点,它与Remedy平台紧密结合,以Remedy特有的方式设计和配置。虽然我从来都不迷信任何所有的“流程引擎”,但是BMC的这套引擎在设计上具有一定的科学性,其思想值得开发人员学习,更值得有意设计流程引擎产品的架构师或设计师学习。本文阐述Approval Server的概述和设计思想。

业务审批流程

审批流程是流程的一个分支概念。在现实生活中,有很多流程,不见得每个都涉及审批。经常听闻,很多开发人员或产品经理把流程和审批流程混为一谈。所谓审批是指,某人对某种资源在具有否决权的前提下,对资源的判决操作。Approval Server在设计上将产品定位为审批流程,而不是“泛流程”。审批流程在特定节点的操作是有限的,可以抽象和归纳的,比如“审批通过”、“拒绝”、“待决”、“取消”等,但是“泛流程”却是千变万化的,操作是无法穷举的,比如“执行”、“确认”、“指派”等。因此,在产品选型时,如果定位是审批,那么Approval Server可以cover到,如果定位中有“泛流程”的操作,那么仅仅靠Approval Server是不够的。

概述

Approval Server物理上与arserver共存是arserver中的一个组件,可选安装。Approval Server安装完之后,会在AR中建立相当数量的表单和工作流,这些东西有些是Approval Server工作的核心,有些提供了用户界面,以便用户操作审批单。Approval Server支持配置审批流程,支持代理审批,支持通知等。这些将在将来的文章中慢慢学习。

设计思想

想要学会配置Approval Server,了解其设计思想是十分关键的。首先,Approval Server的整体基于AR,因此,配置是通过AR表单的方式进行的,没有可视化的配置(至少7604没有),到这里可能很多同学都失望了吧。其次,如果你想要使用Approval Server来配置审批流,那么你必须基于AR表单来设计你的应用程序,当然,你可以用其它的方式来展示数据,但是数据本身必须基于AR。最后,最重要的是Approval Server实际上将审批流抽象化成一个通用的模式,配置流程的过程就是将这个抽象模型具化的过程。下面我将详细描述这个抽象模型,我认为Approval Server在这个抽象模型的设计上还是有一些可取之处的,我相信,无论你是否想要使用这个产品,学习一下这个抽象模型还是能有所收获的。

抽象模型

Approval Server将审批流程抽象为5个阶段,这5个阶段的关系如下图:

  1. 自验证:这个阶段主要考虑的是由于流程本身或者审批人具有较大的权限,使得审批可以直接通过的情况
  2. 下一个审批人:这个阶段获取下一个审批人
  3. 审批人操作:这个阶段等待审批人操作,默认情况下拒绝和通过将引导到其他阶段,但在这个阶段也可以修改这个默认的引导行为,比如某个业务规则要求所有的审批人超过半数通过就算通过
  4. 完成检查:当某个审批人操作完之后,进入到完成检查阶段,这个阶段决定是否继续回到阶段2获取下一个审批人。这里形成了一个循环,于是多个审批节点就可以依靠这个循环来实现
  5. 流程完成:当流程完成后,可以在这个节点添加额外的处理,比如另起一个子流程,或者标记某种状态。

Approval Server基于这个5个阶段执行其流程的引擎驱动,这些阶段是高度抽象的,可以说是逻辑的,每个阶段都有具体的规则具化这种抽象逻辑。在进入到这些具体规则之前,我们先来看看Approval Server预定义的流程类型:

  • Parent-Child模型:这种模型主要用于层级汇报关系的审批
  • Level模型:这种模型主要用于等级审批,类似Parent-Child,但是不同点在于,Level模型强调的是在组织架构中的等级和层级,而不是汇报。在现实中,通常汇报关系也是基于层级的,具有一定的关系。不过,只要记得Level模型未必需要汇报关系。
  • Ad Hoc模型:这种模型的下一个审批人是由上一个审批人指定的,相对使用较少
  • Rule-Based模型:这种模型 说白了就是自定义模型,灵活度较大,不过在配置时需要考虑的东西也比较多,通常需要一些额外的filter参与处理

规则

规则也是一种抽象模型,在配置一个流程的大部分时间都是在具化各种规则,一系列的规则最终将形成一个流程。上文提到了5个阶段,我们将分阶段来阐述这些规则。

自验证阶段

自验证阶段有以下规则:

  • Auto Approval:自动审批。这个规则只有对一个条件的是和否的判断,所以,只能基于申请单本身的某个字段来判断。比如当申请单的餐费少于20元时自动审批通过。如果你希望完成一些更权限有关的需求,比如,申请人能够批准20元以下的的申请,或者申请人是部门经理。那么尽量不要在这个规则中定义,下面的规则将能够满足
  • Get Authority:获取权限。如上面提到的需求,如果需要得到不是更申请单直接相关的权限信息,那么这个规则中可以用于收集数据,用于Self Approval阶段判断。比如在这个规则中获取申请人是否是部门经理,或者获取申请人有权限审批的最大金额
  • Get Authority Self:获取权限。这个规则更Get Authority功能上相同,只不过Get Authority Self只会在1阶段判断,而Get Authority会出现在“完成检查”阶段,后面将提到
  • Self Approval:自己有权限审批。这个规则用Get Authority或Get Authority Self规则中收集的数据来判断是否自己有权限审批通过,并完成流程。如果自己没有权限审批,那么将进入2阶段。

下一个审批人阶段

该阶段是审批流的核心阶段,用来获取审批人,具体的规则见下面的深色区域:

  • Prep Get Next Approver:在获取审批人之前,为下一个规则准备数据
  • Get Next Approver:获取审批人。审批引擎会自动在这个阶段获取Approver,你需要做的只是利用这个规则定义获取审批人的方法,是从某张表中,按照某种条件来获取审批人。
  • Parameterized Get Next Approver:名曰参数化审批人。这个规则用于在“运行时”动态添加审批人的场景。在运行时,可以通过Add-PGNA-Values这个Command在filter中指定。
  • Validate Approver:验证审批人。由于存在Ad Hoc类型的流程,审批人是用户手工填写的,所以在这种流程类型下,需要有个规则来校验审批人的合法性

审批人操作阶段

审批人操作阶段相对比较简单,默认情况下可以不定义任何规则,因为默认的行为是审批人可以执行如下操作中的一种:

  • 批准:引擎将被引导至“审批完成阶段”
  • 拒绝:引擎将被引导至“流程完成阶段”
  • 保持:引擎阶段不会发生任何变化,可能需要有一些通知和升级机制来防止等待时间过长
  • 询问更多:引擎阶段不会发生变化,而相应的被询问人会受到通知,并可以回答询问

与此同时,这个阶段有如下规则用来改变这种默认的扭转行为:

  • Signature Override:用以改变上述默认的规则。比如有这样一个需求,超过半数的审批人批准了请求,那么就算批准。那么当总共有5个审批人时,如果前两个拒绝了,那么另外3个人还有机会让这个请求通过
  • Signature Accumulator:这个规则完全是为Signature Override提供基础数据的,比如进行聚合计算,以提供结果给Signature Override。这个规则相对比较难理解,需要例子才能说明。

下图能够阐述审批流是如何处理这个阶段的规则的:

完成检查阶段

完成检查阶段用以检查审批是否需要终止(即不需要后续的审批人了)。在流程定义阶段可以定义审批结束的依据,包括“找不到下一个审批人”和“完成规则”两种,如果定义为“找不到下一个审批人”为完成的条件,那么引擎会不断的循环Get Next Approver条件直到找不到审批人,如果定义为“完成规则”,那么引擎会以“完成规则”来确定是否结束。

在这个阶段可以有3个规则:

  • Get Authority、Get Authority Regular:与自检查阶段的两个完全相同的功能,为Completion Rule搜集数据
  • Completion rules:实际上就是定义一个条件,当条件满足时,触发“审批完成”,并进入到“流程完成”阶段,否则继续“下一个审批人”规则

流程完成阶段

流程完成阶段通常用于在流程完成后,改变申请单的状态,或者触发工作流甚至启动新的流程,只有一个规则在这个阶段

  • Approval Process Done:分别为ApprovedRejectedCancelledError这四种状态设置动作

总结

本文介绍了BMC的Approval Server,从概念和抽象模型上解释了其设计思想和原则。在实际的项目中未必一定要使用引擎,不过引擎的设计思想却可以拿来学习和提炼,对于提升程序员或架构师的抽象业务能力有一定的启发。


1块2块也是钱,小额赞助