Привет! Меня зовут Дмитрий Канатников. Я работаю архитектором информационных систем в компании Sapiens Solutions с 2013 года и занимаюсь внедрением хранилищ данных на базе SAP и open source-систем с 2007 года. В этой статье расскажу о том, как мы решали проблему медленной выгрузки данных из SAP.

Предпосылки

В современных условиях возрастает актуальность выгрузки данных из SAP ERP в хранилища данных DWH или Data Lakehouse сторонних вендоров. Интеграция с системами, не входящими в экосистему SAP, зачастую сопровождается сложностями: поставщики программного обеспечения, как правило, не поддерживают использование конкурентных продуктов. Нативный механизм выгрузки данных в SAP BW (Business Warehouse) не может быть применен к системам, не принадлежащим к экосистеме SAP.

На нашем проекте внедрения хранилища данных на основе Arenadata DB для одного из крупных банков мы столкнулись со сложностями при интеграции с SAP S/4HANA. Стандартные инструменты для экстракции данных от SAP по тем или иным причинам оказались непригодны для быстрой и надежной выгрузки больших объемов данных. Рассмотрим существующие варианты интеграции.

SAP RFC

SAP RFC (Remote Function Call) позволяет подключаться к серверу приложений и запускать ФМ (функциональные модули) по нативному протоколу SAP, что в теории может дать высокую скорость работы и переиспользование бизнес-логики, реализованной на ABAP. Однако, есть и существенные минусы. При большом объеме выгрузки нет возможности разделить данные на пакеты, а также нет инкрементальной загрузки. Кроме того, для работы клиентского приложения требуется установка SAP RFC SDK с версией, соответствующей SAP ERP и в некоторых случаях дополнительные модули, например, PyRFC для python (уже не поддерживается).

ODBC/JDBC к SAP HANA (Oracle)

Прямое соединение с СУБД минуя сервер приложений – простое решение с хорошей скоростью получения данных, но и здесь могут возникнуть сложности. Невозможность использования бизнес-логики, реализованной на сервере приложений, а также отсутствие дельта-экстракции для стандартных объектов (например, движения материалов) может стать серьезной проблемой при миграции существующего функционала из SAP BW. С точки зрения информационной безопасности не во всех компаниях разрешены интеграции с прямым подключением к СУБД. Также существуют лицензионные ограничения: в большинстве случаев прямое подключение к СУБД запрещено.

SAP OData

OData (Open Data Protocol) - это открытый веб-протокол для получения и обновления данных, основанный на HTTP и REST. В SAP есть возможность создавать OData-сервисы на различных типах объектов и бизнес-сущностей и не только выгружать данные, но и вносить изменения. В контексте экстракции данных наилучшим вариантом является тип источника ODP (Operational Data Provisioning) – фреймворк для экстракции данных, который пришел на смену SAPI и также используется при выгрузке в SAP BW. Он поддерживает пакетирование, дельта-очереди, различные типы источников данных (BW Datasource, ABAP CDS, HANA View и др.) и является идеальным вариантом для целей получения больших объемов данных из SAP. Однако, в связке с SAP OData возникают определенные проблемы. Используемые форматы, такие как XML и JSON, не являются оптимальными с точки зрения размера при выгрузке больших объемов данных. Дополнительно в пакеты данных включается большое количество дублируемых метаданных, что является стандартом в OData. Но самая большая проблема этого метода – очень низкая скорость. Она ниже скорости загрузки данных в SAP BW в несколько раз. Не стоит забывать, что есть и менее очевидные минусы. Для каждого источника данных (бизнес-сущности) требуется сгенерировать отдельный OData-сервис, который включает в себя несколько ABAP-классов и другие объекты. То есть для среднего хранилища данных нужно создать сотни, а то и тысячи новых объектов. С точки зрения полномочий тоже есть сложности: для включения полномочий в роли нельзя просто указать имена сервисов по маске, нужно перечислить их id.

Таким, образом известные механизмы экстракции из SAP ERP обладают теми или иными недостатками, и требуется новое решение.

Наш выбор — кастомный HTTP-сервис

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

HTTP-сервис реализован на ABAP. Так как основную работу проделывает ODP, реализация сервиса достаточна простая. Он получает запрос от клиентского приложения по HTTP(S), запускает процесс экстракции в ODP, используя соответствующие ФМ и классы, получает данные, конвертирует, сжимает и передает клиенту. Соответственно, функциональность сервиса определяется в основном ODP, а именно: типы источников данных BW Datasource, ABAP CDS, HANA View и др., пакетирование данных, дельта-очереди, повтор дельты, мониторинг экстракции в транзакции ODQMON. В ODQMON и системных таблицах ODP можно посмотреть статус процесса экстракции, сформированные пакеты и выгруженные пакеты.

На рисунке представлена схема экстракции в Arenadata DB с подходящим этой СУБД форматом для передачи данных (CSV+GZIP). Однако, с сервисом по HTTP/REST могут работать и другие фреймворки или ETL-инструменты. Так, с помощью Apache Spark или Apache Airflow и соответствующих библиотек, данные передаются в Data Lakehouse.

В отличие от OData-сервисов для простоты ODP-сервис можно реализовать напрямую в транзакции SICF:

Обработчик выполнен в виде ABAP-класса:

Класс реализует интерфейс обработки HTTP-запросов. В нем находится вся логика работы сервиса.

При получении запроса от клиентского приложения сервис регистрируется в ODP как OData-сервис и запускает экстракцию. Получение данных осуществляется последующими запросами к сервису в асинхронном режиме: как только в ODP формируется пакет данных, клиентское приложение может его получить. Есть возможность задавать размер пакета несжатых данных.

При такой архитектуре удается решить главную проблему OData – низкую скорость работы. Параллельная экстракция и передача пакетов данных, собственная реализация конвертации и компрессия данных позволяет получить скорость выгрузки, сравнимую с выгрузкой в SAP BW.

Результаты замеров:

Таким образом, предлагаемая реализация сервиса выгрузки из SAP обладает целым рядом преимуществ:

1. Скорость загрузки: близкая к обычной скорости SAP BW

2. Простота и удобство: не требуется создания дополнительных объектов, кроме реализации сервиса

3. Универсальные открытые протоколы и форматы для интеграции: HTTP/REST/CSV/GZIP

4. Возможность выгрузки в классический DWH или в Data Lakehouse.

5. Возможность доработки сервиса для кастомизации форматов выгружаемых данных под конкретное хранилище данных и ETL-инструменты

6. Возможность переиспользования BW-экстракторов и других объектов с бизнес-логикой, что актуально при миграции

7. Использование стандартного SAP ODP-фреймворка

8. Пакетирование выгружаемых данных

9. Дельта-загрузки (инкремент)

10. Повтор дельта-загрузки в случае сбоев

11. Мониторинг процесса экстракции данных в исходной системе SAP

Эта разработка использовалась при реализации проекта миграции с SAP BW для крупного банка, о котором мы делали вебинар.