В документации Mule указано, что стратегия catch-exception аналогична блоку catch java. Но, к сожалению, полезная нагрузка потребляется (сообщение потребляется); из блока catch полезная нагрузка теряется (в отличие от метода java, где вы можете получить доступ к входным параметрам метода из блока catch/finally).
Проблема с этим дизайном заключается в том, что в любом случае (из потока стратегии перехвата) невозможно узнать ошибку и последнюю известную расширенную полезную нагрузку, которая использовалась (что вызвало ошибку?). Это усложняет проверку данных, вызвавших ошибку.
Предположим, что если есть поток с 10 обработчиками сообщений, становится утомительно идентифицировать обработчик сообщений, вызвавший ошибку.
Я вижу 2 обходных пути в отношении полезной нагрузки:
1) После входящей конечной точки помещать полезную нагрузку в переменную потока перед каждым обработчиком сообщений (еще один недостаток — что происходит с входящими свойствами и вложениями?)
2) Используйте стратегию исключений отката с нулевыми попытками (транзакция будет откатана), и исходное входное сообщение может быть доступно. (недостаток: трудно понять, почему произошла ошибка и на каком процессоре сообщений - пример: у меня может быть 5 или 6 процессоров БД)
Причина, по которой это становится важным, заключается в том, что поддержка приложения ESB в производственной среде становится проще.
Например, из блока catch, если мы можем передать данные полезной нагрузки и исключений (связанные с одним UID), вы можете запустить инструмент мониторинга журнала, отправить его на панель мониторинга в реальном времени для целей мониторинга/создания предупреждений. Тот же подход можно единообразно применить ко всем приложениям/потокам, Java-компонентам и т. д.
MMC слаба в этой области — например, если вы хотите подавить оповещения от пакетного задания после 5 повторений, MMC не сможет этого сделать.
Мои вопросы: 1) Есть ли какая-либо причина, по которой полезная нагрузка становится недоступной? Возможный обходной путь — отправить (последние известные данные) в другую переменную как часть сообщения с именем originalPayload или originalInboundProperties? 2) Любой другой прямой способ передачи исключения и полезной нагрузки в приложение (вместо обходных путей)?
Анант Кришнан (WHISHWORKS.com)
