ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Shipment Verification 的应用过程

Shipment Verification 的应用过程

原创 Linux操作系统 作者:izhonglin 时间:2019-04-12 14:30:07 0 删除 编辑

介绍

本部分主要来介绍 Shipment Verification 的应用过程。





回页首


模拟 EPCIS Event 数据

每一步业务流程操作都会产生相应的 EPCIS Event,这些事件被 RFIDIC Event Capture 捕获并存入数据库中。由于这些事件一般是由其他系统产生,比如 Premises Server,为了简便,本文例子中用一系列的 Event Data 文件来模拟事件。Event Data 存在于 $RFIDIC_HOME/sv_scenario/event_data 目录中,包括供应商的 Commission,Aggregate,Shipping,到零售商的 Receiving 业务步骤的所有事件。下表是所有 Event Data 文件的列表及其描述:


表 1. Event Data 文件的列表及其描述
Event 文件 描述
shipper1_receiver1_commission.xml Shipper1 委托送往 Receiver1 的产品
shipper1_receiver1_aggregate.xml Shipper1 包装送往 Receiver1 的产品
shipper1_receiver1_shipping.xml Shipper1 发送送往 Receiver1 的产品
shipper1_receiver1_received.xml Receiver1 接收 Shipper1 的产品
shipper1_receiver2_commission.xml Shipper1 委托送往 Receiver2 的产品
shipper1_receiver2_aggregate.xml Shipper1 包装送往 Receiver2 的产品
shipper1_receiver2_shipping.xml Shipper1 发送送往 Receiver2 的产品
shipper1_receiver2_received.xml Receiver2 接收 Shipper1 的产品
shipper2_receiver1_commission.xml Shipper2 委托送往 Receiver1 的产品
shipper2_receiver1_aggregate.xml Shipper2 包装送往 Receiver1 的产品
shipper2_receiver1_shipping.xml Shipper2 发送送往 Receiver1 的产品
shipper2_receiver1_received.xml Receiver1 接收 Shipper2 的产品
shipper2_receiver2_commission.xml Shipper2 委托送往 Receiver2 的产品
shipper2_receiver2_aggregate.xml Shipper2 包装送往 Receiver2 的产品
shipper2_receiver2_shipping.xml Shipper2 发送送往 Receiver2 的产品
shipper2_receiver2_received.xml Receiver2 接收 Shipper2 的产品

在 $RFIDIC_HOME/sv_scenario/ 目录下存在的 myTQput.class Java 类文件用于把 Event 数据放入相应的 MQ Queue 中,相应代码使用示例如下:

java myTQput ./event_data/shipper1_receiver1_commission.xml





回页首


供应商发货

通过上面章节我们知道在供应商的发货过程中,存在三个步骤:Commission,Aggregate,Shipping。我们通过把这三个业务步骤产生的 Event Data 文件放入 MQ 队列中,来模拟每一步业务流程。文章例子采用脚本方式来运行供应商的发货过程,脚本位于 $RFIDIC_HOME/sv_scenario 目录下面,关于供应商发货的有两个脚本:

  • shipper1_receiver12_shipping.sh,这个脚本模拟供应商 Shipper1 的 Commission,Aggregate,Shipping 三个业务步骤。
  • shipper2_receiver12_shipping.sh,这个脚本模拟供应商 Shipper2 的 Commission,Aggregate,Shipping 三个业务步骤。

这两个脚本功能类似,下面是 shipper1_receiver12_shipping.sh 脚本的内容:


清单 1. shipper1_receiver12_shipping.sh 脚本
                
# 清除以前的 event 数据
echo "Cleaning up the previous result"
# 清除数据库中的 event 相关的表,相应的 sql 语句在 ./sql 目录中
dbaccess -e - ./sql/clean_events_tab.sql
# 模拟业务步骤,把相关的 event 数据发送到 mq 的 queue 中
echo "Putting data on the queue"
# 相应的 event 数据文件的含义参考上文
java myTQput ./event_data/shipper1_receiver1_commission.xml
java myTQput ./event_data/shipper1_receiver1_aggregate.xml
java myTQput ./event_data/shipper1_receiver1_shipping.xml
java myTQput ./event_data/shipper1_receiver2_commission.xml
java myTQput ./event_data/shipper1_receiver2_aggregate.xml
java myTQput ./event_data/shipper1_receiver2_shipping.xml
echo "Done Putting data on the queue"

我们在 Shipper1 和 Shipper2 分别运行完上面的两个脚本以后,分别查看相应的 Shipment Verification 系统的“Shipment Verification Dashboard”页面和运输接收方 Receiver1 和 Receiver2 的“Expected Received Dashboard”页面。

需要注意的是,由于启动的安全机制,在登录 Shipment Verification 的时候会要求输入用户名密码,这时候输入 rfidic 作为用户名,密码为 rfidic 操作系统用户的密码。

Shipper1 的“Shipment Verification Dashboard”页面链接地址为:

http://Shipper1:9080/com.ibm.rfidic.pharma.shipver/shipper/shipper.jsp 其中链接中的 Shipper1 为 RFIDIC Server 的 IP 地址。得到的结果如下:


图 1. 结果页面
结果页面


summary 中图标的含义如下:

  • 图标 :表示物品在规定的时间内没有到达目的地,数字“0”表示没有物品物品在规定的时间内没有到达目的地。
  • 图标:表示物品正在运输中,数字“2”表示有两件物品正在运输中。

图标:表示当前收到的产品,数字“0”表示当前没有产品被接收方接收到。

从结果中可以看出,当前共有两件物品正在传输中,没有已收到的物品,也没有到指定日期接收方还没有收到的物品。两件传输中的物品中,Shipper1 给 Receiver1,Receiver2 各发送了一件物品:

  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.1 是从 Shipper1 发送往 Receiver1,该条记录前面的标记运输中图标表示该物品当前还处在运输中。

物品 urn:epc:tag:pharma-96:0100.03.1731234.2 是从 Shipper1 发送往 Receiver2,该条记录前面的标记运输中图标表示该物品当前还处在运输中。

Shipper2 的“Shipment Verification Dashboard”页面链接地址为:

http://Shipper2:9080/com.ibm.rfidic.pharma.shipver/shipper/shipper.jsp 其中链接中的 Shipper2 的为 RFIDIC Server 的 IP 地址。得到的结果如下:


图 2. 结果页面
结果页面

从结果中可以看出,当前共有两件物品正在传输中,没有已收到的物品,也没有到指定日期接收方还没有收到的物品。两件传输中的物品中,Shipper2 给 Receiver1,Receiver2 各发送了一件物品:

  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.3 是从 Shipper2 发送往 Receiver1,该条记录前面的标记运输中图标表示该物品当前还处在运输中。

物品 urn:epc:tag:pharma-96:0100.03.1731234.4 是从 Shipper2 发送往 Receiver2,该条记录前面的标记运输中图标表示该物品当前还处在运输中。

运行完这两个脚本一分钟以后,供应商 Shipper1, Shipper2 中的相应的 Event 数据会作为 subscribe query 的查询结果发送到零售商 Receiver1,Receiver2 中,这样作为零售商 Reciever1 和 Receiver2 也可以知道哪些供应商给他们发送了商品。这里的一分钟是在 Receiver1, Receiver2 在 Shipper1, Shipper2 的 RFIDIC Server 中注册的 subscribe query 中的 schedule 设定的。一分钟后我们查看 Receiver1, Receiver2 的“Expected Received Dashboard”。

Receiver1 的“Expected Received Dashboard”页面的链接地址为:

http:// Receiver1:9080/com.ibm.rfidic.pharma.shipver/receiver/receiver.jsp 其中链接地址中的 Receiver1 为 RFIDIC Server 的 IP 地址。得到的结果如下:


图 3. 结果页面
结果页面

从结果中可以看出,当前共有两件物品正在传输中,没有已收到的物品,也没有到指定日期还没有收到的物品。两件传输中的物品中,Shipper1 和 Shipper2 各给 Receiver1 发送了一件物品:

  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.1 是从 Shipper1 发送往 Receiver1,该条记录前面的标记运输中图标表示该物品当前还处在运输中。
  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.4 是从 Shipper2 发送往 Receive1,该条记录前面的标记运输中图标表示该物品当前还处在运输中。

Receiver2 的“Expected Received Dashboard”页面的链接地址为:

http:// Receiver2:9080/com.ibm.rfidic.pharma.shipver/receiver/receiver.jsp 其中链接中的 Receiver2 为 RFIDIC Server 的 IP 地址。得到的结果如下:


图 4. 结果页面
结果页面

从结果中可以看出,当前共有两件物品正在传输中,没有已收到的物品,也没有到指定日期还没有收到的物品。两件传输中的物品中,Shipper1 和 Shipper2 各给 Receiver2 发送了一件物品:

  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.2 是从 Shipper1 发送往 Receiver2,该条记录前面的标记运输中图标表示该物品当前还处在运输中。

物品 urn:epc:tag:pharma-96:0100.03.1731234.3 是从 Shipper2 发送往 Receive2,该条记录前面的标记运输中图标表示该物品当前还处在运输中。





回页首


零售商收货

零售商收货只有一个业务步骤:receiving。我们通过把这个业务步骤产生的 Event Data 文件放入 MQ 队列中,来模拟该业务流程。这里也采用脚本方式来运行零售商的收货过程,脚本位于 $RFIDIC_HOME/sv_scenario 目录下面,关于零售商收货的有两个脚本:

  • shipper12_receiver1_receiving.sh,这个脚本模拟零售商 Receiver1 收到从供应商 Shipper1 和 Shipper2 运输来的货物的过程。
  • shipper12_receiver2_ receiving.sh,这个脚本模拟零售商 Receiver2 收到从供应商 Shipper1 和 Shipper2 运输来的货物的过程。

这两个脚本功能类似,下面是 shipper12_receiver1_receiving.sh 脚本的内容:

清单 2. shipper12_receiver1_receiving.sh 脚本的内容

# 清除以前的 event 数据
echo "Cleaning up the previous result"
# 清除数据库中的 event 相关的表,相应的 sql 语句在 ./sql 目录中
#dbaccess -e - ./sql/clean_events_tab.sql
# 模拟业务步骤,把相关的 event 数据发送到 mq 的 queue 中
echo "Putting data on the queue"
# 相应的 event 数据文件的含义参考上文
java myTQput ./event_data/shipper1_receiver1_received.xml
java myTQput ./event_data/shipper2_receiver1_received.xml
echo "Done Putting data on the queue"

我们在 Receiver1 和 Receiver2 分别运行完上面的两个脚本以后,分别查看相应的 Shipment Verification 系统的“Expected Received Dashboard”页面和运输发送方 Shipper1 和 Shipper2 的“Shipment Verification Dashboard”页面。

Receiver1 的“Expected Received Dashboard”页面链接地址为:

http:// Receiver1:9080/com.ibm.rfidic.pharma.shipver/receiver/receiver.jsp 其中链接中的 Receiver1 为 RFIDIC Server 的 IP 地址。得到的结果如下:


图 5. 结果页面
结果页面

从结果中可以看出,当前共有两件物品已经接收到,没有正在传输的物品,也没有到指定日期接收方还没有收到的物品。两件已经接收到的物品中,Shipper1 和 Shipper2 给 Receiver1 各发送了一件物品:

  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.1 是从 Shipper1 发送往 Receiver1,该条记录前面的标记已接收到图标表示该物品已经接收到。
  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.4 是从 Shipper2 发送往 Receiver1,该条记录前面的标记已接收到图标表示该物品已经接收到。

Receiver2 的“Expected Received Dashboard”页面链接地址为:

http:// Receiver2:9080/com.ibm.rfidic.pharma.shipver/receiver/receiver.jsp 其中链接中的 Receiver2 为 RFIDIC Server 的 IP 地址。得到的结果如下:


图 6. 结果页面
结果页面

从结果中可以看出,当前共有两件物品已经接收到,没有正在传输的物品,也没有到指定日期接收方还没有收到的物品。两件已经接收到的物品中,Shipper1 和 Shipper2 给 Receiver2 各发送了一件物品:

  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.2 是从 Shipper1 发送往 Receiver2,该条记录前面的标记表示该物品已经接收到。
  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.3 是从 Shipper2 发送往 Receiver2,该条记录前面的标记表示该物品已经接收到。

运行完这两个脚本一分钟以后,零售商 Reciever1,Receiver2 中的相应的 Event 数据会作为 subscribe query 的查询结果发送到供应商 Shipper1,Shipper2 中,这样作为供应商 Shipper1,Shipper2 也可以知道哪些零售商已经接收到了他们发送的物品了。这里的一分钟是在 Shipper1,Shipper2 在 Receiver1,Receiver2 的 RFIDIC Server 中注册的 subscribe query 中的 schedule 设定的。一分钟后我们查看 Shipper1,Shipper2 的“Shipment Verification Dashboard”。

Shipper1 的“Shipment Verification Dashboard”页面链接地址为:

http://Shipper1:9080/com.ibm.rfidic.pharma.shipver/shipper/shipper.jsp 其中链接中的 Shipper1 为 RFIDIC Server 的 IP 地址。得到的结果如下:


图 7. 结果页面

从结果中可以看出,当前共有两件物品已经接收到,没有正在传输的物品,也没有到指定日期接收方还没有收到的物品。两件已经接收到的物品中,Shipper1 给 Receiver1 和 Receiver2 各发送了一件物品:

  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.1 是从 Shipper1 发送往 Receiver1,该条记录前面的标记表示该物品已经接收到。
  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.2 是从 Shipper1 发送往 Receiver2,该条记录前面的标记表示该物品已经接收到。

Shipper2 的“Shipment Verification Dashboard”页面链接地址为:

http://Shipper2:9080/com.ibm.rfidic.pharma.shipver/shipper/shipper.jsp 其中链接中的 Shipper2 为 RFIDIC Server 的 IP 地址。

得到的结果如下:


图 8. 结果页面

从结果中可以看出,当前共有两件物品已经接收到,没有正在传输的物品,也没有到指定日期接收方还没有收到的物品。两件已经接收到的物品中,Shipper2 给 Receiver1 和 Receiver2 各发送了一件物品:

  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.3 是从 Shipper2 发送往 Receiver1,该条记录前面的标记表示该物品已经接收到。
  • 物品 urn:epc:tag:pharma-96:0100.03.1731234.4 是从 Shipper2 发送往 Receiver2,该条记录前面的标记表示该物品已经接收到。




回页首


小结

文章介绍了 Shipment Verification 的应用,详细介绍了该应用的每一个步操作,产生的结果,以及对结果的分析。

通过上面的步骤,运输的供应方和接收方都可以通过 Shipment Verification 应用较实时地了解双方所有运输的产品集合和运输状况,这样有效的对运输活动进行了校验,减少了运输活动过程中失误、货品丢失等情况,并可以对运输双方的数据进行了有效的整合,提高了客户的满意程度。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9403012/viewspace-162/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2007-08-16

  • 博文量
    40
  • 访问量
    28975