ABAP: фоновые задания, пакеты и журналирование#

Фоновый запуск меняет условия выполнения, но не отменяет проектирование процесса. Задание должно иметь явные шаги, условия старта, вариант параметров, полномочия, ожидаемый объём и способ проверить результат. Для больших операций дополнительно нужны ограниченные пакеты, сохранение прогресса и правила безопасного повторного запуска.

Контракт фонового задания#

Задание состоит из одного или нескольких шагов. В каждом укажите программу или внешнюю команду, вариант отбора, плановое время или событие запуска, приоритет, целевой сервер либо балансировку, язык, пользователя запуска и ожидаемые spool-результаты. Запланированное задание должно быть корректно выпущено для выполнения; проверяйте владельца, полномочия и условия старта отдельно от факта сохранения расписания.

Вариант отбора является частью воспроизводимости. Фиксируйте его имя и версию, диапазон компании, даты или периодов, режим обработки, ограничения объёма и настройки повтора. Не используйте вариант, который незаметно отбирает все периоды или позволяет запустить разрушающий режим без подтверждения.

Пакетная обработка с восстановлением#

Разбейте большую работу по устойчивому ключу и задайте верхнюю границу размера пакета. Храните идентификатор запуска, диапазон ключей, номер пакета, время начала и окончания, состояние, количество прочитанных, записанных, отклонённых и повторно обработанных объектов. Сохраняйте checkpoint только после фиксации соответствующих данных и результата обработки.

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

Контролируйте конкуренцию и ресурсы: длительность, память, число записей, блокировки, потребление фоновых work process и нагрузку базы. Для тяжёлой выборки применяйте селективные условия и ограниченный пакет; планируйте окно и количество параллельных заданий. Увеличение параллелизма без анализа порядка ключей и блокировок может замедлить процесс или создать взаимные конфликты.

Журнал задания и Application Log#

Job log показывает системные и программные сообщения по шагам задания, включая предупреждения, ошибки и завершение. Используйте его вместе со статусом шага, ABAP dump и spool, если они относятся к проблеме. Job log не является полной трассой бизнес-объектов и не обязательно содержит сообщения отдельных механизмов обработки, например batch input.

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

Разделяйте информационный итог, предупреждение, отклонённую запись и аварийное завершение. Для каждой ошибки укажите, можно ли повторить только запись, пакет или всё задание, нужна ли очистка, и как проверить, что предыдущая попытка не создала документ. Spool используйте для предназначенного пользователю отчёта, а не вместо структурированного журнала.

Контроль результата и диагностика#

Сопоставьте статус задания и шага с числом обработанных и отклонённых ключей. Сверьте контрольные суммы и количества по компании, ledger, периоду и валюте. Успешный статус задания не заменяет контроль бизнес-результата, а сообщение об ошибке не всегда означает, что не было частичной фиксации.

Для расследования сохраните job name и идентификатор экземпляра, владельца, время и start condition, программу и вариант, шаг с ошибкой, application-log object/subobject, бизнес-ключ, текст и номер сообщения, dump/spool-ссылки, checkpoint и последнюю подтверждённую операцию. Сначала проверьте состояние документов и checkpoint, затем выбирайте повтор. Не удаляйте файлы job log напрямую на уровне операционной системы; используйте штатное управление заданиями и хранением SAP.

Ссылки описывают фоновую обработку ABAP Platform 2025 FPS01 и Application Log. Наличие полномочий, доступных ресурсов и эксплуатационных процедур зависит от системы. В этом проекте нет SAP runtime; фоновые задания, batch recovery, SLG1 и бизнес-сверки не выполнялись.

ABAP: Background Jobs, Batches, and Logging#

Running in the background changes execution conditions but does not remove the need to design the process. A job needs explicit steps, start conditions, parameter variant, authorizations, expected volume, and a way to verify its result. Large operations also need bounded batches, saved progress, and safe restart rules.

Background-job contract#

A job consists of one or more steps. For each step, define the program or external command, selection variant, planned time or event, priority, target server or load balancing, execution user, and expected spool output. A scheduled job must be released before it can run; check owner, authorizations, and start conditions separately from whether the schedule was saved.

The selection variant is part of reproducibility. Record its name and version, company and date or period range, processing mode, volume limits, and retry settings. Do not use a variant that silently selects every period or allows a destructive mode without confirmation.

Batch processing with recovery#

Split large work by a stable key and define a maximum batch size. Store the run ID, key range, batch number, start and end time, status, and counts of read, written, rejected, and retried objects. Save a checkpoint only after the corresponding data and processing result have been committed.

A retry must be idempotent or explicitly continue from a confirmed key. Do not advance the read position when the write is unconfirmed. For a partial error, preserve the original keys, reason, input version, and retry procedure; do not mark the whole run successful just because part of the data was processed. Prevent conflicting instances from running at the same time and define cancellation, locking, and restart behavior after a server failure.

Control concurrency and resources: duration, memory, record count, locks, background work-process consumption, and database load. Use selective filters and bounded batches for heavy reads; schedule an appropriate window and number of parallel jobs. Increasing parallelism without checking key order and locking can slow the process or create conflicts.

Job log and Application Log#

The job log shows system and program messages by job step, including warnings, errors, and completion. Use it with step status, ABAP dumps, and spool when relevant. A job log is not a complete trace of business objects and may not contain messages from every processing mechanism, such as batch input.

Application Log adds business context: object and subobject, run ID, business key, message type and class, validation result, and error reference. Write short useful messages at processing boundaries and group them so an operator can find a run in SLG1. Do not log passwords, full personal data, or large payloads as free text.

Distinguish an informational summary, warning, rejected record, and abnormal termination. For each error, state whether to retry a record, batch, or whole job, whether cleanup is needed, and how to verify that the previous attempt did not create a document. Use spool for a report intended for a user, not as a substitute for structured logging.

Verify results and diagnose#

Compare job and step status with counts of processed and rejected keys. Reconcile control totals by company, ledger, period, and currency. A successful job status does not replace a business-result check, and an error message does not always mean that no partial commit occurred.

For an investigation, retain job name and instance ID, owner, time and start condition, program and variant, failed step, Application Log object and subobject, business key, message text and number, dump or spool reference, checkpoint, and last confirmed operation. First verify document and checkpoint state, then choose a retry. Do not delete job-log files directly at the operating-system level; use SAP job and retention management.

The links describe ABAP Platform 2025 FPS01 background processing and Application Log. Available authorizations, resources, and operations procedures depend on the system. This project has no SAP runtime; jobs, batch recovery, SLG1, and business reconciliations were not executed.