We are using WSO2 ESB 4.0.3 with Data services feature on MAC OSX 10.7.4.
I have proxy service which forwards the message to Data Service. When there is any fault in Data service the fault is returned to calling proxy service in OUTSEQUENCE. Now if there is any error I forward this to common error handler from proxy service which happens in OUTSEQUENCE. This common error handler is another proxy service only.
Now when the Error handling is completed the control returns back to original proxy service which called the error handling proxy service. But what happens is when the control returns to original proxy service from error handler it AGAIN starts executing the OUTSEQUENCE of proxy service.
So for me it is executing the OUTSEQUENCE of proxy service twice in case of fault from Data Service.
Is it standard behavior? I used to Java kind of executing where when the call from method returns it starts executing the next line. But here looks like it again starts executing the OUTSEQUENCE from beginning.
To avert executing the OUTSEQUENCE from beginning again I populate the value at "transport" scope in Error hanlder proxy which will used in filter mediator to avoid executing the logic in OUTSEQUENCE twice.
I am trying to find if there are any SOAP headers I can use instead of setting the property. I see no SOAP headers being set like "From" or "ReplyTo" and I believe message co-ordination happens with MessageId. How can we use these SOAP headers instead of property to divert the flow logic.
Please help.
thanks
Abhijit
In this case instead of using send mediator to invoke the web service you can use the call out mediator. Which makes a blocking call to error handling service and returns to the same place.
And also with esb 4.0.3 you can specify the receive sequence at the send mediator level. By default the response is received at the outsequence level.
eg. <send receive="fundTransferSequence">
<endpoint>
<address encoding="UTF-8" statistics="disable"
uri="http://10.1.23.11:8888/EgateValidWS/EgateValidWSSoapHttpPort" >
</address>
</endpoint>
</send>
Related
I'm trying to write a SFTP location through a jms/http proxy. However when there is an error on SFTP endpoint (wrong password, network connectivity issue, remote Dir not exists) I want to trigger fault sequence and handle this error (Try some DLC kind of scenario). I found that fault Sequcence is not invoking for FTP errors unless you set OUT_ONLY=false. However WSO2 docs recommends set OUT_ONLY=true for ftp writes. Similar Question is asked here too. How to handle VFS proxy error in WSO2 EI 6.4?
If I set OUT_ONLY=false it triggers faultSquence for both failures and success FTP writes.
Any workaround to catch FTP errors and trigger faultSequence ?
You can define a responseAction in the endpoint configuration. Please refer to the following sample configuration. The responseAction spedifies when a response comes to a timed out request specifies whether to discard it or invoke the fault handler. Apart from defining the responseAction in the endpoint, you can replace the send mediator with the file connector and it will also invoke the fault sequence during an error.
<send>
<endpoint name="wms-fault-endpoint">
<address uri="vfs:ftp://admin:admin1#localhost:2121/testJ/out">
<timeout>
<duration>10000</duration>
<responseAction>fault</responseAction>
</timeout>
</address>
</endpoint>
</send>
[1]-https://docs.wso2.com/display/EI611/Endpoint+Error+Handling
[2]- https://docs.wso2.com/display/ESBCONNECTORS/File+Connector
In WSO2 ESB v. 4.9.0 send metiator did not terminate sequence where it is and all parent sequences and at last proxy service or API. So, in code :
...
<!-- This seqience has send mediator -->
<sequence key="ElabaFtpFileWrite"/>
<!-- This sequence has send mediator -->
<sequence key="ElabaSendMail"/>
<!-- for instance, some mediator or another logic -->
<log level="full"/>
...
second sequence and log mediator are always performed.
On the contrary, in version 5.0.0. nether second sequence nor log mediator are performed.
According to the documentation about send mediator of v. 5.0.0 second behavior is right. But why in v. 4.9.0 send worked in different way and I didn't find any notice about such issue.
I think I somehow did not notice because I am not very experienced user of WSO2 products.
I changed send mediator to call mediator in first and second sequences and then log mediator is performed.
Is such resolution right?
See https://github.com/wso2/wso2-synapse/commit/dc78d18210f3cbd8d2eb04bcd7236658ee3731f4 : on Jun 29, 2016, send mediator has been changed to return "false" (instead of "true") to avoid remaining mediators to be executed
The documentation reflect this : compare https://docs.wso2.com/display/ESB490/Send+Mediator and https://docs.wso2.com/display/ESB500/Send+Mediator you will notice this add-on :
Do not add any mediator configurations after Send mediator in the same sequence, because WSO2 ESB does not process them. Any mediator configuration after the Send mediator should go to the outSequence or receive sequence.
Anybody would please through some light on difference between call and send mediator and what use cases these two mediators are used.
Send mediator - used to send messages out of Synapse to some endpoint. Then the response is returned to the OutSequence where you can send it back to the client
Use cases - When you only need to send a message to one back end and return the response back to the client.
Call mediator - Also used to send messages out of the Synapse to some endpoint, but the response does not come to the OutSequence. When we send a request using the call mediator, the response will arrive to the mediator that is placed right after the call mediator.So this will allow us to specify all the service invocations one after the other in a chain within a single sequence
Use cases - Service chaining. i.e.- Vehicle license renewal service
Another characteristic is that the callout mediator is blocking, send mediator and call mediator are not blocking. This answer is in regards to WSO2 versions until 4.8.0
I'm trying to setup the following scenario using ESB and Message Broker.
Flow 1:
Client 1 Sends the message to ESB -> ESB consumes the message and stores it into the queue -> End of flow 1;
Flow 2:
Client 2 sends a request to ESB to get messages -> ESB gets the messages from the queue defined for Client 2 -> ESB sends back a pack of message that were present in the queue
While there's no problems to implement Flow 1. Documentation and examples refer to store and forward pattern so I didn't see any live examples on consuming message upon clients request - the "store and pull" model.
Could anyone advise please?
Reference links:
http://docs.wso2.org/wiki/display/ESB460/Sample+702%3A+Introduction+to+Message+Forwarding+Processor
http://docs.wso2.org/wiki/display/MB201/Integrating+WSO2+ESB
Best Regards,
Vladimir.
You can refer to this URL: http://wso2.org/library/articles/2013/03/configuring-wso2-esb-wso2-message-broker
I am also struck on Flow 2. I am unable to get data from mesaagebroker through my proxy
First you need to save your message in a queue
<address uri="jms:/Queue1?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&java.naming.factory.initial=org.wso2.andes.jndi.PropertiesFileInitialContextFactory&java.naming.provider.url=tcp://localhost:5672&transport.jms.DestinationType=queue&java.naming.provider.url=repository/conf/jndi.properties" statistics="disable"/>
You need to specify the queue name in the repository/conf/jndi.properties as mentioned here
http://docs.wso2.org/wiki/display/MB201/Integrating+WSO2+ESB
Then you can define a proxy with the same name of the JMS queue to consume that queue
<proxy xmlns="http://ws.apache.org/ns/synapse" name="Queue1" transports="jms" startOnLoad="true" trace="disable" statistics="disable">
<target inSequence="your_in_sequence" outSequence="your_out_sequence" faultSequence="your_fault_sequence"/>
<parameter name="transport.jms.ContentType">
<rules>
<jmsProperty>contentType</jmsProperty>
<default>application/xml</default>
</rules>
</parameter>
</proxy>
You can use this proxy service to consume queue you have used to save the message
Well this is more like a custom requirement. You can achive this using a custom class mediator or a connector. [1]
[1] https://docs.wso2.com/display/ESB481/Creating+a+Connector
As near as I can tell, the WSO2 ESB does not properly handle proxying a service operation that does not return a response message.
Here's the scenario:
We've got a code-first, axis2 generated web service sitting on WSO2 application server 4.1.0.
The java class that the service is based on has some methods like:
public void updateMyObject(MyObject obj) throws MyServiceException
Axis2 generates a WSDL that does not contain a response message, so this is essentially one-way.
NB: An axis2 generated client stub operating against this operation works fine. When invoking the stub in client code, the client blocks until the operation is successfully processed by the server. If an error occurs on the server, then the custom fault is raised and an exception is thrown on the client side.
But, we want to make this invocation via the ESB. Setting up a simple, basic proxy server will not work. When invoking the service via the ESB, the client code blocks indefinitely even though the remote service was successfully invoked.
I read somewhere that this can be fixed by adding the following to my inSequence:
<property action="set" name="OUT_ONLY" value="true"/>
<property action="set" name="FORCE_SC_ACCEPTED" scope="axis2" value="true"/>
This does the trick in the case that the remote service successfully processes the response. The client code no longer blocks.
However, if there is an error processing the request, the client doesn't know. The ESB basically "eats" the error.
This is no doubt because there is no call-back handler registered for the operation because of the OUT_ONLY setting. Search for OUT_ONLY in the link below for more info:
http://techfeast-hiranya.blogspot.ca/2009/12/wso2-esb-tips-tricks-03-transport.html
The FORCE_SC_ACCEPTED setting seems to be the thing that will keep the client from blocking on the success condition, presumably because that forces a 202 http response to the client so it stops waiting for a response.
Since the client operates as it should against the service for both success and error conditions but I am unable to configure a proxy service that yields the same behavior, in my opinion, the ESB is deficient in this way and that is a bug.
Of course, if there is a way I can configure it so that it does what I want, then I'd love to hear it.
But as near as I can tell, I think not registering a call-back is the wrong thing to do here, even if there is no response. I do not wish to implement a fire and forget here. Executions should still happen synchronously from the client side. My client is expecting an HTTP 200 response but with no body for success.
By examining the WSDL, the ESB should realize that the service has no response message but still register a call back. When the 200 OK is received on success, it should propagate this back to the client and unregister the call-back. When a Fault occurs, it should also relay that back to the client.
So, is there a way to accomplish what I want with the ESB or is it deficient in this way?
However, if there is an error processing the request, the client doesn't know. The ESB basically "eats" the error
What is happening to your client if you define a fault sequence for your proxy in this case?
If we register a call-back fro an outonly operation, what will happen is ESB will wait forever for the response and will run out of threads..
In oneway message;
If it is a successcase use these two properties;
<property action="set" name="OUT_ONLY" value="true"/>
<property action="set" name="FORCE_SC_ACCEPTED" scope="axis2" value="true"/>
For a failure case handle that in the fault sequence. I would like to know, what is happens in the fault scenario.