Замена SAP на российское ПО — задача, с которой сталкиваются многие компании. Часто обсуждают миграцию данных и бизнес-процессов, но ключевой вопрос: что делать с тысячами строк ABAP-кода, написанными за годы эксплуатации? В этой статье разберём подход, при котором ABAP-приложения сохраняются, а технологическая платформа (NetWeaver и HANA) заменяется на отечественные решения. Материал основан на опыте компании «Диасофт», но мы не будем рекламировать конкретный продукт, а сосредоточимся на методологии.

Почему ABAP-код — главный актив

ABAP (Advanced Business Application Programming) — это язык, на котором написана значительная часть кастомизаций SAP. В типичной российской компании объём такого кода может достигать сотен тысяч строк: отчёты, интерфейсы, расширения стандартной функциональности. Переписать всё с нуля — значит потерять годы работы и столкнуться с ошибками. Поэтому стратегия сохранения ABAP-приложений при миграции выглядит привлекательнее, чем полная замена ERP-системы.

Однако ABAP-код исполняется на платформе NetWeaver, которая, в свою очередь, опирается на СУБД (чаще всего HANA). Замена СУБД и сервера приложений требует совместимости на уровне синтаксиса и семантики языка. Это сложная, но решаемая задача.

Ключевые компоненты замены

Чтобы сохранить ABAP-приложения, нужно заменить два уровня: сервер приложений (NetWeaver) и систему управления базами данных (HANA). Рассмотрим каждый.

  • Сервер приложений. Должен поддерживать интерпретацию ABAP-кода, включая диалект, используемый в вашей системе. Важно, чтобы новый сервер обеспечивал совместимость с существующими бизнес-процессами и интерфейсами.
  • СУБД. Должна поддерживать SQL-синтаксис, совместимый с запросами, которые генерирует ABAP-рантайм. Кроме того, необходима поддержка транзакций, блокировок и других механизмов, критичных для ERP.

Пример: СУБД Digital Q.DataBase от «Диасофт» позиционируется как замена HANA в таких сценариях. Но выбор конкретной СУБД — отдельная задача, требующая тестирования.

Пошаговый план миграции

Если вы решили сохранить ABAP-приложения при замене платформы, вот последовательность действий, которую стоит рассмотреть.

  • 1. Инвентаризация ABAP-кода. Соберите статистику: сколько программ, какие конструкции используются, есть ли зависимости от специфичных функций NetWeaver или HANA. Это поможет оценить объём работ.
  • 2. Выбор целевой платформы. Определите, какой сервер приложений и СУБД будут использоваться. Критерии: поддержка нужного диалекта ABAP, производительность, совместимость с существующими интерфейсами, наличие вендорской поддержки.
  • 3. Пилотный проект. Возьмите небольшую группу ABAP-программ (например, отчёты) и перенесите их на новую платформу. Оцените трудозатраты и выявите несовместимости.
  • 4. Адаптация кода. На основе пилота составьте список необходимых изменений. Часто требуется доработка SQL-запросов или замена вызовов специфичных API.
  • 5. Тестирование. Проведите функциональное и нагрузочное тестирование. Убедитесь, что бизнес-логика работает идентично.
  • 6. Промышленная миграция. Переносите оставшиеся приложения итеративно, с обратной связью от пользователей.

Важно: не пытайтесь мигрировать всё сразу. Итеративный подход снижает риски.

Критерии выбора СУБД и типичные ошибки

При выборе СУБД для замены HANA обратите внимание на следующие критерии:

  • Совместимость SQL. Поддерживает ли СУБД синтаксис, используемый в ваших ABAP-запросах (например, оконные функции, CTE, специфичные операторы).
  • Производительность. Проведите бенчмарки на реальных запросах. Особенно важно для аналитических отчётов.
  • Поддержка транзакций и блокировок. ERP-системы чувствительны к конкурентному доступу.
  • Наличие инструментов миграции. Хорошо, если вендор предлагает утилиты для переноса схемы и данных.
  • Стоимость владения. Учитывайте лицензии, поддержку и обучение персонала.

Типичные ошибки:

  • Недооценка объёма ABAP-кода. Начинают миграцию без полной инвентаризации, что приводит к сюрпризам.
  • Игнорирование различий в диалектах ABAP. Код, работавший на NetWeaver, может требовать доработки на новой платформе.
  • Отсутствие пилота. Попытка перенести всё сразу без проверки на небольшом участке.
  • Недостаточное тестирование. Экономия на нагрузочных тестах приводит к проблемам в продакшене.

Пример из практики: одна компания решила заменить HANA на российскую СУБД, но не учла, что часть ABAP-отчётов использует специфичные для HANA функции. В результате потребовалась переработка запросов, что увеличило срок проекта на несколько месяцев.

Что в итоге

Сохранение ABAP-приложений при замене NetWeaver и HANA на российское ПО — реалистичный сценарий, но он требует тщательного планирования. Ключевые факторы успеха: полная инвентаризация кода, выбор совместимой платформы, пилотный проект и итеративная миграция с тестированием. Не стоит рассчитывать, что замена пройдёт «незаметно» для разработчиков — адаптация кода почти неизбежна. Однако этот путь позволяет сохранить инвестиции в ABAP и избежать болезненной переработки бизнес-логики.