Итак, на дворе 2025 год, и все только и говорят про AI и новую эпоху развития IT-технологий. Сам я являюсь SAP SD консультантом, поэтому в процессе работы сталкиваюсь с AI не часто, но с интересом отслеживаю возможности его применения.

Давайте же попробуем разобраться, как всем, кто связан с разработкой SAP, могут помочь современные AI-технологии. Первую часть своего скромного исследования я хотел бы посвятить такой теме, как возможность повайбкодить на ABAP.

Мифы и реалии ABAP и LLM

Существует мнение: чем больше программ написано на определённом языке, и чем больше их в открытом доступе, тем лучше модель может с ним работать и тем лучше она его понимает.

Поэтому часто говорят, что модели хорошо пишут программы, например, на Python или JavaScript, но гораздо хуже на новых языках (например, Kotlin или Dart), а также на старых и малоиспользуемых языках. В этом контексте часто вспоминают мифологический (древнегреческий в ИТ-сообществе) язык программирования COBOL. Так вот, если с чем и можно сравнивать наш внутренний, проприетарный язык разработки в SAP — ABAP, то, скорее всего, с языком COBOL.
Я решил проверить, насколько эти предположения верны, и протестировать современные LLM-модели на написание небольших простых программ на языке ABAP.

С чем сталкиваешься при вайбкодинге на ABAP

Ранее я уже пробовал вайбкодить различные программы на ABAP с помощью LLM. Проблемы, с которыми сталкиваешься в первую очередь — это незнание стандартов и «галлюцинации» модели.

В ABAP, помимо стандартной логики и языковых конструкций, при написании программ мы очень часто используем внутренние библиотеки или фреймворки. Например, одним из краеугольных принципов системы является транзакционность. Мы никогда не выполняем изменения в таблицах (особенно стандартных таблицах базы данных) командами UPDATE или MODIFY. Вместо этого всегда используем бизнес-API — BAPI, либо другие функциональные модули, заранее подготовленные в системе.

То же самое относится к различным внутренним классам и интерфейсам. С появлением ООП-подхода в ABAP многие стандартные инструменты и утилиты, ранее реализованные через функциональные модули, были переведены в аналогичные наборы классов. Поэтому владение и понимание этих классов также необходимо.

Если подытожить, знание стандартных функций и классов в ABAP можно сравнить со знанием всех библиотек в том же Python. Без этих знаний вы можете писать только на «голом» языке, но такие программы часто небезопасны и никогда не пройдут код-ревью в стандартных производственных процессах.

Также важным является знание структуры объектов и стандартной базы данных SAP ERP. Каждый консультант и разработчик, как «Отче наш», знает названия двух-трёх десятков общепринятых таблиц, где хранятся используемые объекты. За время работы приходится сталкиваться и с сотнями других таблиц, которые нужно уметь использовать при извлечении данных. Названия вроде VBAK, MATDOC, ACDOCA мало что скажут обычному человеку, но этот шифр поймёт любой SAP-специалист.

Таким образом, для полноценного написания рабочей программы на ABAP необходимо:

  • знать стандартные функции и классы;

  • правильно их использовать;

  • знать структуру базы данных;

  • уметь обращаться к нужным таблицам при построении поисковых запросов.

Подготовка и инструменты тестирования

Для полноценного тестирования были выполнены следующие шаги:

  1. Выгрузили все существующие в системе функции, таблицы и классы в отдельные файлы из таблиц SAP-системы и сохранили их в текстовых файлах.

  2. Написали собственный парсер на Python для выделения функциональных модулей, классов и таблиц из ABAP-программ, так как готового решения не было найдено в открытом доступе.

Стоит отметить, что я не являюсь специалистом в Python, однако благодаря LLM и вайбкодингу у меня появилась возможность создавать быстрые прототипы и сравнить возможности работы LLM с Python и ABAP. Парсер имеет упрощения: например, таблицы ищутся только внутри непосредственной SQL-обработки, исключая объявления переменных и создание объектов, чтобы избежать лишнего шума.

Третий этап — подготовка промта и правил. Опыт вайбкодинга показал, что правильная постановка задачи критически важна. Поэтому были сделаны намеренные упрощения:

  • Исключена работа с CDS из-за быстрого развития новых объектов.

  • Запрещён OOP-стиль в пользу процедурного подхода для облегчения парсинга.

Системный промт под катом
You are an experienced SAP ABAP developer working on an SAP S/4HANA 1610.  
Generate production‑ready ABAP source code and follow every rule below.

1. **Use only SAP‑standard artifacts**  
   • Function modules: BAPI_* (released only).  
   • Global classes: CL_* that exist in every S/4HANA system.  
   • Transparent tables/views that ship with SAP.  
   → Never invent names; if unsure whether an object exists, write "TODO‑CHECK:<name>" and do not rely on it for data changes.

2. **No direct DB updates on SAP standard tables**  
   • Create / change business objects exclusively through released BAPIs or service classes.  
   • Example: use BAPI_SALESORDER_CREATEFROMDAT2 + BAPI_TRANSACTION_COMMIT instead of INSERT/UPDATE VBAK.  


3. **Clean‑ABAP style**  
   • Inline DATA declarations, meaningful prefixes (lv_, lt_, ls_).  
   • Typed exceptions (CX_STATIC_CHECK) instead of MESSAGE.  
   • Use helper to convert bapiret2 messages to exceptions.  

4. **Documentation**  
   • Add ABAP Doc ("!) for every public class and method, describing parameters, returning values and exceptions.  

5. **Output rules**  
   • Return **only** the ABAP code wrapped in 
abap …
 fences — no explanations, comments or text outside the code.  


⛔ NO custom objects
• Do not create or use any Z*/Y* classes, structures, tables, or function modules.
• Do not declare local classes (CLASS … DEFINITION LOCAL).
• Only released BAPI_, CL_  and standard SAP tables are permitted.

⛔ NO wrappers / helpers
• Do not write your own helper classes or methods; call the standard SAP API directly.
• If a helper object seems necessary, write TODO-CHECK:<name> instead of code.

Задача была сформулирована так, чтобы максимально использовать BAPI, классы и таблицы на примере цепочки документов: сбытовой заказ → поставка → фактура.

Тестовое задание
TASK  “SD_ORDER➜DELIVERY➜INVOICE”

You should  create executable program  GPT_o3.abap

INPUT

p_vbeln  TYPE vbak-vbeln   "Sales order number

BUSINESS STEPS

1. Read the sales order header, items and current status through a *released* SAP API.

2. If the pricing date of the order is either empty **or** identical to the creation date,

then set a new pricing date = creation_date + 7 calendar days, save the change and commit.

3. Ensure the order is not blocked for delivery.

• If blocked, raise a checked exception and stop processing.

4. Create an outbound delivery for the order via a *released* SAP API and commit.

5. Create a billing document for that delivery via a *released* SAP API and commit.

6. Retrieve the complete document flow (order → delivery → invoice) via a *released* SAP API

and display it as an ALV grid with columns:

FROM_VBELN | FROM_OBJCAT | TO_VBELN | TO_OBJCAT | CREATED_ON

Инструментом тестирования стала IDE Trae с доступными LLM-моделями.

Скриншот с IDE Trae  доступными LLM-моделями
Скриншот с IDE Trae доступными LLM-моделями

Модели, недоступные в IDE, проверялись напрямую через браузер (WebChat). При тестировании глобальные правила не включались, а локальное правило было добавлено в промт.

Весь код и тестовые данные можно посмотреть в репозитории
https://github.com/GunS82/abap_vibecode_checker

Результаты и выводы

Файл

Классы/Интерфейсы

Функции

Таблицы БД

Всего

% реальных

DeepSeekR1.abap

1

6

0

12

71.4%

DeepSeekV3.abap

0

7

0

13

71.4%

GPT4_1.abap

0

8

1

13

88.9%

GPT4o.abap

2

7

0

14

77.8%

GPT_o3.abap

1

7

1

17

77.8%

Gemini25_Flash.abap

1

6

0

21

57.1%

Gemini25_Pro.abap

4

5

1

21

100.0%

Grok4.abap

1

5

0

15

83.3%

KimiK2.abap

3

7

0

13

70.0%

Qwen3_Coder.abap

3

5

2

25

90.0%

Sonnet35.abap

0

8

0

18

75.0%

Sonnet37.abap

0

8

0

21

87.5%

Sonnet4.abap

1

5

1

20

85.7%

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

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

Безнадёжно ли применение LLM в SAP, или есть перспективные сценарии использования? На эту тему я планирую написать в следующих статьях.

Что касается вайбкодинга на ABAP, на мой взгляд, единственным приемлемым путём является создание специализированной LLM от SAP, обученной на внутреннем коде. Однако некоторые эксперты сомневаются, что такого объема данных достаточно, чтобы модель могла существенно превзойти существующие публичные модели. Завялятся, что такие решения уже существуют, но, к сожалению, проверить их возможности мне пока не удалось.

Если у вас есть опыт такого вайбкодинга, оставляйте комментарии. Возможно, у вас есть более эффективный подход.

Комментарии (2)


  1. Rarity64
    02.08.2025 19:07

    Почему абапер должен знать как «отче наш» много таблиц по модулю? Как правило, абапер может работать в куче модулей и за всем не управишься. У абапера есть своя работа, у консультанта — своя, он пусть и направляет, где что в какой таблице брать.

    Почему обновления таблиц с помощью UPDATE и MODIFY не используются? Внутри BAPI может это как раз и произойти.


    1. gennadybanin Автор
      02.08.2025 19:07

      Все таблицы он знать как раз не обязан, но в процессе долгой работы они все "въедаются" в память сами.

      По поводу обновлений - если это свои таблицы , то это часто делается. Но стандартные таблицы, особенно связанные с традиционными объектами сам SAP рекомендует делать только через BAPI.