Iterate/Aggregate Fault Handling in WSO2 EI
Iterate/Aggregate Fault Handling in WSO2 EI
In this article, see how to iterate/aggregate fault handling in WSO2 EI.
Join the DZone community and get the full member experience.Join For Free
In WSO2, we can implement the Splitter and Aggregator EIP using the Iterate and Aggregate mediators. With the Splitter pattern, we can split a message composed by different elements that need to be processed individually, and then we use the Aggregator pattern to aggregate the results of each individual call and then perform some processing over the aggregated results.
Happy Path Example
In a happy path example, all the requests and processing done inside the iterate mediator will occur with no failures, and the aggregate mediator will handle the results of all the requests made. We can see that in the proxy below:
This proxy basically creates a payload contaning multiple echoInt requests, and then we iterate over each echoInt to make a request to the echo service. Inside the iterate, we set the Action header and make a request to the endpoint using the call mediator. We added the property FORCE_ERROR_ON_SOAP_FAULT so in case of a SOAPFault returned by the backend service, the flow will be redirected to the fault sequence.
In this example, there is no error, so the aggregate mediator after the iterate will gather all the responses and aggregate them in a single message and respond back. We can see the response of this Proxy service in the xml below:
You may also want to read: Iterative Processing Using the For Each Scope in Mule
In the proxy below, we made a small change in the payloadFactory in order to force a soap fault from the backend:
We are passing the value ‘abc’ in the second echoInt element. With this example, when we try the proxy, we are not going to receive any response as the flow is redirected to the faultSequence, and we can see the log entry:
[2020-02-16 21:32:41,526] [EI-Core] INFO - LogMediator ON FAULT SEQ = faultSequence default
The full proxy service code can be seen below:
Fault Handling With Iterate/Aggregate
In order to still have the aggregate to work when having a fault, we need to make some changes to proxy and make use of sequences. After the changes we are going to have the following artifacts:
- The Proxy Service
- Iterate sequence
- Aggregate sequence
- IterateFaultHandler sequence
The proxy service code can be seen below:
The main difference from the previous proxy is that inside the iterate, we are using a predefined sequence instead of an anonymous sequence. And we have the AggregateSequence just after the iterate mediator.
The AggregateSequence just contains the code that we had previously inside the proxy:
There is nothing special in that sequence.
Now let us see the IterateSequence:
It contains the same code that we had in the proxy, but the tricky part is in the onError property of the sequence where we specify which sequence should be executed in case of errors in the sequence, that in this case is the IterateFaultHandler. So, in this case, when it tries to execute the echoInt with the abc value it will receive the SOAPFault and will redirect the flow to the IterateFaultHandler.
So, now let us see the IterateFaultHandler:
Inside this fault sequence, we create an error payload with the faultstring. Then we set the RESPONSE property to true, this indicates to the synapse engine that this message is in the response direction. And then we call the AggregateSequence. We need to specify the RESPONSE property because the aggregate mediator expects the message flow to be in the response direction.
So, now when we try the proxy it will receive a fault for the element with the invalid value and then redirect to the fault sequence, it will generate that error payload and calls the aggregate. We can see below the error log indicating that it executed the fault sequence and then the final payload:
[2020-02-16 21:55:48,155] [EI-Core] INFO - LogMediator ON ITERATE FAULT SEQ = IterateFaultHandler
The response payload:
With this approach, the aggregate is always executed and the flow finishes without any issues.
You may ask, “Why not call the AggregateSequence inside the Proxy faultSequence?” When we try using the AggregateSequence inside the faultSequence of the proxy, it will throw the error below and that does not happen when we use a named sequence for the fault handling:
I hope this helps! See you in the next post.
Published at DZone with permission of Francisco Ribeiro , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.