В своих интеграционных решениях для систем, построенных на платформе Remedy, мы используем JMS очереди для передачи сообщений. Для этого нами был разработан Filter API плагин для Remedy. Использование плагина позволило нам решить ряд задач:
- Повторять запросы любое приемлемое кол-во раз, до успешного завершения обработки (в случае ошибки timeout на стороне обрабатывающего сервиса) ;
- Повысить пропускную способность интеграции, при этом обеспечить стабильное поведение системы (нет ограничения кол-ва для одновременно передаваемых в интеграции запросов);
- Обеспечить мониторинг обмена сообщений за счет контроля размера очереди. Переполнение очереди сигнализирует либо об изменении кол-ва передаваемых запросов в единицу времени, либо об аварийном состоянии сервиса;
- Организовать последовательную обработку сообщений через очередь. При интеграции через веб-сервисы часто сталкивались с нарушением порядка запросов к смежной системе;
- Организовать пост-обработку сообщений , в ситуации временной неработоспособности «входящего» сервиса. Успешно применяется при плановых и внеплановых работах на сервере (отключение сервисов). При эксплуатации системы была ситуация: увидели, что падает исходящий поток в сервисе (ошибка памяти при передаче большого файла 500 МБ). После устранения проблемы успешно передали все зависшие запросы;
- Реализовывать функции ожидания обработки сообщения. Например, ожидание появления файла на указанном ftp/sftp-ресурсе;
- Обеспечить асинхронное взаимодействие между системами.
На сайте сообщества Remedy можно найти пример реализации плагина: https://communities.bmc.com/docs/DOC-3395. Наша реализация позволяет динамически трансформировать передаваемые сообщения и настраивать передачу сообщений в разные очереди через конфигурационные файлы. Свои реализацию плагина мы подстраиваем под задачи заказчика. Кроме того, в своих решениях мы используем альтернативные способы организации очередей.