业务背景
- 场景一:产成品以重量计量,生产汇报入库数量以车间现场称重为准,比如生产胶带、原纸等产品,产品下线后使用地磅称重,按照实际称重数字作为生产完工数量。
- 场景二:ERP系统中进行业务操作,需要读取本地硬件数据,如加密卡、IC卡等,以读取到的信息作为解码依据或身份认证等,例如严格控制领用的材料需要操作人员刷卡认证身份进行领料。
- 场景三:ERP系统操作时,需要读取本地系统的配置文件或数据文件,该文件在不同客户端存在差异且与操作终端有绑定关系,无法直接在在ERP系统中配置。
以上业务场景都涉及到本地文件或硬件的读写操作,但是苍穹平台的插件等都是运行在服务端,无法直接读取、操作操作本地资源。
解决方案
面对无法直接解决的问题,最简单的方法就是加一层;在本地运行一个服务,对内可以直接操作本地资源,对外提供API接口供ERP系统调用。将直接操作本地文件或硬件转换为可被调用的WebAPI接口,星瀚或AI套件就可以直接调用接口来满足业务需求。
本文以一个具体项目读取地磅数据需求为例,应用灵基开发本地服务程序。
具体实现
- 进入灵基,切换到“开发”,新建会话,选择“通用应用”,直接提出开发需求。如
开发一个Windows桌面程序,使用WinForms框架,需要在Windows系统上长期运行;功能要求:1、com口取数:1.1、从本地com串口读取称重数据,并按照串口配置解析成有效重量值,按照kg显示;1.2、提供com口参数配置界面,端口名(如 `COM3`)、波特率(默认 9600)、数据位(默认 8)、校验位(None/Odd/Even/Mark/Space)、停止位(1 / 1.5 / 2)、流控(None/XOnXOff/RTS/RTS+XOnXOff)、读写超时;在配置界面可以对串口读数进行测试;并且可以将配置信息在本地进行存储;1.3、每次运行程序自动加载默认配置,并且检查端口是否存在、是否被占用,给出明确中文报错(占用 / 设备未连接 / 超时)。2、对外提供WebAPI接口:2.1、以WebAPI方式对外提供接口,并且可以对接口端口配置,所有接口以JSON格式返回信息;2.2、接口需要实现ApiKey鉴权,在请求头`X-Api-Key` 或 query `?api_key=` 取 Key,需匹配,否则返回401错误,ApiKey 存放在服务配置文件,且可在「服务配置」界面设置/修改;2.3、需要对外提供健康检查、获取串口信息、获取称重数据的接口;2.4、接口的配置信息必须在本地保存,并且提供接口启动、停止功能。3、日志:需要对程序的启动、退出记录,对WebAPI启停、接口调用进行详细记录,包括请求报文、返回报文;所有的日志必须带时间戳,日志存储位置{程序目录}/logs/yyyy/MM/yyyy-MM-dd.log,按天分文件,含 INFO/WARN/ERROR 与异常堆栈。日志写入失败不能影响主流程。4、界面要求:4.1、按照经典windows应用程序布局,顶部菜单栏,包含文件(退出、关于按钮)、服务(配置WebAPI、启动、停止)、串口(串口配置、打开、关闭);中间显示快速功能按钮(打开串口、关闭串口、启动服务、停止服务、服务配置、串口配置)以及状态卡片、服务日志区(可滚动);4.2、实现系统托盘图标显示,托配图标实现右键菜单(显示窗口、退出),双击图标可以快速恢复窗口显示;4.3、点击主界面右上角的叉号不退出程序,要将窗口隐藏至系统托盘;4.4、点击退出时需要二次确认,并且在确认界面上默认选中“否”防止误操作,在系统退出时同时关闭WebAPI服务,关闭com口连接。5、部署要求:最终程序可以打包成为一个exe文件,可以直接在windows系统上运行,不依赖于其他应用或服务。

2. 按照需求,灵基将整体开发拆分为8个步骤执行

执行完成后,将所有实现功能及发布的文件全部列出:

3. 到项目路径下可以看到C#功能,可以直接使用VS打开。在发布路径下可以看到编译后的应用程序,起作用config文件夹存储串口和WebAPI配置,logs文件夹为按照日期存储的日志,这两个文件夹在应用程序运行时会自动创建。

4. 运行应用程序可以单到程序主界面,已经按照需求布局,进入服务配置、串口配置可以进行参数配置,并且配置完成后自动存储到config文件夹下。



5. 启动服务后,用postman、Apifox之类的工具可以直接调用


6. 后续只需要在ERP的生产汇报单等单据中开发插件,按需要调用接口即可获取到业务数据。
应用效果
- 通过灵基开发本地服务即可实现将对本地文件或硬件的操作转换为接口调用方式,解决苍穹操作本地资源的需求。
- 通过本文演示,可以看到灵基可以同时满足苍穹应用开发以及通用应用开发两种不同的模式,在项目交付过程中一个AI平台即可实现不用的开发场景。
经验总结
- 对于通用应用开发,在选择技术框架时需要考虑现场的实际应用场景,如涉及到本地资源的操作使用winforms更方便一些。
- 在进行开发需求描述时,尽量详细的描述需求,比如功能性要求、界面要求、非功能性要求(如日志、界面等)、部署要求。
- 对于此类需要在现场长期运行的小程序或服务,尽量选用成熟稳定的技术方案,并且打包成一个直接拷贝即可运行的应用程序,尽量减少后期的部署、运维工作量。
1358



被折叠的 条评论
为什么被折叠?



