点击蓝字 关注我们

一

前言

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系统,产生相应的系统单据.