Hello,
"And because the second step can be invoked in many contexts" can be like :
* context 1 : retrieval of documents. We have an API like
/documents/customer/{id}.
- First step, I retrieve the local documents from the {id}.
- Then step 2, I want to find the equivalence of the {id} for the other
source (we'll call this equivalence, {id2}). However, {id2} does not exist
so my web service returns 404. BOOM, step 2 prime is trigger
- step 2 prime, fault sequence. How can I send back the retrieved documents
from the first step? I can use a property and in this sequence, retrieve
the property via a PayloadFactory and just use the respond mediator.
whereas step 3 should be:
- retrieve the document from the other source and merge them with the local
ones
* context 2 : retrieval of customer information. We have an API like
/customer/{id}
- First step, I retrieve the local information from the {id}.
- Then, step 2, I want to find the equivalence of the {id} for the other
source (we'll call this equivalence, {id2}). However, {id2} does not exist
so my web service returns 404. BOOM, step 2 prime is trigger. Yep, because
we use the same sequence as in the context 1 because we are lazy :)
- step 2 prime, fault sequence. How can I send back the local information
from the first step whereas this same fault sequence could potentially be
used for the context 1? Use the same property?
whereas step 3 should be:
- retrieve the information from the other source and merge them with the
local ones
Because of those two contexts (or more), I can't just call the fault
sequence to do the merge because the data types are different. Or maybe by
using a flag with the switch mediator but I don't know if it is
common/right practice to do so.
Regards,
Thomas
2018-03-21 15:41 GMT+01:00 Vinod Kavinda <[email protected]>:
> Hi Thomas,
> How about including your third step in a separate sequence and invoking it
> from the fault sequence when it is triggered?
>
> Thanks,
> Vinod.
>
> On Wed, Mar 21, 2018 at 8:05 PM, Himasha Guruge <[email protected]> wrote:
>
>> Hi Thomas,
>> Could you elaborate on following.
>> " And because the second step can be invoked in many contexts, I can't
>> just customize the fault sequence to invoke the third step."
>>
>> How about using switch mediator in fault sequence (for error_code
>> property) and based on that, invoke the third step?
>>
>> Thanks,
>> Himasha
>>
>> On Tue, Mar 20, 2018 at 8:43 PM, Thomas LEGRAND <
>> [email protected]> wrote:
>>
>>> Hello,
>>>
>>> I have a situation where I want to retrieve data from two sources. So,
>>> the client sends a request to a specific resource of an ESB API and the
>>> sequence follows like this :
>>>
>>> - retrieve the data from the local source
>>> - retrieve a corresponding id for the other source
>>> - if the correspondence exists, retrieve the data from the other source
>>>
>>> In the second step, I call a little REST web service which returns a 404
>>> when the correspondence does not exists. The call is implemented by using a
>>> Address mediator, like this:
>>>
>>> <call blocking="true">
>>> <endpoint>
>>> <address format="get" uri="${getCorrespondenceUrl}"/>
>>> </endpoint>
>>> </call>
>>>
>>> Of course, as you can see, the "getCorrespondenceUrl" is built just
>>> before thanks to registry parameters. My problem is the Address endpoint
>>> takes the 404 code as an error and just stop the sequence:
>>>
>>> TID: [-1234] [] [2018-03-20 15:48:45,114] INFO {
>>> org.apache.axis2.transport.http.HTTPSender} - Unable to sendViaGet to
>>> url[http://blablabla/find/my/correspondence] {
>>> org.apache.axis2.transport.http.HTTPSender}
>>> org.apache.axis2.AxisFault: Transport error: 404 Error: Not Found
>>>
>>> So, I tried to use a fault sequence by setting the onError attribute:
>>>
>>> <sequence name="getCorrespondenceSequence"
>>> onError="getCorrespondenceFaultSequence" trace="disable" xmlns="
>>> http://ws.apache.org/ns/synapse";>
>>> </sequence>
>>>
>>> However, once this sequence is triggered, there is no turning back to
>>> the third step. And because the second step can be invoked in many
>>> contexts, I can't just customize the fault sequence to invoke the third
>>> step.
>>>
>>> So, is there a way to tell the mediator that 404 is no big deal?
>>>
>>> Regards,
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [email protected]
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Himasha Guruge
>> Senior Software Engineer
>> WS*O2* *Inc.*
>> Mobile: +94 777459299 <+94%2077%20745%209299>
>> [email protected]
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Vinod Kavinda
> Senior Software Engineer
> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.*
> Mobile : +94 (0) 712 415544
> Blog : http://soatechflicks.blogspot.com/
> [image: http://wso2.com/signature]
> <http://wso2.com/signature>
>
>
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
