工作流系统中增加“业务活动”这一概念的想法
这样我们在为业务流程建模时,首先是定义“业务流程”,其次应该是识别流程中有哪些“业务活动”,并为“业务活动”定制一些属性,最后才是定义具体的流程。使用一套已经建立好了的“业务流程”来定制流程就变得非常的轻松,流程上关联业务流程,活动上关联业务活动,这样所有与业务相关的属性就都可以设置好。
先前版本的工作流将活动上不管是与业务相关的,还是与流程相关的属性一齐混杂在流程设计器上。这种实现方式有几大弊端:1、无法实现同一业务概念的复用,在一个活动上定的业务概念,需要在另一个相同业务意义的活动上原封不同的重定一遍。虽然我们实现了活动的复制,但我认为这种复制不是解决这种业务意义复用的很好方式。2、所有的与业务相关的实体都是独立于工作流系统之外的,在定义流程时将这些业务实体的设置记录在流程定义中。由于流程的版本控制,先前已经运行的流程定义是无法改变的,而业务实体又可能是会发生变化的,如单据的字段权限变化了(对于自定义表单这样生来就是为适应变化的,就更容易发生变化了),构件的参数又增加了一个等等,致使流程运行时业务上的改变得不到及时的体现,甚至运行不下去。3、流程运行结果,更通俗的讲可能是审批的结论、意见不能根据业务意义进行分类,明显的体现是审批结果打印时,所有的意见结论都罗列在一起(这个需求来源于OA项目组)。
哪些活动属性应该放到“业务活动”上,我认为表单定义、表单权限设置(动作权限、字段权限),其他象外部工具、规则等也可以考虑放进来。
工作流可以无区别的对待普通流程和OA使用的动态流程的权限设置,都包括表单参数设置、表单动作权限的设置、表单字段权限的设置。
值得一提的是,像加签、会签、跳转等权限,我认为是纯粹的流程权限,不应该去表单的权限混为一谈,可以强制识别这些的流程引擎提供了的流程动态功能,并为其设置权限。
对特殊性、向下兼容的考虑,在流程定义上仍然保留这些在“业务活动”添加的属性,在使用时首先查找具体活动上的定义,再查找业务活动上的定义。这样的同一“业务活动”对应的活动也可以有完全不同的特性,而且对于老版本的流程定义,即使没有在活动上关联业务活动,仍可以正常运行。