Введение

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

Алгоритм (этапы) оптимизации ABAP-программ:

1. Определение KPI - во сколько раз должна быть ускорена программа или требуемое время работы при определенных условиях запуска.

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

3. Определение узких мест и способов их оптимизации.

4. Оптимизация программы.

5. Повторение пунктов 2-4, вплоть до получения заданного KPI или до признания невозможности его достижения.

Этап 1. Определение KPI

Процесс оптимизации может оказаться почти «бесконечным» и, естественно, очень трудозатратным. Чтобы избежать дополнительной работы, необходимо определить условие завершения цикла оптимизации, или KPI. Примером KPI может быть: программа должна ускориться в 100 раз или программа должна отрабатывать не более 10 секунд. Конечно же KPI должен быть реалистичным. Также KPI должен учитывать параметры запуска программы: например, на небольших объемах данных (например отчет за 1 месяц) разница во времени работы с базой данных на HANA, и не на HANA может быть незначительна и оптимизация потребует значительных трудозатрат, а на больших объемах данных (годовых) эта разница будет значительно больше. Естественно, данные должны соответствовать бизнес-процессу (не нужно выполнять отчет за несколько лет, если он запускается всегда за один год).

Пример выбора KPI работы программы

В таблице (Рис.1) показаны варианты выбора KPI.

Рис.1 Вариант выбора KPI

Этап 2. Анализ производительности

Анализ производительности это - сбор статистики по времени выполнения операторов ABAP программы.

Я рекомендую выполнять анализ производительности в транзакции ST12, эта транзакция разработана SAP AGS (SAP Active Global Support) для комплексного анализа производительности ABAP. Можно использовать транзакцию SAT (старая SE30), если кому-то нравиться.

Более подробно о ST12 в моей статье http://sapland.ru/articles/stats/2013/1/analiz-proizvoditelinosti-abap-programm.html.

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

После трассировки, необходимо отсортировать результаты по полю Net(%) по убыванию. Для нас интересен топ 3-5, в зависимости от распределения времени и, желательно, чтобы вызовы приходились на Z-код.

Примеры результатов трассировки

Случай первый

На рис.2 скриншот результата трассировки тестовой Транзакции 1, топ 3

Рис. 2 Результат трассировки Транзакции 1 в ST12

В рассмотренном случае 50% времени программы занимает запрос к таблице AUSP в Z-области. И 16% - вызов ФМ READ_TEXT, который сложно оптимизировать.

Случай второй

На рис.3 скриншот результата трассировки тестовой Транзакции 2, топ 3

Рис. 3 Результат трассировки Транзакции 2 в ST12

Во втором случае (Рис…..) 51% времени работы занимает запрос в цикле к таблице MATERIALID, вызов из стандартной программы, а 27% времени занимает запрос в цикле к таблице IFLOS. В таких случаях проводим анализ стека выполнения.

Рис. 4 Анализ стека выполнения операторов для Транзакции 2 в ST12

Мы видим, что проблемный код находится в BAPI, который вызывается во внедрении BADI. Так что, потенциал оптимизации есть, где-то на 70%.

Этап 3. Анализ результатов трассировки. Определение узких мест

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

Анализу производительности кода программы ABAP посвящено несколько курсов SAP, книги, статьи в интернете. Мы имеем множество различных ситуаций, , которые сложно описать в статье или даже книге. когда программа ABAP имеет низкую производительность Для полного понимания всех тонкостей ABAP нужно прочитать весьма много курсов , книг и иметь большой опыт программирования на ABAP.

Тем не менее, я рассмотрю некоторые основные шаблоны ситуаций:

Таблица 1

Анализ результатов для первого случая примера. 

Результат трассировки приведён для тестовой Транзакции 1

Рис. 5 Результат трассировки Транзакции 1 в ST12

Смотрим ABAP код

Видим тяжелый, особенно для SAP HANA, запрос SELECT … FOR ALL ENTRIES

Анализ второго случая

Рис.6 Результат трассировки Транзакции 2 в ST12

Вызов BAPI в цикле (почти 200 тыс. раз) в котором избыточные запросы

Рис. 7 Место вызова BAPI. Которая является причиной низкой производительности

Этап 4. Шаблоны ABAP и сценарии их оптимизации

Сценарии (способы) оптимизации

Существует два сценария использования HANA: «ABAP on HANA» и «HANA акселератор через secondary DB connection».

• Самый удобный случай, когда ABAP on HANA, тогда мы можем использовать External view и ADMP (в прошлом Database Proxy), а сами ABAP OPEN SQL запросы выполняются в HANA, так же мы можем использовать Core Data Service вместо HANA View

• Вариант с HANA акселератор более сложный и уже экзотичный, т.к. мы ограничены в использовании хранимых процедур (нет возможности передать массив данных (внутреннюю таблицу) в параметры хранимой процедуры), приходиться преобразовывать SELECT-OPTIONS в условие WHERE. Если не хватает оптимизации ABAP (SELECT … CONNECTION), тогда необходимо переносить логику ABAP программы в HANA Calculation view.

Пример оптимизации для условного типового случая

Есть программа, трассировка в которой показала низкую производительность в цикле LOOP

Программа не переписывается целиком, мы заменили медленный цикл на вызов ADMP (хранимой процедуры), логика цикла перенесена в хранимую процедуру

Тот же случай, но c использованием HANA акселератор; пришлось переписать всю программу на HANA view, что более трудозатратно.

Сравнение способов оптимизации

• Оптимизация ABAP – самый старый способ, особенно он полезен, когда HANA используется как акселератор, иногда достаточно направить запрос в HANA (SELECT … CONNECTION) и уже достичь существенных результатов.

• Оптимизация с использованием HANA хранимых процедур – очень удобно, при использовании ADMP, позволяет быстро оптимизировать проблемный код, без редизайна всей программы удобно для передачи внутренних таблиц, но не удобно использовать и передавать условия WHERE

• Оптимизация с использованием HANA Calculation Engine (graphical в нашем случае) – один из самых трудозатратных способов оптимизации, имеет смысл для оптимизации больших проблемных участков программ или для полного переноса логики ABAP в HANA, но при этом получая значительное ускорение (в сотни раз). Для ограничения данных в HANA view (как Exteranl view) можно использовать SELECT-OPTIONS.

Оптимизация с использованием Core Data service (CDS) – тоже самое, что и HANA View, но более гибкое за счет использования SQL, рекомендуется использовать вместо HANA View Ниже рассмотрим некоторые типовые ABAP шаблоны и как их можно оптимизировать (перенести в HANA)

Шаблоны ABAP и способы оптимизации

Таблица 2

Общий совет.

Вся обработка данных – это выборка, объединение или агрегация данных. Поэтому старайтесь представить логику данных в этом виде. Далее попробуйте перенести логику из ABAP на обычный SQL, гугл помогает. Далее, если используете CE и CDS,  этот SQL можно перенести в CE функции.

Сферический пример.

ABAP: