Нагрузочное тестирование SAP BW в современных условиях: опыт и практики реального проекта

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

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

Привет, Хабр! На связи Володин Михаил, ведущий инженер по нагрузочному тестированию, и Смирнов Вадим, старший инженер по нагрузочному тестированию в IBS. В этой статье мы поделимся своим опытом НТ SAP BW для одного из крупнейших российских банков.

Реальный кейс: нагрузочное тестирование для крупного банка

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

Для банка это не абстрактная задача. SAP BW — центральное хранилище данных, от которого зависит формирование управленческой отчетности для правления, расчет лимитов и рисков, витрины данных для фронт-офисных систем и ETL-процессы загрузки из АБС. Перегрузка BW запускает цепную реакцию: проблема в BW → задержка в OLAP-кубах → недоступность дашбордов → невозможность принятия решений по кредитам и инвестициям. 

Возможные финансовые последствия простоев системы впечатляют: регуляторные штрафы за несвоевременную отчетность могут достигать 10 миллионов рублей, простой только 100 аналитиков в течение 4 часов обходится банку свыше миллиона рублей. Срывы сроков закрытия отчетных периодов, в свою очередь, могут привести к каскадным последствиям для всего бизнеса.

Кроме того, без нагрузочного тестирования невозможно безопасно внедрять новую функциональность, планировать аппаратные мощности и обосновать бюджет на инфраструктуру. Издержки на нагрузочное тестирование кратно перекрывают потенциальные финансовые потери от регуляторов и ключевых клиентов.

Дальше погрузимся в технические детали нашего проекта, где расскажем о том, как использовали инструмент LoadRunner для решения поставленных задач.

Что надо было сделать

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

Задачи были классические, как и при любом тестировании крупных систем: 

• найти максимальную пропускную способность, при которой система не деградирует;

• провести тестирование стабильности;

• обнаружить максимальное количество узких мест и дать рекомендации по их устранению.

Также нужно было исследовать параметры вызовов RFC, при которых система будет обрабатывать наибольший объем информации за наименьшее время. Когда мы услышали такие цели, прикинув примерное количество запусков и имея ограниченное время на проведение работ в две недели, закрались сомнения: «Успеем ли?» Обсудили наши опасения с заказчиком и пришли к решению — по максимуму автоматизировать процесс.

С целью дальнейшего развития НТ на проекте у заказчика было желание использовать все возможные варианты взаимодействия с системой различными способами. Разделить эти методы можно как:

• Взаимодействие через веб-интерфейс:

  • Crystal reports,

  • Web Intelligence,

  • BEX web.

• Взаимодействие через десктопное приложение SAP Logon:

  • RSRT,

  • ABAP-отчеты.

• Стороннее ПО и интеграции:

  • RFC-протокол,

  • модуль расширения SAP Analysis для Microsoft Office,

  • прямой вызов веб-сервисов.

Поскольку инструмент Load Runner — своеобразный «стандарт» для работы с SAP, он уже использовался у заказчика. LR поддерживает работу с протоколом SAP GUI из-под капота.

Разбор подходов, типов скриптов и инструментов тестирования

Рассмотрим более детально процесс разработки скриптов для разных методов взаимодействия с SAP.

Взаимодействие с SAP через браузер

Пользователи SAP работают с ним через браузер при использовании Crystal reports, Web Intelligence, BEх web.

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

Web Intelligence – один из инструментов платформы SAP BusinessObjects Business Intelligence, с помощью которого можно осуществлять доступ к данным, независимо от места их хранения, что позволяет получать актуальную деловую информацию и делиться ею с другими пользователями.

Запросы BEx – это запросы, созданные в SAP BEx Query Designer на основе инфокубов SAP. Основанные на запросах BEx документы и отчеты создаются, изменяются и обновляются в интерфейсе апплета Web Intelligence или в клиенте Web Intelligence Rich Client. В интерфейсе Web Intelligence HTML можно просматривать и обновлять документы, но нет возможности изменить элементы документов на основании запросов BEx.

Взаимодействие происходит по протоколу HTTP/HTTPS. С технической стороны это классическое общение пользователя с системой через интерфейс, которое включает отправку HTTP-запросов (GET/POST) к эндпоинтам, где сервер обрабатывает запросы к базам данных SAP BW, возвращая результаты в формате HTML, JSON или XML для дальнейшего отображения в браузере.

Для записи таких сценариев в LR требуется использовать протокол Web HTTP/HTML.

Шаги записи:

1. В VuGen: Создать новый скрипт→ Выбрать протокол Web HTTP/HTML → Выбрать предпочтительный браузер. 

2. Recording options: установить «Record HTTP». 

3. Start Recording: открыть браузер, совершить действия по согласованному профилю, выполнить логаут.

4. Stop Recording: происходит автогенерация скрипта в Action. Разделить полученный код на логические разделы, vuser_. Action,vuser_end 

5. Провести корреляцию и параметризацию.

6. Добавить проверки для облегчения отладки и проверки корректности ответа.

Обязательно стоит уделить время написанию проверок, которые будут контролировать корректность ответа основной операции. Достаточно часто происходит так, что код ответа для инструмента является успешным — например, 200, но с точки зрения бизнес-процесса успехом тут даже не пахнет, потому что ожидаемая информация отсутствует. Это встречается достаточно часто, не только в случае с SAP. 

В LR подобные проверки можно реализовать, сравнивая вытащенный текст из ответа с ожидаемым, например, так:

if(strstr(lr_eval_string("{text}"), title_request_report) != NULL){
lr_end_sub_transaction("UC01_S04", LR_PASS);
   }
   else{
lr_output_message("ERROR!!! not found: %s",lr_eval_string("{title_request_report}"));
lr_end_sub_transaction("UC01_S04", LR_FAIL);
lr_end_transaction("UC01", LR_FAIL);
   return 0;
}

где text — переменная, содержащая данные с открытой страницы, полученные при помощи

sapgui_htmlviewer_dom_get_property

sapgui_htmlviewer_dom_get_property("/usr/cntlHTML_VIEWER/shellcont/shell",

"document.body.InnerHTML",

"text",

LAST);

title_request_report — переменная, содержащая искомый текст.

Взаимодействие через SAP GUI

SAP Logon используется для полной эмуляции GUI. В контексте нашего теста это важно, так как он позволяет протестировать элементы системы, к которым нет доступа через веб-протокол. Это позволяет тестировать производительность системы под нагрузкой, имитируя множественных пользователей, взаимодействующих с UI-элементами, такими как окна, кнопки, поля ввода и таблицы. В нашем случае через интерфейс десктопного приложения мы работали с транзакцией RSRT и ABAP-отчетами.

При воспроизведении сценария каждый виртуальный пользователь (VU) запускает сессию SAP GUI и автоматически выполняет требуемые действия, в нашем случае:

1. Авторизация.

2. Выполнение транзакции (в нашем случае — RSRT).

3. Заполнение необходимых параметров и выполнение операции.

4. Логаут и закрытие сессии.

Для записи таких сценариев в LR требуется использовать протокол SAP GUI. Также требуется выполнить донастройку и самого SAP, разрешив его скриптование:

Процесс записи выполняется следующим образом:

1. В VuGen создаем новый скрипт и выбираем для него протокол SAP GUI.

2. Жмем кнопку «Start Recording». 

3. В открывшемся окне настраиваем путь к SAP logon и начинаем запись.

4. В открывшемся экземпляре SAP Logon выполняем необходимые действия, расставляя начало и завершение транзакций. 

5. Жмем «Stop Recording» — происходит автогенерация скрипта.

6. При необходимости разносим действия на логические разделы: Vuser_init и vuser_end.

7. Проводим корреляцию и параметризацию.

8. Добавляем проверки для проверки корректности ответа и облегчения отладки.

9. Настраиваем Runtime Settings (think time, iterations, pacing)  непосредственно в VuGen или LR Enterprise.

Также столкнулись с проблемами:

При работе с SAP GUI была ошибка при отладке/воспроизведении скрипта. На двух идентичных по характеристикам машинах с одинаковым ПО один и тот же скрипт SAP GUI отрабатывал по-разному. На одной выполнялся корректно, а на второй мы получали программную ошибку ABAP. В нашем случае решением стало воспроизведение через клиента SAP — настройка происходит следующим образом:

Runtime settings->Network->Advanced->Replay using running SAP Logon application — выставить галочку.

При выставлении этих параметров скрипт отрабатывал все действия, но это крайний вариант, так как без включения этой настройки Controller/VuGen взаимодействует напрямую через сервер SAP, а при включении взаимодействие происходит через клиент SAP GUI, что приводит к повышенной утилизации ресурсов генератора нагрузки.

В одном из сценариев с открытием ABAP-отчета на одном из шагов с подгрузкой файла требовалось подтверждение пользователя — некая защита SAP от выполнения скриптов. Записать действия во всплывающем окне «Безопасность SAP GUI» не удавалось, а без подтверждения скрипт не выполнялся — зависал намертво. Для решения потребовалось отключить на клиентах SAP, через которые выполняется воспроизведение, подтверждения в подобных окнах. В настройках нужно перейти в Security — Security Configuration — Open Security Configuration — в поле Default Action выбрать «Allow». Важным уточнением является то, что агенты LR на генераторах должны быть запущены как процесс, а не как служба. 

Взаимодействие SAP с внешними приложениями и системами

В нашем профиле присутствовали сценарии с вызовом веб-сервисов — это скрипты, в которых выполняется обращение к определенным эндпоинтам.

Данные сценарии используют протокол HTTP/HTTPS и отличаются от описанных ранее только отсутствием «шагов». Пускай скрипт заключается в отправке одного запроса — не забываем о проверках!

RFC (Remote Function Call) — это протокол SAP для удаленного вызова функций (модулей ABAP) в системе SAP из внешних приложений. RFC позволяет синхронно или асинхронно вызывать процедуры, передавая параметры и получая результаты, без необходимости в UI или веб-интерфейсе. 

Мы изучили методы взаимодействия по RFC с SAP из внешних систем. Нами были обнаружены такие методы, как: 

SAP Java Connector (JCo) — официальная библиотека от SAP, предназначенная для интеграции Java-приложений с системами SAP через протокол RFC (Remote Function Call). Она позволяет вызывать RFC-функции, включая BAPI (Business Application Programming Interface), как синхронно, так и асинхронно, обеспечивая двустороннюю связь между Java-кодом и SAP-системой.

C/C++: SAP NetWeaver RFC SDK — это низкоуровневая библиотека на языке C (с обертками для C++), предоставляемая SAP для прямого доступа к RFC-интерфейсам.

SDK позволяет создавать клиентские и серверные приложения, вызывать RFC-функции, передавать сложные данные (структуры, таблицы) и управлять соединениями в различных режимах. Библиотека компилируется статически или динамически и требует установки нативных зависимостей, что делает ее идеальной для встраивания в legacy-системы или высокопроизводительные приложения.

Python: pyrfc 

Это Python-библиотека для взаимодействия с SAP.

• удобство: позволяет работать с SAP из Python-скриптов, не углубляясь в низкоуровневые детали C/C++.

• автоматическая конвертация данных: сложные структуры данных SAP преобразуются в знакомые Python-объекты, такие как словари и списки;

• основная сфера применения: идеально подходит для быстрого прототипирования, скриптов автоматизации, задач анализа данных и интеграции SAP с современными стеками машинного обучения.

Мы остановились на использовании pyrfc, поскольку для решения нашей задачи это казалось наиболее быстрым и простым решением.

LR не имеет встроенной поддержки RFC-протокола, поэтому нами была реализована промежуточная прослойка — легковесный веб-сервис на Python (с использованием фреймворка FastAPI), который выступает в роли «моста» или «прокси» между LR и SAP.

Верхнеуровневая логика его работы была достаточно проста:

• принимает запрос от LR;

• отправляет данные в SAP по RFC;

• получает ответ от SAP;

• возвращает ответ в LR.

Для удобства и точности взаимодействия в логику работы заглушки добавлен маппинг json (чтобы сформированные генератором запросы можно было сразу отправлять в нее), благодаря замеру времени с момента вызова RFC до получения ответа повышается точность полученных результатов.

В итоге схема работы всей связки выглядит так:

Тем самым при выполнении исследования зависимости скорости обработки от подаваемого объема данных нам нужно лишь указать требуемые параметры запроса и запустить. Запрос сгенерируется автоматически, выполнится требуемое взаимодействие с SAP, и в редис будут записаны необходимые и важные для анализа метрики.

Анализ и отчеты 

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

Наши запуски выполнялись по планировщику в LR Enterprise, пока мы отдыхали, а сборка отчетов по нескольким десяткам ночных запусков составляла не более 30 минут. Отдельно уже вручную дообогащали отчет информацией по состоянию стенда.

Скрипт для формирования отчета по запуску

Этот скрипт является основным инструментом для сбора метрик одного тестового прогона. Скрипт имеет возможности настройки конфигурации запуска (деление по ступеням, указание SLA) в отдельном конфигурационном файле. 

Основные выполняемые функции:

1. Сбор данных: подключается к Redis и забирает все логи об успешных и ошибочных операциях.

2. Фильтрация и парсинг: обрабатывает сырые логи, извлекая ключевую информацию — время ответа, тело запроса/ответа, код ошибки, эндпоинт, время выполнения.

3. Анализ и статистика: рассчитывает ключевые метрики производительности:

   • минимальное, среднее, максимальное время ответа;

   • процентили (50, 90, 95, 99);

   • количество ошибок и их процентное соотношение.

4. Генерация Excel-отчета: создает многостраничный файл формата .xlsx, содержащий:

   • полный список всех операций;

   • сводную статистику по всему тесту и по каждому шагу отдельно;

   • графики времени ответа с отметками SLA и 95-го перцентиля;

   • анализ ошибок с группировкой по типам;

   • график RPS (запросы в секунду).

Скрипт для сводного отчета

Этот скрипт используется для анализа и сравнения нескольких тестовых прогонов.

1. Агрегация данных: автоматически находит в папке все отчеты (по маске report_*.xlsx).

2. Сравнение метрик: из каждого отчета извлекает самые важные показатели (например, 95-й перцентиль времени ответа и процент ошибок).

3. Создание сводного отчета: 

   • генерирует новый Excel-файл, в котором в виде таблицы и графиков показано, как менялись времена отклика и количество ошибок от теста к тесту;

   • генерирует Word-документ с аналогичной информацией, но структурой, в которую оставалось добавить информацию о мониторинге стенда и выводы.

Заключение

На этапе постановки задач мы были сильно напуганы сжатыми сроками и количеством предстоящих запусков в рамках исследований. Без автоматизации эта задача попросту была нерешаема. 

В результате мы не просто успешно покрыли все необходимые сценарии, включая взаимодействия по RFC, но и смогли разработать удобную инфраструктуру для проведения необходимых исследовательских испытаний. Разработанные средства имеют потенциал доработки, если потребуется протестировать новый функционал. 

Инструмент LR имеет из-под капота удобный планировщик, выполняющий запуски ночью в нерабочее время, а скрипты по сбору логов в считаные минуты соберут информативные отчеты, освобождая от рутинной работы. В наше основное рабочее время мы можем заниматься расширением тестового покрытия.

Под текущие цели заказчика мы сделали конвейер, который по факту работал круглосуточно, а мы, в свою очередь, не перегружались с переработками.