REF: диагностика производительности и сбоев интеграции#

Медленная операция, зависшая доставка и ошибка обработки требуют разных доказательств. До трассировки или повтора выясните, на каком участке и в каком временном интервале возникает симптом, сохраните корреляцию с исходным бизнес-событием и отделите техническую доставку от успешного финансового результата.

Эта статья задаёт общий порядок. Для деталей используйте материалы о контракте RFC, BAPI и IDoc, ABAP SQL, блокировках и update task, трассах и профилировании и фоновых заданиях и Application Log.

1. Зафиксируйте воспроизводимый контекст#

Для одного бизнес-случая сохраните:

SID/систему, клиента, релиз, приложение или endpoint и направление вызова;
время начала и конца с часовым поясом, узел/instance, пользователя и тип процесса;
бизнес-ключ документа, технический идентификатор сообщения или запроса, IDoc/очереди/job и корреляционный ID, если он предусмотрен;
входные параметры, объём строк, ожидаемый и фактический результат, полный код и текст ошибки;
номер попытки, время предыдущей попытки, статус отправки и приёма, статус прикладной обработки и созданный бизнес-документ, если есть;
параметры измерения: одинаковый ли сценарий, объём и состояние данных сравниваются.

Не помещайте пароли, токены и персональные данные в журналы расследования. Идентификаторы и выдержки храните по правилам доступа к продуктивным данным.

2. Разделите задержку по этапам#

Сначала оцените общее время и число обработанных объектов, затем разложите путь на доступные в данном интерфейсе интервалы:

запрос сформирован и отправлен;
сеть/RFC или посредник принял сообщение;
сообщение попало в очередь либо было передано получателю;
приложение начало обработку;
ABAP, SQL, lock wait или update завершились;
результат зафиксирован и подтверждён вызывающей стороне.

Измеряйте время ожидания и активное время отдельно, если система это показывает. Сравните несколько сопоставимых выполнений и объем данных. Один общий таймер не показывает, где тратится время; единичный медленный запуск также не доказывает устойчивую деградацию.

3. Выберите узкий диагностический след#

Признак	Что измерять и где искать
Дольше работает весь шаг ABAP	Runtime/ABAP trace: доли времени по вызовам и участкам кода; сравнение с тем же сценарием
Значимое время уходит в обращения к базе	SQL trace: длительность, число обработанных строк, частота повторяющихся операторов и план доступа
Процесс ждёт блокировку	Уточните тип lock: SAP enqueue или database lock wait; найдите владельца, ожидающую операцию, объект и длительность ожидания
RFC медленный или завершается ошибкой	Направление вызова, destination, удалённый узел, длительность, переданный объём и парная запись на принимающей стороне
Сообщение или задание долго стоит в очереди	Очередь/IDoc/job, её направление, первый незавершённый элемент, статус планировщика, время ожидания и соответствующий журнал приложения
Сообщение доставлено, но бизнес-результата нет	Отдельно проверьте статус IDoc/сообщения, application log, прикладной документ и его проводку; успешная доставка сама по себе не доказывает бизнес-обработку

В ABAP Performance Trace доступны, в зависимости от выбранного типа, SQL, enqueue, RFC и table-buffer следы. Сначала сузьте пользователя, транзакцию, программу или короткий интервал, затем включите только нужный сбор, воспроизведите операцию и сразу остановите трассу. Трассы могут влиять на нагрузку, а кольцевые файлы перезаписываются. Используйте их адресно и с необходимыми полномочиями. См. SAP Help: Recording Performance Data.

SQL trace отвечает на вопрос об обращениях к базе; для распределения времени по ABAP-вызовам нужен подходящий runtime trace или профилировщик. Не делайте вывод о качестве запроса только по числу операторов: учитывайте длительность, повторяемость, селективность и число читаемых строк. Не сравнивайте trace-записи разных объёмов данных как равнозначные.

Различайте логические блокировки SAP и ожидания блокировок СУБД. Для SAP enqueue проверьте lock-объект, владельца и связанный процесс; для DB lock wait проследите блокирующую и ожидающую транзакции. Не удаляйте запись блокировки по возрасту без проверки владельца и незавершённой SAP LUW: снятие активной блокировки может нарушить целостность обработки. См. SAP Help: SAP Lock Concept и SAP Help: Lock Analysis.

4. Найдите стадию интеграции#

Для RFC, qRFC или IDoc сопоставьте одну и ту же операцию на обеих сторонах. Запишите направление и destination, сообщение/IDoc, имя очереди или LUW, первый ошибочный статус, текст протокола, время и фактический шаг прикладной обработки. Проверяйте соответствующий монитор и журналы отправителя, получателя и посредника; номер сообщения и время должны связывать записи в общую цепочку.

Для входящего IDoc SAP разделяет передачу/сохранение IDoc и последующую прикладную обработку. Поэтому отсутствие ошибки связи не означает, что документ обработан приложением. Найдите status record и его текст, затем подтвердите или опровергните создание требуемого бизнес-документа. См. SAP Help: Inbound Processing of IDocs.

Не переводите очередь в активное состояние, не удаляйте LUW и не запускайте массовую повторную обработку, пока не установлены причина первого сбоя, владелец данных и безопасное поведение повторного сообщения. Сообщения могут ждать предыдущую запись, зависеть от порядка обработки или требовать исправления данных/настроек на другой стороне.

5. Решите, допустим ли повтор#

При таймауте отправитель может не знать, успел ли получатель выполнить операцию до потери ответа. Перед повтором проверьте по бизнес-ключу и технической корреляции: создан ли документ, изменилось ли состояние и зафиксирован ли результат. Не полагайтесь только на отсутствие подтверждения у отправителя.

Повтор допустим, если контракт операции обеспечивает безопасную дедупликацию либо целевая сторона проверяет стабильный ключ запроса. Для финансовой операции сначала выясните, допускается ли повтор и как исключается дублирование; в противном случае дождитесь сверки состояния и согласования владельца процесса. Сохраняйте исходный payload/reference, номер попытки и связь с предыдущим сообщением. Переотправка с новым ключом может выглядеть для получателя как новая операция.

После исправления повторите тот же контрольный сценарий и сравните измерения до/после. Подтвердите доставку, прикладной статус, документ и финансовый результат; отдельно проверьте, что повтор не создал дубликат. Запишите исправленную причину, изменённый параметр или объект, способ проверки и остаточные ограничения.

Источники охватывают ABAP Platform 2025 FPS01 и входящую обработку IDoc для S/4HANA On-Premise 2025 FPS01. Интерфейсы мониторинга, доступные trace-инструменты и статусы зависят от продукта, релиза и способа интеграции. Ни реальный инцидент, ни клиентские журналы, очереди, блокировки или SAP runtime в рамках этой работы не проверялись.

Связанные материалы#

REF: Diagnosing Performance and Integration Failures#

A slow operation, stalled delivery, and processing error require different evidence. Before tracing or retrying, determine where and during which time interval the symptom occurs, preserve its link to the source business event, and distinguish technical delivery from a successful financial outcome.

This page provides a shared sequence. For detail, see RFC, BAPI, and IDoc contracts, ABAP SQL, locks and the update task, traces and profiling, and background jobs and the Application Log.

1. Capture a reproducible context#

For a single business case, preserve:

SID/system, client, release, application or endpoint, and call direction;
start and end time with time zone, node/instance, user, and process type;
business document key, message/request ID, IDoc/queue/job ID, and correlation ID if available;
input parameters, row volume, expected and actual outcome, full error code and text;
attempt number, prior attempt time, send and receive status, application-processing status, and created business document if any;
measurement parameters: whether the compared runs use the same scenario, volume, and data state.

Do not place passwords, tokens, or personal data in investigation logs. Store identifiers and extracts under the access rules for production data.

2. Split the delay into stages#

Measure total time and number of processed objects first, then break the path into available intervals:

request created and sent;
network/RFC or middleware received the message;
message entered a queue or was handed to the receiver;
application processing started;
ABAP, SQL, lock wait, or update processing completed;
result committed and acknowledged to the caller.

Measure wait time separately from active processing when the system exposes it. Compare multiple equivalent runs and data volumes. One overall timer does not reveal where time is spent, and a single slow run does not prove sustained degradation.

3. Choose a focused diagnostic trace#

Signal	What to measure and where to look
The whole ABAP step is slower	Runtime/ABAP trace: time by call and code section; compare the same scenario
Database calls account for substantial time	SQL trace: duration, rows processed, repeated statement frequency, and access plan
The process waits for a lock	Identify the lock type: SAP enqueue or database lock wait; find owner, waiting operation, object, and wait duration
RFC is slow or fails	Call direction, destination, remote node, duration, transferred volume, and the matching entry at the receiver
A message or job stays in a queue	Queue/IDoc/job, direction, first pending item, scheduler status, wait duration, and related application log
Message delivered, but business result absent	Check message/IDoc status, Application Log, application document, and its posting separately; successful delivery alone does not prove business processing

Depending on the selected type, ABAP Performance Trace can record SQL, enqueue, RFC, and table-buffer activity. First narrow the user, transaction, program, or time window. Then enable only the needed collection, reproduce the operation, and stop the trace promptly. Traces can add load, and circular trace files can overwrite older records. Use them narrowly and with the required authorizations. See SAP Help: Recording Performance Data.

A SQL trace answers questions about database access; use a suitable runtime trace or profiler to understand time spent across ABAP calls. Do not judge a query only by its statement count: consider duration, repetition, selectivity, and rows read. Traces from different data volumes are not directly comparable.

Distinguish SAP logical locks from database lock waits. For SAP enqueue, inspect the lock object, owner, and associated process; for a DB lock wait, follow the blocking and waiting transactions. Do not delete a lock by age alone without checking its owner and incomplete SAP LUW: removing an active lock can compromise processing consistency. See SAP Help: SAP Lock Concept and SAP Help: Lock Analysis.

4. Locate the integration stage#

For RFC, qRFC, or IDoc, match the same operation on both sides. Record direction and destination, message/IDoc, queue or LUW name, first error status, protocol text, time, and the actual application-processing step. Check the relevant monitor and logs at sender, receiver, and middleware; message ID and time should tie the records into one chain.

For inbound IDocs, SAP distinguishes transferring/storing the IDoc from the subsequent application processing step. Therefore, a clean communication status does not mean that the application processed it. Find the status record and its text, then confirm whether the required business document was created. See SAP Help: Inbound Processing of IDocs.

Do not activate a queue, delete an LUW, or start mass reprocessing until the initial failure cause, data owner, and safe repeat behavior are known. Messages can wait on earlier records, depend on processing order, or require data or configuration fixes on the other side.

5. Decide whether a retry is safe#

After a timeout, the sender may not know whether the receiver completed the operation before the response was lost. Before retrying, check the business key and technical correlation to see whether a document was created, state changed, or result committed. Do not rely only on the sender's missing acknowledgement.

Retry only when the operation contract supports safe deduplication or the target checks a stable request key. For a financial operation, confirm that a retry is allowed and how duplicates are prevented; otherwise reconcile the state and get the process owner's approval. Preserve the original payload/reference, attempt number, and link to the previous message. Re-sending under a new key may look like a new operation to the receiver.

After a fix, repeat the same control scenario and compare measurements before and after. Confirm delivery, application status, document, and financial result; separately verify that the retry did not create a duplicate. Record the cause, changed parameter or object, verification method, and residual limitations.

The sources cover ABAP Platform 2025 FPS01 and inbound IDoc processing for S/4HANA On-Premise 2025 FPS01. Monitors, trace tools, and statuses vary by product, release, and integration method. No real incident, customer logs, queues, locks, or SAP runtime were inspected for this material.

REF: диагностика производительности и сбоев интеграции