Коллеги, ситуация такая: к нам в систему приходят соообщения из PI и обрабатываются ABAP-прокси. Иногда при обработке сообщения возникает ошибка уровня бизнес логики и в таком случает возникает исключение, предусмотренное интерфейсом. Однако такое ошибочное сообщение блокирует всю входящую очередь, что естественно никого не устраивает. Ручной перезапуск бесполезен, т.к. при повторной обработке возникает та же самая ошибка.
Что можно попробовать сделать в такой ситуации?

какое именно "предусмотренное исключение" не обрабатывается в коде прокси?

CX_SAPPLCO_STANDARD_MSG_FAULT - возвращается аккуратный списочек ошибок/предупреждений в ответ на пришедшее сообщение.
Хм, а что, блокируется очередь или нет зависит от вида ошибки?

CX_SAPPLCO_STANDARD_MSG_FAULT унаследован от CX_PROXY_FAULT ?

Вообще, в двух системах (BW7 и иксайной) я такого CX_PROXY_FAULT не нашёл, наверное у вас он какой-то специфичный а не стандартный для Local Integration Engine.

В qRFC/SMQ2 будет при многих исключениях зависать, собственно это "так и должно быть" для мониторинга. Можно настроить задание по периодическому рестарту LUWов, тогда будет пробовать снова и снова. Как правило, такие необработанные исключения требуют вмешательства оператора.

Необходимо в коде Abap-proxy ловить любое исключение, а затем генерировать уже исключение данной прокси. Таким образом сообщение не будет висеть в очереди со статусом Sheduled, более того через SXI_MONITOR ты сможешь увидеть текст исключения в виде XML-ки, а сообщение будет со статусом Application Error, и к нему будут доступны все фичи - редактирование меседжа, алертинг и рестарт.
Чтобы у Abap-proxy было собственное исключение, необходимо, чтобы интерфейс на котором генерируется прокси имел Fault Message.

Да, это исключение в ERP обитает, но у нас накатывались какие-то дополнительные компоненты. CX_SAPPLCO_STANDARD_MSG_FAULT наследуется от CX_DYNAMIC, который наследуется от CX_ROOT. На самом деле рестарт в большинстве случаев может не помочь, т.к. если проблема в пришедших данных (т.е. бизнес уровня), то ошибка будет повторяться при каждом перезапуске.
Т.е. я вижу несколько вариантов:
1. Редактировать сообщение (но ведь отправившая система об этом ничего не узнает, возникнет рассинхронизация данных и маленький персональный хаос);
2. Удалить сообщение и перезапустить очередь (но нужно как-то уведомлять отправившую систему об ошибке);
3. Пропустить сообщение и отправить текст исключения отправителю - вот этот вариант и видится мне самым разумным.



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

Спасибо всем вам большое за помощь!

>А очередь все равно блокируется. Наверное я где-то какую-то мелочь упускаю.
А сообщение случаем не EOIO ? Префикс у имени очереди с буквой T или Q ?

>В крайнем случае буду сообщения об ошибках отправлять отдельным интерфейсом. Или акноледжменты настраивать буду учиться.
Никакой дополнительной ф-ии для акноледжментов не нужно! Если в заголовке сообщения стоит, что оно требует акноледжмент, то
1) Если успешно обработалось, автоматически пошлется успешный ack
2) Если прокси словила исключение (было сгенерировано исключение именно данной прокси), то отправится акноледжмент appl err

Вывод - надо полюбому ловить все исключения в прокси.

Гляньте ноты
Note 1483845 - Using the report RSARFCEX
и
Note 527481 - tRFC or qRFC calls are not processed

и как эти ноты помогут в описанной ситуации?