Это спорный вопрос

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

Стоимости я не знаю, но она точно немаленькая. В качестве серверов там стоят HP-шные многопроцессорные (если правильно помню 8 камней по 8 ядер) машинки, так что я думаю, что рекомендации SAP там приблизительно выполняются

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

+1

Пример распараллеливания процессов обработки можно посмотреть в отчете RSPARAGEN.
Смысл в том, чтобы запускать заданное число параллельных процессов через STARTING NEW TASK и отслеживать их завершение, по завершению одного запускать следующий.

Могу предложить следующий механизм(с кодом если надо).
Диспетчер фоновых процессов - ФМ, которому на вход идут подготовленные данные для запуска программ в фоновом режиме(программа, вариант, таблица rsparams), список аппл.серверов с указанием числа одновременно работающих заданий. ФМ запускает разрешенное число заданий, и далее периодически проверяет, если процесс освободился, запускает следующую задачу. Можно управлять приоритетом и порядком выполнения заданий. Могу сказать, что метод очень действенный, более прозрачный чем call function startind new task или in background task.

Неплохо
Буду благодарен, если Вы им поделитесь.

Можно пояснить, как происходит передача параметров и получение данных для фоновых задач?

Да, конечно можно.
Задача: обеспечить выполнение ресурсо- и время- ёмких задач за приемлемое время, обеспечить равномерную загрузку серверов.
Пример использования - ценнобразование в крупной торговой сети.
Реализация: делаем программу, позволяющую порождать фоновые задания по определенным правилам.
селекционный экран: ограничения по объектам сети(регионы, БЕ, магазины, и т.д.)
шаги:
Программа 1, вариант, доп. параметры
Программа 2, вариант, доп. параметры
Программа 3, вариант, доп. параметры
....
Варианты запуска
- на группу обработки, число одновременно работающих процессов
- с указанием конкретных серверов, число одновременно работающих процессов на сервере

Что происходит при запуске.
В случае с ценообразованием необходимо было сгруппировать магазины по регионам и для каждой такой группы запланировать последовательное выполнение программы1, программы2, программы3.. и тд.
собственно эти данные(vkorg, vtweg, werks, и т.д.) в конечном итоге должны попасть на вход команды submit,


CASE 'X'.
WHEN p_srv."с указанием конкретных серверов
CALL FUNCTION 'ZLO_SСHEDULE_START'
EXPORTING
i_shedule_data = lt_sсhedule_data
i_server_data = lt_server_data
i_wait = p_wait.
WHEN p_gr. "на группу обработки
CALL FUNCTION 'ZLO_SСHEDULE_START_GROUP'
EXPORTING
i_shedule_data = lt_sсhedule_data
i_server_group = p_group
i_num_process = p_num_p
i_wait = p_wait.
ENDCASE.


здесь lt_sсhedule_data:
PROGRAMM PROGRAMM программа которую необходимо запланировать
VARIANT VARIANT вариант(не обязательно)
SEL_OPTIONS TY_STANDARD_SEL параметры
JOB_NAME BTCJOB имя джоба
GROUP CHAR6 группа (в примере с ценообразованием это был регион)
LEVEL POSNR номер шага
START AS4FLAG служебн.
FINISH AS4FLAG служебн.

lt_server_data
SRVNAME BTCSRVNAME appl сервер
NUM_JOBS NUMC2 число заданий

дальше ФМ запускает положенное число заданий и каждые p_wait секунд проверяет, не закончилось ли какое-нибудь
если закончилось - подыскивает какое запустить следующим. (у меня приоритет был следующим - запускаются программы, в чьей группе(group) предыдущий шаг(level) завершен(или в случае первого уровня не запущен) ).



Похожим образом может быть решена задача массовой прокачки idoc движений материала.
Проблемы при использовании стандартного механизма распараллеливания - занимаются диалоговые процессы и что самое неприятное, idoc с одним магазином блокируют друг друга (для одинковых материалов, MARC).
Решение - выбрать idoc в нужном статусе, за нужные даты и т.д. разбить по заводам(у нас это можно определить из порта отправителя) сгруппировать внутри завода например по 5000 и подать на вход того же ФМ ZLO_SСHEDULE_START.

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

Ну это немного другое...При массовом изменении данных механизм фоновых задач действительно хорошо подходит.
Но при необходимости распараллелить вычисления в "тяжелом" отчете, особенно если этот отчет запускают с разными параметрами несколько пользователей встает задача корректного сбора данных от параллельных задач. В этом случае CALL TRANSATION ..STARTING NEW TASK ... PERFORMING ... подходит значительно лучше. При этом также есть возможность указания сервера приложений/группы серверов.

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

Миллионы записей при достаточно сложном алгоритме обрабатываются часами, но никак не сутками. Железо у Вас вроде достаточно мощное. Странно это как-то. Если не секрет, расскажите вкратце какие операции выполняются над записями.