实际情况不是这样，框框自己并不送货
等等，在我们实际的生活中，电商们并不自己送货，他们将这部分工作外包给了物流公司。是的，从成本的角度考虑，外包送货是最合适的选择。实际上，整个订单从提交到最后的完成情况还要稍微复杂一些，如下图所示：
从图中我们可以看出，这个流程跨越了两家公司，同时也涉及到了三个系统的集成，这三个系统分别是框框网的前台网站、框框网的后台负责仓储、进出货和物流的ERP系统以及外包物流公司的ERP系统。三个系统各自有自己的处理流程，整个订单的端到端处理流程由这三个系统的三个流程所共同完成：当我们在框框网提交订单时，一个消息被发送到框框的后台ERP系统，这个消息触发一个货物的出库流程，当货物打包完毕出库时，一个消息被发送到物流公司的ERP系统，同时触发物流公司的包裹配送流程，当我们给物流公司的配送员付款完毕时，对我们顾客来说框框的购物流程已经结束，然而整个流程依旧还要继续，配送员回到公司完款，一个消息被发送回框框的后台ERP，物流公司的包裹配送流程结束，框框网的这个订单这才处理完成。
在本文的一开始，我们提到了那个糟糕的退货故事，问题就在于当订单交由物流公司进行货物配送时，我们包括框框失去了对配送流程的可视化，物流公司的处理情况在我们的流程中黑盒了。如何解决这部分的问题呢，有两种处理方法：一是在框框网订单处理流程中加入捕获事件，正如图中所示的，当框框后台ERP和物流公司ERP对订单进行处理时，每到一个任务节点就给框框网的订单处理流程发送消息，由此给我们标示出订单的实时状态。
现在，让我们来看看自己的订单会得到什么数据呢，GET http://api.kuangkuang.com/order/1000？框框网前台网站返回数据：
<order>
<link rel="detail" media-type="application/xml" url="http://api.kuangkuang.com/order/1000"/>
<content>
<id>1000</id>
<cost>88.0</cost>
<state>waiting send</state>
<history>
<activity rel="submit" time="2011-6-28 14:00" participant="ronghao"/>
<activity rel="review" time="2011-6-28 14:30" participant="xinpeng"/>
<activity rel="delivery package" time="2011-6-28 15:00" participant="haorong"/>
<activity rel="warehouse" time="2011-6-28 17:00" participant="pengxin"/>
</history>
</content>
</order>
订单状态为等待物流公司送货，注意到这段数据：
<history>
<activity rel="submit" time="2011-6-28 14:00" participant="ronghao"/>
<activity rel="review" time="2011-6-28 14:30" participant="xinpeng"/>
<activity rel="delivery package" time="2011-6-28 15:00" participant="haorong"/>
<activity rel="warehouse" time="2011-6-28 17:00" participant="pengxin"/>
</history>
工作流加入了订单处理的历史信息，从这段信息可以看出，我们要明天上午才能收到自己的货物了。
为什么没有集成呢？第一是物流公司的客户往往不止框框一家，第二是框框往往不会选择一家物流公司，这些都给系统集成带来了难度，我们会突然发现需要太多的集成点，调试、系统之间的约定，这些都需要大量的工作和成本。
既然第一种使得我们即时查看我们订单状态成本太大，那我们看看第二种方法：使用一个统一的流程管理系统来管理整个端到端的流程。下篇见。
