Добрый день!
Программка в цикле использует функцию EDI_DATA_INCOMING чтобы считать файлы xml и преобразовать их в idoc-и.
Но незадача - если наткнется на ошибочный xml - вылетает напрочь с дампом - данная функция генерирует неперехватываетмое исключение - message type X.
Как бы так сделать чтоб после сбоя пропускать сбойные файлы и продолжать процесс до конца

Вообще эту систему считывания idoc не очень понимаю, может там вообще все неправильно сделано, судя по форумам такой проблемы ни у кого не было, и в документации по EDI/IDOC тоже совсем о другом говорится

Thanks in advance

Я там нашел это место в функции, где можно перехватить, но что-ли писать свою 'невылетающую' ZEDI_DATA_INCOMING?

А если асинхронный вызов попробовать?
CALL FUNCTION func STARTING NEW TASK taskname
... PERFORMING form ON END OF TASK .

Спасибо
Что то я пробовал запустить асинхронно но не могу разобраться с синтаксисом
а можно какой нибудь пример простой?

Как темплайт, что-то типа такого:

Вызвал асинхронно
Теперь при кривом файле вылетает на RECEIVE RESULTS FROM FUNCTION 'EDI_DATA_INCOMING'.
А по другому результат не узнать
наверное

ндаа ...тут надо подумать

А если вообще закомментировать RECEIVE RESULTS ?
ФМ же ничего не возвращает.
Или поэксериментируйте с параметрами этого оператора:
4. ... EXCEPTIONS except1 = rc1 ... exceptn = rcn

да вообще штука полезная, можно попробовать
только жаль что все молчком выполняет - хоть бы subrc возвращала

Так или иначе спасибо за идею

Проблему эту решил
но теперь возникла новая - что-то съехало в настройках
теперь считывает XML очень медленно.

Визуально по SM50 видно,
если раньше возникали сразу несколько процессов считывания, у них появлялась 'RFC' в Прич., теперь же видно только один процесс (поле Прич всегда пустое) и вводится в час по чайной ложке - очень медленно.

При том что в Dev все идет нормально,
в продуктиве вот так тормозит (на тех же программах)
Не случалось ли у вас подобного?
Где бы порыться - тут видимо что-то из BASIS настроек

Это тоже исправили, оказалось раздулась таблица edidc - контрольные записи IDOC. 99% времени программа делала неоптимальный Select извлечения из нее последней записи (до 15 сек уходило на каждом IDOC).
Когда оптимизировал селект - все заработало как надо

А вообще нем мог бы кто-нибудь объяснить - RFC функции выполняются асинхронно?
Такое впечатление что вызов ФМ EDI_DATA_INCOMING не ждет завершения своей обработки - в цикле возникает lots of параллельных процессов обработки IDOC, и соответственно сессий в СУБД. Хотя как - непонятно
Или может я не так понял?

Вот схемка программы
----------- Cut --------------
LOOP AT t.

* Фактическая обработка XML - здесь может произойти исключение (аварийное завершение с дампом)
CALL FUNCTION 'EDI_DATA_INCOMING'
EXPORTING pathname = t-pathname
port = 'ZOUT'
EXCEPTIONS OTHERS = 1.

* Считываем IDOC с наибольшим номером (последний созданный)
CLEAR: docnum, edidc.
SELECT MAX( docnum ) FROM edidc INTO docnum.
SELECT SINGLE * FROM edidc WHERE ( edidc~docnum = docnum ).

ENDLOOP.
---------- Cut ---------------