统一接口现场问题排查及解决方案（干预）
2024-01-22 13:39:06 19 举报AI智能生成
登录查看完整内容
统一接口现场问题排查及解决方案（干预）是一种针对现场设备或系统的统一接口问题进行快速定位和解决的方法。它通过对现场设备的监控和数据分析，发现并定位问题，然后通过干预措施对问题进行处理，以恢复设备的正常运行。这种方法能够有效地提高设备的可靠性和稳定性，减少故障发生的可能性。此外，它还能够帮助维护人员更好地了解设备的运行状态，及时发现潜在的问题，为设备的维护和升级提供有力的支持。总之，统一接口现场问题排查及解决方案（干预）是一种高效、可靠的方法，能够为现场设备的运行和维护提供有力的保障。
作者其他创作
大纲/内容
处理：查看校验工具，相应调用的错误信息，或统一接口日志，基本上给的比较明确
分类一：调用删除接口异常
处理：确认实际调用方式，查找xml，以及查找【正确的实际调用顺序】和明确【准确调用时间】，以及提供【患者号】
分类二：不是调用删除，而通过其他途径想达到删除处方、删除单药、删除组、部分删除
删除相关问题
处理：开控制台，network下勾选☑️disable_cache 并刷新，再看
原因一：前端缓存
处理：确认换包范围：后端jar包，前端静态资源statics是否均已按照需要替换
原因二：包未更新
处理：检查部署，包名等
原因三：后端部署或其他配置错误
现场接口程序与demo不一样
处理：参见上述【概念及配置介绍-三种接口请求方式】，要求his开发对照检查，或请他们自己百度
原因一：his推送方式出错，如his收到xxx错误等
处理：对比校验工具请求时间、请求返回的错误信息（不是校验报告）。确认原因后调整接口程序相应配置项或找his调整他们的相关限制
原因二：双方超时设置、网络设置等
postman测正常但his推失败
步骤一：确认要达到的效果，务必把业务需要，转换成接口对接的，自己表述一遍，理清思路
参见上述 【事中场景-专项功能操作-报文字段修改】，包括字段增加、移除、拷贝、重命名等执行顺序，都有详细介绍
步骤二：结合现有配置，测试是否满足需要
步骤三：慎重考虑配置后影响范围
希望特殊处理哪个入参或出参
（浅）接口调用层问题思路
step1 根据患者号、处方/医嘱号和时间，查找接口校验工具对应数据是否同时有正常给到干预和审方，并确认相关配置。包括相应明细内容是否有发过删除接口、数据有效接口等
step2 点击详情，查看具体给到干预和审方xml是否在有疑问的数据项上完全一致
step3 如不一致，结合接口配置情况后还有疑问的作为接口支持问题上报；如一致，校验工具展示的内部调用数据和业务系统上数据项显示不同，则作为相应干预或审方问题上报
1、怀疑审方、干预在没有合理原因下数据不一致
step1 根据患者号和时间，查找干预里是否有这条数据，对应警示信息等级是否正确
step2 如果干预没有，根据患者号和时间，在校验工具（2.5接口的话后台看接口日志、备份文件）查找对应对数据是否内部给到了干预
step3 点击详情，具体查看xml内容和是否有已明确打印出的报错原因
step4 如果校验工具（2.5接口的话后台看接口日志、备份文件）展示了内部没有给到干预，在确认没有相关配置项影响到后，再作为接口问题上报；【如果校验工具展示了已正常给到干预，进一步查看干预和审方日志】
step5 日志里，grep出对应患者去跑引擎的入参：分别在干预、审方日志里找【重点看：1.分别合并了几个药去跑，2.分别有没有报错，3.去跑的检验诊断等是否相同】
step 6 根据找到的原因，解释给院方，对确实是我们问题的再上报干预/审方bug（不经过以上步骤，提供日志、xml等信息，单纯一个截图，测试可以退回oa单）
2、审方出现不应该开到这一步的医嘱，如发现8级
step1 确认接口系统里，干预相关配置是否正确（参见接口专项文档之合并历史相关操作）
step2 根据患者号和时间，找到接口给到干预的那份数据详情xml里，是否包含了多余数据。该数据和接口配置项是否一致
3、认为干预跑出了过去多余的医嘱或警示信息
step1 根据患者号和时间，处方/医嘱号，在校验工具里检索到对应接口数据记录
step2 查看外部调用时是否正确传值
step3 如外部发送数据正确，再查看接口给到审方的xml是否传值，是否有报错
step4 如果展示和接口内部发审方xml也不一致，则需接口审方自己的配置项和系统逻辑考虑。（都确认不了原因的，作为审方问题上报oa支持）
4、在审方中某项患者或医嘱数据、时间没有正确展示、或展示了错误、多余的数据
step1 根据患者号和时间，处方/医嘱号，在校验工具里检索到对应接口给到审方/干预的数据
step2 找到药品对应的规则，结合上述xml数据 确认是否确实当前审核组，应该跑出该信息
step3 如果确认数据和规则都正确，作为审方/干预问题上报
step4 如果数据本身缺失或错误，进一步查看接口收到的外部调用；如果规则问题，调整规则或和药学老师确认；如果对规则具体运行逻辑，请咨询知识建设和引擎的产品
5、在审方/干预中 该跑出来的警示信息没跑出来、跑出了多余警示信息
step1 查看审方方案，任务（入参）是否满足：尤其注意 警示信息过滤条件（决定任务生成），警示信息展示过滤（决定哪些警示信息展示出来），两个是互相独立的配置项，互不影响
step2 确认符合方案的，同前，通过校验工具，根据患者号、时间等信息找到对应xml，查看入参xml数据是否正常。包括外部给接口的和接口给到审方的，对比数据和规则、方案
step3 尤其注意 生命体征传值不完整时的取值逻辑、检验有效时间和取值逻辑、同一处方/医嘱数据是否被删除过，调用删除的时间顺序等等。还无法解释的，作为审方问题上报
6、对审方任务，认为不应该需要审核或展示有疑问
（2.5接口的话后台看接口日志、备份文件）
对应数据是否同时有正常给到干预和审方，并确认相关配置
包括相应明细内容是否有发过删除接口、数据有效接口等
step1 根据患者号、处方/医嘱号和时间，查找接口校验工具
step3 如不一致（一般不会），结合接口配置情况后还有疑问的可作为接口支持问题上报；
（这一步也可以去取审方、干预 跑引擎日志（双方关键词都是“引擎”）日志的跑引擎入参和出参打印的都很清楚
将其放到格式化工具去对比，哪些字段不同，是否能解释具体的警示信息不同原因【这里需要结合该药品规则】
通常可能是一个字段，传了同个含义但不同的值）
step4 如接口给到审方和干预的入参一致，查看审方和干预界面显示数据是否和入参一致如不一致【现场无需细揪引擎逻辑】请his修改给到两边的关键字段，务必相同
step5 校验工具展示的内部调用数据和干预/审方里数据项显示不同、则可作为相应干预或审方问题上报（这种，基本没有在我了解到的所有排查最终结果出现过）
7、审方干预警示信息不一致及处理
（浅）各类警示信息疑问排查思路【外部调用接口展示的xml数据不符合医院业务预期的，请HIS继续进一步排查】
查看日志是否有报错
报错1：一般是xml标签缺少，根据接口文档自行解决
报错2：某些必传标记值未传，如stop_flag传了空
第一步，先看error，error一般能明确看出问题，比如旧版本厂家id缺失等。很明显
日志有报错
原因：可能是处方明细没有关联上处方id，明细中缺少recipe_id或者与info中recipe_id不一致
场景1：门诊数据没产生任务
原因：base里的source与标签不一致，如source是住院，xml标签却是opt
场景2：检验数据不入库
日志无报错
请求成功，审方系统却没产生任务 或 任务显示异常
soapui格式化
soapui能测通，单接口不能拉取到数据
原因：xml标签列表配置有误
1、通过事后配置的HIS之http接口请求与响应原始XML备份目录【pull_his_http_data_bak_dir】查看备份目录
tmp/his
*_request.xml是请求的入参，可比较soapui的入参
*_response.xml是请求的出参，可比较soapui的出参
2、看一下请求的入参和出参是否正确
3、入参出参都是正确，则比较出参中rootTag标签，和其他字段的标签是否和出参一致
4、验证一下【医院HTTP详情】HTTP地址是否正确，注意不要用 ?wsdl结尾
5、注意请求的流媒体
6、注意webservice请求的SOAPAction固定参数名（注意参数名有的需要小写：soapAction）
HTTP请求头信息列表：参数名称SOAPAction:
6、如果his提供的webservice地址，soapui也请求不成功，这需要和his协商帮助查找原因
排查流程
医院http详情：HTTP地址不能以
接口程序事后http拉取（220630），获取数据日志显示获取为空
1、数据流转流程：统一接口/校验工具--nginx---干预系统---引擎
校验工具中查询耗时情况：校验工具-列表-耗时
2、统一接口、校验工具
sql查询统一接口日志表查看耗时
示例：校验工具-列表页面f12，点击“详情”查看此条记录id
根据上面的id，查询统一接口库中数据，Sql：SELECT * FROM tb_interface_log_request_detail WHERE request_chain_id = '1037408568757850112'
统一接口库查询：
Nginx查询：根据统一接口中记录的请求时间，查询nginx日志access_intervene_2022-11.log，找到对应时间点日志，nginx耗时5.001s，状态499
干预问题时继续nginx查询
可查询tomcat下对应时间点附近的access日志
干预查询
辅助工具：http://confluence.ipharmacare.net/x/4YNsAg
goaccess:http://confluence.ipharmacare.net/x/1oNsAg
引擎查询
事中接口查询耗时情况问题排查-耗时过长
看pull库tv_4开头表需有数据，没有请确认 接口-系统基本配置-事后-标准数据是否写入文件/入库启用（可能有影响）
4.0拉取库里没有的看下是否有引起入库失败
3.0获取后需要入库转的同样确认下这两配置
如果先入库再自己配转一遍的，注意配sql弄清要from表名，和join的关联字段写对
一般改成date，date基本时间格式都支持，要增加的话在统一接口-基本配置-支持的时间格式
4.0拉取未取到
【锁表了需要解锁】
去到mysql数据库
找到check_change_log_lock_table表，解锁
查看日志提示：could not acquire change log lock
0331升级到0630后，data_check 校验工具启动不起来
请求地址 填写不用带wsdl，给带dsdl是看的
请求header参数 SOAPAction 值：协议地址
截取标签 有cdata的配置最外面，cdata外的
模版里时间或关联字段变量用%s替换 不是?
配置 接口版本 字符集有没有不小心碰错了
时间类型的，xml标签映射默认timestamp
拉取到0条但不报错，请查看/data/data/interface_bak/…/AFTER/…下his具体返回
不一定pull_info日志体现问题，请看备份文件
尤其一般his具体标签名按文档，rootTag没按
xml标签映射 rootTag确认 否则一个也读不到！
事后webservice上报【基础检查list】
【校验详情】页面查看数据校验报告、返回结果、错误信息、请求参数
查看【接口校验工具-事后数据-拉取任务明细】页面，转换异常的任务详情
查看【接口校验工具-事后数据-对接错误汇总】页面
查看统一接口和校验工具的error日志
事后拉取数据，校验提示异常（字符长度过长）
检查系统配置中的 门诊处方增量 是否开启，若未开启，状态改成有效即可
按照跨就诊合并历史处方干预，实际统一接口没有合并历史处方发送干预
问题排查思路
换到930接口需要配截取标签（即使升级前不配截取）
配置截取标签后 如拉取pull日志有报错
一般是his回参中包括BOM头（Unicode里标识文件格式编码的一个隐藏标记，没办法用电脑上一般工具看到）
如果his不方便去掉，可换到最新版接口程序，有兼容处理
“【...文件路径】中获取数据非XML格式“ 的
事后webservice拉取his回参中有< >的(像cdata转义)
统一接口-基本配置-事后-统一接口拉取任务单个节点启动的线程数 出厂默认5改成1
930前是单线程，后面为了拉的快支持多线程，有的his服务反而响应不了
接口换到211230以后的（包括220331 220630）如果事后拉取请求his不稳定
新建个数据库，例如ipharmacare_pull_930
启动接口，自动创建好全表结构后，drop新建库里以下表，再复制：小海豚右键原库某个表-复制表到其他库-从原库勾选以下表复制到新库
系统基本配置 tb_sys_config审方点评推送配置 tb_sf_result_config_info自定义配置 tb_xml_transform_conf（以下如果没用到的不用复制，用到的要）事后数据库连接 tb_hospital_db_info
事后sql：tb_hospital_sql_configtb_sql_http_relationtb_sql_relation
事后http：tb_hospital_http_infotb_http_headertb_http_paramtb_http_relation
事后存储过程：tb_procedure_infotb_procedure_paramtb_procedure_relation
事中轮询：tb_hospital_quartz_sqltb_hospital_quartz_sql_map
接口表结构升级后要重新恢复到210930接口
【先清下表】
先对pull库所有tb4*_开头表，和ipt*_/opt* 开头表，作truncate操作【各有十来个，否则接口启动会在中间卡很久，误导起不来 也影响数据库】
统一接口跨半年以上版本升到最新的（包括整体升级里含统一接口）
报错320 530的要重置
InterfaceCheckParam InterfaceInvokeParam
报错404的直接添加
如果新版报错提示其他带upload的也一样
ip:15672页面进入 上面菜单选queues上面是已有队列 拉到下面Add a new queue填入队列名称 其他选项默认，点Add queue也可以重启下mq再重启接口先kill再restart
接口启动异常mq队列找不到
1 分析内存是否紧张 增加资源
2 检查关闭内存缓存 swap 分区swapoff -a 具体原理和详细操作，见运维新增实施知识库：http://confluence.ipharmacare.net/pages/viewpage.action?pageId=60592808
统一接口服务器连接不上（CPU占用很高）干预审方接口返回数据慢（redis服务异常）
如果his有的数据就是给不了，自定义配置空转1
事后数据拉取，存在部分必填字段HIS提供不了
应用服务器 cd /data/soft/redis/bin./redis-cli -h 10.1.1.xx -p 6379 -n 13 -a ipharmacare //连redis 改为应用ipkeys \"*task*\" //模糊查找对应key 找到复制名字del \"ipharmacare_pull_task_status\" //删掉del \"ipharmacare_pull_task\" //有的话也删掉
接口拉取数据事中提示存在当前任务
数据库连接池中的连接到达最大数，无法创建新连接解决方案：遇到连接不足的情况修改最大连接数
统一接口上报异常，全都失败，偶尔会出现，只要一个失败会大批量全失败
问题原因：住院就诊信息，配置成增量追加了，导致执行顺序不对；解决方案：改成全量覆盖即可。
事后数据上报住院主数据在上报成功，住院医嘱关联上报，显示关联数据为空
药师工作站通过统一接口获取的电子病历数据无法自动换行
常见问题解决方案
直接在后面加如serviceCode=GY_SF_V4&test_mode=true回参就能看到了比每次发送-再找对应备份文件方便的多
现场测试接口给干预/患教4转3时
加上&test_mode=true对所有接口都有效，回参就是接口处理后往业务系统下游传的实际数据
4转3postman测试后门
（sql自己转一下处理的，需开启接口基本配置-事后-标准数据是否入库）
先存储过程和http（webservice） 最后视图上报（sql现场可灵活处理）
首先，按拉取方式
先拉取4.0所有数据类型 再拉取配置3.0的所有数据类型
同一个上报方式内
先拉取主类型：门诊处方 住院就诊
再拉取其他类型（因为可能关联主类型）
同方式同版本同个数据类型（患者信息）
才是先拉取，先创建，也就是id小的
同方式同版本
统一接口事后拉取顺序
产品业务逻辑&测试相关
统一接口
0 条评论
回复 删除
下一页
