删除相关问题
分类一：调用删除接口异常
处理：查看校验工具，相应调用的错误信息，或统一接口日志，基本上给的比较明确
分类二：不是调用删除，而通过其他途径想达到删除处方、删除单药、删除组、部分删除
处理：确认实际调用方式，查找xml，以及查找【正确的实际调用顺序】和明确【准确调用时间】，以及提供【患者号】
现场接口程序与demo不一样
原因一：前端缓存
处理：开控制台，network下勾选☑️disable_cache 并刷新，再看
原因二：包未更新
处理：确认换包范围：后端jar包，前端静态资源statics是否均已按照需要替换
原因三：后端部署或其他配置错误
处理：检查部署，包名等
（浅）接口调用层问题思路
postman测正常但his推失败
原因一：his推送方式出错，如his收到xxx错误等
处理：参见上述【概念及配置介绍-三种接口请求方式】，要求his开发对照检查，或请他们自己百度
原因二：双方超时设置、网络设置等
处理：对比校验工具请求时间、请求返回的错误信息（不是校验报告）。确认原因后调整接口程序相应配置项或找his调整他们的相关限制
希望特殊处理哪个入参或出参
步骤一：确认要达到的效果，务必把业务需要，转换成接口对接的，自己表述一遍，理清思路
步骤二：结合现有配置，测试是否满足需要
参见上述 【事中场景-专项功能操作-报文字段修改】，包括字段增加、移除、拷贝、重命名等执行顺序，都有详细介绍
步骤三：慎重考虑配置后影响范围
（浅）各类警示信息疑问排查思路<br>【外部调用接口展示的xml数据不符合医院业务预期的，请HIS继续进一步排查】<br>
1、怀疑审方、干预在没有合理原因下数据不一致
step1 根据患者号、处方/医嘱号和时间，查找接口校验工具对应数据是否同时有正常给到干预和审方，并确认相关配置。<br>包括相应明细内容是否有发过删除接口、数据有效接口等<br>
step2 点击详情，查看具体给到干预和审方xml是否在有疑问的数据项上完全一致
step3 如不一致，结合接口配置情况后还有疑问的作为接口支持问题上报；<br>如一致，校验工具展示的内部调用数据和业务系统上数据项显示不同，则作为相应干预或审方问题上报<br>
2、审方出现不应该开到这一步的医嘱，如发现8级
step1 根据患者号和时间，查找干预里是否有这条数据，对应警示信息等级是否正确
step2 如果干预没有，根据患者号和时间，在校验工具（2.5接口的话后台看接口日志、备份文件）<br>查找对应对数据是否内部给到了干预<br>
step3 点击详情，具体查看xml内容和是否有已明确打印出的报错原因
step4 如果校验工具（2.5接口的话后台看接口日志、备份文件）展示了内部没有给到干预，<br>在确认没有相关配置项影响到后，再作为接口问题上报；<br>【如果校验工具展示了已正常给到干预，进一步查看干预和审方日志】
step5 日志里，grep出对应患者去跑引擎的入参：分别在干预、审方日志里找<br>【重点看：1.分别合并了几个药去跑，2.分别有没有报错，3.去跑的检验诊断等是否相同】
step 6 根据找到的原因，解释给院方，对确实是我们问题的再上报干预/审方bug<br>（不经过以上步骤，提供日志、xml等信息，单纯一个截图，测试可以退回oa单）<br>
3、认为干预跑出了过去多余的医嘱或警示信息
step1 确认接口系统里，干预相关配置是否正确（参见接口专项文档之合并历史相关操作）
step2 根据患者号和时间，找到接口给到干预的那份数据详情xml里，是否包含了多余数据。<br>该数据和接口配置项是否一致<br>
4、在审方中某项患者或医嘱数据、时间没有正确展示、或展示了错误、多余的数据
step1 根据患者号和时间，处方/医嘱号，在校验工具里检索到对应接口数据记录
step2 查看外部调用时是否正确传值
step3 如外部发送数据正确，再查看接口给到审方的xml是否传值，是否有报错
step4 如果展示和接口内部发审方xml也不一致，则需接口审方自己的配置项和系统逻辑考虑。<br>（都确认不了原因的，作为审方问题上报oa支持）<br>
5、在审方/干预中 该跑出来的警示信息没跑出来、跑出了多余警示信息
step1 根据患者号和时间，处方/医嘱号，在校验工具里检索到对应接口给到审方/干预的数据
step2 找到药品对应的规则，结合上述xml数据 确认是否确实当前审核组，应该跑出该信息
step3 如果确认数据和规则都正确，作为审方/干预问题上报
step4 如果数据本身缺失或错误，进一步查看接口收到的外部调用；如果规则问题，调整规则或和药学老师确认；<br>如果对规则具体运行逻辑，请咨询知识建设和引擎的产品<br>
6、对审方任务，认为不应该需要审核或展示有疑问
step1 查看审方方案，任务（入参）是否满足：尤其注意 警示信息过滤条件（决定任务生成），<br>警示信息展示过滤（决定哪些警示信息展示出来），两个是互相独立的配置项，互不影响<br>
step2 确认符合方案的，同前，通过校验工具，根据患者号、时间等信息找到对应xml，查看入参xml数据是否正常。<br>包括外部给接口的和接口给到审方的，对比数据和规则、方案<br>
step3 尤其注意 生命体征传值不完整时的取值逻辑、检验有效时间和取值逻辑、同一处方/医嘱数据是否被删除过，调用删除的时间顺序等等。<br>还无法解释的，作为审方问题上报<br>
7、审方干预警示信息不一致及处理
step1 根据患者号、处方/医嘱号和时间，查找接口校验工具
（2.5接口的话后台看接口日志、备份文件）
对应数据是否同时有正常给到干预和审方，并确认相关配置
包括相应明细内容是否有发过删除接口、数据有效接口等
step2 点击详情，查看具体给到干预和审方xml是否在有疑问的数据项上完全一致
step3 如不一致（一般不会），结合接口配置情况后还有疑问的可作为接口支持问题上报；
step4 如接口给到审方和干预的入参一致，查看审方和干预界面显示数据是否和入参一致<br>如不一致【现场无需细揪引擎逻辑】请his修改给到两边的关键字段，务必相同<br>
（这一步也可以去取审方、干预 跑引擎日志（双方关键词都是“引擎”）<br>日志的跑引擎入参和出参打印的都很清楚<br>
将其放到格式化工具去对比，哪些字段不同，是否能解释具体的警示信息不同原因<br>【这里需要结合该药品规则】<br>
step5 校验工具展示的内部调用数据和干预/审方里数据项显示不同、则可作为相应干预或审方问题上报<br>（这种，基本没有在我了解到的所有排查最终结果出现过）<br>
请求成功，审方系统却没产生任务 或 任务显示异常
查看日志是否有报错
日志有报错
第一步，先看error，error一般能明确看出问题，比如旧版本厂家id缺失等。很明显
报错1：一般是xml标签缺少，根据接口文档自行解决
报错2：某些必传标记值未传，如stop_flag传了空
日志无报错
场景1：门诊数据没产生任务
原因：可能是处方明细没有关联上处方id，明细中缺少recipe_id或者与info中recipe_id不一致
场景2：检验数据不入库
原因：base里的source与标签不一致，如source是住院，xml标签却是opt
接口程序事后http拉取（220630），获取数据日志显示获取为空
原因：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查询统一接口日志表查看耗时<br>
/事中所有接口，请求好事超过 1s 的记录，按照耗时以及请求时间倒序<br>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<br>
示例：校验工具-列表页面f12，点击“详情”查看此条记录id
统一接口库查询：
根据上面的id，查询统一接口库中数据，<br>Sql：SELECT * FROM tb_interface_log_request_detail WHERE request_chain_id = '1037408568757850112'<br>
干预问题时继续nginx查询
Nginx查询：<br>根据统一接口中记录的请求时间，查询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基本时间格式都支持，要增加的话在统一接口-基本配置-支持的时间格式
<br>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日志<br>
按照跨就诊合并历史处方干预，实际统一接口没有合并历史处方发送干预
检查系统配置中的 门诊处方增量 是否开启，若未开启，状态改成有效即可
