这篇主要进一步反思原有相关工作流引擎和BPM软件的一些看法。
我曾经谈到过,BPM应该包括了自动化业务流和人工审批流,同时BPM关注的是跨系统流程,而对于工作流引擎往往重点是单系统内的流程。正是基于这个思考,一直很难真正想清楚一个完整的端到端流程的发起和处理是否可以完全靠BPM系统来进行从建模,设计,开发和发布的全过程。
要知道对于企业业务分工的细化,本身对于业务部门的员工操作的业务都是端到端流程的一个部分,这些业务员工本身就不需要关注端到端流程,而真正对端到端流程关注的往往是企业类似流程优化和绩效改进的部门,但是对于流程部门往往并不进行流程实际的发起,操作和执行。
正是由于这个原因,再次重申一个观点就是对于BPM端到端流程的建模可以通过BPM软件进行,但是对于BPM流程建模最终还是要分解到不同的各个业务系统中的子流程,而这些子流程才是通过BPM软件或流程引擎进行建模,设计和执行。而对于端到端的BPM流程建模更多的将用于端到端流程的监控而不是实际执行。
回到当前常见的BPM流程软件来说,可以看到更多的仍然是完成业务系统内部的审批流,但是为了具备自动化的业务处理节点能力,比如在报账单据人工审批完成后可以触发生成付款单据,可以将报账单据导入到ERP等业务系统,要实现这个通常的做法仍然是在传统的工作流引擎基础上增加了调用外部业务服务能力接口部分的内容,当然如果做的更加方便,我们还可以进一步提供业务服务的适配能力,比如对JMS,数据库等的业务服务适配能力。通过这种改进可以看到传统的工作流引擎已经具备集成自动化业务处理节点的能力。
在集成了业务服务节点后,一个关键点就是进一步对业务服务的输入和输出的适配,即对于流程表单和流程执行中的数据信息能够作为参数输入传递到业务服务的输入中,而对于业务服务的输出既可以映射到流程表单中,也可以传递到流程执行的全局变量参数中,做为业务规则和逻辑判断的基础。
再提及一个完整的BPM软件的时候,经常还会谈到独立的业务规则引擎以处理复杂的业务规则。要知道BPM软件本身就是一个完整的快速应用开发平台,因此除了经常谈到的数据建模,表单建模,流程建模,权限建模外,还需要具备业务规则建模的能力。当前的很多BPM软件本身也具备业务规则的简单处理能力,但是往往这些简单条件判断或规则是紧耦合在流程建模定义文件中的,当有了规则引擎后可以看到复杂的业务规则即可以剥离处理在单独的规则引擎中进行处理,同时将业务规则的定义本身也发布为业务服务节点供流程引擎设计时调用。
经过本次思考,也进一步明确了对于BPM后续的关注点已经和ESB集成平台和服务的集成关系。