Splitter within a Splitter

[GPS]

My workflow requires that, for every splitted message:

0. Splitter for List
.....
.....
1. Go to a DB table.
2. Retrieve all records matching some criteria
3. For each one of those:
3.a make a webservice call
3.b Handle response (Store it temporarily)
4. For the main message, make some other webservice call, enriching the main message with response(s) from 3.b
5. Handle main response.

6. Aggregator for step 0.

I have a splitter for handling response from step 2, and if the list size is not empty, I give it to splitter, else directly go to step 4.

I am facing an issue, wherein after aggregating at 3.b, once I go to step 6, the final aggregation takes place immediately. It seems that intermediate aggregation removes the previous headers values required for later aggregation.

Is this the expected behavior? If yes, is there any alternative within SI itself? I don't want to go a for loop at step 3.

SI version: 1.0.4

Thanks
GPS

[Dave Syer]

I don't think I understand the flow quite. Why do you describe 3b as an aggregation? Isn't step 4 the only aggregator? Why is step 6 needed at all? I presume the webservice call is synchronous.

[GPS]

yes, everything is synchronous.

here is a more clearer (hopefully) flow -->

0. Splitter(1) for List
.....
.....
1. Go to a DB table.
2. Retrieve all records matching some criteria.

if records found -->
3. Give to Splitter(2)
3.a make a webservice call
3.b Handle response
4. Aggregation for Splitter(2) and send as input to Step 5

if no records found -->
Go directly to step 5

5. For the main splitted message, make some other webservice call, enriching it with aggregated response from step 4, if it exists
6. Handle webservice response.

7. Aggregator for Splitter(1)

[GPS]

here is the code snippet:

<splitter id="fiISOSubmitPaymentSplitter" input-channel="fiISOPaymentProcessorOChannel" output-channel="fiISOSubmitPaymentSplitterOChannel" />

<service-activator ref="fiISOPaymentMessageProcessorBean" input-channel="fiISOSubmitPaymentSplitterOChannel" method="processPaymentForSubmit"
output-channel="fiISOSubmitPaymentReqChannel" />

<payload-type-router input-channel="fiISOSubmitPaymentReqChannel">
<mapping type="java.util.ArrayList" channel="fiNotesSplitterIChannel" />
<mapping type="XXXX.SubmitPaymentRequest" channel="fiISOSubmitPaymentOutboundChannel" />
</payload-type-router>

<splitter id="fiAddNoteSplitterId" input-channel="fiNotesSplitterIChannel" output-channel="fiAddNoteReqChannel" />

<service-activator ref="addNotesNSGateway" method="handleMessage" input-channel="fiAddNoteReqChannel" />

<aggregator id="fiAddNoteAggregatorId" input-channel="fiNotesWSResponseChannel" output-channel="fiNotesAggregatorOChannel"
timeout="1800000" send-partial-result-on-timeout="true" />

<service-activator ref="fiISOPaymentMessageProcessorBean" method="processAddNotesResponse" input-channel="fiNotesAggregatorOChannel"
output-channel="fiISOSubmitPaymentReqChannel" />

<service-activator ref="submitPaymentPOGateway" method="handleMessage" input-channel="fiISOSubmitPaymentOutboundChannel" />

<service-activator id="fiISOSubmitPaymentResponseHandlerId" ref="fiISOPaymentMessageProcessorBean" input-channel="fiISOSubmitPaymentResponseChannel" method="processSubmitPaymentResponse" output-channel="fiISOSubmittedPaymentAggIChannel" />

<aggregator id="fiISOSubmittedPaymentAggregatorId" input-channel="fiISOSubmittedPaymentAggIChannel"
output-channel="fiISOSubmittedPaymentAggOChannel" timeout="3600000" send-partial-result-on-timeout="false" ref="tempAggregator"/>

submitPaymentPOGateway --> its replyChannel is fiISOSubmitPaymentResponseChannel

[Dave Syer]

Ah, I see. I can tell from your aggregators that you are using Spring Integration 1.0, and there is no out-of-the-box support for nested aggregators there. You can upgrade to 2.0, or you can manipulate the headers manually in a pair of interceptors, so that the details of the outer split are saved before the inner split takes place and then re-constituted before the outer aggregation.

[GPS]

You can upgrade to 2.0

So that means 2.0 supports nested splitters / aggregators?