Граждане.

Возникла следующая проблема. Необходимо обрабатывать входящие айдоки не сразу кучей (сколько их там на сервере лежит), а по одному. Т.е. один обработался - второй всосался. Слышал где-то в SALE есть такая настроечка: стоит крыжЫк - обрабатывается по одному, не стоит - кучей сразу. Излазил - не нашел. Подскажите, а?

Простите за наивный вопрос.

Может быть, транзакция BD51?

А..
Там есть такая штука, как Input Type/ Тип ввода
Так вот на функциональный модуль стоит тип "1" - отдельный ввод.
Думаете стоит поставить "2" - отдельный ввод с блокировкой айдока?
А чтобы это значило?

Дело вот в чем:
На серваке лежит два айдока с перемещением запаса (одного и того же). Так вот один айдок обрабатывается, а второй стопорится со статусом 51. Т.е. транзакция блокируется пользователем который обрабатывает первый айдок.
В связи с этим еще один вопрос: а второй айдок когда обрабатываться начнет?

Если мне память не изменяет можно еще посмотреть танзакцию WE20.

Посмотрели. Но там-то особо не разгуляешься. Ничего похожего нетЪ. Единственное, что можно попользовать, так это чтобы айдоки всасывались, а потом по очереди обрабатывались программой фоновой обработки. Но мне такая штука не подходит.

В настройках SALE нашел программу, которая доталкивает айдоки с 51-ым статусом. Её надо вешать в фон. Но хотелось бы по нашему, по простецки.. Вот только найти бы.

Программа RBDAPP01, в ней указываешь вариант вызова - и будет вам счастье...

джага-джага

То, что вы хотите, наиболее логично организовать с помощью выбора "Collective processing" в WE20 и потом периодически гонять программу RBDAPP01 без parallel processing и с Packet size = 1.

Но тут есть такая фишка, что RBDAPP01 фактически только инициирует последовательную обработку IDoc'oв (т.е. вызывает соответствующие функции и т.п. в SAP), а вот в процессе уже возможны сюрпризы, т.к. некоторые locks убираются до того, как IDoc полностью закончил обработку. В результате получаем IDoc # 1 со статусом ОК, а следующий IDoc # 2 со статусом 51 и какой-нибудь "data locked by...". Т.е. фактически обработка # 1 еще крутится где-то там на фоне, а RBDAPP01 думает, что там уже все покончалось и смело запускает # 2. Можно попробовать поиграть настройками в BD51 (информация о них весьма скупая), но не факт, что это поможет. Скорее всего будет просто медленнее.

Жаловались в SAP (если не выбран parallel processing в RBDAPP01, то почему de facto он происходит?), те нас долго футболили, а потом заявили, что это дизайн такой, "to preserve data integrity". Посоветовали выставить late lock на ОМ, а мы уже давно выставили и это все равно не помогает.

Так что если найдете решение, кроме как написания собственной программы обработки, - свистните.

А не пробовали такую штуку, как сериализация?

В книжке так написано:
Inbound type
There are three types of function module in inbound processing:
1. Those that support mass processing
2. Those that can only process one IDoc at a time and do not use an ALE-enabled transaction
3. Those that can only process one IDoc at a time and that use an ALE-enabled transaction
For the latter two types, the ALE layer splits up an incoming packet of IDocs and calls the function module once for each IDoc. The latter two need to be distinguished from one another because the ALE processing before the function is called differs in each case.

Думаю что значение 2 - это то что нужно. При условии что после отработки ФМ происходит COMMIT WORK AND WATE. COMMIT WORK гарантирует снятие всех блокировок а WATE - гарантирует завершение отработки всех модулей обновления.