《BPMN2.docVIP

在Sequence Flow连接线上可以添加两种标记：代表Flow是有“条件”的菱形标记和代表“缺省”Flow的斜线标记。 条件标记表示此Sequence Flow有条件表达式，只有表达式满足才从本Flow流过。缺省的意思是说：先判断其他带条件的Flow，所有其他条件都不满足的话才从本Flow流过。 带“条件”标记的Sequence Flow只能出现在Task之后，不能出现在Gateway或Event之后。“缺省”Sequence Flow可以出现在Task和Gateway之后，但不能出现在Event之后。 下面左右两张图表示的是否是一样的流程呢？ 答案是：不一样。 左边的图表示：如果上下两个条件Flow不满足的话，就走中间的缺省Flow; 只要有一个条件满足，中间的Flow就不会经过。 右边的图表示：不管上下两个条件Flow满足不满足，都会经过中间的Flow; Task后面不带标记的Sequence Flow的意思是：always. 下面的Task后面直接分叉出来三条无条件Sequence Flow，它们会并行执行： BPMN2.0中消息(Message)可以表示在不同组织之间传递的各种形式信息，比如Email、Fax、电话、信件、SOAP或JMS调用、甚至是人工传递的口信。 可以发送消息的图元包括：User Task, Service Task, Send Task, subProcess, 标注为发送消息的End Event和Intermediate Event。发送消息有如此多的选择，我们在建模中如何做比较好呢？ 基本上我们可以把消息发送按是否有执行人参与分为两类： 1、手工回复的Email、Fax、电话、信件、人工传递的口信为一类消息，它们都需要人工执行，我们需要用User Task表示； 2、自动发送的Email、Fax、SOAP或JMS调用我们用Service Task, Send Task, 标注为发送消息的Intermediate Event。其中如果发送后需要等待应答消息的话，使用Service Task，不需要等待应答消息的使用Send Task和标注为发送消息的Intermediate Event。 下面是一个例子： 上面流程中，如果供应商有系统接收自动下单的话我们使用Send Task，否则使用User Task人工下单。这里假设下单后并不需要接受反馈信息，使用标注为发送消息的Intermediate Event代替Send Task也是一样的，它们都是就绪就马上发送消息，并且发送完成控制流马上转移到下游： 如果自动下单后还需要得到反馈信息（比如成功下单后一般会有订单号返回），我们就可以使用Service Task来建模： 虽然我们可以在Send Task后紧跟一个Receive Task来接收反馈消息，但这样流程显得繁复，没有必要。 在实际使用中，BPMN流程建模标准的边界事件(Boundary Event)是很有用的一个功能。 比如，在下面的投诉处理流程片段中，如果服务人员在2小时内没有处理客户的投诉，流程将转到服务主管，由主管亲自处理： 上图中的定时边界事件会在“投诉处理”任务就绪时开始计时，如果任务在预定时间到达前完成，边界事件后面的任务（这里是“主管处理”）不会执行。如果任务在预定时间达到前还没有完成，定时事件将触发，结果就是“投诉处理”任务被中止，“主管处理”任务被激活。 在通常情况下，我们会希望在预定时间到达时（或者某个事件发生时），流程还是按一般的路线运行，只是给我们一个处理特殊事件的机会。比如上面这个例子中，投诉2小时没处理完的话，我们希望主管介入，但还是由服务人员来处理。 BPMN 2.0中新引入的Non-interrupting events（非中断事件）就可以在这种情景下发挥作用： 上面的流程中，因为我们设置边界定时事件是“非中断”的，即事件触发后并不会中止边界事件依附的任务节点，2小时后，“主管督促”任务会生成，同时“投诉处理”任务仍然保留。 非中断事件和中断事件在图形显示上的区别是：前者的边框是虚线的。 如果你看到一张BPMN流程图中包含有虚线的事件节点，就可以确认这是用BPMN2.0符号画的流程图。 BPMN 2.0的新特性--Event Sub-Process(事件子流程) 星期六, 09/04/2010 - 17:15 — ShenJ 做过实际业务流程设计的人都知道，正常的、没有例外和出错处理的流程是最容易建模的。（所以正常的流程又称为happy flow） 处理流程中的例外和错误是流程建模中比较难的一部分。如果建模规范或语言对此支持好，使用起来自然会省力很多。 BPMN 2.0之前，已专门有Boundary Event(边界事件)来处理例