Оптимизация Z-транзакций модуля ТОРО с целью повышения скорости обработки данных

Предпосылки

После любого внедрения системы SAP наступает не менее важный процесс ее сопровождения и последующего развития. Зачастую команда поддержки сталкивается с тем, что при создании Z-транзакций (ABAP-разработок) не учтено влияние роста объёма исторических данных на время выполнения этих транзакций.

В связи с этим команда поддержки (сопровождения) систем сталкивается, в том числе, и с необходимостью оптимизации внедрённого Z-функционала.

Рассматриваемая проблема

Рассмотрим один из подходов, который был использован при оптимизации Z-функционала, относящегося к бизнес-процессу планирования и выполнения ТОРО.

У заказчика в течение нескольких лет существования системы росло число заказов на технические обслуживание:

• 2007 г. 90.265 шт.
• 2008 г. 118.860 шт.
• 2009 г. 194.208 шт.
• 2010 г. 323.490 шт.
• 2011 г. 357.074 шт.
• 2012 г. 364.935 шт.
• 2013 г. 406.250 шт.
• 2014 г. 486.742 шт.

Разработанная в рамках внедрения основная рабочая Z-транзакция пользователя, вследствие накопления большого количества данных, перестала удовлетворять бизнес в части производительности. Попытка запуска транзакции с целью получить консолидированные данные за квартал по нескольким подразделениям компании заказчика часто заканчивалась дампом по тайм-ауту (2 часа). При этом накопительные отчеты за полугодие или год однозначно переставали работать.

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

При запуске с использованием таких же параметров стандартные транзакции SAP (IW39) также не обеспечивали необходимой скорости обработки и не могли послужить альтернативой.

В процессе мониторинга производительности системы специалисты службы сопровождения обратили на это внимание.

Был выполнен анализ работы программы, определены узкие места и предложено решение, которое позволило увеличить быстродействие транзакции почти в 3 раза.

Решение по оптимизации:

Теперь расскажу несколько подробнее о том, как выполнялась оптимизация.

Шаг 1

Определены наиболее часто используемые параметры, с которыми шла запускаемая программа:

• завод «WERK»
• периоды (базисный срок начала «GSTRP», базисный срок конца «GLTRP»)

Шаг 2

Выполнена трассировка и анализ «узких» мест работы программы (Табл. 1).

Таб. 1. Анализ узких мест программы

Шаг 3

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

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

Для быстрого выбора заказов:

1.      В таблицу AUFK (соответственно, и в ракурс CAUFV) добавлены Z-поля: ZZ_AFKO_GLTRP и ZZ_AFKO_GSTRP (Рис. 1).

Рис. 1. Расширение таблицы AUFK.

2.       Доработан User Exit на сохранение заказа ТОРО (создание и изменение), который записывает данные AUFK-ZZ_AFKO_GLTRP = AFKO-GLTRP, AUFK-ZZ_AFKO_GSTRP = AFKO-GSTRP.

3.       Реализована вспомогательная техническая утилита для первоначального заполнения указанных Z-полей (AUFK-ZZ_AFKO_GLTRP, AUFK-ZZ_AFKO_GSTRP) данными