PO 系列目标系统对异步消息的处理
原创 无峰 [ ABAP 技巧与实战 ](javascript:void\(0\);)
**点击蓝字** 关注我们
一
前言
PO(/PI)是SAP公司的一个中间件产品，用来辅助连接SAP系统与外围系统. (当然外围系统之间也可以使用PO).
**本文主要介绍目标系统对异步消息处理的注意事项**
二
问题发现
最近在项目中碰到一个PO与目标系统的数据传递问题.
目标系统人员称通过PO传递的单据有重复的.同时提供了重复的单号.
通过单号查询了PO的消息包,发现单号在PO系统中并没有重复, 只是该单所在的消息包在PO中的处理因为目标系统报错,重试了3次.
因此猜测导致单据重复的原因:目标系统每次报错之前都成功处理了部分单据,但是因为http服务超时报错,后面的单据没有处理,PO重试错误消息时又成功处理了部分单据,
导致重复.
后文是对该问题的分析及可能的解决方案
下图显示了PO监控器中该消息的重试及报错信息
三
多单传递
一般设计PO接口时,会允许一个消息传送多个单据(或主数据).
如下图,在PO中定义的DATA TYPE 中,会把消息主体节点(图示中是 body, 这个节点名称按项目习惯来命名)设置为 0..unbounded .
表示一个消息中可以存在多个body 节点. 一个body 节点往往是一单(或者一个主数据). 因此每个消息允许存在多单或多个主数据.
四
发出方控制
发出方程序一般通过参数控制每个消息中发送一个还是多个单据
五
消息包大小
一般情况下,发送同样个数的单, 消息包越大(一个消息中的单据数越多),意味着调用次数越少. 消息包越小,意味着调用次数越多.
总的时间开销=每个消息包的处理时间*消息包个数.
从总体性能来看, 并非包越大越好.消息包过大,单个消息包的处理性能可能会下降很多. 导致总体时间开销增大.
PO本身对消息包的大小有个建议(大概是不要超过4M左右).
因为每个接口的信息的大小不一致,因此每个接口传递的最佳单据个数也不尽相同,但是大概500-1000个单左右比较合适
_对于同步接口,因为调用方等待反馈结果. 消息包越小越好,以便目标系统及时完成处理并反馈接口, 所以同步接口往往每个消息包传递一单._
六
消息错误重试
PO会把消息包作为一个整体处理,
在处理过程中,如果碰到目标系统反馈异常,PO会根据参数设置,重新尝试消息的处理,最大尝试3次.(可通过底层参数调整,单个接口可以通过通道参数设置该接口的重试次数)
XI will by default try to restart the message 3 times at intervals of 5
minutes before the status of the message is changed from Waiting to System
Error .
We can achieve this by changing the retry count used by the Adapter Engine, by
default its set to 3 times, 5 minutes apart. This count can be changed in
Visual Admin->server->services-> SAP XI Adapter: XI.Here change the number
Retries parameter from 3 to 10 and change the retry retryInterval to around
10minutes. For these configuration changes to be picked up, restart SAP XI
Adapter: XI.
• xiadapter.inbound.numberRetries.default 3 重试次数
• xiadapter.inbound.retryInterval.default 300000 重试间隔(入站)
• xiadapter.outbound.retryInterval.default 300000 重试间隔(出站)
七
消息包处理方式
这里的消息包处理主要指目标系统对异步消息包的处理.
基于消息包的完整性及PO的重试机制,目标系统可以有两种处理方式
• 消息包作为一个整体考虑,消息包中含的单,要么整体成功,要么整体失败.这样PO的报错重试机制就不会导致目标系统重复写入单据
• 对单据做排重处理, 根据关键字识别单号, 对于存在的单号,做修改处理或记录日志报错,对于不存在的单号,做写入处理.(更完整的逻辑是:检查单据状态, 如果允许修改,才修改,对于不允许修改的单据,通过日志报错)
同时针对报错中的超时问题,目标系统需要修改http关于超时的参数,给服务调用更多的可用时间间隔.
当然,如果外围系统无法按上述逻辑调整. 也可以由发出系统改成每个消息包只传一单.
这个改动作为权宜之计可以临时使用一下. 因为大数据量传输时,每个消息只传一个单据, 会导致对PO的大量调用.
总体耗时增加的同时对PO的总体执行性能也会产生影响.
图示:推荐的消息处理方式
八
总结
异步接口无论发出方,还是接收方,都需要对发送/接收的数据做详细的日志记录.这样才能在业务发现数据异常时,通过不同环节的日志查询发现问题产生的原因.
同时目标系统最好有单据重复校验,单据的临时保存及出错单据的重处理机制.
这样对于一些因为目标系统原因导致的错误,解决报错原因后, 无需源系统重新发送数据,目标系统即可对临时存储的单据完成报错数据的重处理.
一般情况下,如果目标系统是SAP系统,
可以通过IDOC来作为单据的临时存储.这样可以利用IDOC的监控及重处理机制(需要增强单据重复校验机制),确保单据最终成功的写入SAP系统,产生相应的系统单据.
