У меня есть это требование в службе мула, которую он должен использовать из входящего соединителя (источника потокового сообщения), только если бизнес-условие выполняется. Мне нужно посмотреть в базе данных, выполняется ли это условие, и тогда только мой входящий коннектор должен начать потреблять. Каждый раз он должен проверять это условие и потреблять, только если условие истинно. Предложите лучший способ добиться реализации в муле.
Мул: входящий коннектор использует только при соблюдении бизнес-требований.
Ответы (3)
Хотя фильтр сообщений теоретически корректен, на практике это часто достигается с помощью соединителя базы данных с запросом SELECT, который определяет, какие строки должны быть обработаны в предложении WHERE. Вы можете поместить запрос в элемент <poll></poll>
в начале потока, чтобы выполнить запрос по расписанию, как показано в второй пример здесь.
Это сложно сказать, не заглядывая в ваш поток, что именно вы хотите реализовать. Обычно, если вы хотите, чтобы ваша входящая конечная точка потребляла, а поток работал, лучшим вариантом является установка фильтра сообщений. после входящей конечной точки, которая проверит условие и позволит сообщению передать следующему процессору..
Поскольку здесь вы хотите проверить условие из базы данных, вам нужно поместить компонент БД после входящей конечной точки, которая будет извлекать значение бизнес-условия из БД, а затем вы можете поместить либо фильтр сообщений< /strong> или Выбор маршрутизатора для передачи полезной нагрузки сообщения следующему компоненту Mule.
Обычно это делается с помощью шаблона интеграции фильтра сообщений.
Этот шаблон реализован в Mule как (и только как) фильтры, другие шаблоны, которые могут помочь, особенно маршрутизаторы и обходные пути, но более последовательный способ сделать это — с фильтрами.
В случае с Mule у вас есть несколько фильтров, однако нет встроенного фильтра на основе SQL-запросов. Это сказано. У вас есть несколько вариантов:
- Фильтр в java, который можно создать как экземпляр Spring bean-компонента, внедренного в источник данных, а затем использовать в качестве настраиваемый фильтр со ссылкой ar.
- если это предназначено для повторного использования, реализуйте как DevKit модуль.
- в качестве обходного пути реализуйте подпоток, который использует конектор базы данных для извлечения результата запроса, а затем фильтрует или нет в конце потока с помощью фильтра выражения.