Разбираюсь в теме, возникло несколько вопросов. Нашла пример на saphelp, легче не стало http://help.sap.com/saphelp_nw2004s/hel ... ontent.htm
1. В примере кол-во процессов, на которые делится обработка задается железно в описании переменных, что мне не очень нравится. При этом используется ФМ 'SPBT_INITIALIZE', который возращает кол-во свободных процессов на данный момент. Я правильно понимаю что отсюда и можно брать число процессов используемых для распараллеливания.
2. Оптимальный размер пакета, который передается на обработку, грубо говоря число строк таблицы. Во всех рабочих примерах которые я видела, это число опять задано железно. Непонятно на что опираясь. Я так понимаю узнавать это число путем деления числа строк таблицы на число процессов не камильфо, моя цель не забить все свободные процессы а ускорить обработку, не мешая другим. Вот сижу думаю, определять кол-во строк исходя из примерной оптимальной работы ФМ, и времени обработки одной записи, или как.

Если стоит задача ускорить обработку, начать стоит с оптимизации. Что у вас медленно работает? Распараллеливание - последнее дело, и в большинстве случаев оно создает больше проблем чем решает

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

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

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

В реальной жизни этого недостаточно. См. программу RSPARAGENER8, со строки 366.

Кроме этого, на практике вызов ФМ в режиме STARTING NEW TASK занимает диалоговый режим, для одной сессии пользователя есть ограничение - 6 режимов.
Поэтому число параллельных вызовов в случае использования дополнения DESTINATION 'NONE' или 'BACK' будет ограничено количеством свободных режимов.
Для определения уже занятых режимов можно использовать ФМ 'TH_LONG_USR_INFO'.

Реализовывал распараллеливание "тяжелых" задач типа автозаказа или расчета розничных цен в ритейле. Могу поделиться опытом. Был разработан диспетчер фоновых задач, который планировал задачи из своего списка таким образом, чтобы в каждый момент времени работало не более заданного числа.

Или нет выделенного сервера для параллельной обработки

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

Это зависит от диаметра кривизны рук разработчика

Это правда

Выбирается исходя из размера максимального диалогового шага (параметр rdisp/max_wprun_time).
Если этот параметр равен 1200 секунд (20 минут), то передавать в ФМ нужно столько записей, сколько обрабатывается за это время.
А так обычно количество записей делится на количество параллельных процессов

Если все же решите пойти сложным путем, стоит обратить внимание на следующие моменты:
1. Число процессов - не самая большая проблема. Наверное лучше сделать константой. Вычислить оптимально время обработки пакета довольно сложно, т.к. со временем это значение будет меняться из-за увеличения объема данных в таблицах, других работающих одновременно процессов, изменения настроек сервера, железа и т.д. Ну и сервера в продуктиве как правило намного мощнее тех что в системе разработки.
2. Если процессы запускать в диалоговом режиме, их время работы и количество ограничено (в версии < 7.20 их вроде не может быть больше 6). Надежнее сделать фоновые процессы, но тут сложности возникают при передаче данных из основной программы.
3. Как правило необходимо предусмотреть блокировку от повторно запуска, т.к. если вы займете все диалоговые процессы, сервер скорее всего ляжет
4. Какие-либо коммуникации между процессами весьма затруднительны
5. Последнее и наверное самое сложное. Если какой-то из процессов свалиться в дамп, необходимо его как-то перезапустить. Причем желательно с того момента, где произошла остановка

Все сдаюсь

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

Как раз из-за п.3 количество свободных процессов нужно вычислять перед каждым запуском.

И опыт, сын ошибок трудных...

Большие трудности возникают при возврате данных.

А зачем в параллельных процессах коммуникации между собой? Отслеживанием выполнения должна заниматься запускающая программа.

По какой причине процесс должен свалиться в дамп? При хорошем тестировании такой проблемы быть не должно

Тут важно знать тип обработки, которую нужно распараллелить:
-Если это создание документов, то логгирование обработки каждого документа просто необходимо, и продолжить процесс по результатам таблицы лога не составляет большого труда.
-Если это отчет, то при дампе не возвратится результат для всего пакета обработки (должна возникнуть ошибка при вызове RECEIVE RESULTS) и эиту ситуацию можно обработать в основной программе..

[off]__Gennady, и прайс свой скажите [/off]

Если бы я предлагал продать, я бы так и написал...
Без описания задачи просто как-то странно давать рекомендации