Интеграция SAP с ИИ: пишем умный редактор промптов для инвентаризации на ABAP

Меня зовут Виктория Мохирева, я консультант SAP MM. Сегодня расскажу о том, как мы с командой решили колоссальную задачу инвентаризации — пересортицу товаров — с помощью интеграции SAP с большой языковой моделью (ИИ).

Вот как бывает в обыденности магазина: пришёл товар, на учете кружка, а на полке по факту тарелка. Начинается танец с бубном из таблиц, сверка номенклатур и постоянные акты. Чтобы автоматизировать подбор правильных групп для пересортицы, мы написали инструмент, который позволяет общаться с ИИ напрямую из SAP GUI. Решение получилось достаточно компактным и элегантным. А под капотом у нас — архитектура, ключевые куски кода и логика ^[1], которые помогли нам превратить «регулярный ручной труд» в интеллектуальный диалог с машиной, и теперь у нас не разрозненная масса товаров, а сформированные по определенным параметрам логичные группы.

Задача: помочь пользователю «спросить правильно»

Главная проблема при внедрении ИИ в корпоративные процессы — не в том, чтобы отправить запрос, а в том, чтобы сформировать его контекстно. Мы не хотели давать пользователю пустое текстовое поле, куда он напишет «ну, в общем, подбери группу». Нам нужно было:

1.     Предоставить удобный интерфейс для ввода промпта прямо в SAP.

2.     Автоматически подгружать в запрос данные по текущей инвентаризации (материалы, описания, товарные отделы).

3.     Сохранять всю историю взаимодействия для аудита и отладки.

4.     Сделать так, чтобы разработчик мог легко масштабировать решение на другие бизнес-процессы.

Архитектура решения: класс LCL_PROMPT_EDITOR и его связь с глобальным API ZCLMM_AI_API

Сердцем системы стал локальный класс LCL_PROMPT_EDITOR. Почему локальный? Потому что на этапе прототипирования и тесной интеграции с конкретным циклом инвентаризации (программа редактора промптов) это позволило нам быстро итерировать, не создавая десятки глобальных типов.

Однако локальный класс — это лишь «тонкий клиент» для пользовательского ввода. Всю «тяжелую» работу по коммуникации с внешним миром берет на себя глобальный класс ZCLMM_AI_API. Это наш центральный шлюз для всех звонков к ИИ.

В конструктор класса мы передаем важные параметры контекста: подразделение (IV_DEP) и таблицу параметров (IT_PARAMS), где хранятся пары “Номер материала — Текст материала”. Это ключевой момент — ИИ получает не просто вопрос, а структурированные данные для анализа.

abap

METHOD constructor.

    mt_params = it_params.
    mv_dep    = iv_dep.

ENDMETHOD.

1. Удобство ввода: Кастомизированный TextEdit

Мы использовали стандартный элемент CL_GUI_TEXTEDIT, но настроили его под специфику: включили моноширинный шрифт (SET_FONT_FIXED). Это важно, когда ИИ возвращает табличные данные или коды материалов — они не “плывут”, как в пропорциональном шрифте.

abap

METHOD init_editor.

      ” Инициализируем текстовый редактор
      CREATE OBJECT mo_text_editor
        EXPORTING
          parent = mo_editor_container.

      ” Настраиваем параметры редактора
      mo_text_editor->set_toolbar_mode( toolbar_mode = 1 ).
      mo_text_editor->set_statusbar_mode( statusbar_mode = 1 ).
      mo_text_editor->set_font_fixed( ).

      ” Загружаем шаблон по умолчанию
      load_default_template( ).

ENDMETHOD.

Чтобы пользователь не мучился с формулировками, мы добавили кнопку “Загрузить шаблон”. Метод LOAD_DEFAULT_TEMPLATE заполняет редактор структурированным промптом, в который уже подставлены текущие материалы и контекст подразделения. Это резко повышает качество ответов ИИ.

Вот несколько вариантов промпта для использования:

Вариант 1.
«Сформулируй аналитический подход к классификации товаров внутри категории. Необходимо разработать правило формирования идентификатора группы пересорта, который имеет структуру: префикс (XX.YYY), за которым следует код материала и код логического объединения. Объясни, по какому принципу товары попадают в те или иные логические блоки. На основе этого принципа проведи разбивку всего ассортимента и создай схему нумерации, позволяющую однозначно определить принадлежность любого товара к конкретной группе пересорта».

 Вариант 2.
«Требуется описать логику кодирования групп пересорта в формате “XX.YYY.{материал}.{логика}”. Нужно объяснить, как товары группируются внутри своей категории. Используя эту логику, необходимо обработать полный перечень товаров и предложить итоговый принцип присвоения номеров, чтобы можно было четко идентифицировать, к какой группе относится каждая единица товара».

Вариант 3.
«Разработай методологию присвоения кодов группам пересорта согласно маске “Префикс.Код_материала.Код_группы”. Опиши механизм распределения товарных позиций в разрезе категорий и подгрупп. Примени данную логику ко всему объему данных и на ее основе составь схему кодификации, которая позволит классифицировать любой товар по заданной группе пересорта».

2. Интеграция с ИИ: Метод SEND_PROMPT_TO_AI

Этот метод — основной боевой модуль. Он выполняет три действия:

·        Сохраняет промпт на контент-сервере (для архива).

·        Пишет лог в БД.

·        Отправляет запрос в AI.

 В коде видно, что мы не лепим всё в кучу, а строго разделяем ответственность. Локальный LCL_PROMPT_EDITOR отвечает за интерфейс и пользовательскую сессию, а за HTTP-вызовы, JSON-сериализацию и обработку таймаутов отвечает глобальный ZCLMM_AI_API. Это позволяет, например, исправлять ошибки ^[2] в логике отправки или менять провайдера ИИ, не трогая код сотен локальных редакторов.

3. Надежность и прозрачность: Логирование всего и вся

Для интеграции с ИИ прозрачность критична. ИИ может ошибиться, и бизнес-пользователь должен иметь возможность спросить: “Почему он предложил именно эту группу?”.

Мы реализовали двухуровневое сохранение:

·        Контент-сервер (UPLOAD_PROMPT_TO_CS) : Сам промпт сохраняется как txt файл на content server. Это гарантирует, что мы всегда знаем, какой именно текст был отправлен модели, даже если кодировки в логах БД “посыпятся”.

·        База данных (ZMM_T_AI_PROMPT) : Здесь хранятся метаданные: TASK_ID (уникальный GUID), дата, пользователь, статус, короткий текст ответа. По TASK_ID всегда можно найти полный промпт на контент-сервере.

4. Эргономика: Обработка команд пользователя

Пользовательский интерфейс управляется через стандартную панель инструментов CL_GUI_TOOLBAR. Все действия (SEND, CLEAR, TEMPLATE, EXIT) обрабатываются в методе PROCESS_USER_COMMAND. Это классический подход Model-View-Controller в миниатюре, где класс редактора выступает контроллером.

5. Чистота памяти ^[3]: Зачем нужен метод FREE

В ABAP важно следить за памятью, особенно в долгих сессиях. Мы не полагаемся на сборщик мусора, а явно освобождаем графические компоненты (CONTAINER, EDITOR, TOOLBAR) при выходе. Это предотвращает утечки памяти (memory leaks) и зависание gui-статусов.

Результаты и взгляд в будущее

Внедрение этого инструмента позволило нам:

1.     Сократить время обработки формирования групп на 95%. Пользователь больше не ищет группы в справочниках, а просто проверяет предложенный ИИ вариант.

2.     Унифицировать запросы. Шаблоны промптов гарантируют, что ИИ получает данные в нужном формате.

3.     Получить прозрачность. Мы всегда можем провести аудит: какой запрос был отправлен и какой ответ получен по каждому TASK_ID.

Следующий шаг — вынести ядро редактора в отдельный глобальный класс (например, ZCL_AI_PROMPT_EDITOR) и повесить на него BADI. Это позволит подключать его к разным бизнес-процессам (закупки, продажи, претензии) без переписывания кода, просто передавая разные параметры и шаблоны.

Спасибо за внимание ^[4]!