网上报检系统升级方案.doc

天津边检总站网上报检系统升级方案 升级目的 充分总结我总站网上报检系统四年来的使用情况及业务变动等新的需求，对软件系统及部分配置进行改造，以更好地实现预检数据准确导入梅沙系统，提高报检效率。 二、业务需求 修改现有系统的回执签发模式，在客户端打开接收到的单据后，增加“通过”、“不通过”、和“退回重发”三个按钮点击后相应信息反馈至代理客户端，同时取消原有的反馈内容填写栏。点击“不通过”后，该单据将不得修改重发，如有需要代理端只得重新填写。另外，在单据入库后，自动向电子口岸发“接收成功”反馈信息。有效库、无效库文件名及内容可在管理界面（增加）查询，方便问题查找。 将现有冷备模式变为双机热备，实现数据实时同步 对网络设备进行配置，在主机出现故障时，可通过修改相关参数，直接切换至备用服务器，减少电子口岸切换的中间环节。 针对服务器运行正常，但部分服务出现异常、磁盘空间不足、日志文件过大等情况，拟开发相应监控软件，以便及时发现问题，并反馈至值班人员客户端，形成报声音报警提示 增加磁盘空间等自动清理模块，可手工操作，界面化管理。 三、升级内容 （一）关于退回重发业务逻辑的调整 增加预报授权模块，添加增加授权，取消授权功能，以便检查员可以对于有多次预报需求的代理通过授权的方式允许其多次进行申报。对于其他代理仍沿用现有模式以降低检查员的工作量。 增加基于回执签发模式的业务按钮，取消现有的业务回执由检查员手工填写的模式，新增的按钮类型为已通过预检，已收到申报，退回重发三种方式。对于多次提交的同批次数据，处理逻辑为覆盖原有。 重新设计现有的日志处理模块，按照处理逻辑细分工作流阶段为已接收，验证失败，验证成功，已收到申报，退回重发，已通过预检，记录每个阶段的转乘日志，以方便检查员能清晰的反馈代理提交信息的处理情况，增强执法效率。 现有网上报检系统架构与EDI的接口处理 现有的网络架构中梅沙系统接口服务器与EDI那里没有中间过渡层，结果导致现有系统想做备份切换，必须我们切换服务器，同时EDI那里也要做接口服务器的切换，使得现有的双机备份方式形同虚设，因为EDI那里修改访问梅沙系统的接口服务器步骤较为繁琐，同时一次切换需要两个不同的地方同时都要修改也与应急备份的宗旨不符。为此，本次升级建议将架构修改为使用NAT的方式在防火墙与梅沙系统接口服务器间进行地址转换，这样，用最经济安全的手段实现了我们系统备份的切换与EDI方面的剥离。系统做切换时只需修改我们防火墙的映射地址即可。 （三）现有的冷备份方式转为热备份方式 网上报检系统如果要将现有的冷备份模式转为热备份模式，需要开发新的数据同步程序，现有的技术无法直接使用。程序开发涉及到2个模块： EDI数据分发模块，处理EDI上传数据的本地服务器分发，其功能包括，检索EDI提交的报文信息 服务器数据接收处理模块，处理接收到EDI报文，并将处理结果进行本地数据库之间的异步同步。 从而实现所有已处理和未处理数据的双机实时备份。 （四）增加服务器自动管理系统 现有的服务器管理模式对于系统管理员的要求较高，而且不便于及时发现问题，为此技术处提出了增加服务器自动管理系统的要求，经过我们的技术论证，决定开发以下模块以实现系统的自动管理： 在服务器端增加后台管理守护进程 该守护进程具备以下功能： 通过设定策略监控磁盘空间和系统日志，对于出现异常的磁盘空间或者系统日志，按照既定策略予以自动处理。 监控系统后台进程的运行状况，对于异常中断的进程进行自动重启， 监控数据库表空间，对于异常的表空间，向前台报警中断发送提示报警。 提供系统运行报告 增加报警客户端 该客户端具备以下功能 后台异常状况的自动处理信息查看。 服务器系统运行状况查看 监控历史数据查询 （五）EDI回执报文格式 接口报文的文件名称规则： 报文类型 文件命名模式 说明 回执报文 HZ+年月日时分秒毫秒 接口报文的内容组织格式说明： 报文的内部数据根据前导符来确定记录的类型（所谓前导符就是一行的第一个字符，参见下表）每行代表一种数据类型的一条记录，各数据项之间（不论是否为空）以’^’号分隔，最后一个数据项结束时（不论是否为空），也须在末尾处以’^’标识。 数据的前导符 数据类型 备注 @ 船舶资料记录 说明：以上前导符均为半角单字节字符。 回执格式说明： Name Comment Data Type ApplyOrderID(主键) 序号 VARCHAR2(10) ReturnContent 回执内容 VARCHAR2(4000) ReturnType 回执类型 CHAR(1)（校验为0，执法为1） ReplyUser 回执人 VARCHAR2(30) ReplyDateTime 回执时间 DATA HZKADM 回执