Shipment Verification 的应用过程

最新推荐文章于 2025-12-27 15:45:53 发布
转载 最新推荐文章于 2025-12-27 15:45:53 发布 · 236 阅读 · 0
文章标签：

#java #数据库 #操作系统

介绍

本部分主要来介绍 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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9403012/viewspace-162/

ciyi7513
关注
软件测试英语单词词汇
送你一匹马
02-01 2542
软件测试英语单词 Acceptance testing : 验收测试 Acceptance Testing：可接受性测试 Accessibility test : 软体适用性测试 actual outcome：实际结果 Ad hoc testing : 随机测试 Algorithm analysis : 算法分析 algorithm：算法 Alpha testing : α测试 ...
SAP License：SAP MM中的几个概念
SAP权限管控|SAP用户权限管理|SAP权限合规检查|SAP全日志管理
03-12 426
库存类型与库存状态是库存的两个不同属性，如颜色与尺寸可以用来描述同一个物料,这里的库存类型可分为寄售、自有等，库存状态分为：非限制、冻结、质检等。 库存类型有：公司库存、供应商寄售库存、寄存在客户的库存、供给供应商/分包商的库存、按业务分配的销售订单库存与项目库存。 库存状态有：非限制库存、质检库存、冻结库存、退货库存、转移中的库存、在运库存、限制使用的库存。 相关问答： 1、问：“ 101收货同样可以收货到质检和冻结，GR Blocked Stock收货和101收货到冻结有什么区别？ GR Block
Shipment Verification 的运用场景
ciyi7513的博客
07-14 337
本文将从用户角度介绍 Shipment Verification 的运用场景，该场景中涉及到两个供应商和两个零售商之间使用 Shipment Verification 进行运输、收货的过程，以及这个过程需要的所有的配置。 介绍...
深入解析区块链技术应用：从理论到Python实践
闲人编程的博客
08-27 925
区块链技术已经从加密货币底层发展为多行业基础设施。本文系统解析了区块链的核心原理和应用场景，并提供了Python实现示例。内容包括：1）区块链基础概念与密码学原理（哈希函数、非对称加密等）；2）Python实现的区块链核心结构（交易、区块类和完整区块链类），涵盖交易签名验证、工作量证明挖矿等关键功能。文章通过代码演示了区块链从理论到实践的实现过程，包括创建创世区块、交易验证和区块链维护机制，为开发者提供了实用的技术参考。
Spree工作流引擎：业务流程自动化配置
gitblog_00882的博客
08-29 600
Spree作为一个成熟的开源电商平台，其核心优势之一就是强大的工作流引擎系统。该系统通过状态机（State Machine）机制，为订单处理、支付流程、物流配送等关键业务环节提供了高度可配置的自动化工作流解决方案。 ## 核心工作流组件 ### 1. 订单状态机（Order State Machine） Spree的订单工作流采用基于状态机的设计模式，定义了完整的购物车到订单完成的业务流程：...
SAP 经常使用T-CODE
少年休闲海
04-30 8471
Plant Maintenance (PM)IW32 - Change Plant Maintenance Order IW33 - Display Plant Maintenance Order IW34 - Create Notification Order IW51 - Create Service Notification IW52 - Change Service Notificatio...
软件测试专业英语应用
weixin_30553777的博客
10-31 269
Acceptance testing : 验收测试 Accessibility test : 软体适用性测试 Ad hoc testing : 随机测试 Algorithm analysis : 算法分析 Alpha testing : α测试 Anomaly : 异常 Artifact : 工件 Automated Tes...
快时尚电商行业智能体设计思路与应用实践（一）借助超长上下文窗口分钟级构建智能客服系统
亚马逊云科技专栏
06-19 1194
本文探讨了快时尚电商行业智能客服系统的设计思路和实现方法，重点介绍了如何利用超长上下文能力快速构建智能客服。文章分析了智能体设计模式，包括功能需求维度、推理策略维度和知识获取维度，并详细阐述了智能客服系统的流程架构和数据管道设计。最后，通过基于 Amazon Bedrock 中的多个模型，展示了如何分钟级快速构建智能客服原型系统。针对智能客服系统，使用了多个不同的大模型（Nova Premier、Palmyra、Nova Lite、DeepSeek-R1），通过具体对话示例，对应答效果进行了对比分析。
软件测试英语词汇
CealWang的博客
03-02 3616
软件测试英语专业词汇 NLV：Nation Language Version 本地化版本 FVT：Functional Verification Testing 功能验证测试 TVT：Translation Verification Testing 翻译验证测试 SVT：System Verification Testing 系统验证测试 fault－－故障 在软件中一个错误的表现。 fe...
软件测试中英文词汇
李丽军 @ IBM-FileNet
04-07 2136
Acceptance testing : 验收测试Acceptance Testing：可接受性测试Accessibility test : 软体适用性测试actual outcome：实际结果       Ad hoc testing     : 随机测试Algorithm analysis : 算法分析algorithm：算法       Alpha testing      : α测试ana
DDR IP设计流程
02-15
### DDR IP 设计流程 #### 1. 需求分析与规格制定 在DDR IP设计初期，需明确目标应用的具体需求和技术指标。这包括但不限于数据传输速率、功耗要求以及接口兼容性等特性[^2]。 #### 2. 架构规划 基于前期的需求...
SAP 常用T-CODE
热门推荐
Summit
04-20 1万+
Plant Maintenance (PM) IW32 - Change Plant Maintenance Order  IW33 - Display Plant Maintenance Order  IW34 - Create Notification Order  IW51 - Create Service Notification  IW52 - Change Service
gmp php study,[技术干货] USP中文翻译连载 | 产品生命周期的包装密封性检查 (1、2之3)...
weixin_29447621的博客
03-22 1691
最近几次在客户GMP检查现场，充分感受到无菌产品包装密封性检查和验证的重要性，而国内又没有细致的无菌包装指南，USP<1207>这些年持续更新，完整细致且技术指导性较强，特此进行翻译，以饷洛施德GMP咨询公众号的读者。无菌产品包装密封性是无菌保证的重要环节，其密封性保证方式也是无菌产品GMP检查的必然关注点。近年来随着包装密封性检测技术的快速提升，法规也同步保持更新。特别是USP&lt...
点赞系统问题
amdkk的博客
12-26 797
​​：Spring Pulsar 提供的接口，允许通过customize方法深度定制消费者行为。批量接收策略配置。：控制批量消息接收策略maxNumMessages：单次批量拉取多少条信息timeout：超时后触发批量处理。NACK重试策略当消费者调用时触发重试。：消息重投递的退避策略接口。.minDelayMs(1000) // 初始延迟 1 秒 .maxDelayMs(60000) // 最大延迟 60 秒 .multiplier(2) // 指数退避倍数。
电子书《Java编程思想（第4版）》
吴名氏的博客
12-23 5766
电子书《Java编程思想（第4版）》
计算机毕业设计|基于springboot + vue健康茶饮销售管理系统(源码+数据库+文档)
12-24 861
本文介绍了基于SpringBoot+Vue的健康茶饮销售管理系统开发。系统采用前后端分离架构，后端使用SpringBoot框架简化配置，前端采用Vue实现组件化开发，数据库选用MySQL。文章详细说明了系统设计原则、技术选型理由，并提供了代码示例和测试案例。系统功能完整，包含商品管理、用户认证等模块，通过严格测试确保安全性。文末附有源码获取方式和最新毕设选题推荐，适合作为计算机专业学生的项目参考。
抽象类和接口的区别
最新发布
tryxr的博客
12-27 596
本文对比了Java中接口（Interface）与抽象类（AbstractClass）的8个核心区别。主要差异包括：抽象类使用abstract class定义，支持单继承，可包含实例字段和构造器，体现"is-a"关系；接口使用interface定义，允许多实现，仅包含常量，体现"can-do"能力。抽象类适合共享代码和状态，接口适合定义跨类能力。建议优先使用接口定义能力，仅在需要共享状态或实现模板方法时使用抽象类，并考虑组合优于继承。二者可结合使用，如Shape抽象类实
通过adb命令获取某个window或View/子View的绘制内容并输出为png图片的方法
Railshiqian的博客
12-23 968
本文介绍了通过adb工具获取Android系统Window和View结构的方法。首先需要建立adb与ViewServer的连接（端口4939），然后通过"LIST"命令获取可dump的窗口列表，再使用"DUMP [窗口ID]"命令查看指定窗口的View树结构。该方法可帮助开发者分析应用界面问题，替代已废弃的Hierarchy View工具。示例展示了如何获取系统导航栏TopCarSystemBar的View层级信息，包括ViewGroup的各种属性和状态。
mybatis-plus插件解决sql报错：this is incompatible with sql_mode=only_full_group_by ”
吉他程序员的博客
12-23 260
解决的办法可以改sql，也可以改sql服务的conf配置， 但是如果你项目用的是mybatis-plus插件 ， 就可以用我介绍的很简单的方法。是 MySQL 的严格模式要求，确保 GROUP BY 查询的语义明确。这个错误是 MySQL 5.7+ 版本中最常见的兼容性问题之一。SELECT 列表中的列不在 GROUP BY 子句中。MySQL 无法确定从分组中的哪行返回这些列的值。且这些列也不是聚合函数的参数。然后重启项目就可以了。
axi verification ip 使用
01-08
### 使用 AXI Verification IP 进行验证的设计实例 #### 创建 Vivado 工程并添加 AXI VIP 为了使用 AXI Verification IP (VIP) 对 AXI4 或 AXI4-Lite 接口进行验证，在 Vivado 中创建一个新的工程，并通过块设计...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值