既然第一种使得我们即时查看我们订单状态成本太大,那我们看看第二种方法:使用一个统一的流程管理系统来管理整个端到端的流程。
业务流程管理系统的职责有两个:一是由其管理起各个系统间的集成工作,这样避免了各个系统间的大量耦合;二是由其跟踪订单状态,完成订单在整个流程中的可视化。
我们来看看具体的api调用,当我们在框框网站提交一个ID为1000的订单时,框框网站会发送一个消息到http://api.kuangkuang-bpm.com/process-definition/1,由此触发整个的流程,启动一个新的流程实例。发送的消息:
<order> <link rel="detail" media-type="application/xml" url="http://api.kuangkuang.com/order/1000"/> <content> <id>1000</id> <cost>88.0</cost> </content> </order>
业务流程管理系统给我们返回的消息:
<process-instance> <link rel="process-instance" media-type="application/xml" url="http://api.kuangkuang-bpm.com/process-instance/1"/> <content> <id>1</id> <data> <order-id>1000</order-id> <order-cost>88.0</order-cost> </data> <definition> <link rel="process-definition" media-type="application/xml" url="http://api.kuangkuang-bpm.com/process-definition/1"/> </definition> <current-activity> <name>订单提交</name> <link rel="activity-definition" media-type="application/xml" url="http://api.kuangkuang-bpm.com/activity-definition/1"/> </current-activity> </content> </process-instance>
返回的消息中给我们指出了该订单所关联的流程实例ID,当前正在执行的任务。流程系统创建流程实例后接下来继续往下执行,它发送一个消息到框框的后台ERP系统,触发后台ERP系统对订单的处理,同时告诉其访问当前流程实例的URI。现在我们假设流程执行到物流公司的配送任务,我们在框框网站查看订单的即时状态系统会有哪些动作。第一步我们同样是GET:http://api.kuangkuang.com/order/1000,返回的数据:
<order> <link rel="detail" media-type="application/xml" url="http://api.kuangkuang.com/order/1000"/> <link rel="process-instance" media-type="application/xml" url="http://api.kuangkuang-bpm.com/process-instance/1"/> <content> <id>1000</id> <cost>88.0</cost> </content> </order>
返回的消息中多了一个访问流程实例的URI,那么我们的客户端程序继续GET:http://api.kuangkuang-bpm.com/process-instance/1,返回的数据:
<process-instance> <link rel="process-instance" media-type="application/xml" url="http://api.kuangkuang-bpm.com/process-instance/1"/> <content> <id>1</id> <data> <order-id>1000</order-id> <order-cost>88.0</order-cost> </data> <definition> <link rel="process-definition" media-type="application/xml" url="http://api.kuangkuang-bpm.com/process-definition/1"/> </definition> <current-activity> <name>物流配送</name> <type>sub-process</type> <link rel="detail" media-type="application/xml" url="http://api.zjs-erp.com/order/2000"/> <link rel="activity-definition" media-type="application/xml" url="http://api.kuangkuang-bpm.com/activity-definition/3"/> </current-activity> <history> <activity name="提交订单" type="start" time="2011-6-29 14:00" participant="ronghao"/> <activity name="仓储出货" type="sub-process" time="2011-6-29 15:30"> <link rel="detail" media-type="application/xml" url="http://api.kuangkuang-erp.com/order/1000"/> </activity> </history> </content> </process-instance>
我们看到当前正在执行的任务是物流配送,这是一个子流程任务,想具体了解这个子流程执行的情况,我们的客户端程序继续GET:http://api.zjs-erp.com/order/2000,啊哈,框框将配送任务外包给了宅急送啊。
<order> <link rel="detail" media-type="application/xml" url="http://api.zjs-erp.com/order/2000"/> <link rel="process-instance" media-type="application/xml" url="http://api.kuangkuang-bpm.com/process-instance/1"/> <content> <id>2000</id> <cost>88.0</cost> <current-activity> <name>配送</name> </current-activity> <history> <activity name="接受包裹配送单" time="2011-6-29 15:40" participant="ronghao"/> <activity name="包裹入库" time="2011-6-29 15:45" participant="xinpeng"/> </history> </content> </order>
好了,有了这三段数据,我们就可以清楚的看到订单所经过的各个环节以及当前的状态。从中可以看到两点:一是我们通过kuangkuang-bpm.com所提供的流程服务将各个系统进行了数据和流程的集成;二是各个被集成的系统也需要实现rest的api以供我们的客户端程序进行数据的mashup。
故事完了吗?还没有,京东618活动简报:收获订单40多万份,订购金额超2亿,已经发货一个多亿,尚有十几万份订单积压,大约三日左右可以处理完毕。不足之处:流量多次超过4个G,服务器运行缓慢;图书备货量严重不足。与服务器相比,我更加关心如何及时将这几十万份订单处理完毕以及库存如何应对促销而产生的水平震荡,这显然不是一家物流公司可以完成的,需要多家物流公司一起消化这些订单,那么,问题来了,当我们mashup数据时,如何对这些物流公司返回的不同的数据格式进行处理?这时就需要标准化media type了,建立行业标准,企业级rest等于自定义、创造和标准化media type。
第二个问题,kuangkuang-bpm.com算是云服务否?框框私有云。