Spring Integration: как обновить Object in Claim Check с текущей полезной нагрузкой?

Я использую Spring Integration для отправки запроса SOAP, получения ответа SOAP и его обработки. Я также использую (или пытаюсь использовать) шаблон проверки требований для хранения исходного запроса и ответа SOAP в объекте, простом POJO, называемом ExchangeMessage, который выглядит следующим образом:

public class ExchangeMessage {

  protected String request;
  protected String response;
  ...

Вот как сейчас выглядит мой поток:

(1) <int:transformer input-channel="transformerChannel" output-channel="requestChannel"/>
(2) <int:gateway default-request-channel="transformerChannel" />

<int:chain input-channel="requestChannel" output-channel="loggerChannel">
(3)  <int:service-activator ref="exchangeMessageServiceActivator" />
(4)  <int:claim-check-in/>
(5)  <int:claim-check-out/>
(6)  <int:transformer expression="payload.getRequest()" />
(7)  <ws:outbound-gateway uri="http://.../>
(8)  <int:transformer ref="xmlMsgToPojoTransformer" />

    ... processing ...

</int:chain>

По сути, в (1) и (2) я отправляю простой POJO на входящий шлюз, и он преобразуется в простой запрос SOAP (строка).

Внутри цепочки в (3) bean-компонент exchangeMessageServiceActivator принимает строку и создает объект ExchangeMessage, вызывая его метод setRequest() с запросом SOAP.

В (4) я сохраняю только что созданный ExchangeMessage в Claim Check.

В (5) я проверяю его обратно, а в (6) и (7) отправляю содержимое ExchangeMessage.getRequest() на исходящий шлюз WS. Я понимаю, что мог бы сделать это с помощью Обогащателя заголовков, но, поскольку я все равно хочу сохранить объект ExchangeMessage, я решил, что это почти то же самое, даже несмотря на то, что вызов Claim-Check-Out сразу после Claim-Check-In является чем-то вроде уродливый.

Проблема начинается между (7) и (8). Полезной нагрузкой (7) является ответ SOAP. Прежде чем преобразовать его в объект (и затем обработать...), я хочу получить ExchangeMessage с помощью ‹ Claim-Check-Out >, вызвать метод ExchangeMessage.setResponse() с ответом SOAP. , а затем затем преобразовать ответ SOAP в объект для обработки.

Проблема в том, что если между (7) и (8) я вставлю ‹ Claim-Check-Out >, я потеряю исходную полезную нагрузку (7), ответ SOAP.

Я думал об использовании какого-то активатора службы между (7) и (8), чтобы каким-то образом загрузить ExchangeMessage из проверки требований и вызвать его метод setResponse(), используя полезную нагрузку из (7), но я не могу понять, как это сделать. Я зашел так далеко:

SimpleMessageStore simpleMessageStore = (SimpleMessageStore)context.getBean("simpleMessageStore");
ClaimCheckOutTransformer claimCheckOutTransformer = new ClaimCheckOutTransformer(simpleMessageStore);
claimCheckOutTransformer.transform(Message???);

Если полезной нагрузкой для этого активатора службы будет строка (ответ SOAP), откуда берется сообщение, которое мне нужно передать, как ClaimCheckOutTransformer.transform()?

Мне нравится Spring Integration. Но этот поставил меня в тупик.


person Robert Bowen    schedule 12.12.2016    source источник


Ответы (1)


Было бы проще сохранить ExchangeMessage в заголовке с помощью средства обогащения заголовков, а не использовать проверку требований.

Таким образом, позже вы сможете вызвать setResponse().

В противном случае вам нужно будет сохранить полезную нагрузку для проверки требований (между 4 и 5), а также ответ перед повторной проверкой, но это будет более сложный процесс, чем простое сохранение исходного объекта и вообще не использование проверки требований. .

person Gary Russell    schedule 12.12.2016
comment
Хммм... но разве заголовки доступны не только следующему потребителю ниже по течению? Другими словами, если я помещу ExchangeMessage в заголовок после шага (3), то вызову исходящий шлюз (назовите его (4), будет ли он по-прежнему доступен для шага (5), например, Service Activator, который захватит ExchangeMessage в заголовке и вызывает его метод setResponse ()? Или мне нужно вручную добавлять заголовок на каждом этапе? Я пробовал что-то подобное ранее ... пытался получить доступ к заголовку 2 или 3 потребителям ниже по течению от того, когда Header Enricher добавил заголовок, а он говорит, что заголовка не существует... - person Robert Bowen; 12.12.2016
comment
Заголовок будет сохранен в каждом нисходящем сообщении. Единственное исключение будет, если у вас есть пользовательский преобразователь, который возвращает тип Message<?>, а не только полезную нагрузку (возможно, потому, что преобразователь также хочет манипулировать заголовками); в этом случае платформа предполагает, что пользовательский преобразователь отвечает за распространение любых заголовков, которые он хочет сохранить; обычно используется метод copyHeaders() построителя сообщений. - person Gary Russell; 12.12.2016
comment
Вау, спасибо большое, я и не знала! Это именно та информация, которую я искал в документах SI — как долго живут заголовки? Я полагаю, что произошло то, что я, должно быть, пытался получить доступ к заголовку после преобразователя, поэтому он больше не присутствовал. Поиграв с заголовками, я пришел к выводу, что использование Claim Check было бы чище, поскольку мне не пришлось бы сериализовать и десериализовать каждое сообщение. Но кажется, что мой вариант использования — одновременное использование данных, хранящихся в Claim Check и текущей полезной нагрузки, — слишком сложен. Спасибо еще раз! - person Robert Bowen; 12.12.2016