Привет, Хабр!
Меня зовут Андрей Жуйков, в «Диасофт» я занимаюсь развитием и продвижением СУБД Digital Q.DataBase.
Обычно я рассказываю о базах данных, их архитектуре и возможностях. Но сегодня хочу показать, как наша СУБД становится частью более масштабного решения – замены технологической платформы SAP с сохранением существующих ABAP-приложений.
Причем самое интересное здесь даже не замена СУБД, а то, что происходит с программами, написанными на ABAP.
Лучше один раз увидеть
Для начала предлагаю посмотреть короткую демонстрацию.
В ролике показан редактор ABAP-кода на российской платформе КРЫМ-Р.
Разработчик пишет программу на ABAP, нажимает «Сохранить», затем «Активировать». И вот тут начинается самое интересное.
По нажатию одной кнопки платформа автоматически преобразует ABAP-код в C++, компилирует его и устанавливает полученный исполняемый компонент на сервер приложений.
Никакого ручного переписывания на C++, самостоятельной компиляции или развертывания бинарных файлов. Для разработчика все выглядит как обычная работа с ABAP.
Зачем понадобился C++, что происходит при активации и как все это работает без оригинального SAP NetWeaver? Об этом и поговорим.
Зачем вообще менять работающую SAP-систему
Представьте крупное предприятие, которое последние двадцать лет развивало свои информационные системы на SAP.
За это время написаны тысячи ABAP-программ, настроены интеграции, реализованы сложные бизнес-процессы. Все работает, сотрудники привыкли, разработчики знают систему вдоль и поперек.
И вот возникает задача: необходимо отказаться от зарубежного программного обеспечения.
Что делать? Внедрять новую ERP, переписывать бизнес-логику, переносить данные, заново настраивать интеграции? Для крупного предприятия такой проект легко может растянуться на несколько лет.
Причем существующая система может прекрасно справляться со своими задачами. Проблема не в бизнес-логике, а в технологической платформе, на которой она работает.
А что, если заменить саму платформу, сохранив уже написанные ABAP-приложения?
Именно такой подход мы реализовали в «Диасофт». Причем здесь есть несколько довольно интересных технических решений: прозрачная конвертация ABAP в C++, собственный сервер приложений и гибридная СУБД, использующая разные механизмы хранения и обработки данных.
Давайте разбираться, как все это устроено.
Что находится под капотом SAP
Для начала вспомним архитектуру классической SAP-системы.
В упрощенном виде она состоит из трех уровней:
-
Presentation Layer – пользовательский интерфейс, например SAP GUI.
-
Application Layer – сервер приложений SAP NetWeaver AS ABAP, на котором выполняется бизнес-логика.
-
Database Layer – СУБД, отвечающая за хранение и обработку данных.
На первый взгляд все достаточно традиционно. Но самое интересное происходит на уровне сервера приложений.
SAP NetWeaver AS ABAP – это не просто механизм выполнения программ. Он отвечает за пользовательские сессии, фоновые задания, управление процессами, взаимодействие с базой данных, распределение нагрузки и множество других системных функций.
А сама бизнес-логика реализована на ABAP.
Все это тесно связано. Поэтому просто взять исходный ABAP-код, перенести его на другой сервер и запустить не получится.
Необходимо воспроизвести среду, на которую рассчитывают программы.
В нашем решении эту задачу выполняет российская платформа КРЫМ-Р, а за хранение и обработку данных отвечает Digital Q.DataBase.
Пишем на ABAP, а исполняем C++. Как это работает?
Один из центральных механизмов решения – автоматизированное преобразование ABAP-программ в C++.
Да, именно в C++.
Но здесь есть важная деталь: C++ не становится обязательным языком разработки. Он используется внутри процесса преобразования для получения исполняемого кода.
Разработчик по-прежнему работает на ABAP. А все необходимые действия по преобразованию и сборке выполняются платформой автоматически.
Что скрывается за кнопкой «Активировать»
Внутри платформы запускается следующая последовательность:
ABAP → транспиляция в C++ → компиляция → бинарный код → установка на сервер КРЫМ-Р
Разберем ее подробнее.
1. Сохранение ABAP-программы
Разработчик работает с исходным кодом на знакомом языке. Ему доступны привычные сценарии редактирования и активации программ.
2. Активация программы
После нажатия кнопки «Активировать» платформа запускает процесс преобразования.
Исходный ABAP-код анализируется и транспилируется в C++.
Термин транспиляция означает преобразование исходного кода с одного языка программирования на другой.
Но задача конвертера не сводится к механической замене операторов. Необходимо сохранить семантику программы, учесть особенности типов данных, выражений, операций и взаимодействия с системными функциями.
Для поддержки необходимых возможностей ABAP используются механизмы самой платформы КРЫМ-Р.
3. Компиляция C++
Полученный C++ автоматически передается компилятору, который формирует исполняемый бинарный код для целевой платформы.
4. Установка на сервер
После успешной сборки результат автоматически устанавливается на сервер приложений КРЫМ-Р.
Программа готова к выполнению.
Обратите внимание: активация – это не запуск самой бизнес-операции. Она подготавливает и устанавливает исполняемую версию программы. А уже затем пользователь может ее запустить.
Всю эту последовательность разработчику не приходится выполнять вручную.
Почему именно C++?
Здесь все довольно прагматично.
C++ – широко распространенный компилируемый язык с развитой экосистемой инструментов сборки для различных операционных систем и аппаратных архитектур.
Поэтому C++ используется как промежуточный этап между исходной ABAP-программой и машинным кодом.
Вместо реализации собственного компилятора ABAP непосредственно в машинный код каждой целевой архитектуры можно использовать существующую инфраструктуру компиляции C++.
Разумеется, переносимость не возникает автоматически: сформированный код, необходимые библиотеки и сама среда выполнения должны поддерживать целевую платформу.
Но использование распространенного языка позволяет опираться на уже существующие инструменты разработки.
И здесь, пожалуй, главный момент.
C++ не навязывается ABAP-разработчику как новый язык программирования.
Он может вообще не видеть сгенерированный код и продолжать работать на ABAP столько, сколько ему необходимо.
А если в дальнейшем появится задача развивать приложение непосредственно на C++, такой путь тоже можно рассматривать. Правда, в этом случае уже необходимо решить, как сопровождать измененный C++ и не потерять доработки при повторной генерации из ABAP. Это отдельный сценарий разработки.
Таким образом, предприятие может сохранить существующую команду и процессы разработки, не устраивая одновременно с миграцией платформы еще и переход на другой язык программирования.
КРЫМ-Р: что приходит на замену SAP NetWeaver
С преобразованием кода разобрались. Но полученный бинарный файл должен где-то выполняться.
Для этого и предназначена платформа КРЫМ-Р. Это российская программная платформа, которая реализует функции сервера приложений, необходимые для работы перенесенных программ. В ее составе предусмотрены сервер приложений и SDK.
КРЫМ-Р обеспечивает управление пользовательскими сессиями, выполнение приложений, распределение нагрузки, взаимодействие с базой данных и другие инфраструктурные функции.
Особенно интересно, что платформа поддерживает работу не только с отдельными ABAP-программами, но и с взаимосвязанными программными объектами, включая функциональные группы и классы.
Для реальных корпоративных систем это принципиально: бизнес-логика почти никогда не существует в виде одной самостоятельной программы.
Обычно перед нами целый набор компонентов, которые взаимодействуют между собой, используют общие данные и вызывают системные функции. Поэтому перенос отдельного исходного файла – лишь часть задачи. Необходимо обеспечить работу соответствующего прикладного окружения.
И еще одна интересная деталь: пользовательский интерфейс тоже необязательно переписывать с нуля.
SAP GUI больше не нужен? А что увидит пользователь?
Представим бухгалтера, который десять лет работает с определенными экранами SAP.
Он знает, какую кнопку нажать, в какое поле ввести данные и где посмотреть результат. А теперь ему предлагают совершенно новый интерфейс.
Знакомая ситуация: технически система стала лучше, зато пользователи внезапно перестали ее любить.
В КРЫМ-Р предусмотрен другой вариант. Классические экраны SAP, включая DynPro и селекционные экраны, могут отображаться непосредственно в веб-браузере. При этом сохраняются привычные элементы управления: поля, таблицы, кнопки и другие компоненты интерфейса.
То есть вместо оригинального SAP GUI пользователь может работать через браузер.
Есть также возможность изменить оформление. Предусмотрены несколько визуальных тем, в том числе более современные.
Для переключения используются настройки платформы, включая механизм CHANGE_CONFIG.
Получается довольно любопытная ситуация: приложение уже выполняется на другой платформе, а пользователь продолжает работать со знакомой функциональностью.
Конечно, это не означает, что любой экран SAP автоматически и без доработок заработает в браузере. Сложные DynPro, нестандартные элементы и специфичные сценарии требуют проверки. Но возможность сохранить интерфейс позволяет избежать еще одной дорогостоящей части миграции – полного перепроектирования пользовательского взаимодействия.
А теперь самое интересное для любителей СУБД
Сервер приложений мы заменили. Но корпоративная система – это еще и данные. И здесь появляется отдельная техническая задача.
SAP HANA – далеко не обычная реляционная СУБД. Она активно использует оперативную память, поддерживает построчное и поколоночное хранение, располагает собственными механизмами выполнения запросов и оптимизации вычислений.
Например, при аналитической обработке не всегда эффективно читать строки целиком. Если запросу нужны только несколько столбцов из большой таблицы, поколоночное хранение позволяет существенно сократить объем обрабатываемых данных.
Другие задачи, наоборот, ориентированы на частые изменения отдельных записей и транзакционную обработку.
Поэтому просто заменить SAP HANA на классическую PostgreSQL без изучения нагрузки – идея, мягко говоря, не универсальная.
PostgreSQL – зрелая промышленная СУБД, но она не воспроизводит автоматически особенности архитектуры SAP HANA.
В рассматриваемом решении для хранения и обработки данных используется Digital Q.DataBase.
Реляционная, поколоночная и in-memory обработка
Digital Q.DataBase – российская гибридная СУБД, построенная на основе существенно переработанного PostgreSQL.
В ее архитектуре предусмотрено несколько механизмов хранения и обработки данных.
Реляционная обработка
Классический подход для транзакционных систем: SQL, таблицы, индексы, транзакции, ограничения целостности и другая функциональность, которую мы ожидаем от промышленной СУБД.
Поколоночная обработка
Для аналитических сценариев используются механизмы, позволяющие эффективно обрабатывать данные по столбцам.
Это актуально для выборок, агрегирования больших объемов информации и других операций, характерных для аналитических нагрузок.
In-memory
Отдельный компонент обеспечивает работу с данными в оперативной памяти, сокращая задержки для определенных типов операций.
Разумеется, использование оперативной памяти само по себе не означает, что любой запрос автоматически станет быстрее.
Все зависит от алгоритмов обработки, структуры данных, профиля нагрузки и конфигурации оборудования.
Но сочетание нескольких моделей обработки позволяет эффективнее работать с различными типами задач.
При этом Digital Q.DataBase не является программной копией SAP HANA. Поэтому при переносе данных и приложений необходимо проверять SQL-совместимость, транзакционное поведение и специфичные механизмы, которые использует исходная система.
Как выглядит архитектура после перехода
Теперь соберем все вместе.
Вместо привычной связки SAP GUI → SAP NetWeaver → SAP HANA получаем другую архитектуру:
Веб-браузер / desktop-клиент
↓
Балансировщик нагрузки
↓
Кластер серверов приложений КРЫМ-Р
↓
Кластер Digital Q.DataBase
Клиентская часть может взаимодействовать с системой по HTTPS. Также предусмотрен desktop-клиент на основе Qt.
Прикладная логика выполняется на серверах КРЫМ-Р, а данные хранятся и обрабатываются в Digital Q.DataBase.
Таким образом, мы получаем единый российский технологический стек: от пользовательского интерфейса и сервера приложений до уровня хранения данных.
Архитектура предусматривает масштабирование уровня приложений, балансировку нагрузки и использование отказоустойчивой конфигурации СУБД.
При этом производительность всей системы зависит не только от базы данных. Важны управление пользовательскими сессиями, работа фоновых процессов, эффективность SQL-запросов, распределение ресурсов и взаимодействие между компонентами.
Отказоустойчивость также требует отдельных испытаний: необходимо проверить поведение системы при отказе узлов, восстановление соединений, резервное копирование и другие сценарии промышленной эксплуатации.
Можно ли таким образом перенести вообще весь SAP?
Вот здесь я бы предложил отделять технологические возможности от ожиданий заказчика.
В настоящей SAP-системе, особенно большой и давно эксплуатируемой, все гораздо сложнее, чем набор ABAP-программ. Там могут присутствовать собственные разработки, стандартные модули, расширения, внешние интеграции, сложные структуры данных, фоновые задания и специфичные функции SAP. И все это связано между собой. Поэтому автоматизированная конвертация ABAP не равнозначна гарантированному переносу всей системы SAP ERP или S/4HANA.
Перед миграцией необходимо выяснить, какие программные объекты используются, какие системные функции требуются для их выполнения, как организованы интеграции и какие особенности работы с данными необходимо сохранить.
Отдельно следует учитывать лицензирование и права на использование исходного кода, особенно стандартных компонентов SAP.
Иными словами, волшебной кнопки «перенести вообще все» здесь нет.
Но для поддерживаемой ABAP-программы кнопка «Активировать» действительно автоматизирует всю цепочку от исходного кода до установленного исполняемого компонента.
И это принципиально разные вещи.
Вместо заключения
На мой взгляд, самое интересное в этой технологии – возможность заменить технологическую платформу SAP, сохранив существующую бизнес-логику и привычный язык разработки.
КРЫМ-Р обеспечивает исполнение ABAP-приложений, а Digital Q.DataBase отвечает за хранение и обработку данных. При этом разработчики могут продолжать работать на ABAP, а всю цепочку преобразования в исполняемый код платформа берет на себя.
А как вам такой подход к миграции SAP? Особенно интересно мнение ABAP-разработчиков и архитекторов корпоративных систем.
Полезные ссылки
ссылка на оригинал статьи https://habr.com/ru/articles/1101290/