Spring Integration Java DSL поведение использования нескольких ".channel ()"

Question

Я тестирую поведение метода .channel () и наблюдаю вещи, которые мне не понятны.

@Bean
    public IntegrationFlow flow() {
        return IntegrationFlows.from("my-gateway")
                .channel("first-channel")
                .channel("second-channel")
                .get();
    }

Если я помещаю операторы печати в «первый канал», они не печатаются. Но некоторые из бизнес-логик c все еще, кажется, происходят. Изменить: Добавлен код для активаторов услуг

@ServiceActivator(inputChannel = "first-channel")
   public Message testFlow(Message message) {
   System.out.println("Entered First Channel " + "\n" + "Message Header: " + message.getHeaders() + "\n" + "Message Payload" + "\n" + message.getPayload());
return message;

}

@ServiceActivator(inputChannel = "second-channel")
   public Message testFlow(Message message) {
   System.out.println("Entered Second Channel " + "\n" + "Message Header: " + message.getHeaders() + "\n" + "Message Payload" + "\n" + message.getPayload());
return message;

}

application.properties:

logging.level.root=TRACE

Разрешено ли мне передать сообщение через несколько каналов в одном java dsl IntegrationFlow? Или все IntegrationFlow ограничены одним каналом / ServiceActivator каждый?

Редактировать: в журналах появляется только оператор печати second . Почему это?

Answer 1

Нет, вы определенно можете создать поток с несколькими каналами, и у вас даже может быть такая конфигурация. A bridge() помещается между ними внутри каркаса. Изображение, которое вам нужно для дампа сообщений из прямого звонка в какую-то очередь или наоборот. Или ваш канал сообщений может даже основываться на некотором постоянном хранилище для таких сообщений, как JMS, AMQP и т. Д. c.

Абстракция MessageChannel является первоклассным гражданином в Spring Integration и основана на канонической интеграции. Модель, описанная в EIP: https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageChannel.html

Важность такой реализации между конечными точками становится полезной, когда вы видите, как эти конечные точки слабо связаны, и целевая реализация MessageChannel может диктовать нам Некоторое изменение поведения в середине потока.

Еще один аспект в качестве аргумента, что допустимо иметь поток, подобный тому, который вы определили, это ChannelInterceptor. У вас все еще может быть определение только с именами каналов, но ChannelInterceptor может применяться к ним глобально в соответствии с его параметром шаблона.

Верно и обратное: вы можете объявить поток только с конечными точками, а каркас помещает канал между ними.

Пожалуйста, обратитесь к документации для получения дополнительной информации: https://docs.spring.io/spring-integration/docs/5.2.3.RELEASE/reference/html/dsl.html#java -dsl