卷烟工业企业物流信息系统接口标准.doc

附件2：卷烟工业企业物流信息系统接口标准技术报告一、 验证目的验证卷烟工业企业物流信息系统接口标准的适用范围，技术环节是否可行，业务定义是否符合行业习惯。二、 验证内容本接口标准适用于与烟草行业卷烟物流信息系统数据进行接口的系统及相关外围系统。1. 接口交互模型。2. 接口实现方式。（1） 接口关系。卷烟工业企业物流系统在实际应用中，主要同烟草行业的外部系统存在业务数据交换关系，交换的方式双向数据交换，一方面外部系统会将物流业务的来源单据通过接口传给物流系统作为物流系统的订单。另一方面，物流系统也会将运输仓储情况反馈给外部系统。物流系统外部（2） 技术规范。接口实现的技术主要是两种方式：消息队列方式和Webservice方式。下面我们分别针对这两种情况进行描述。一般情况下，这两种方式都能满足物流系统数据接口集成需求，所以我们原则上不建议采用的方式，因为那样无形中会增加技术的复杂度。消息队列和Webservice相关技术都比较成熟，风险很低。消息队列方式的技术规范：外部系统物流系统单据1单据2单据2人工处理1人工处理2自动处理1人工处理3消息队列方式适用的业务场景业务场景说明：在异步处理的场景中所有的业务处理之间采用直接数据传递而不进行处理成功状态判断，因此所有的业务处理之间都是异步的操作。此种特点适合采用消息队列的方式来进行集成。所有的接口与接口之间都是简单的数据传递，不需要任何的等待及反馈。都是由上游业务系统产生的结果直接传递到下游系统，因此这些都可以看成是异步的业务处理流程，在我们的整体的架构设计中最适合用消息队列消息发布与订阅的方式进行业务集成。消息队列集成流程图：外围系统业务集成总线物流系统单据2单据2单据1单据1单据2单据2人工处理1人工处理2自动处理1人工处理3异步信息流处理1异步信息流处理2异步信息流处理3123456简要说明：上图描述的是通过消息队列集成的流程图。其中红色的点表示需要集成的接口。其中1、3、5、都是按照约定的数据格式主动发送数据至指定的消息队列队列中。其中的2、4、6都是系统主动从指定的队列中读取消息，根据消息格式与内容判断下一步的处理过程，如发起人工处理或自动处理等。消息队列集成方式程序结构图：如上图所示，整个数据传输过程从结构上划分为4部分，首先发送方包含两部分，接收方包含两部分。发送方：包含外部系统和本地消息队列服务器，发送方的外部系统只与本地消息队列服务器进行通讯。将数据打包好后发送到本地消息队列服务器的远程队列中。远程队列会根据配置信息自动将数据发送到物流系统的本地队列。接收方的本地消息队列服务器的本地队列接收到消息后，自动触发处理机制，将数据解析，并且保存到本地数据库的表中。Webservice方式的技术规范Webservice方式适用的业务场景：外部系统物流系统单据1处理成功单据2处理失败业务处理.用户参与业务处理1自动业务接口处理用户参与业务处理用户参与业务处理2业务参数n.是否成功自动业务处理业务场景说明：在当前业务场景中，外部系统需要调用物流系统的自动业务接口处理，该业务接口处理返回业务处理状态；如果处理成功则发起物流系统中的用户参与的业务处理过程，同时外部系统启动一个自动业务处理；此时外部系统等待物流系统的用户参与过程，直到用户参与处理完成，则启动本系统的用户参与业务处理；如果处理不成功，则外部系统直接返回用户参与业务处理1告知用户业务处理失败。上面的场景中需要外部系统需要知道物流系统的处理结果，是同步调用方式，所以需要采用Webservice方式集成。WebService方式流程图：外部系统业务集成总线物流系统单据1单据2成功单据2用户参与业务处理1自动业务接口处理(WS)业务处理.是否成功用户参与业务处理用户参与业务处理2业务处理n.自动业务处理同步消息流处理1(WS)12异步信息流处理134简要说明：接口1的改造，首先外部系统中原来直接调用接口进行返回的部分，改成调用业务集成总线中提供的WebService接口；接口2的改造，业务集成平台实现的基于WebService的消息流调用由物流系统封装的自动业务接口处理的WebService接口然后直接返回处理状态给外部系统；接口3的改造，物流系统在完成人工参与业务处理过程后，必须按照约定格式发送数据到消息队列队列中；接口4的改造，外部系统必须根据消息达到格式以及内容判断业务处理逻辑，从而准备处理下一个业务逻辑处理。接口1、2是采用了WebService方式进行的集成；接口3、4是采用了消息队列的方式进行的集成。WebService方式时序图：描述：假设外部系统为客户端，物流系统为服务器端，当客户端用户点击发送按钮时（或者某种操作时），调用服务器WS接口的相关功能，此时会产生一个同步的WebService请求。同时，需要将传递的数据集封装成一个标准的XML数据流，做为参数传送到服务器端。（3） 不同技术方案的时效性。消息队列WEBSERVICE轮询模式阻塞模式进行同步调用接口，则只需要同步调用即可。按照业务要求设置定时读取时间消息发送数据后马上获取，不发送数据，队列则处于等待的模式。1 5 分钟准即时既是（4） 接口数据交换格式。 TMSERPxmlPOD2009-05-30 10:10:10 false !CDATA 示例说明：约定的接口数据格式，字符集采用UTF-8，每一个消息，都包含一个消息头和消息体。消息头中包含：发送方；：接收方；：文件类型；：消息内容类型；：文件处理方法；：发送时间，格式为YYYY-MM-DD HH:MM:SS（例如2008-04-24 05:26:30）；是否BASE64编码文件，“true”表示“是”，“false”表示“否”；文件名称消息体中包含约定好的数据项内容，数据项的内容必须要达成一致。（5） 接口数据交换内容。分类报文标识报文名称方向基础信息类SHIPMENT_METHOD运输方式outboundCARRIER_INFO 承运商信息outboundRECEIVER_INFO客户交货地点inbound业务类NEW_ORDER订单创建inboundUPDATE_ORDER订单更新inboundDELETE_ORDER订单删除inboundORDER_AUDITED订单审核生效outboundSHIPMENT_CONFIRMED调度生效outboundSHIPMENT_CANCELED调度失效outboundPICKING_FINISHED拣货完成inboundSHIP发车确认outboundVEHICLE_LOCATION_UPDATE在途位置更新inboundTRANSPORTATION_ALERT在途报警inboundCARGO_ACCEPTED到货确认inboundTMS_DATA物流执行情况查询outboundVEHICLE_INFO车辆inboundDRIVER_INFO司机信息outboundRFP运输询价outboundRFP_REPLY运输询价反馈inboundSHIPMENT_ORDER运输任务指派outboundVEHICLE_STATUS车辆状态更新outboundUSER用户管理inbound三、 验证的评价与建议在2009年11月24日，中烟电子商务公司召集安徽中烟，江苏中烟，上海烟草集团，福建中烟，贵州中烟, 红塔烟草集团, 红云红河烟草集团, 湖北中烟等工业公司在武汉召开了烟草工业物流信息系统数据接口规范标准编制研讨会。通过调研，与会专家有如下评价和建议：1.湖北中烟走在了行业的前列；2.接口标准非常重要；3.复杂度高，与各个系统及商业企业接口；4.起点较高，基于服务（SOA）；5.范围是行业工业企业物流标准，甚至可以定位为成品标准。对应国家局即将定的工商企业标准即可;6.本标准定位为“研究标准”；7.不能用MQ之类的产品名称来定位，应该用“同步”或“异步”来定义;8.订单和物流单的关系需要理清，相关的标准国家局已经统一了;9.其他信息如车辆信息等等应参照国家局的标准来统一;10.程序只能作为例子，不能作为标准的一部分;11.标准制订过程，国家局有个规范，国标1.1格式，详细明确了制订过程中各步的动作；12.标准范围还太小，不太符合标题，可以考虑缩小标题范围或扩大标准的范围;13.规范化建议：去掉无用的术语定义，如MQ等；建议把标准中涉及的ERP等系统改为“外部系统”；“国家局编码”改为“行业编码”；建议在标准中增加报文的检索目录；建议减少口语化文字；14.适用性问题，在接口方式的选择上多一些包容性的方案。有很多中间表之类的方法，也应有所涉及;15.涉及到技术的版本，建议取消，以保持长效;16.重发机制还应考虑更全面，如消息体错误等;17.考虑接入系统较多，方式复杂的情况，增加一些接口增加的管理内容，接入的审批流程，安全评估流程和标准;18.对于软件的部署方式也考虑做一些规范；19.通讯的安全应加以考虑；20.增加一些校验字段之类的手段；21.目前全国公司的管理模式不太一样，标准应多一些兼容性;22.建议标准往供应链上流延伸;23.注重协调。一个是与已有标准的协调，再有就是与其他正在制订的标准项目组协调;24.与第三方承运商对接的问题；25.订单和调度之间的界限;26.应定位于框架性标准。物流管理信息系统和业务信息系统;27.在途项目中的一些内容可以直接引用。由物流分标委协调;28.与各个管理系统的接口还要再加以描述;29.格式按照GB1.1进行编制。四、 验证结论完成了对标准的预研。 通过研讨会，收集了各方行业专家的意见，完成了对卷烟工业企业物流信息系统接口标准的预研，得出的结论是：1.该标准和卷烟工商在途接口标准有部分重合，需要缩小标准的范围，范围是行业工业企业物流标准，可以定位为成品标准