本文将从用户角度介绍 Shipment Verification 的运用场景,该场景中涉及到两个供应商和两个零售商之间使用 Shipment Verification 进行运输、收货的过程,以及这个过程需要的所有的配置。
Shipment Verification 是基于 IBM WebSphere RFID Information Center(RFIDIC) 的应用系统。该应用面向供应链领域,是 IBM RFID Solution 的方案之一。
Shipment Verification 使得供应链运输双方(运输方和接收方)能够实时查看所有运输和接收商品的列表、以及每一类商品的状态,极大地提高企业供应链运输双方之间信息的可见性,使得整个供应链可以更好的整合,达到增加供应链反应速度、提高客户满意度、以及减少成本等目的。
本文将从用户角度上介绍 Shipment Verification 的运用场景,该场景中涉及到两个供应商和两个零售商之间使用 Shipment Verification 进行运输、收货的过程,以及这个过程需要的所有的配置。
![]() ![]() |
![]()
|
图 1. Shipment Verification 的组件结构

由上图我们可以看出 Shipment Verification 系统建立在 RFIDIC 的基础上。Shipment Verification 应用于供应链运输的交易双方,我们结合运输方运输与接收方接收这两个业务来进一步描述 Shipment Verification 的运行机制。
运输方执行运输业务流程的时候,相应的 EPCIS Event 将从“Premises Server”产生,并存放入运输方的 RFIDIC 的 MQ 中,该事件将被 RFIDIC 捕获,经过 TDI Assemble Line 解析,并最终存放入运输方的 RFIDIC 的数据库中。这时可以从运输方的 Shipment Verification 的“Shipment Verification Dashboard”中查看到运输列表及其状态,状态应为“正在运输中”。
由于供应链上下游的不同 RFIDIC 系统之间由于存在业务关系,所以互相注册了相关的 subscribe query。subscribe query 根据配置会间隔一段时间运行,并会把最终的查询结果 (Query Response) 返回到相应的目的地址。在 Shipment Verification 中,接收方在运输方注册了 subscribe query,查询的返回结果会被接收方的“HTML Listener”接收,并存入接收方的 RFIDIC MQ 中,该事件列表将被 RFIDIC 捕获,经过 TDI Assemble Line 解析,并最终存放入接收方 RFIDIC 的数据库中。这时可以从接收方的 Shipment Verification 的“Expected Received Dashboard”中查看到接收物品列表及其状态,状态应为“正在运输中”。
接收方执行接收业务流程的时候,相应的 EPCIS Event 将从“Premises Server”产生,并存放入接收方的 RFIDIC 的 MQ 中,该事件将被 RFIDIC 捕获,经过 TDI Assemble Line 解析,并最终存放入接收方的 RFIDIC 的数据库中。这时可以从接收方的 Shipment Verification 的“Expected Received Dashboard”中查看到接收物品列表及其状态,状态应为“运输完成”。
运输方在接收方 RFIDIC Server 上注册的 subscribe query 根据配置会间隔一段时间运行,并会把查询结果 (Query Response) 返回到相应的目的地址,即运输方。在 Shipment Verification 中,返回的结果会被运输方的“HTML Listener”接收,并存入运输方的 RFIDIC MQ 中,该事件列表将被 RFIDIC 捕获,经过 TDI Assemble Line 解析,并最终存放入运输方 RFIDIC 的数据库中。这时可以从运输方的 Shipment Verification 的“Shipment Verification Dashboard”中查看到运输列表及其状态,状态应为“运输完成”。
通过这种结构,供应链运输业务交易双方能够及时地获取到对方 RFIDIC Server 中相关的 EPCIS Event 数据,及时地查看到运输货物列表及其状态。
具体的过程以及显示的界面和结果,在下面的应用场景中有详细的描述和介绍。
![]() ![]() |
![]()
|
假设存在两家供应商 (Shipper1 和 Shipper2), 和两家零售商 (Receiver1 和 Receiver2)。它们之间存在业务往来,我们使用 RFIDIC 和 Shipment Verification 来实施他们之间的运输流程。
下图是供应商 Shipper1 的基于地域的组织结构图,图中 Shipper1 有两个工作地点,其中 Shipper1_Picking & Packing 是进行拣货、包装的场所,包装后的产品会运往下一个工作地点 Shipper1_Shipping 进行运输。
图 2. 供应商 Shipper1 的基于地域的组织结构图

Shipper2 的组织结构和 Shipper1 类似,如下图所示:
图 3. 供应商 Shipper2 的基于地域的组织结构图

下面两张图是供应商 Receiver1 和 Receiver2 的基于地域的组织结构图。其中 Receiver1 只有一个工作地点:Receiver1_Receiving,它用于从接收供应商运输过来的产品。Receiver2 的组织结构也类似。它们分别如下图所示:
图 4. Receiver1 和 Receiver2 的基于地域的组织结构图

下图是整个应用场景的流程图,所有的业务流程分别属于两个供应商 Shipper1, Shipper2 和两个零售商 Receiver1,Receiver2。
- 图中“ Commission1”,“Aggregate1”,“Shipping1”业务是属于 Shipper1,其中“ Commission1”,“Aggregate1”业务是在“Shipper1_Picking & Packing”场所进行,“Shipping1”业务是在“Shipper1_Shipping”场所进行。
- 图中“ Commission2”,“Aggregate2”,“Shipping2”业务是属于 Shipper2,其中“ Commission2”,“Aggregate2”业务是在“Shipper2_Picking & Packing”场所进行,“Shipping2”业务是在“Shipper2_Shipping”场所进行。
- 图中“ Receiving1”业务是属于 Receiver1,并在“Receiver1_Receiving”场所进行。
- 图中“ Receiving2”业务是属于 Receiver2,并在“Receiver2_Receiving”场所进行。
图 5. 整个应用场景的流程图

![]() ![]() |
![]()
|
整个用户场景需要四台计算机,两台用于模拟两个供应商,两台模拟两个零售商。这四台机子分别安装 IBM RFID Information Center1.0.0.0 和 Shipment Verification1.0.0.0,之后下载下面的链接文件,并保存到这四台机子的 $RFIDIC_HOME/sv_scenario 中。sv_scenario 的文件结构如下表所示:
文件夹 | 描述 |
event_data | 模拟的 RFID 事件文件 |
mdm_data | 本文的用户场景需要的 master data |
security | 供应商和零售商之间用于权限控制的 Policy 文件 |
query | 供应商和零售商之间进行 subscribe query 的查询文件 |
sql | 常用的 sql 语句 |
安装完 RFIDIC1.0.0.0 以及 Shipment Verification1.0.0.0 以后,需要为应用导入 Master Data。Master data 相对于 Event Data 来说是辅助数据,它为 Event Data 中的字段提供了上下文的作用。RFIDIC 中 Master Data 有以下三种:
- Location Master Data
- Product Master Data
- Vocabulary
本文的例子所需的 Master Data 以及每一个 master data 文件的含义如下表所示,这些文件位于 $RFIDIC_HOME/sv_scenario/mdm_data 目录下面。
Master data file | 描述 |
1_locations.xml | Location master data |
2_readpoints.xml | Read point master data |
3_products.xml | Product master data |
4_locationHierarchy.xml | Location Hierarchy master data |
5_productHierarchy.xml | Product Hierarchy master data |
6_standardVocabularies.xml | 标准的 vocabulary |
7_userVocabularies.xml | 用户扩展的 vocabulary |
导入 Master Data 可以使用 RFIDIC 的安装目录下的一个 Shell 命令进行导入,即 $RFIDIC_HOME/bin/import-masterdata.sh 命令,但该命令一次只能导入一个 Master Data 文件。本文的例子中使用了一个 Shell 脚本来导入所有的 Master Data,脚本中依次导入所有的 Master Data。脚本位于 $RFIDIC_HOME/sv_scenario/mdm_data/importAllMasterdata.sh,执行该脚本将导入所有所需的 master data。
RFIDIC 和 Shipment Verification 的安全配置包括两个部分:用户验证,权限。下面分别来介绍这两个部分的配置:
- 用户验证
用户验证设置哪些用户可以访问 RFIDIC 和 Shipment Verification,可以通过配置 WebSphere Application Server 的验证机制来达到用户验证的目的。
- Enable Global Security 以及 user registry 配置
在代表供应商和零售商的四台 RFIDIC Server 中,访问 WebSphere Application Serve 的 console 页面,打开 Security->Global Security 配置页面,选上“Enable global Security”,选择 Active user registry 为“Local OS”。配置后的页面如下图所示(该配置重启后生效):
图 6. 配置后的页面

- Map security roles to users/groups
- 在两台供应商 (Shipper1,Shipper2) 的 RFIDIC Server 中,创建操作系统用户 receiver1, receiver2 和组 receiver1, receiver2,并且 receiver1 用户属于 receiver1 组,receiver2 用户属于 receiver2 组。访问 WebSphere Application Serve 的 console 页面,在Enterprise Applications > com.ibm.rfidic.webEAR > Map security roles to users/groups 配置页面中,依照下图进行配置:
图 7. 配置页面

- 在两台零售商 (Receiver1,Receiver2) 的 RFIDIC Server 中,创建操作系统用户 shipper1, shipper2 和组 shipper1, shipper2,并且 shipper1 用户属于 shipper1 组,shipper2 用户属于 shipper2 组。访问 WebSphere Application Serve 的 console 页面,在 Enterprise Applications > com.ibm.rfidic.webEAR > Map security roles to users/groups 配置页面中,依照下图进行配置:
图 8. 配置页面

- 在全部的四台 RFIDIC Server 中,访问 WebSphere Application Serve 的 console 页面,在 Enterprise Applications > com.ibm.rfidic.pharma.shipverEAR > Map security roles to users/groups 配置页面中,依照下图进行配置:
图 9. 配置页面

- 权限
Shipment Verification 的权限机制是建立在 RFIDIC 的基础上,它本身并没有权限控制。本文为 Shipper1,Shipper2,Receiver1,Receiver2 定义了 Policy 配置文件,可以通过 RFIDIC 的 Security Policy Editor 的 Import 操作导入到 RFIDIC 中。下表描述了不同的 RFIDIC Server 对应的 Policy 配置文件,这些配置文件在 $RFIDIC_HOME/sv_scenario/security/ 目录下:
Policy 文件 | RFIDIC Server |
securityPolicyShipper_On_Receiver1.xml | 导入 Receiver1 的 RFIDIC Server 中 |
securityPolicyShipper_On_Receiver2.xml | 导入 Receiver2 的 RFIDIC Server 中 |
securityPolicyReceiver_On_Shipper1.xml | 导入 Shipper1 的 RFIDIC Server 中 |
securityPolicyReceiver_On_Shipper2.xml | 导入 Shipper2 的 RFIDIC Server 中 |
我们以 Shipper1 为例子,介绍如何导入 securityPolicyReceiver_On_Shipper1.xml policy 文件。
- 访问http://shipper1:9080/com.ibm.rfidic.web/admin 弹出下面的对话框,输入 rfidic 用户及其密码,按确定按钮登录。
图 10. 登录

- 访问 Security Policy Editor,选择 Import 操作,并选择
“securityPolicyReceiver_On_Shipper1.xml” policy 文件,界面如下图所示:
图 11. Import 操作

- 选择 Import 按钮,执行导入 policy 操作,成功后界面如下所示:
图 12. 操作成功

- Subscription query
RFIDIC Server 的查询接口遵循 EPCIS 的规范,不同的 EPCIS Server 之间通过 query 接口相互交互,获取权限控制以内的数据,这些数据包括 Master Data 和 Event Data。在 Shipment Verification 应用中,为了及时获得供应商和零售商之间的业务信息,交易双方在对方的 EPCIS Server 上注册了 subscribe query。通过这种查询,可以周期性地查询交易对方的 EPCIS Server,并发送需要的数据到自身的 EPCIS Server 中。下面的表格中描述了供应商和零售商之间注册的 subscribe query,这些 subscribe query 的查询文件在 $RFIDIC_HOME/sv_scenario/query 目录下。
注册的 RFIDIC Server | subscribe query | Description |
Receiver1, Receiver2 | Shipper1_queryRequestOnReceiver.xml | Shipper1 在 Receiver1/Receiver2 的 RFIDIC Server 上注册的 subscribe query |
Receiver1, Receiver2 | Shipper2_queryRequestOnReceiver.xml | Shipper2 在 Receiver1/Receiver2 的 RFIDIC Server 上注册的 subscribe query |
Shipper1, Shipper2 | Receiver1_queryRequestOnShipper.xml | Receiver1 在 Shipper1/ Shipper2 的 RFIDIC Server 上注册的 subscribe query |
Shipper1, Shipper2 | Receiver2_queryRequestOnShipper.xml | Receiver2 在 Shipper1/ Shipper2 的 RFIDIC Server 上注册的 subscribe query |
这些 subscribe query 文件中的 标签中填写的值是相应 subscribe query 返回查询结果的目标地址。比如:Shipper1_queryRequestOnReceiver.xml 中的 应该填写http://shipper1:9080/HttpToMQ/EPCISQueryResults,其中 shipper1 表示 shipper1 的 IP 地址。其它的 subscribe query 文件类似。
![]() ![]() |
![]()
|
通过这一篇文章,介绍了基于 IBM RFID Information Center1.0 的应用系统 Shipment Verification 的结构、应用的业务场景、安全配置等。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9403012/viewspace-161/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/9403012/viewspace-161/