Как с помощью Clean ABAP и Low‑code ускорить выгрузки в 5 раз
Привет, Хабр! Меня зовут Дмитрий, я работаю ведущим разработчиком в Lenta tech («Группа Лента»). В этой статье я разберу архитектуру решения, где технические инструменты — наследование классов и абстрактные типы данных — работают на конкретные бизнес‑цели. Я поделюсь нашими принципами по созданию гибкого ядра, способного за считанные дни подключать новых потребителей без риска для стабильности системы.
Когда «просто выгрузка» превращается в кошмар
Представьте типичный ИТ‑ландшафт крупного ретейлера: десятки тысяч сотрудников, сотни магазинов и постоянно растущий список внешних систем. Сегодня бизнесу нужно передавать данные в WFM для планирования графиков, завтра — в Directum для кадрового ЭДО, послезавтра — на платформу DORS и количество систем‑получателей только растет.
Стандартный путь «одна система — одна программа выгрузки» быстро превращается в «спагетти‑код». Поддержка копится как снежный ком, логика сбора данных дублируется, а нагрузка на шину SAP PI становится непредсказуемой. Каждое внедрение новой системы превращается в проект на месяц с бесконечным тестированием, а риск поломать старые интерфейсы при обновлении общих функций растет в геометрической прогрессии. Для решения этой сложной задачи мы пошли путем создания внутреннего продукта.
Нам требовался универсальный «движок», который позволит:
Сократить Time‑to‑Market новых интеграций в 5 раз: с недель до дней на новый поток, не переписывая ядро;
Гарантировать производительность: 10 000 объектов за 7 минут;
Обеспечить надежность: пакетная передача, обработка дельт и строгий контроль дублей;
Гибкость: переход к модели Low‑code и управление через настроечные таблицы.
Ниже представлена целевая архитектура решения в сравнении с классическим подходом
Конфигурация: управление потоками без переписывания ядра
В основе системы лежит принцип «Конфигурация важнее кода». Чтобы запустить новый поток данных, нам не нужно создавать новую Z‑программу — все ключевые параметры вынесены в настроечные таблицы:
Идентификатор потока: Уникальный ключ системы‑потребителя (WFM, Directum, DORS).
Класс‑обработчик: Имя ABAP‑класса, наследуемого от базового.
Параметры пакетирования: Размер пакета (например, по 1000 объектов) для оптимальной нагрузки на шину PI.
Режим работы: Выбор «Срез», «Дельта», «Отложенные события».
Бизнес‑ценность: Такой подход превращает интеграцию в Low‑code инструмент. Консультант может оперативно перенастроить параметры или добавить новую систему, просто создав запись в таблице. Это исключает риск сломать работающие интеграции.
В интерфейсе настройки достаточно указать ID системы‑получателя, выбрать один из предустановленных классов‑обработчиков и указать режим. Всё остальное — логирование, пакетирование и транспорт — движок берет на себя автоматически.
Архитектура классов: полиморфизм и магия «REF TO DATA»
А теперь к самому интересному — как это устроено. Вся техническая сложность скрыта в родительском классе, а бизнес‑логика вынесена в специализированных наследников.
Базовый класс: универсальный «транспортер» Родительский класс инкапсулирует в себе около 80% кода и отвечает за инфраструктуру. Сердце родителя — метод SEND_CONTENT.
Слепая отправка: благодаря использованию абстрактного типа данных (REF TO DATA), метод отправки абсолютно всеяден. Он не знает структуру данных конкретного потока — он просто упаковывает контент в прокси‑структуры и обеспечивает доставку.
Единый контракт: это гарантирует, что при изменении структуры данных в SAP или на стороне приемника нам не нужно переписывать логику транспорта.
Мы разделили классы по опции сбора данных, что позволило унифицировать логику обработки изменений.
Метод GET_CONTENT (Абстрактный): В родителе он пустой. Каждый наследник переопределяет его:
Класс «Срез»: Логика формирования слепка данных на текущий момент.
Класс «Дельта»: Логика вычисления изменений с момента последней выгрузки.
Инженерный вызов (CDPOS и PCL4): для HR в ретейле критично отслеживать изменения задним числом. Наш Дельта‑наследник работает напрямую с низкоуровневыми логами системы — таблицами CDPOS/CDHDR и кластером PCL4. Мы сканируем логи по конкретным полям, что гарантирует: любое изменение (даже сделанное кадровиком прошлым числом) будет мгновенно подхвачено.
Технический профит: Такой подход позволяет реализовать Event‑driven логику. Мы транслируем события, произошедшие в системе, что критично для WFM (реакция на перевод сотрудника) и Directum (запуск КЭДО по событию приема).
Скорость ретейла: как не уронить систему в пик нагрузок
Скорость и надежность — критические факторы для ретейла. Если интеграция вешает систему на часы, бизнес теряет деньги.
Интеллектуальное разбиение на пакеты: программа‑диспетчер отправляет данные порционно (например, по 1000 объектов) через SEND_CONTENT. Это снижает нагрузку на память и исключает таймауты на шине.
Фиксация по уникальному ключу: для каждой записи формируется хеш. Это исключает дубли: при повторном запуске система не будет спамить принимающую сторону уже отправленными данными.
Архитектура хаба позволяет избежать избыточной нагрузки при тиражировании с помощью оптимизации один ко многим. Если один и тот же набор данных (например, базовые инфотипы сотрудника) требуется сразу нескольким системам (WFM и Directum), движок выполняет сбор данных единожды. Сформированный контент кэшируется в рамках сессии и транслируется всем подписанным потребителям. Это превращает линейную зависимость нагрузки от количества систем в константу, позволяя подключать новых участников без просадки производительности БД.
Реальные цифры: благодаря типизации через ABAP Proxy (вместо тяжелых IDoc/ALE) исключает избыточные преобразования данных. В результате цикл выгрузки для 10 000 объектов занимает всего 7 минут.
Архитектура на базе REF TO DATA дает нам не только производительность, но и уникальную гибкость: движку фактически все равно, куда поставлять данные — В Directum RX или 1C. Целевая система меняется простым переключением в настройках, при этом тяжелая бизнес‑логика сбора и пакетной обработки в SAP HR остается нетронутой.
В ретейле скорость измеряется не только миллисекундами работы кода, но и скоростью реакции ИТ на запросы бизнеса. Переход к модели low‑code и гибкому фреймворку радикально сократил наш Time‑to‑Market (TТM). Теперь время тратится не на написание программ с нуля, а на финальное тестирование. Это позволяет запускать новые интеграции в разы быстрее, сохраняя стабильность системы
Главный стратегический эффект перехода на конфигурационную модель — сокращение Time‑to‑Market (TTM) на 80%. Исключив этап написания кода для каждого нового потока, мы трансформировали процесс: теперь путь от бизнес‑заявки до промышленного запуска занимает одну рабочую неделю вместо месяца, а основное время тратится на проверку качества данных, а не на борьбу с кодом.
Эксплуатация: стандартные инструменты
Одним из требований была простота поддержки. Мы интегрировали фреймворк в стандартную экосистему SAP. Мониторинг в одно окно: Вся диагностика (WFM, Directum, DORS) доступна в транзакции SXI_MONITOR. Ошибки видны сразу, а пакеты можно перезапускать стандартными средствами без повторного тяжелого сбора данных в SAP HR.
Анализ рынка: почему не стандарт?
Критерий | Стандартные IDoc / ALE | Наш Фреймворк | ||
Скорость разработки | ❌ | Медленно (сложные структуры) | ✅ | Высокая (1–3 дня) |
Производительность | ❌ | Средняя (XML/ALE) | ✅ | Максимальная (7 мин / 10к) |
Гибкость контента | ❌ | Жесткие сегменты | ✅ | Любой (через REF TO DATA) |
Стоимость поддержки | ❌ | Высокая (Z‑код в Enhacement‑ах) | ✅ | Низкая (Clean ABAP) |
Почему это важно сегодня? Стандартные экстракторы часто заточены под родные облачные продукты. В условиях миграции на Directum RX или 1С бизнесу нужен инструмент, который не капризничает при смене схемы данных.
Важнейшее преимущество кастомного фреймворка перед стандартом в текущих реалиях — это роль безопасного моста для импортозамещения. Процесс миграции в ретейле такого масштаба не происходит в один день. Наш хаб решает главную проблему гибридного ландшафта — синхронизацию. Пока ядро остается в SAP, а периферия постепенно уходит на отечественное ПО, решение гарантирует, что данные во всех системах будут консистентны, даже если они меняются прошлым числом.
Заключение
Мы построили адаптивный слой между стабильным SAP HR и динамичным миром внешних систем. Что получил бизнес:
Защита инвестиций: Код написан один раз и масштабируется на любые системы.
Оперативность: Запуск новых потоков в разы быстрее конкурентов.
Архитектурный иммунитет к ретро‑изменениям: Режим «Гарантированной дельты» на базе CDPOS и PCL4 обеспечивает 100% консистентность данных, даже если данные меняются прошлым числом.
Чистота архитектуры сегодня — это не академическая прихоть или просто красота кода. Это прямой рычаг эффективности бизнеса и, что важнее, фундамент технологического суверенитета. Такая гибкость позволяет крупному ретейлу не просто отвечать на вызовы импортозамещения, но и сохранять лидерство в условиях постоянной трансформации.
А готовы ли вы к построению прагматичной архитектуры на благо бизнес‑ценности?