Hi Thomas,
Yes given your scenarios handling each separately based on a flag/flags
(with switch mediator) would be the possible solution. You could store
these properties(such as documents) in registry itself.
Thanks,
Himasha
On Wed, Mar 21, 2018 at 9:08 PM, Thomas LEGRAND <
thomas.legr...@versusmind.eu> wrote:
> 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 <vi...@wso2.com>:
>
>> 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 <himas...@wso2.com>
>> 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 <
>>> thomas.legr...@versusmind.eu> 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
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Himasha Guruge
>>> Senior Software Engineer
>>> WS*O2* *Inc.*
>>> Mobile: +94 777459299 <+94%2077%20745%209299>
>>> himas...@wso2.com
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev@wso2.org
>>> 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>
>>
>>
>
--
Himasha Guruge
Senior Software Engineer
WS*O2* *Inc.*
Mobile: +94 777459299
himas...@wso2.com
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
