我正在使用Spring集成來發送SOAP請求,接收SOAP響應並對其進行處理。我也使用(或嘗試使用)索賠格紋圖案存儲原始SOAP請求和響應,在一個對象,一個簡單的POJO,叫ExchangeMessage,它看起來像這樣:Spring集成:如何使用當前有效負載來更新聲明中的對象?
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)I發送一個簡單的POJO入站網關,它被轉換成一個簡單的SOAP請求(字符串)。
在鏈中,在(3)中,exchangeMessageServiceActivator bean接受String,並創建一個ExchangeMessage對象,並使用SOAP Request調用它的setRequest()方法。
在(4)我將新創建的ExchangeMessage保存在Claim Check中。 (5)中,我將其檢出並在(6)和(7)中將ExchangeMessage.getRequest()的內容發送到WS出站網關。我意識到我可以使用Header Enricher做到這一點,但由於我想保存ExchangeMessage對象,我認爲它幾乎是一樣的,即使在聲明簽入後立即調用聲明簽出是一種醜陋。 (7)和(8)之間出現問題。 (7)的有效載荷是SOAP響應。 之前解組成一個對象(然後處理它...),我想要使用<聲明簽出>檢索ExchangeMessage,使用SOAP響應調用ExchangeMessage.setResponse()方法,然後然後將SOAP響應轉換爲對象進行處理。如果在(7)和(8)之間我堅持一個<聲明簽出>,我會丟失(7)的原始有效負載,即SOAP響應。 (7)和(8)之間使用某種服務激活器,以某種方式從Claim Check中加載ExchangeMessage,並使用(7)中的有效內容調用其setResponse()方法,但我無法弄清楚如何去做。到目前爲止,這我已經得到了:
SimpleMessageStore simpleMessageStore = (SimpleMessageStore)context.getBean("simpleMessageStore");
ClaimCheckOutTransformer claimCheckOutTransformer = new ClaimCheckOutTransformer(simpleMessageStore);
claimCheckOutTransformer.transform(Message???);
如果此服務激活的有效載荷將是一個String(SOAP響應)來自哪裏,我需要傳遞給如何ClaimCheckOutTransformer.transform()消息?
我喜歡Spring Integration。但是這個讓我難住。
嗯...但不是隻有下一個下游消費者可用的標題?換句話說,如果我在步驟(3)後將ExchangeMessage放入標題中,然後調用出站網關(稱爲它(4),它是否仍然可用於步驟(5),例如獲取ExchangeMessage的服務激活器在頭文件中調用它的setResponse()方法?或者我必須在每一步中手動添加頭文件嗎?我之前嘗試過類似這樣的方法...嘗試訪問Header Enricher添加頭,它說頭不存在... –
頭將保留在每個下游消息。唯一的例外是,如果你有一個自定義轉換器,返回類型'消息>'而不是隻有有效載荷(可能是因爲轉換器也希望操作標頭);在這種情況下,框架假定自定義轉換器負責傳播任何想保留的標頭;通常使用消息構建器的'copyHeaders()'方法 –
哇,非常感謝,我不知道!這正是我在SI文檔中尋找的信息 - 標題生存了多久?我相信發生的事情是,我必須一直試圖在變壓器之後訪問標題*,因此它不再存在。在使用頭文件之後,我得出結論,使用Claim Check將會更清晰,因爲我不必爲每條消息序列化和反序列化。但似乎我的使用案例 - 同時使用存儲在Claim Check *和*當前有效負載中的數據 - 太複雜了。再次感謝! –