В ФМ с IN BACKGROUND TASK, SUBMIT не отрабатывает.
Решил вызовом CALL TRANSACTION ... BDC .. MODE = 'N'.

Поясните пожалуйста(я с MM "дружу" недавно), необходимость проверки блокировки материала,
и если можно пример.

Такой вариант тоже рассматривается, но пока работаю над тем что есть.

SVT, я бы все-таки использовал вариант Удава: пишем свою функцию путем копирования из EXIT_SAPLMGMU_001, чтобы интерфейс был одинаковый, не забываем поставить признак 'Update module'. Можно еще поставить ей атрибут 'Start delayed', чтобы она в процессе обновления вызывалась во второй очереди. В расширении вызываем свою функцию, передавая ей все поля с новыми данными и с дополнением IN UPDATE TASK. Так никаких селектов делать не надо, все данные будут переданы интерфейсом функц модуля. Вполне возможно, что на момент реального вызова своей функции таблицы будут уже обновлены - только эксперимент покажет.

Добавка 'IN BACKGROUND TASK' - это RFC вызов, срабатывающий по COMMIT WORK. Если не указываешь DESTINATION, то используется 'NONE'. Еcли 'NONE' не существует, то записи будут висеть в SM58, а система 30 раз через каждые 15 минут (это параметры по умолчанию) будет пытаться это сделать. Потом они повиснут в SM58 в красном цвете и через 8 дней (по стандарту) самоликвидируются.

Если в момент вызова новой функции данные уже обновлены, то можно вызвать еще одну функцию с добавкой 'STARTING NEW TASK', внутри которой попробовать вызвать SUBMIT. Работает почти также, как и IN BACKGROUND TASK, только не требует COMMIT WORK и в SM58 не попадает. Делает ли оно само COMMIT WORK - не знаю - эксперимент покажет.

Проверь destinataion NONE в SM59 и очередь SM58 (твои вызовы IN BACKGROUND TASK скорее всего там).

Максим.

Вот здесь на последней картинке показано, зачем нужно проверять блокировки

Дело в том, что при каждом сохранении материала будет вызываться отправка ФМ в отдельном диалоговом процессе.
Если будет происходить массовая загрузка ОЗМ(например, через LSMW), то существует вероятность, что все диалоговые процессы окажутся заняты.
В случае с отправкой IDOC по расписанию будет гарантированно занят лишь один процесс (в зависимости от настроек, конечно).

ALE-распределение использовать не вариант?

http://help.sap.com/saphelp_nw04/helpda ... ameset.htm

Вроде вариант

Максим спасибо. Эксперимент показал что: - Не подходит.
А прямой вызов в инклуде 'ZXMG0U02' (как уже писал) тянет в формируемый Idoc старые(не изменённые) данные (краткий текст матрериала например).

Что получилось - в тр. MM02(после COMMIT-a) вызвать в 'Дистанционный' модуль с SUBMITOM с 'IN BACKGROUND TASK'.

Смотрел MB58 - "оседают" все мои вызовы ФМ - 'ZTESTSUBMIT'. Гоже ли это?


Удав, niemda, спасибо за наводки, по-свободе буду посмотреть,
но пока - срочно "рубим лес отплёвываясь щепой".

А ты пробовал своей функции, кот ты с IN UPDATE TASK вызываешь, ставить атрибут "Start delayed"? Есть вероятность, что в этом случае он будет вызван уже после того, как таблицы обновлены. Нужен еще один эксперимент, если не пробовал.

Модуль с IN BACKGROUND TASK надо вызвать в расширении MGA00001, а выполнится он на самом деле после COMMITа, но, скорее всего, это не поможет, так как таблицы не будут обновлены. Можно в модуле с IN BACKGROUND TASK заблокировать материал с ожиданием - материал заблокируется, когда все апдейты выполнятся, ты сможешь запостить IDoc с новыми данными.

Это не гоже. У тебя проблемы с destination 'NONE'. Иди в SM59 и проверяй. По умолчанию NONE должен быть локальным сервером.

Так ведь не получится так, потому что человек упорно пытается в процессе обновления вызвать SUBMIT который инициирует коммит что не допустимо конечно. С атрибутом "Start delayed" ФМ выполнится в том же процессе обновления только в другом LUW. Да, он будет вызван когда данные закоммитятся в таблицах, когда то я делал такое. Это есть процесс V2.


Блокировать с ожиданием. Я бы не советовал так делать, потому что будет только определённое кол-во попыток блокировать и ждать он тоже может определенное кол-во времени. Лучше использовать цикл и проверять пока блокировка не снимется тр mm01. Не суть важно, в общем подход, проверять блокировку материала, когда она снимется, значит данные закоммитились, это то о чем Удав писал, там есть подводные камни.

Зашел в SM59. RFC Destination -'NONE', Connection Type - 'I' (Internal Connection.).
Всё, вроде, верно...
Какого плана должны быть проблемы? Чего не хватает?
Во что выльется накопление сообщений в SM58?

Самое лучшее - самоликвидируются. Самое худшее - выполнятся все сразу в самый ненужный момент.
А в каком статусе зависли? Может, написано, почему висят?

Кстати, 'ZTESTSUBMIT' должна быть RFC enabled.

Еще можно попробовать вариант: Сделать ehnancement на выходе из функции MATERIAL_UPDATE_DB (там уже точно таблицы обновлены). В этом ehnancement вызвать свою функцию с STARTING NEW TASK (IN UPDATE TASK, IN BACKGROUND TASK не подойдут). В своей функции вызвать SUBMIT. Своя функция должна быть RFC enabled.

А почему не подойдут?
Про блокировки и "подводные камни" я писал, но с их учетом отрабатывать будет.

Висит в замечательном статусе "1 ÓÛÐÒÝëå IDOC's ÔÛï âØßÐ ÔÞÚ-âÐ MATMAS áÞ×ÔÐÝÞ." По поводу сообщений пока никакой информации.
Попробовал "Выполнить LUW F6" - статус сменился на "ThISend: bad tm type / connection closed (no data)".


'ZTESTSUBMIT' - RFC enabled (Дистанционный модуль ).
Вызов -

Сначала использовал 'MATERIAL_UPDATE_DB', но констультант посоветовал ФМ - 'MATERIAL_WRITE_DOCUMENT' т.к. вызывается позже.

А без DESTINATION ФМ пробовали вызывать?

Не подойдут, потому что я предлагал вызов в конце MATERIAL_UPDATE_DB, которая сама в UPDATE TASK вызывается, то есть после COMMIT, а для IN BACKGROUND TASK тоже COMMIT нужен, чтобы выполниться.

Похоже, что функция все-таки вызывается и submit выполняется (так как слова IDoc и MATMAS вполне разборчиво написаны) - проверь в дебагере, может, там разборчивее? Может, и IDoc создается? Может, если в англ яз залогониться разборчивее будет?

Пробовал - работает.
Разница в сообщениях в SM58:


- последний тест на 'EN'.

Правка. После прогона в SM58 в отладчике запись ликвидируется.

Правка2 и только конструкция: - отрабатывает и не оставляет "следов" в SM58.