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
Related
We are getting below exception with Kafka 2.11 and wso2 esb 6.2 with sasl enabled. SASL mechanism in wso2 esb and Kafka clsuter is PALIN but randmoly seeing Error 2 in logs.
Does anybody experienced this error and any help is appreciated.
Error 1:
java.util.concurrent.ExecutionException: org.apache.kafka.common.errors.TimeoutException: Expiring 1 record(s) for TESTTOPIC: 30051 ms has passed since batch creation plus linger time
Error 2:
[2019-11-02 01:36:50,265] ERROR - [Producer clientId=producer-4526] Connection to node -1 failed authentication due to: Unexpected handshake request with client mechanism PLAIN, enabled mechanisms are [GSSAPI] {org.apache.kafka.clients.NetworkClient}
Based on the Second Error Message *Unexpected handshake request with client mechanism PLAIN, enabled mechanisms are [GSSAPI]*, it would seem that the saslMechanism has not been configured properly on the ESB side. It is configured to GSSAPI Kerberos by default.
I would recommend getting the latest version of the Kafka Connector. You can find the documentation and the relevant links here
One such example of a PLAIN configuration with the Kafka Connector would be :
<kafkaTransport.init>
<bootstrapServers>localhost:9092</bootstrapServers>
<keySerializerClass>org.apache.kafka.common.serialization.StringSerializer</keySerializerClass>
<valueSerializerClass>org.apache.kafka.common.serialization.StringSerializer</valueSerializerClass>
<securityProtocol> SASL_PLAINTEXT </securityProtocol>
<saslMechanism> PLAIN </saslMechanism>
<saslJaasConfig>org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="12345"</saslJaasConfig>
<maxPoolSize>100</maxPoolSize>
</kafkaTransport.init>
This is the relevant configuration required to make use of the Kafka Connector. The Security Protocol can be configured to SASL_SSL as well.
Here is one such proxy configuration
<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="KafkaTransport"
startOnLoad="true"
statistics="disable"
trace="disable"
transports="http,https">
<target>
<inSequence>
<kafkaTransport.init>
<bootstrapServers>localhost:9092</bootstrapServers>
<keySerializerClass>org.apache.kafka.common.serialization.StringSerializer</keySerializerClass>
<valueSerializerClass>org.apache.kafka.common.serialization.StringSerializer</valueSerializerClass>
<securityProtocol>SASL_SSL</securityProtocol>
<saslMechanism>PLAIN</saslMechanism>
<sslKeystoreLocation>/Users/Ibaqu/kafka.client.keystore.jks</sslKeystoreLocation>
<sslKeystorePassword>admin123</sslKeystorePassword>
<sslTruststoreLocation>/Users/Ibaqu/kafka.client.trustore.jks</sslTruststoreLocation>
<sslTruststorePassword>admin123</sslTruststorePassword>
<saslJaasConfig>org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="12345";</saslJaasConfig>
<maxPoolSize>100</maxPoolSize>
</kafkaTransport.init>
<kafkaTransport.publishMessages>
<topic>test</topic>
</kafkaTransport.publishMessages>
</inSequence>
</target>
<description/>
</proxy>
You can give this particular proxy a try to test your connection.
How can I configure a WSO2 Integrator FIX initiator endpoint which utilizes automatic session failover supported by Quickfix/J?
In Quickfix/J, it is possible to configure automatic failover of the initiator session using the FIX config file as follows (assuming two localhost FIX servers listening on ports 9997,9998)
[SESSION]
SenderCompID=SYNAPSE
TargetCompID=EXEC
SocketConnectHost=localhost
SocketConnectPort=9997
SocketConnectHost1=localhost
SocketConnectPort1=9998
ReconnectInterval=5
All examples in WSO2 documentation show FIX endpoints configured with a hardcoded host such as:
<send>
<endpoint>
<address uri="fix://localhost:9997?BeginString=FIX.4.4&SenderCompID=SYNAPSE&TargetCompID=EXEC"/>
</endpoint>
</send>
This pattern is not possible for us because the target FIX server is on a remote server with a hostname that is different per environment, so I never want to hardcore the target host like this.
Ideally I would like to do something like this:
<send>
<address uri="fix://<dynamic hostname>:9997?BeginString=FIX.4.4&SenderCompID=SYNAPSE&TargetCompID=EXEC"/>
// the endpoint representing the above FIX Session
// where the target host is dynamically defined
// and not hardcoded anywhere in my car application
</send>
On the receiver/listener side as a Proxy Service this works fine, because in the proxy service it lifts the configuration from the supplied initiator config URL parameter, so the failover happens "under the hood" by the FIX engine.
<parameter name="transport.fix.InitiatorConfigURL">quickfix.cfg</parameter>
However it doesn't look like it's possible to do the same when you are sending a message to the target FIX server.
Does anyone have a good suggestion or an example for how to achieve this?
As you are using a normal 'address endpoint' you should also be able to use the normal failover configurations: see https://docs.wso2.com/display/ESB500/Configuring+Failover+Endpoints for info.
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.
I am using WSO2 ESB 4.0.3 with Java 6 on MAC OSX 10.7.4. I have also installed Data Services Features.
In the typical scenario I have one proxy service which the client calls and I pass one the request to Data Service. Now if I have FAULT message from the Data service back to proxy how do I check in proxy service whether the response from Data Service is Fault or normal valid response?
Currently I am using following filter mediator logic in outsequence of proxy service
<filter xpath="get-property('FAULT')">
<then>
<log category="ERROR" level="custom" separator=",">
<property name="OWCHECK-faultMessage" value="TQS_OWCHECK - Received Fault From OWCHECK Data Service !!!!"/>
<property expression="$body" name="Fault-I-Got-Is"/>
<property name="OWCHECK-Forwading-Error" value="TQS_OWCHECK - Forwarding the Fault to Error Handler !!!!"/>
</log>
<else>
<xslt key="conf:/tqs/owcheck/proxy-output-transform.xslt"/>
<log category="INFO" level="custom" separator=",">
<property name="ValidResponse" value="TQS_OWCHECK - Sending Valid Response Back."/>
</log>
<send/>
</else>
</filter>
But this logic of checking the "FAULT" property works when axis2 has NIO senders & receivers in axis2.xml.
How ever if I switch the receivers & senders in axis2.xml from NIO to standard servlet one's (org.wso2.carbon.core.transports.http.HttpTransportListener / org.wso2.carbon.core.transports.http.HttpTransportListener) I do not get the "FAULT" property set and my error handling does not work.
Is there a standard way of checking if the response from one proxy service to another or response from data service to proxy is FAULT or not? I am looking for something which is independent of transport senders and receivers, at least HTTP ones.
Please help.
thanks
Abhijit
It is not good documentation I believe where none of the samples talk about how to handle the faults from Data service to Proxy service or am I missing something?
I would be thankful if I know the best practices to handle the errors from Data service as well as from one proxy to another proxy service.
Please help. This is big project at very prestigious company.
I think you need to check whether the soap body element has a soap:fault message or not. you can use the filter mediator with some xpath expression to check that.
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>