Время чтения ~5 мин.
Aloha, друзья!
Довольно часто мы сталкиваемся с ситуацией, когда программа выполняется неприлично долго. Как правило, причиной является большой объем обрабатываемых данных. В этом случае, для ускорения работы программы прибегают к параллельной обработке.
Если вычисления в программе в принципе подлежат распараллеливанию, то сделать это можно несколькими способами.
Создание фоновых процессов
Для создания фоновых процессов используются ФМ-ы ‘JOB_OPEN’ и ‘JOB_CLOSE’. Примеры можно найти здесь и здесь.
Минус такого подхода в том, что разработчику приходится самому заботиться о том, как получить результат работы каждого задания. Например, считывать результаты из спула или из кластерной таблицы и т.п.
Cоздание диалоговых процессов
Суть такого подхода, состоит в том, что мы не ждем пока ФМ вернет результат, а следом делаем новый вызов этого же ФМ-а, с другими входными данными. Т.е. вызов ФМ-а происходит асинхронно (aRFC). Таким образом при каждом вызове создается отдельный диалоговый процесс.
Когда процесс завершает выполнение, результат его работы (например, строки таблицы) забирается с помощью специальной команды RECEIVE RESULTS FROM FUNCTION внутри метода или подпрограммы, вызванной с дополнением ON END OF TASK. Более подробно об этом рассказано здесь.
Минус такого способа распараллеливания в том, что для каждой программы необходимо создать свой RFC ФМ. Кроме того, разработчику необходимо самому позаботиться об обработке ошибок.
SPTA Framework
SPTA Framework существует уже давно.
Если верить автору статьи SPTA является более безопасной платформой для параллельной обработки, так как в нем встроена защита от проблем, связанных с памятью ABAP, поэтому она очень безопасна. Кроме того, инфраструктуру SPTA очень легко внедрить, и вся работа по параллельной обработке выполняется SAP, нам не нужно беспокоиться о том, как ее обрабатывать.
В системе есть демо-программа SPTA_PARA_DEMO_1 с примером использования фреймворка. Пример несколько отстраненный, поэтому предлагаю рассмотреть более реальный.
Допустим, нам необходимо выгрузить в ALV следующую таблицу:
Для того, чтобы получить ФИО сотрудника, напишем простую программу с использованием SPTA фреймворка для распараллеливания задач.
Листинг может выглядеть так:
Как видно из листинга, центральным моментом является ФМ SPTA_PARA_PROCESS_START_2. Он представляет собой обертку над все тем же aRFC. В этом вы можете легко убедиться сами посмотрев его код.
Справедливо было бы не выделять его в отдельный заголовок, однако, я сделал это намеренно, чтобы еще раз подчеркнуть тему поста.
Продолжим.
На вход ФМ-а необходимо подать следующие параметры:
- группа серверов (см. tcode RZ12);
- названия callback-подпрограмм (методы, увы, не разрешены);
- входные данные любой структуры.
Названия callback-подпрограмм из примера говорят о порядке их вызова.
BEFORE_RFC — данные (табельные номера) разделяются на пачки для каждой задачи.
IN_RFC — считывание ФИО каждого табельного из пачки и заполнение выходной таблицы.
AFTER_RFC — результат работы каждой задачи собирается в одну таблицу.
Листинг каждой подпрограммы:
Отладка SPTA
Если при работе SPTA используются разные экземпляры сервера, то для перехода в режим отладки внешней точки останова не достаточно. В дополнение нужно использовать транзакцию SRDEBUG.
Подведем небольшой итог.
Минус использования SPTA в том, что вам приходится использовать подпрограммы. Это «разрывает» все ваши попытки хоть как-то идти в ногу со временем и писать код в ООП стиле.
В этом плане подход, в котором вы самостоятельно создаете RFC ФМ выглядит выгоднее.
UPD: Обозначенный недостаток SPTA можно избежать, используя ZCONCURRENCY_API.
Какой способ распараллеливания использовать решать конечно вам. Но, как говорится, кто владеет информацией, тот владеет информацией :-).
На этом все, пока!