推荐订阅源

上篇的姊妹篇，上个系列是由工作流模式推业务场景，而本系列是由业务场景推运行时实现，都是头脑风暴的总结，不都是正确的，欢迎大家指正问题。

（1） 描述

内部交易流程，完成了整个业务过程之后是集中开票的过程。开票操作是批操作，至于哪些放到一批里面，这个规则不确定，可能由人决定，可能是一个月开一次票。

单纯的从业务发生发展角度来看，内部交易完成以后就应该是开票，以上的业务流程图很简单，如下：

  

展开来看，想要达到的运行效果类似于下图：

 

（2） 解决方案

a、 将内部交易和集中开票分到不同的业务流程上，本来这者就没有太紧密的联系，因此分到两个业务流程上也很自然。实现方式上，内部交易流程实例正常结束，之后由人参与决定哪些数据集中到一张发票上，激活开票流程。为了流程回溯，在数据汇合的时候应该记录内部交易流程和开票流程之间的关系。这种方案适用于内部交易流程和开票之间没有固定规则，需要人参与的场景。

b、 用多实例模式中的在运行时都不确定执行次数的方式来实现这个流程，内部交易流程是一个可重复执行的活动块，这个活动重复执行的次数是在运行时外部事件决定的，可能是时间，也可能是人参与产生的事件。如，在某些管理方法中是月结的，即是由时间作为外部事件，下图描述了这种情况。

 

上图的流程的启动条件是每月月初，并使能重复执行Scope块活动，每个内部交易开始激活一个执行线程，此内部交易流程结束后，整个Scope块活动仍然处于使能状态，直到结束条件‘时间到月末’成立，整个Scope块活动结束，然后进行集中开票。

（3） 含义引申

从上面的两个解决方案引出了一个问题，什么样的流程环节应该画在一个流程里面，而什么样的应该分开，这个是不是有选择的标准？是根据实施人员的经验来进行判断？那么两个不同水平的实施人员所定制的流程的可用性将有天壤之别。目前总结的标准或者说是策略包括：

a、 流程描述、展现的含义是不是清楚。在特定流程定制工具的约束下，是不是能表达出流程的本义。

b、 数据转换存不存在问题。在一个流程中，这个肯定不是问题，而分开了可能就有问题。

c、 流程回溯、数据跟踪的方便性，同上面一条的道理。

除了上述的选择标准的问题，还有一个问题不得忽视。如何保持流程之间的串联性，说白了就是如果是自动激活了流程，如何通知这个流程启动，而如果是由人激活的流程，那么如果去通知这个人。自然的联想就是通过消息中间件，其特征必须具备传达的可靠性、大吞吐量和回馈的准确性。微软的建议是使用Biztalk，那么就在这种假设下构建了如下的业务流程图。

 

上图表达了粗粒度的业务流程图，图中每个方块代表的是一个模块内的流程，而模块间的流程的互操作性由Biztalk的能力提供，主要依赖强大的Mapping做数据转换、抓取数据的BAM用来做数据跟踪、消息中间件的能力。

另一个问题是业务流程划分的力度不能过小，如果还是以一个功能点为一个业务流程的话，又回到了目前功能驱动的情况了。