SAP-разработчик: как показать ABAP и интеграции в кейсах

Список технологий ABAP OO, CDS, OData, IDoc и RFC не складывается в инженерный кейс. Интервьюеру нужно понять, как разработчик переводит функциональное требование в контракт, выбирает расширение, контролирует производительность и проводит изменение через ландшафт. Хороший рассказ связывает код с документом, пользователем и эксплуатацией.

Возьмём приложение согласования заказов с Fiori-интерфейсом и обменом статусами с внешней системой. Объём растёт к закрытию месяца, часть сообщений приходит повторно, права зависят от закупочной организации, а transport должен пройти через несколько систем. Здесь найдётся место и ABAP OO, и CDS/OData, и failure paths.

Контракт до класса и enhancement

Уточните вход, результат, объём, авторизацию и транзакционную границу. Фраза «добавить кнопку повторной отправки» требует решений: кто имеет право, какой статус допустим, создаётся ли новая попытка, можно ли повторить успешно обработанное сообщение, что увидит пользователь при timeout.

Сначала ищите released extension point и стандартный API. Modification стандартного объекта увеличивает цену upgrade и требует более сильного основания. BAdI, enhancement spot, event или side-by-side сервис выбираются по lifecycle, данным и гарантии, а не по привычке команды.

ABAP OO помогает отделить domain rule от доступа к базе, RFC и UI. Интерфейсы для repository и outbound gateway дают тестируемость, но не нужны вокруг каждой простой операции. Граница оправдана изменяемой зависимостью или отдельным контрактом.

Различайте технический и бизнес-успех. HTTP 200 или зелёный IDoc-статус не доказывает, что downstream создал правильный документ и применил нужные правила.

CDS и OData: семантика выдачи

CDS view проектируют от потребителя и cardinality. Неверная ассоциация размножает строки, скрытый фильтр теряет документы, вычисление в application layer создаёт лишний transfer. Аннотации полезны, когда выражают семантику и авторизацию, а не заменяют понимание SQL-плана.

Для OData определите paging, filter, sort, concurrency token, сообщения ошибок и допустимый payload. Endpoint списка не должен тащить тяжёлый текст каждого документа. $expand ограничивают по необходимости; права проверяются на backend для каждой операции, независимо от скрытой кнопки Fiori.

Изменение контракта версионируют или делают обратно совместимым. Добавление nullable-поля обычно безопаснее смены смысла существующего. Consumer contract test и smoke в quality system показывают, что внешняя команда не обнаружит drift только после production transport.

Производительность измеряют на объёме

Начните с SAT/ST12, SQL Monitor или подходящего trace, а не с догадки о медленном цикле. Смотрите время базы, число round trips, объём переданных строк, CPU ABAP и повторные вызовы. Один SELECT внутри LOOP может быть причиной, но массовый SELECT без фильтра тоже не улучшение.

Pushdown в CDS полезен для фильтрации и агрегации, если план и индексы соответствуют данным. Сложное вычисление, которое невозможно объяснить или тестировать, иногда лучше разделить. FOR ALL ENTRIES требует непустой driving table и понимания дублей; join или range могут быть яснее.

Кэш допустим для данных с понятной свежестью и инвалидацией. Буферизация кастомной таблицы с частыми изменениями создаст устаревшие решения авторизации. В кейсе назовите baseline, изменение, объём и guardrail, а не только процент ускорения на одном примере.

Интеграция переживает повтор и частичный сбой

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

Статусы разделяют отправку, доставку и обработку. Support должен увидеть correlation id, безопасную причину и допустимое действие: retry, исправление данных или эскалацию. Автоматический retry применяют к временным сбоям; ошибка схемы будет лишь умножать нагрузку.

LUW и update task требуют ясной точки commit. Нельзя отправить необратимый внешний вызов внутри локальной транзакции и надеяться на общий rollback. Outbox или промежуточный статус фиксирует intent, после чего отдельный worker выполняет доставку идемпотентно.

Схема показывает опорные решения кейса «SAP-разработчик: как показать ABAP и интеграции в кейсах».

Transports и рассказ о выпуске

Перечислите зависимости transport requests, customizing и workbench objects, последовательность импорта, роли и smoke. Retrofit между ландшафтами, незавершённая задача коллеги и конфликт версий требуют coordination. Копирование объекта вручную не является стратегией выпуска.

Проверьте вакансии SAP-разработчика и зарплатный диапазон, затем выберите кейс нужной глубины. Завершите post-release наблюдением: очередь IDoc, error rate OData, время ответа, business count и план отката. Так код выглядит частью управляемой системы.

Авторизацию проверяйте на уровне действия и данных. DCL для чтения CDS не обязательно защищает custom action, а UI-роль не заменяет AUTHORITY-CHECK. Негативный тест с пользователем другой закупочной организации должен закончиться отказом без утечки полей.

При mass processing проектируйте пакет, checkpoint и restart. Один LUW на сто тысяч документов удерживает ресурсы и дорого откатывается. Малые идемпотентные порции позволяют продолжить после ошибки, но требуют итоговой сверки полноты.

ATC и code review ловят разные классы проблем. Статический анализ находит запрещённые API и подозрительные конструкции, коллега проверяет контракт и эксплуатацию. Исключение ATC имеет владельца и причину; массовое подавление предупреждений прячет upgrade risk.

Для background job назовите variant ownership, окно, параллелизм, блокировки и реакцию на пропущенный запуск. Job, который просто стартует чаще после замедления, способен наложиться сам на себя и удвоить нагрузку в самый тяжёлый период.

Fiori error message должен помогать пользователю исправить данные, но не раскрывать stack или внутренний endpoint. Техническая причина уходит в application log с correlation id. Support связывает сообщение экрана и журнал без копирования чувствительного payload.

На интервью полезно показать отказ от разработки. Если стандартный API после проверки покрывал требование, отказ от кастомного RFC сократил поддержку и upgrade cost. Инженерная ценность измеряется качеством решения, а не количеством написанного ABAP.

Мини-кейс: повтор IDoc после validation error

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

Разработчик разделил транспортный и бизнес-результат. В ledger сохраняются внешний business key, версия операции, статус обработки и correlation id. Timeout и 503 допускают ограниченный backoff при идемпотентности. Schema или validation error переводит запись в состояние, где нужен исправленный payload либо изменение mapping; автоматический retry без изменения данных не запускается.

На стороне ABAP проверили authorization для действия и закупочной организации, а не только видимость кнопки Fiori. Массовую обработку разбили на порции с checkpoint, чтобы один дефект не откатывал сто тысяч документов. Business count после завершения сверяется с источником, включая пропуски и дубли.

Transport plan связал workbench object, customizing и зависимый service definition. Сначала импортировали совместимый контракт, затем реализацию и роли; post-import smoke прошёл негативным пользователем и реальным повтором сообщения. Для частичного импорта заранее определили остановку и восстановление, без ручного копирования объектов между системами.

Для validation error support получил не общий текст сбоя, а безопасный код причины, поле контракта и действие владельца данных. Исправленное сообщение сохраняет тот же business key, но получает новую версию; точный повтор старого payload возвращает прежний результат ledger. Так разработчик различил повтор доставки и новую бизнес-попытку. Негативный тест доказал, что пользователь другой purchasing organization не видит ни payload, ни возможность retry, даже если знает технический идентификатор.

Метрики после выпуска разделили accepted, processed и rejected документы. Равенство отправленных и принятых сообщений больше не выдавалось за полноту бизнес-обработки.

Финальная фраза кейса проста: код ускорил обработку только после того, как повтор, права и выпуск стали проверяемыми контрактами. Одного зелёного IDoc-статуса для этого недостаточно.