SAP 集成以及PO异步接口调优

原创

已于 2023-08-05 21:24:16 修改 · 1.6k 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#java #开发语言 #SAP #ABAP #PO #PO调优

于 2023-08-03 14:06:09 首次发布

文章探讨了国内SAP系统中PO相关技术文档的缺乏，重点介绍了处理接收数据延迟和异步线程错误的方法，如检查SMQ2队列、使用RSQOWKEX/RSQIWKEX重置队列、调整Java消息系统队列并发和使用WilyIntroscope进行分析。作者还提供了针对不同场景的优化策略，如权限检查和后台系统性能调整等。

前言：目前国内的SAP相关的技术文档实在是少得可怜，PO相关的就更少了，基本上都是需要摸索，官方的技术专家很多时候的回复都是说了又似乎没说。。。

背景：由于目标系统接收数据缓慢或者是异步线程出现异常导致错误积压。

临时处理方案：

1.在SXI_MONITOR中查看异常报错的异步接口线程，全选之后重新启动；

2.在SMQ2入站队列中，对非running状态的队列进行激活或者解锁，保证队列的正常运作

3.对相关队列进行全局重置，参考note 2552322，下面为该note的部分内容：

RSQOWKEX 是用于重置出站队列条目的报告，以便出站队列调度程序可以处理队列。同样，RSQIWKEX 对应于入站 qRFC 场景。

创建出站 qRFC 时，首先调用调度器来处理此队列，队列的状态变为“正在运行”。

如果队列成功执行，将从 SMQ1（出站队列监控器）中消失，
如果未成功，队列将转到状态 SYSFAIL、RETRY、CPIERR 之一（请参阅 SAP Note 378903“SMQ1、SMQ2 中的队列状态和表 ARFCRSTATE”），其中详细解释了状态）。

此时，通过执行 RSQOWKEX 处理此队列，调度器将重试，如果之前的错误是临时的（例如，临时锁定），则此时队列将成功处理。

如果已调度报表 RSQOWKEX/RSQIWKEX，则调度器与报表之间可能会存在重复执行或死锁的情况，选择相同的条目。
如果未选择选择选项“无“重试队列”和“无“正在运行的队列”，则会发生这种情况。

从 RFC 的角度来看 - 不必在 ECC 中为 EWM 相关队列设置这些作业，因为创建内向/外向队列时将自动调用计划器。仅当队列首次未成功发送时，才有助于重新处理。但在重新处理之前，需要检查首次进入错误状态的原因。

4.如果上述方案无法彻底解决，可以通过SMQR进入RFC监控器中，选中所有条目，选择“编辑”选项，然后选择激活调度器激活队列的运行状态

后续优化方案：

1.SMQ2如果持续有retry的队列，除了上述的解决方案之外，可能还需要考虑到权限问题，可以参考note：1862256 - 入站队列 (SMQ2) 保持状态 RETRY

2.根据Tuning the PI/PO Messaging System Queues | SAP Blogs提示的检查方案，对可能存在的问题点进行检查并有针对性的排除，同时可以参考93159中的建议https://me.sap.com/notes/937159

3.由于异步线程的特殊性，有可能接收方系统无法在同一时间承受大量的数据，因此单向调整PO队列通道进程并不能很好处理“供需关系”，甚至导致冗余的进程拖垮了服务器的性能，因此，为了保证全局业务的正常进行，可以适当在合理的进程数下，设置全局通道、制定最大接收数量。比如说全局的异步通道为10，指定最大接收数量为4，那么久意味着最少可以允许最大3个系统在同一时间进行高并发的异步数据传输。

最大接收数量的配置在PO网页的管理后台，属性配置中的服务：

XPI Service: Messaging System->messaging.system.queueParallelism.maxReceivers，如果是0的话是无限制，如果设置了值的话就是有生效的

下面搬运Mike Sibler的文章内容，虽然是老版本的，但是还是有很多可以借鉴的地方：

Tuning the PI/PO Messaging System Queues

Motivation:

Most of the PI/PO adapters are running on Java. With PI 7.3 also the IDoc and HTTP adapter will be available for Java. Therefore for most of the scenarios Java only processing of messages is possible using Integrated Configuration objects (ICO).

For classical ABAP based scenarios the parallelization was mainly triggered by adjusting the parallelization of the ABAP queues in the Integration Engine. Now, since all the steps like mappings and backend calls are executed in the same queue the tuning of the Java based Messaging System queues is now essential. This blog tries to summarize the aspects that have to be considered when tuning the Messaging System queues.

The description is valid for all SAP PI releases. Newer versions have additional possibilities that will be explained where necessary.

Note: All this information will also be made available in the next version of the PI performance check via SAP Note 894509.

Prerequisite:

Wily Introscope is a prerequisite for the analysis discussed below. For more information on Wily please refer to SAP Note 797147 and Processes for 7.2.

Overview

Messaging System:
The task of the Messaging System is to persist and assign resources for messages processed on the Java stack.

Queues in the Messaging System
The queues in the Messaging System behave different then the qRFC queues in ABAP. The ABAP queues are strictly First In First Out (FIFO) queues and are only processed by one Dialog work process at a time. The Messaging System queues have a configurable amount of so called consumer threads that process messages from the queue. The default number of consumer threads is 5 per adapter (JDBC, File, JMS, …), per direction (inbound and outbound) and Quality of Service (asynchronous (EO, EOIO) and synchronous). Hence in case a message is taking very long other messages that arrived later can finish processing earlier. Therefore Messaging System queues are not strictly FIFO.

There are four queues per adapter. All the queues are named <Adapter>_