统一接口现场问题排查及解决方案（干预）

2024-01-22 13:39:06   21  举报





AI智能生成

统一接口现场问题排查及解决方案（干预）是一种针对现场设备或系统的统一接口问题进行快速定位和解决的方法。它通过对现场设备的监控和数据分析，发现并定位问题，然后通过干预措施对问题进行处理，以恢复设备的正常运行。这种方法能够有效地提高设备的可靠性和稳定性，减少故障发生的可能性。此外，它还能够帮助维护人员更好地了解设备的运行状态，及时发现潜在的问题，为设备的维护和升级提供有力的支持。总之，统一接口现场问题排查及解决方案（干预）是一种高效、可靠的方法，能够为现场设备的运行和维护提供有力的保障。

知识地图

作者其他创作

大纲/内容

问题排查思路

删除相关问题

分类一：调用删除接口异常

处理：查看校验工具，相应调用的错误信息，或统一接口日志，基本上给的比较明确

分类二：不是调用删除，而通过其他途径想达到删除处方、删除单药、删除组、部分删除

处理：确认实际调用方式，查找xml，以及查找【正确的实际调用顺序】和明确【准确调用时间】，以及提供【患者号】

现场接口程序与demo不一样

原因一：前端缓存

处理：开控制台，network下勾选☑️disable_cache 并刷新，再看

原因二：包未更新

处理：确认换包范围：后端jar包，前端静态资源statics是否均已按照需要替换

原因三：后端部署或其他配置错误

处理：检查部署，包名等

（浅）接口调用层问题思路

postman测正常但his推失败

原因一：his推送方式出错，如his收到xxx错误等

处理：参见上述【概念及配置介绍-三种接口请求方式】，要求his开发对照检查，或请他们自己百度

原因二：双方超时设置、网络设置等

处理：对比校验工具请求时间、请求返回的错误信息（不是校验报告）。确认原因后调整接口程序相应配置项或找his调整他们的相关限制

希望特殊处理哪个入参或出参

步骤一：确认要达到的效果，务必把业务需要，转换成接口对接的，自己表述一遍，理清思路

步骤二：结合现有配置，测试是否满足需要

参见上述【事中场景-专项功能操作-报文字段修改】，包括字段增加、移除、拷贝、重命名等执行顺序，都有详细介绍

步骤三：慎重考虑配置后影响范围

（浅）各类警示信息疑问排查思路
【外部调用接口展示的xml数据不符合医院业务预期的，请HIS继续进一步排查】

1、怀疑审方、干预在没有合理原因下数据不一致

step1 根据患者号、处方/医嘱号和时间，查找接口校验工具对应数据是否同时有正常给到干预和审方，并确认相关配置。
包括相应明细内容是否有发过删除接口、数据有效接口等

step2 点击详情，查看具体给到干预和审方xml是否在有疑问的数据项上完全一致

step3 如不一致，结合接口配置情况后还有疑问的作为接口支持问题上报；
如一致，校验工具展示的内部调用数据和业务系统上数据项显示不同，则作为相应干预或审方问题上报

2、审方出现不应该开到这一步的医嘱，如发现8级

step1 根据患者号和时间，查找干预里是否有这条数据，对应警示信息等级是否正确

step2 如果干预没有，根据患者号和时间，在校验工具（2.5接口的话后台看接口日志、备份文件）
查找对应对数据是否内部给到了干预

step3 点击详情，具体查看xml内容和是否有已明确打印出的报错原因

step4 如果校验工具（2.5接口的话后台看接口日志、备份文件）展示了内部没有给到干预，
在确认没有相关配置项影响到后，再作为接口问题上报；
【如果校验工具展示了已正常给到干预，进一步查看干预和审方日志】

step5 日志里，grep出对应患者去跑引擎的入参：分别在干预、审方日志里找
【重点看：1.分别合并了几个药去跑，2.分别有没有报错，3.去跑的检验诊断等是否相同】

step 6 根据找到的原因，解释给院方，对确实是我们问题的再上报干预/审方bug
（不经过以上步骤，提供日志、xml等信息，单纯一个截图，测试可以退回oa单）

3、认为干预跑出了过去多余的医嘱或警示信息

step1 确认接口系统里，干预相关配置是否正确（参见接口专项文档之合并历史相关操作）

step2 根据患者号和时间，找到接口给到干预的那份数据详情xml里，是否包含了多余数据。
该数据和接口配置项是否一致

4、在审方中某项患者或医嘱数据、时间没有正确展示、或展示了错误、多余的数据

step1 根据患者号和时间，处方/医嘱号，在校验工具里检索到对应接口数据记录

step2 查看外部调用时是否正确传值

step3 如外部发送数据正确，再查看接口给到审方的xml是否传值，是否有报错

step4 如果展示和接口内部发审方xml也不一致，则需接口审方自己的配置项和系统逻辑考虑。
（都确认不了原因的，作为审方问题上报oa支持）

5、在审方/干预中该跑出来的警示信息没跑出来、跑出了多余警示信息

step1 根据患者号和时间，处方/医嘱号，在校验工具里检索到对应接口给到审方/干预的数据

step2 找到药品对应的规则，结合上述xml数据确认是否确实当前审核组，应该跑出该信息

step3 如果确认数据和规则都正确，作为审方/干预问题上报

step4 如果数据本身缺失或错误，进一步查看接口收到的外部调用；如果规则问题，调整规则或和药学老师确认；
如果对规则具体运行逻辑，请咨询知识建设和引擎的产品

6、对审方任务，认为不应该需要审核或展示有疑问

step1 查看审方方案，任务（入参）是否满足：尤其注意警示信息过滤条件（决定任务生成），
警示信息展示过滤（决定哪些警示信息展示出来），两个是互相独立的配置项，互不影响

step2 确认符合方案的，同前，通过校验工具，根据患者号、时间等信息找到对应xml，查看入参xml数据是否正常。
包括外部给接口的和接口给到审方的，对比数据和规则、方案

step3 尤其注意生命体征传值不完整时的取值逻辑、检验有效时间和取值逻辑、同一处方/医嘱数据是否被删除过，调用删除的时间顺序等等。
还无法解释的，作为审方问题上报

7、审方干预警示信息不一致及处理

step1 根据患者号、处方/医嘱号和时间，查找接口校验工具

（2.5接口的话后台看接口日志、备份文件）

对应数据是否同时有正常给到干预和审方，并确认相关配置

包括相应明细内容是否有发过删除接口、数据有效接口等

step2 点击详情，查看具体给到干预和审方xml是否在有疑问的数据项上完全一致

step3 如不一致（一般不会），结合接口配置情况后还有疑问的可作为接口支持问题上报；

step4 如接口给到审方和干预的入参一致，查看审方和干预界面显示数据是否和入参一致
如不一致【现场无需细揪引擎逻辑】请his修改给到两边的关键字段，务必相同

（这一步也可以去取审方、干预跑引擎日志（双方关键词都是“引擎”）
日志的跑引擎入参和出参打印的都很清楚

将其放到格式化工具去对比，哪些字段不同，是否能解释具体的警示信息不同原因
【这里需要结合该药品规则】

通常可能是一个字段，传了同个含义但不同的值）

step5 校验工具展示的内部调用数据和干预/审方里数据项显示不同、则可作为相应干预或审方问题上报
（这种，基本没有在我了解到的所有排查最终结果出现过）

请求成功，审方系统却没产生任务或任务显示异常

查看日志是否有报错

日志有报错

第一步，先看error，error一般能明确看出问题，比如旧版本厂家id缺失等。很明显

报错1：一般是xml标签缺少，根据接口文档自行解决

报错2：某些必传标记值未传，如stop_flag传了空

日志无报错

场景1：门诊数据没产生任务

原因：可能是处方明细没有关联上处方id，明细中缺少recipe_id或者与info中recipe_id不一致

场景2：检验数据不入库

原因：base里的source与标签不一致，如source是住院，xml标签却是opt

接口程序事后http拉取（220630），获取数据日志显示获取为空

soapui能测通，单接口不能拉取到数据

soapui格式化

原因：xml标签列表配置有误

排查流程

1、通过事后配置的HIS之http接口请求与响应原始XML备份目录【pull_his_http_data_bak_dir】查看备份目录

2、看一下请求的入参和出参是否正确

tmp/his

*_request.xml是请求的入参，可比较soapui的入参

*_response.xml是请求的出参，可比较soapui的出参

3、入参出参都是正确，则比较出参中rootTag标签，和其他字段的标签是否和出参一致

4、验证一下【医院HTTP详情】HTTP地址是否正确，注意不要用 ?wsdl结尾

5、注意请求的流媒体

6、注意webservice请求的SOAPAction固定参数名（注意参数名有的需要小写：soapAction）

HTTP请求头信息列表：参数名称SOAPAction:

6、如果his提供的webservice地址，soapui也请求不成功，这需要和his协商帮助查找原因

医院http详情：HTTP地址不能以

事中接口查询耗时情况问题排查-耗时过长

1、数据流转流程：统一接口/校验工具--nginx---干预系统---引擎

2、统一接口、校验工具

校验工具中查询耗时情况：校验工具-列表-耗时

sql查询统一接口日志表查看耗时

/事中所有接口，请求好事超过 1s 的记录，按照耗时以及请求时间倒序
SELECT * FROM `tb_interface_log` WHERE request_time > '2022-11-03 18:00:00' AND consume_time > 1000 AND service_id < 300 ORDER BY consume_time DESC,request_time DESC

示例：校验工具-列表页面f12，点击“详情”查看此条记录id

统一接口库查询：

根据上面的id，查询统一接口库中数据，
Sql：SELECT * FROM tb_interface_log_request_detail WHERE request_chain_id = '1037408568757850112'

干预问题时继续nginx查询

Nginx查询：
根据统一接口中记录的请求时间，查询nginx日志access_intervene_2022-11.log，找到对应时间点日志，nginx耗时5.001s，状态499

干预查询

可查询tomcat下对应时间点附近的access日志

引擎查询

辅助工具：http://confluence.ipharmacare.net/x/4YNsAg

goaccess:http://confluence.ipharmacare.net/x/1oNsAg

4.0拉取未取到

看pull库tv_4开头表需有数据，没有请确认接口-系统基本配置-事后-标准数据是否写入文件/入库启用（可能有影响）

4.0拉取库里没有的看下是否有引起入库失败

3.0获取后需要入库转的同样确认下这两配置

如果先入库再自己配转一遍的，注意配sql弄清要from表名，和join的关联字段写对

一般改成date，date基本时间格式都支持，要增加的话在统一接口-基本配置-支持的时间格式

0331升级到0630后，data_check 校验工具启动不起来

查看日志提示：could not acquire change log lock

【锁表了需要解锁】

去到mysql数据库

找到check_change_log_lock_table表，解锁

事后webservice上报【基础检查list】

请求地址填写不用带wsdl，给带dsdl是看的

请求header参数 SOAPAction 值：协议地址

截取标签有cdata的配置最外面，cdata外的

模版里时间或关联字段变量用%s替换不是?

配置接口版本字符集有没有不小心碰错了

时间类型的，xml标签映射默认timestamp

拉取到0条但不报错，请查看/data/data/interface_bak/…/AFTER/…下his具体返回

不一定pull_info日志体现问题，请看备份文件

xml标签映射 rootTag确认否则一个也读不到！

尤其一般his具体标签名按文档，rootTag没按

事后拉取数据，校验提示异常（字符长度过长）

查看【接口校验工具-事后数据-拉取任务明细】页面，转换异常的任务详情

【校验详情】页面查看数据校验报告、返回结果、错误信息、请求参数

查看【接口校验工具-事后数据-对接错误汇总】页面

查看统一接口和校验工具的error日志

按照跨就诊合并历史处方干预，实际统一接口没有合并历史处方发送干预

检查系统配置中的门诊处方增量是否开启，若未开启，状态改成有效即可

常见问题解决方案

事后webservice拉取his回参中有< >的(像cdata转义)

换到930接口需要配截取标签（即使升级前不配截取）

配置截取标签后如拉取pull日志有报错

“【...文件路径】中获取数据非XML格式“ 的

一般是his回参中包括BOM头（Unicode里标识文件格式编码的一个隐藏标记，没办法用电脑上一般工具看到）

如果his不方便去掉，可换到最新版接口程序，有兼容处理

接口换到211230以后的（包括220331 220630）如果事后拉取请求his不稳定

统一接口-基本配置-事后-统一接口拉取任务单个节点启动的线程数出厂默认5改成1

930前是单线程，后面为了拉的快支持多线程，有的his服务反而响应不了

接口表结构升级后要重新恢复到210930接口

新建个数据库，例如ipharmacare_pull_930

启动接口，自动创建好全表结构后，drop新建库里以下表，再复制：小海豚右键原库某个表-复制表到其他库-从原库勾选以下表复制到新库

系统基本配置 tb_sys_config
审方点评推送配置 tb_sf_result_config_info
自定义配置 tb_xml_transform_conf（以下如果没用到的不用复制，用到的要）
事后数据库连接 tb_hospital_db_info

事后sql：
tb_hospital_sql_config
tb_sql_http_relation
tb_sql_relation

事后http：
tb_hospital_http_info
tb_http_header
tb_http_param
tb_http_relation

事后存储过程：
tb_procedure_info
tb_procedure_param
tb_procedure_relation

事中轮询：
tb_hospital_quartz_sql
tb_hospital_quartz_sql_map

统一接口跨半年以上版本升到最新的（包括整体升级里含统一接口）

【先清下表】

先对pull库所有tb4*_开头表，和ipt*_/opt* 开头表，作truncate操作
【各有十来个，否则接口启动会在中间卡很久，误导起不来也影响数据库】

接口启动异常mq队列找不到

报错320 530的要重置

报错404的直接添加

InterfaceCheckParam
InterfaceInvokeParam

如果新版报错提示其他带upload的也一样

ip:15672页面进入上面菜单选queues
上面是已有队列拉到下面Add a new queue
填入队列名称其他选项默认，点Add queue
也可以重启下mq再重启接口先kill再restart

统一接口服务器连接不上（CPU占用很高）
干预审方接口返回数据慢（redis服务异常）

1 分析内存是否紧张增加资源

2 检查关闭内存缓存 swap 分区swapoff -a 具体原理和详细操作，见运维新增实施知识库：http://confluence.ipharmacare.net/pages/viewpage.action?pageId=60592808

事后数据拉取，存在部分必填字段HIS提供不了

如果his有的数据就是给不了，自定义配置空转1

接口拉取数据事中提示存在当前任务

应用服务器 cd /data/soft/redis/bin
./redis-cli -h 10.1.1.xx -p 6379 -n 13 -a ipharmacare //连redis 改为应用ip
keys "*task*" //模糊查找对应key 找到复制名字
del "ipharmacare_pull_task_status" //删掉
del "ipharmacare_pull_task" //有的话也删掉

统一接口上报异常，全都失败，偶尔会出现，只要一个失败会大批量全失败

数据库连接池中的连接到达最大数，无法创建新连接
解决方案：遇到连接不足的情况修改最大连接数

事后数据上报住院主数据在上报成功，住院医嘱关联上报，显示关联数据为空

问题原因：住院就诊信息，配置成增量追加了，导致执行顺序不对；
解决方案：改成全量覆盖即可。

药师工作站通过统一接口获取的电子病历数据无法自动换行

1.接口视图配置progress_category类型需写死3
转工作站视图caseType对应 1格式input 二格式pdt 三格式html
2.需更换统一接口到1222（原0928，下发入库数据本身即不换行）数据入库为：
在事后校验看获取记录，再在事中看下发。928下发前带空格下游入库貌似被程序去掉了
3.药师工作站前端只展示
（标准html文件，不直接展示\n 以及回车换行等隐藏字符）
因此需视图调整为 replace(replace(progress_note_content,'ｃｈｒ(13)','
'),'ｃｈｒ(10)','
') as xxx

产品业务逻辑&测试相关

4转3postman测试后门

现场测试接口给干预/患教4转3时

直接在后面加如serviceCode=GY_SF_V4&test_mode=true
回参就能看到了比每次发送-再找对应备份文件方便的多

加上&test_mode=true对所有接口都有效，回参就是接口处理后往业务系统下游传的实际数据

统一接口事后拉取顺序

首先，按拉取方式

先存储过程和http（webservice）
最后视图上报（sql现场可灵活处理）

（sql自己转一下处理的，需开启接口基本配置-事后-标准数据是否入库）

同一个上报方式内

先拉取4.0所有数据类型
再拉取配置3.0的所有数据类型

同方式同版本