Модульная интеграция Spring Gateway - PullRequest
0 голосов
/ 25 сентября 2018

В попытке модульности потоков Spring Integration я начал использовать шаблон, в котором я помещаю входящие и исходящие шлюзы в отдельные классы, а затем импортирую их при необходимости для создания потоков.Например, вот минимальное интеграционное тестирование, показывающее грубый подход:

@RunWith(SpringRunner.class)
@SpringBootTest(classes = { SampleIntegrationFlowTest.class })
@SpringIntegrationTest
@EnableIntegration
public class SampleIntegrationFlowTest {

    @Autowired
    private InboundGateways inboundGateways;

    @Autowired
    private OutboundGateways outboundGateways;

    @Test
    public void testFlow1() {
        StandardIntegrationFlow flow = IntegrationFlows
            .from(inboundGateways.createAccount())
            .transform(new JsonToXmlTransformer())
            .handle(outboundGateways.soapAccount())
            .transform(new XmlToJsonTransformer())
            .get();

        flow.start();
    }

    @Test
    public void testFlow2() {
        StandardIntegrationFlow flow = IntegrationFlows
            .from(inboundGateways.searchAccount())
            .transform(new JsonToXmlTransformer())
            .handle(outboundGateways.soapAccount())
            .transform(new XmlToJsonTransformer())
            .get();

        flow.start();
    }

    @Configuration
    static class InboundGateways {

        @Gateway
        public MessagingGatewaySupport createAccount() {
            return WebFlux.inboundGateway("/accounts")
                .requestMapping(mapping -> mapping
                    .consumes("application/json")
                    .produces("application/json")
                    .methods(HttpMethod.POST))
                .get();
        }

        @Gateway
        public MessagingGatewaySupport searchAccount() {
            return WebFlux.inboundGateway("/accounts")
                .requestMapping(mapping -> mapping
                    .produces("application/json")
                    .methods(HttpMethod.GET))
                .headerExpression("name", "#requestParams.name")
                .get();
        }

    }

    @Configuration
    static class OutboundGateways {

        @Gateway
        public MessageHandler soapAccount() {
            return new SimpleWebServiceOutboundGateway("http://example.com/accounts");
        }

    }
}

Я структурирую его таким образом, чтобы я мог:

  1. Группировать входящие шлюзы вместе, чтобы яможет генерировать класс InboundGateways из контракта Swagger.
  2. Возможность повторного использования исходящего шлюза из нескольких потоков (несколько входящих конечных точек отдыха направляются к одной исходящей конечной точке мыла).

Вопросы:

  1. Есть ли недостатки в том, как я это структурировал?Есть ли способы улучшить его, учитывая указанные выше цели?
  2. Есть ли возможность «смоделировать» входящие шлюзы как интерфейсы, аннотированные @ MessagingGateway / @ Gateway, чтобы я мог взаимодействовать с ними, как обычный pojo?Это может быть полезно при интеграции в существующий код или через интеграционные тесты.Если есть способ, я не могу понять, как сделать что-то вроде Webflux.inboundGateway (

1 Ответ

0 голосов
/ 26 сентября 2018
  1. Аннотация @Gateway ничего не делает.

Я не вижу проблем с вашим подходом;вы не можете повторно использовать исходящие шлюзы (если объявлено как @Bean - все в порядке, как у вас).Это связано с тем, что любой вызывающий ответ MessageHandler может иметь только один выходной канал.

Нет;@MessagingGateway предназначен для создания GatewayProxyFactoryBean - для взаимодействия между унаследованным Java-кодом и интеграционным потоком.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...