I'm testing the beta release of wso2 esb 5.0.0 which has an interesting feature for me, websockets.
I declare de inbound endpoint,like the documentation define (https://docs.wso2.com/display/ESB500/WebSocket+Inbound+Protocol) but i am only be capable of receive empty messages from my client (the connection is done) and i can not be capable to send any message to my cliente.
Have any one try this feature?
Thanks.
PD: this is my ws inbound enpoint
<inboundEndpoint name="testws" onError="errorsq" protocol="ws"
sequence="testwssq" suspend="false">
<parameters>
<parameter name="inbound.ws.port">9091</parameter>
<parameter name="ws.outflow.dispatch.sequence">testbesq</parameter>
<parameter name="ws.outflow.dispatch.fault.sequence">errorsq</parameter>
<parameter name="ws.client.side.broadcast.level">1</parameter>
</parameters>
</inboundEndpoint>
and these are my sequences
<sequence name="testbesq">
<log level="full"/>
</sequence>
<sequence name="testwssq">
<log level="full"/>
<log level="custom">
<property name="request" value="message receive"/>
</log>
</sequence>
Unlike HTTP, which is an application-level protocol, in the WebSocket protocol there is no enough information in an incoming message to process these messages, these messages are either text or binary low-level frames. Because of this, we had to define some custom subprotocol over WebSocket. This will allow both client and server parties to know the content type of frames they communicate.
By default every Inbound endpoint support following Synapse subprotocols.
synapse(contentType='application/json')
synapse(contentType='application/xml')
synapse(contentType='text/xml')
I used Netty WebSocket client and below command to test this. And once client connected(handshake), I put message <Test>message</Test> and I could see the backend response on websocket client side.
java -DsubProtocol="synapse(contentType='application/xml')" -DclientPort=9091 -cp netty-example-4.0.30.Final.jar:lib/*:. io.netty.example.http.websocketx.client.WebSocketClient
Related
Using WSO2EI 6.4.0 with RabbitMQ as inbound transport as described in the documentation RabbitMQ AMQP Transport.
Seems working well, though there's only the "sunny day" scenario covered.
Requiring preserving the message ordering, on exception we cannot just requeue the message back to the queue. If the backend service is not available, I'd like to rollback the message and attempt to process the message later. As far I understood we need to send the nack response.
<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="test_mgs_processing_proxy"
startOnLoad="true"
statistics="disable"
trace="disable"
transports="http,rabbitmq,local">
<target>
<inSequence>
<log level="full">
<property name="step" value="test_mgs_processing_proxy"/>
</log>
<property name="OUT_ONLY" value="true"/>
<!-- simulate an exception has occured -->
<property name="SET_ROLLBACK_ONLY" scope="axis2" value="true"/>
<payloadFactory media-type="xml">
<format>
<step xmlns="">test_mgs_processing_proxy</step>
</format>
<args/>
</payloadFactory>
</inSequence>
</target>
<parameter name="rabbitmq.exchange.name">amq.topic</parameter>
<parameter name="rabbitmq.queue.name">app_a</parameter>
<parameter name="rabbitmq.connection.factory">AMQPConnectionFactory</parameter>
<description/>
</proxy>
Setting FORCE_SC_ACCEPTED makes the message considered as consumed. Even if we set the SET_ROLLBACK_ONLY property, the message stays in the NACK state and is not resent (at least no quickly).
Question - using the RabbitMQ AMQP Transport, is there a way to configure redelivery interval of not-processed messages?
Seems like it is an issue in WSO2 EI 6.4.0. https://github.com/wso2/product-ei/issues/4739
The issue is not there when you use Inbound Endpoints. The issue is there only when you use a Proxy with rabbitmq transport.
I have two proxy services for testing purpose that connects with JIRA using JIRA Connector. First one, accepting "application/json" payload:
<proxy name="PruebaJIRA_01" startOnLoad="true" trace="disable" transports="https http">
<description/>
<target>
<inSequence>
<log level="full"/>
<jira.init>
<username>xxxxxx</username>
<password>xxxxxx</password>
<uri>http://gea-jira.its.ute.com/jiragea</uri>
</jira.init>
<property expression="json-eval($.consulta)" name="query"/>
<jira.searchJira>
<query>{$ctx:query}</query>
</jira.searchJira>
<log level="full"/>
<respond/>
</inSequence>
</target>
</proxy>
The second one, accepting "text/xml" payload:
<proxy name="PruebaJIRA_02" startOnLoad="true" trace="disable" transports="https http">
<description/>
<target>
<inSequence>
<property name="messageType" scope="axis2" value="application/json"/>
<log level="full"/>
<jira.init>
<username>xxxxxx</username>
<password>xxxxxx</password>
<uri>http://gea-jira.its.ute.com/jiragea</uri>
</jira.init>
<property expression="//root/consulta" name="query"/>
<jira.searchJira>
<query>{$ctx:query}</query>
</jira.searchJira>
<log level="full"/>
<respond/>
</inSequence>
</target>
</proxy>
It seems that JIRA connector only accept JSON incoming data, so in the second one I have a "messageType" conversion at the top of the sequence.
Both services run OK, but the question is: Why is the second proxy working if I am using an xpath expression?
I am using wso2 ESB 4.9.0.
Thanks in advance.
ESB receives disparate message formats from different clients and systems, because of this ESB required a canonical message format inside the ESB to do all the message mediation tasks. Because of this the message builder used to convert the incoming messages into a canonical format. The canonical format using inside the ESB is SOAP. So surely your XPATH expression works with the soap message.
MessageType property used to select correct message formatter and the message formatter is used to build the outgoing stream from the proxy.
More Info - demystifying-wso2-esb-pass-through-transport /
Working with Message Builders and Formatters
Iteration mediator works with WSo2 Tryit tool but when the same message is sent through SOAP UI the proxy it does not iterate. My proxy service is very simple it has a xslt mediator and then does the iteration. Do I need to change the content type?
Can you paster your proxy service source code.
Try it tool is a evolving tool, but you should always do your testing from SOAP UI.
This is the sample format :-
<iterate expression="//m0:getQuote/m0:request" preservePayload="true"
attachPath="//m0:getQuote"
xmlns:m0="http://services.samples">
<target>
<sequence>
<send>
<endpoint>
<address
uri="http://localhost:9000/services/SimpleStockQuoteService"/>
</endpoint>
</send>
</sequence>
</target>
Is it possible to enable HTTPS protocol for an API on the WSO2 ESB?
https://localhost:8280/api/mySslApi
You can simply call the HTTPS endpoint of the API and it's enabled by default. Note that HTTPS port is 8243 not 8280.
https://localhost:8243/api/mySslApi
By default it is already enabled that way, if you follow axi2.xml config ,you will find below details,
1.for Http
<transportReceiver name="http" class="org.apache.synapse.transport.passthru.PassThroughHttpListener">
<parameter name="port" locked="false">8280</parameter>
<parameter name="non-blocking" locked="false">true</parameter>
<!--parameter name="bind-address" locked="false">hostname or IP address</parameter-->
<!--parameter name="WSDLEPRPrefix" locked="false">https://apachehost:port/somepath</parameter-->
<parameter name="httpGetProcessor" locked="false">org.wso2.carbon.mediation.transport.handlers.PassThroughNHttpGetProcessor</parameter>
<!--<parameter name="priorityConfigFile" locked="false">location of priority configuration file</parameter>-->
</transportReceiver>
2.for Https
<transportReceiver name="https" class="org.apache.synapse.transport.passthru.PassThroughHttpSSLListener">
<parameter name="port" locked="false">8243</parameter>
<parameter name="non-blocking" locked="false">true</parameter>
<parameter name="HttpsProtocols">TLSv1,TLSv1.1,TLSv1.2</parameter>
Yes, In WSO2 ESB, when we want to secure a REST API, we can simply make it available via HTTPS like bellow.
<resource uri-template="/view/{symbol}" methods="GET" protocol="https">
And let the security handlers validate the credentials.
<handlers>
<handler class="org.wso2.rest.BasicAuthHandler"/>
</handlers>
For detail information : https://docs.wso2.com/display/ESB490/Securing+APIs
We currently support BasicAuth/usernametoken secured endpoints via the publisher..You may need to edit the axis2.xml for "HostnameVerifier" parameter in caseof handshake errors..Check the following link for further details.
http://docs.wso2.org/wiki/display/AM131/Adding+an+API
how to use faultsequence of proxy in esb
i want to use faultsequence when occur a fault in EndPoint. for example i stop service1 using jconsole and want to route message to service2 when call proxy service. but when i call proxy using soapui it show fault this message : The system is attempting to access an inactive service..
<target>
<inSequence >
<send>
<endpoint name="cal" >
<address uri="http://localhost:9763/services/service1/"/>
</endpoint>
</send>
</inSequence>
<faultSequence>
<log level="custom">
<property name="text" value="An unexpected error occured for service"/>
<property name="message" expression="get-property('ERROR_MESSAGE')"/>
</log>
<send>
<endpoint>
<address uri="http://localhost:9763/services/service2/"/>
</endpoint>
</send>
</faultSequence>
please guide me!
When your endpoint 1 is inactive it returns a soap fault and you want it to go to the fault sequence. But at the moment that fault sequence is considered as a response and it is sent to the client (soap ui).
In WSO2 ESB 4.5.0 onwards, there is a new property FORCE_ERROR_ON_SOAP_FAULT added. By setting this property, soap faults will be directed to fault sequence. You can do your next logics when you are in the fault sequence (for example invoking another sequence).
Refer [1] for a sample proxy service.
[1] http://maharachchi.blogspot.com/2012/09/now-you-can-send-soapfaults-to-fault.html
I believe your exact scenario is apart of your main end point if it faild you need to route the message to secondary endpoint.
Correct approach to your implementation is not using the fault sequence right approach is using fail over endpoint. You can find reference document at [1][2].
For sample you can refer "Sample 53: Failover sending among 3 endpoints" [3].
[1].http://wso2.org/project/esb/java/3.0.1/docs/endpoint_guide.html#FoEp
[2].http://docs.wso2.org/wiki/display/ESB403/Failover+Endpoint
[3].http://wso2.org/project/esb/java/3.0.1/docs/samples/endpoint_mediation_samples.html
Thank You,
Dharshana.