Sometimes you might spend lot of time in analyzing the reason for getting 400 bad request when you invoke an up and running backend service through WSO2 ESB.
When you configure and save the synapse configuration of your proxy, you will not see any issue. But sometimes there can a possible reason for this issue.
One good example is explained below :
Look at the below synapse configuration of WSO2 ESB proxy service.
<proxy name="statuscodeProxy"
transports="https http"
startOnLoad="true"
trace="disable">
<description/>
<target>
<inSequence>
<log level="full"/>
<send>
<endpoint>
<address uri="http://10.100.0.31:8090"/>
</endpoint>
</send>
</inSequence>
<outSequence>
<log level="full"/>
<send/>
</outSequence>
</target>
</proxy>
By the look of it, this is alright and you are good to configure it in WSO2 ESB. But the endpoint defined as : http://10.100.0.31:8090 is not exactly the endpoint the backend service expects.
Sometimes there can be missing parameters etc. But if you exactly know your backend service does not expect any parameters and still it throws a 400 bad reques, can you imagine the reason for this?
After spending hours, I accidently found a possible reason :
it was due to the backend expects a / at the end of the endpoint. So it expects :
http://10.100.0.31:8090/ except http://10.100.0.31:8090
If you configure a tcpmon in between ESB and the backend, you will see the difference as below :
http://10.100.0.31:8090 : GET HTTP/1.1 - 400 bad Request
http://10.100.0.31:8090/ : GET / HTTP/1.1
- 200 OK
So if you too come across this situation, please try out this option. Sometimes this might save your time! :)
Showing posts with label Enterprise Service Bus. Show all posts
Showing posts with label Enterprise Service Bus. Show all posts
Monday, February 16, 2015
Monday, December 1, 2014
WSO2 ESB Script Mediator Using JavaScript with a Json payload
Synapse supports Mediators implemented in a variety of scripting languages such as JavaScript, Groovy, or Ruby. For More information on script mediator please refer this link.
This blog post will explain a scenario of using script mediator with a Json payload.
Configure back-end
==============
1. Deploy this webapp in an appserver.
https://svn.wso2.org/repos/wso2/trunk/commons/qa/qa-artifacts/esb/esb481/JSONscenarios/withScriptMediator/pizzashop-rs_1.0.zip
Configure ESB
=============
2. Provide the following api synapse configuration.
Invoking the service
==============
3. Invoke the service
curl -v "http://localhost:8280/pizzashop/api/menu/pizza/all"
You will get all the available pizza list.
This blog post will explain a scenario of using script mediator with a Json payload.
Configure back-end
==============
1. Deploy this webapp in an appserver.
https://svn.wso2.org/repos/wso2/trunk/commons/qa/qa-artifacts/esb/esb481/JSONscenarios/withScriptMediator/pizzashop-rs_1.0.zip
Configure ESB
=============
2. Provide the following api synapse configuration.
<api name="pizzashop" context="/pizzashop"> <resource methods="GET" uri-template="/api/menu/pizza*"> <inSequence> <send> <endpoint> <http method="get" uri-template="http://localhost:9765/pizzashop-rs_1.0/services/menu/pizza/all"/> </endpoint> </send> </inSequence> <outSequence> <log level="full"/> <script language="js">var payload = mc.getPayloadJSON();mc.setPayloadJSON(payload); </script> <send/> </outSequence> </resource> </api>
Invoking the service
==============
3. Invoke the service
curl -v "http://localhost:8280/pizzashop/api/menu/pizza/all"
You will get all the available pizza list.
Labels:
Enterprise Service Bus,
ESB,
Json payload,
Script Mediator,
WSO2
Friday, July 12, 2013
How to test the disable HTTP chunking for outgoing messaging via WSO2 ESB and a REST request
There are few HTTP transport-specific
properties in ESB.
Properties use in ESB access various
types of information regarding a message that passes through the ESB.
Also properties can be used to control the behavior of the ESB on a
given message.
WSO2 ESB support transfer-encoding –
chunked by default. To make it disabled, there is a property that
would help to perform it.
<property name="DISABLE_CHUNKING" value="true" scope="axis2"/>
Transfer-encoding - chunked is a feature came along with HTTP 1.1. Therefore no matter what HTTP 1.0 will support only content type. Therefore if the message is forced to send as HTTP1.0 you will be able to see only the content type. Refer the previous blog post for more reference. Outgoing message can be seen in here.
By the following steps I will be
explaining how to test this behavior if WSO2 ESB.
Download WSO2 ESB,
http://wso2.com/products/enterprise-service-bus
To Setup :
----------------
- Go to <ESB_Home>/samples/axis2Server/src/SimpleStockQuoteService and build it, ant
- Start the Go to <ESB_Home>/samples/axis2Server and start the axis2Server by the following command, sh axis2server.sh.
- Start the ESB Server, <ESB_Home>/bin by providing, sh wso2server.sh.
- Run a tcpMon to view the outgoing messages.
- Start the tcpmon in the <ESB_Home>/bin - sh tcpmon.shCreate 2 listeners as below.1. Listen Port 8281, Target host – localhost, Target port – 8280 – Before hits the ESB2. Listen Port 9001, Target host – localhost, target port – 9000 – After passing through ESB and Before hits the backend
- Log in to the ESB and provide the following synapse configuration.
<?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://ws.apache.org/ns/synapse"> <sequence name="fault"> <log level="full"> <property name="MESSAGE" value="Executing default "fault" sequence"/> <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/> <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/> </log> <drop/> </sequence> <sequence name="main"> <header name="Action" value="urn:getQuote"/> <filter source="get-property('To')" regex=".*/StockQuote.*"> <property name="DISABLE_CHUNKING" value="true" scope="axis2"/> <send> <endpoint> <address uri="http://localhost:9001/services/SimpleStockQuoteService" format="soap11"/> </endpoint> </send> <drop/> </filter> <send/> </sequence> </definitions>
To Send the Rest request :
---------------------------------------------
- Go to axis2Client, <ESB_Home>/samples/axis2Client and send the following REST request.
ant stockquote -Dtrpurl=http://localhost:8281/services/StockQuote -Drest=true
Labels:
chunking,
Enterprise Service Bus,
ESB,
HTTP 1.1,
HTTP transport properties,
transfer encoding,
WSO2
How to test the Force HTTP 1.0 outgoing messages via WSO2 ESB and a REST request
There are few HTTP transport-specific
properties in ESB.
Properties use in ESB access various
types of information regarding a message that passes through the ESB.
Also properties can be used to control the behavior of the ESB on a
given message.
WSO2 ESB support HTTP 1.1 outgoing
messages by default. To make it HTTP 1.0, there is a property that
would help to perform it.
<property name="FORCE_HTTP_1.0" value="true" scope="axis2"/>
By the following steps I will be
explaining how to test this behavior if WSO2 ESB.
Download WSO2 ESB,
http://wso2.com/products/enterprise-service-bus
To Setup :
----------------
- Go to <ESB_Home>/samples/axis2Server/src/SimpleStockQuoteService and build it, ant
- Start the Go to <ESB_Home>/samples/axis2Server and start the axis2Server by the following command, sh axis2server.sh.
- Start the ESB Server, <ESB_Home>/bin by providing, sh wso2server.sh.
- Run a tcpMon to view the outgoing messages.
- Start the tcpmon in the <ESB_Home>/bin - sh tcpmon.shCreate 2 listeners as below.1. Listen Port 8281, Target host – localhost, Target port – 8280 – Before hits the ESB2. Listen Port 9001, Target host – localhost, target port – 9000 – After passing through ESB and Before hits the backend
- Log in to the ESB and provide the following synapse configuration.
<?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://ws.apache.org/ns/synapse"> <sequence name="fault"> <log level="full"> <property name="MESSAGE" value="Executing default "fault" sequence"/> <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/> <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/> </log> <drop/> </sequence> <sequence name="main"> <header name="Action" value="urn:getQuote"/> <filter source="get-property('To')" regex=".*/StockQuote.*"> <property name="FORCE_HTTP_1.0" value="true" scope="axis2"/> <send> <endpoint> <address uri="http://localhost:9001/services/SimpleStockQuoteService" format="soap11"/> </endpoint> </send> <drop/> </filter> <send/> </sequence> </definitions>
To Send the Rest request :
---------------------------------------------
- Go to axis2Client, <ESB_Home>/samples/axis2Client and send the following REST request.
ant stockquote -Dtrpurl=http://localhost:8281/services/StockQuote -Drest=true
Observations :
-------------------------
- On the server side, Standard :: Stock price = $157.06490695255485 will be generated.
- Observe the tcpMon.
Rest request sent to ESB can be
seen in port 8281,
POST /services/StockQuote HTTP/1.1
Outgoing message from ESB can be
seen in port 9001,
Saturday, June 29, 2013
How to test Multipart/form-data with attachments and json content type pass-through support for WSO2 ESB.
I hope the reader of this blog has got an
idea about WSO2 ESB and the pass-through transport and the different
type of content types support for the product.
For more information read on,
http://wso2.com/products/enterprise-service-bus/
To test Multipart/form data, we need
the below things ready.
- A backend service.
- tcpmon to view the pass through
- A form to submit data
- Attachments – text files, json file, an image
- WSO2 ESB with the correct synapse configuration of the proxy
Backend Service
- As the backend service, I will be setting the offset to 2 and run a WSO2 App Server, which can also be downloaded from http://wso2.com/products/application-server/. I am using 5.1.0.
- I will be using the HelloService in unsecured mode.
- I assume now that I have the HelloService up and runninn in, http://localhost:9765/services/HelloService
Set up tcp mon
1. Start the tcpmon in the
<ESB_Home>/bin - sh tcpmon.sh
2. Create 2 listeners as below.
1. Listen Port 8281, Target host –
localhost, Target port – 8280 – Before hits the ESB/
HelloProxyService proxy
2. Listen Port 9766, target host –
localhost, target port – 9765 – After passing through ESB and
Before hits the backend
A form to submit data
form action="http://localhost:8281/services/HelloProxyService/greet"
<html>
<head><title>multipart/form-data - Client</title></head>
<body>
<form action="http://localhost:8281/services/HelloProxyService/greet" method="POST" enctype="multipart/form-data">
User Name: <input type="text" name="name">
User id: <input type="text" name="id">
User Address: <input type="text" name="add">
AGE: <input type="text" name="age">
<br>
Upload :
<input type="file" name="datafile" size="40" multiple>
</p>
<input type="submit" value="Submit">
</form>
</body>
</html>
Attachments
- As attachments, I have just a text file with some texts in it
- A jpeg image
- A Json file with a json object.
{
"name":"John Johnson",
"street":"Oslo West 555",
"age":33,
"phone":"555 1234567"
}
Synapse configurations
- The below proxy will allow the user to view the data that has been sent.
<Port> = 9766 or a different port you provide
<proxy name="HelloProxyService"
transports="https http"
startOnLoad="true"
trace="disable">
<description/>
<target>
<endpoint>
<address uri="http://localhost:<port>/services/HelloService"/>
</endpoint>
<outSequence>
<property name="OUT_ONLY" value="true"/>
<send/>
</outSequence>
</target>
</proxy>
2. If you want to test whether this form data saved in to a file correctly, you can enable VFS transport in axis2.xml and use the following synapse accordingly. We will be saving it in to a file in the given location.
<proxy name="HelloProxyService"
transports="https http"
startOnLoad="true"
trace="disable">
<description/>
<target>
<endpoint>
<address uri="vfs:file:///home/ushani/Downloads/out"/>
</endpoint>
<inSequence>
<property name="OUT_ONLY" value="true"/>
</inSequence>
<outSequence>
<send/>
</outSequence>
</target>
</proxy>
To Test :
(Listen Port 8281, Target host – localhost, Target port – 8280 – Before hits the ESB/ HelloProxyService proxy)
(Listen Port 9766 or a different port, target host – localhost, target port – 9765 or different port which the backend service is run – After passing through ESB and Before hits the backend)
Labels:
Content Type,
Enterprise Service Bus,
ESB,
Multipart/Data form,
Pass Through,
VFS,
WSO2
Wednesday, April 24, 2013
How to test SOAP Fault Data in WSO2 ESB and JMS message store, a message processor with a reply sequence and a fault sequence
In this post I am not going to explain
about message store or message processor and their behavior. I will
exactly explain how to test SOAP Fault Data in WSO2 ESB and JMS
message store, a message processor with a reply sequence and a fault
sequence.
Before you try out
this sample, it is better to read the following articles and blog
posts to get more information.
- To read more on WSO ESB : http://wso2.com/products/enterprise-service-bus/
- Product Documentation : http://docs.wso2.org/wiki/display/ESB460/Enterprise+Service+Bus+Documentation
- Message Store : http://docs.wso2.org/wiki/display/ESB460/Message+Stores
- JMS Message Stores : http://docs.wso2.org/wiki/display/ESB460/JMS+Message+Store
- Message processor : http://docs.wso2.org/wiki/display/ESB460/Message+Processors
- Mediators : http://docs.wso2.org/wiki/display/ESB460/Mediators
- Samples on Forward Mesaging patterns with Message Stores and processors : http://docs.wso2.org/wiki/display/ESB460/Store+and+Forward+Messaging+Patterns+with+Message+Stores+and+Processors
- Error Codes : http://docs.wso2.org/wiki/display/ESB460/Error+Handling+and+Error+Codes
- Blogs : http://techfeast-hiranya.blogspot.com/2012/01/wso2-esb-tips-tricks-08-message-stores.html and http://maharachchi.blogspot.com/2012/09/now-you-can-send-soapfaults-to-fault.html
- Behaviour : https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbxKydMUlsUcTyFfMyUqeMps2pWqBhVnt-NP6Tn7zWYsQGOv1Wc0kl5-7Ha64B5iaqtYGXP92t1yLGFFTCJrplWNesVJCEkBgxDShrSjd84XwC6eW1HEYu6ptgMzPMFLGcC82Y2C-nisTI/s1600/dlc.png
- Applications and networks can be full of errors, Applications crash. Network routers and links get into states where they cannot pass messages through with the expected efficiency. These error conditions are very likely to cause a fault or trigger a runtime exception in the ESB.
- When applications and networks can be full of errors. Applications crash. Network routers and links get into states where they cannot pass messages through with the expected efficiency. These error conditions are very likely to cause a fault or trigger a runtime exception in the ESB.
- It is not mandatory to associate each sequence and proxy service with a fault sequence. In situations where a fault sequence is not specified explicitly, a default fault sequence will be used to handle errors.
Whenever
an error occurs in WSO2 ESB, the mediation engine attempts to provide
as much information as possible on the error to the user by
initializing the following properties on the erroneous message:
- ERROR_CODE
- ERROR_MESSAGE
- ERROR_DETAIL
- ERROR_EXCEPTION etc
We can configure a message broker to
save the failed requests in a message store for later delivery. When
the client
sends requests to a proxy service , the proxy service stores the
messages to a JMS message store if it cannot be delivered and then
the back-end service is invoked by a message forwarding processor,
which picks stored messages in the JMS message store.
To
test this scenario we need the following:
- Message Broker – I will be using WSO2 Message Broker (MB)
- WSO2 ESB
- WSO2 Application Server to invoke a service – Axis2Service (You can use any other service which will generate an exception)
To configure WSO2 ESB, AS and MB, follow the steps below:
- Follow the steps in the following location. http://docs.wso2.org/wiki/display/ESB460/Configure+with+WSO2+Message+Broker
- Or 1 and 2 steps in http://sandapa.blogspot.com/2013/02/jms-messaging-with-wso2-esb-460-and.html
- Now the ESB and Message broker should be ready.
Configurations :
---------------------------
- Set the offset as 2 in carbon.xml (<AS_HOME/repository/conf>) and start the Application server deploying the Axis2service. Refer the following document. http://docs.wso2.org/wiki/display/AS510/Installation+Guide
- Create a proxy. Provide the following synapse configuration.
<proxy name="FaultTestProxy"
transports="https http"
startOnLoad="true"
trace="disable">
<description/>
<target>
<inSequence>
<log level="full"/>
<property name="target.endpoint" value="AxisEp"/>
<property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/>
<property name="FORCE_ERROR_ON_SOAP_FAULT" value="true"/>
<store messageStore="Queue1"/>
</inSequence>
<outSequence>
<send/>
</outSequence>
<faultSequence>
<log level="full" category="ERROR"/>
</faultSequence>
</target>
</proxy>
6. Set the endpoint as following to invoke Axis2Service. This can be any service which will help to produce an error.
<endpoint name="AxisEp">
<address uri="http://localhost:9765/services/Axis2Service">
<suspendOnFailure>
<errorCodes>-1</errorCodes>
<progressionFactor>1.0</progressionFactor>
</suspendOnFailure>
</address>
</endpoint>
7.
Create
a message store as following.
<messageStore class="org.wso2.carbon.message.store.persistence.jms.JMSMessageStore"
name="Queue1">
<parameter name="java.naming.factory.initial">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="store.jms.cache.connection">false</parameter>
<parameter name="java.naming.provider.url">repository/conf/jndi.properties</parameter>
<parameter name="store.jms.JMSSpecVersion">1.1</parameter>
<parameter name="store.jms.destination">Queue1</parameter>
</messageStore>
8.
Create
a Scheduled Message Forwarding Processor as following.
<messageProcessor class="org.apache.synapse.message.processors.forward.ScheduledMessageForwardingProcessor"
name="MyMsgProc"
messageStore="Queue1">
<parameter name="message.processor.reply.sequence">Axis_Ok</parameter>
<parameter name="max.delivery.attempts">4</parameter>
<parameter name="interval">5000</parameter>
<parameter name="message.processor.fault.sequence">Axis_Fault</parameter>
</messageProcessor>
9.
Following fault
sequence should be configured
<sequence name="Axis_Fault">
<log level="custom" category="ERROR">
<property name="text" value="An error occured"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="ERROR_MESSAGE"
expression="get-property('ERROR_MESSAGE')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="ERROR_CODE"
expression="get-property('ERROR_CODE')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="ERROR_DETAIL"
expression="get-property('ERROR_DETAIL')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="ERROR_EXCEPTION"
expression="get-property('ERROR_EXCEPTION')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="FaultTo"
expression="get-property('FaultTo')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="FAULT"
expression="get-property('FAULT')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="SENDING_FAULT"
expression="get-property('SENDING_FAULT')"/>
<property xmlns:ns="http://org.apache.synapse/xsd" name="REPLY" expression="/"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="RESPONSE"
expression="get-property('RESPONSE ')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="HTTP_SC"
expression="get-property('HTTP_SC')"/>
</log>
<log level="full" category="ERROR"/>
</sequence>
The whole Synapse Configuration would be as follows :
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://ws.apache.org/ns/synapse">
<registry provider="org.wso2.carbon.mediation.registry.WSO2Registry">
<parameter name="cachableDuration">15000</parameter>
</registry>
#######################
# Proxy
#######################
<proxy name="FaultTestProxy"
transports="https http"
startOnLoad="true"
trace="disable">
<description/>
<target>
<inSequence>
<log level="full"/>
<property name="target.endpoint" value="AxisEp"/>
<property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/>
<property name="FORCE_ERROR_ON_SOAP_FAULT" value="true"/>
<store messageStore="Queue1"/>
</inSequence>
<outSequence>
<send/>
</outSequence>
<faultSequence>
<log level="full" category="ERROR"/>
</faultSequence>
</target>
</proxy>
#######################
# Endpoint
#######################
<endpoint name="AxisEp">
<address uri="http://localhost:9765/services/Axis2Service">
<suspendOnFailure>
<errorCodes>-1</errorCodes>
<progressionFactor>1.0</progressionFactor>
</suspendOnFailure>
</address>
</endpoint>
#######################
# Fault Sequence
#######################
<sequence name="Axis_Fault">
<log level="custom" category="ERROR">
<property name="text" value="An error occured"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="ERROR_MESSAGE"
expression="get-property('ERROR_MESSAGE')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="ERROR_CODE"
expression="get-property('ERROR_CODE')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="ERROR_DETAIL"
expression="get-property('ERROR_DETAIL')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="ERROR_EXCEPTION"
expression="get-property('ERROR_EXCEPTION')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="FaultTo"
expression="get-property('FaultTo')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="FAULT"
expression="get-property('FAULT')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="SENDING_FAULT"
expression="get-property('SENDING_FAULT')"/>
<property xmlns:ns="http://org.apache.synapse/xsd" name="REPLY" expression="/"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="RESPONSE"
expression="get-property('RESPONSE ')"/>
<property xmlns:ns="http://org.apache.synapse/xsd"
name="HTTP_SC"
expression="get-property('HTTP_SC')"/>
</log>
<log level="full" category="ERROR"/>
</sequence>
<sequence name="main">
<in>
<log level="full"/>
<filter source="get-property('To')" regex="http://localhost:9000.*">
<send/>
</filter>
</in>
<out>
<send/>
</out>
<description>The main sequence for the message mediation</description>
</sequence>
#######################
# Message Store
#######################
<messageStore class="org.wso2.carbon.message.store.persistence.jms.JMSMessageStore"
name="Queue1">
<parameter name="java.naming.factory.initial">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="store.jms.cache.connection">false</parameter>
<parameter name="java.naming.provider.url">repository/conf/jndi.properties</parameter>
<parameter name="store.jms.JMSSpecVersion">1.1</parameter>
<parameter name="store.jms.destination">Queue1</parameter>
</messageStore>
#######################
# Message Processor
#######################
<messageProcessor class="org.apache.synapse.message.processors.forward.ScheduledMessageForwardingProcessor"
name="MyMsgProc"
messageStore="Queue1">
<parameter name="message.processor.reply.sequence">Axis_Ok</parameter>
<parameter name="max.delivery.attempts">4</parameter>
<parameter name="interval">5000</parameter>
<parameter name="message.processor.fault.sequence">Axis_Fault</parameter>
</messageProcessor>
</definitions>
To Test:
------------
1. Via SOAP create a new SOAP project and provide the following wsdl URL,
http://localhost:8281/services/FaultTestProxy?wsdl
2. Then stop the Axis2Service and send the following request in echoInt method. (We are sending a String value except an int value)
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org">
<soapenv:Header/>
<soapenv:Body>
<ser:echoInt>
<!--Optional:-->
<ser:x>String</ser:x>
</ser:echoInt>
</soapenv:Body>
</soapenv:Envelope>
3. Then the message store will store the message. Then start the Axis2Service. Then the Message Processor will pick the message and try to forward it. Due to the string value, following Error codes will be printed in the ESB Server console.
ERROR - LogMediator text = An error occured, ERROR_MESSAGE = Invalid value "String" for element x, ERROR_CODE = Client, ERROR_DETAIL = , ERROR_EXCEPTION = , FaultTo = , FAULT = TRUE, SENDING_FAULT = null, REPLY = <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><ns:BAMEvent xmlns:ns="http://wso2.org/ns/2010/10/bam" activityID="13320046414250_138"/></soapenv:Header><soapenv:Body><soapenv:Fault xmlns:axis2ns26="http://schemas.xmlsoap.org/soap/envelope/"><faultcode>axis2ns26:Client</faultcode><faultstring>Invalid value "String" for element x</faultstring><detail/></soapenv:Fault></soapenv:Body></soapenv:Envelope>, RESPONSE = null, HTTP_SC = 500
This was done with the great help provided by Charitha Kankanamge. :)
Labels:
Enterprise Service Bus,
ESB,
Fault Sequence,
Message Processor,
Message Store,
SOAP Fault Data,
WSO2
Saturday, March 16, 2013
How to set up a Task scheduler and store messages in a message store using WSO2 ESB (Enterprise Service Bus) and WSO2 MB (Message Broker)
This is a simple scenario which allows
you to create a scheduled task and in the main sequence, which has a
IN and OUT to send the request to the backend service
(SimpleStockQuote Service) and get the response and store it in the
JMS message store which points to the WSO2 Message Broker and process
it inside the ESB message processor.
- SetupFollow the first 3 steps given in the Following blog written By Sandapa Handakumbura.http://sandapa.blogspot.com/2013/02/jms-messaging-with-wso2-esb-460-and.html
a. Prerequisites
b. Step 1 - Configuring MB
c. Step 2 - Configuring ESB
d. Step 3 - Setting up the Backend
For More information : http://docs.wso2.org/wiki/display/ESB460/Configure+with+WSO2+Message+Broker
Now we have a up and running ESB and a Message Broker.
- Create a Message Store
- Login to the ESB using the Mgt Console E.g., URL : https://localhost:9444/carbon/
- Click on the Message Stores under Main → Manage → Service Bus
- Click on Add Message Stores and select Add JMS Message Store to create a JMS message store.
- Provide the mandatory parameter as below. Since we use JMS and as in above steps we have created a message store named Queue1 in jndi properties, we should configure the following as below.- Name - Queue1- Message Store Provider - org.wso2.carbon.message.store.persistence.jms.JMSMessageStore- Initial Context Factory - org.wso2.andes.jndi.PropertiesFileInitialContextFactory- Provider URL - repository/conf/jndi.properties
So the above created Message store
synapse configuration should be as follows:
<messageStore class="org.wso2.carbon.message.store.persistence.jms.JMSMessageStore" name="
Queue1
"> <parameter name="java.naming.factory.initial">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter> <parameter name="store.jms.cache.connection">false</parameter> <parameter name="java.naming.provider.url">repository/conf/jndi.properties</parameter> <parameter name="store.jms.destination">
Queue1
</parameter> <parameter name="store.jms.JMSSpecVersion">1.1</parameter> </messageStore>
- Create the Task Scheduler
- Click on the Scheduled Tasks under Main → Manage → Service Bus
- Click on Add Task to create a task.
-Task Name -TheTask
-Task Group-
synapse.simple.quartz
-Task Implementation -
org.apache.synapse.startup.tasks.MessageInjector
Properties
----------------
-format - Literal -
soap12
-to - Literal -
http://localhost:9000/services/SimpleStockQuoteService
-message - XML -
<ser:getSimpleQuote xmlns:ser="http://services.samples">
<ser:symbol>IBM</ser:symbol>
</ser:getSimpleQuote>
-soapAction - Literal -
urn:getSimpleQuote
Trigger Information of the Task
---------------------------------
--
-Trigger Type - Simple
-Count -1
-Interval (in seconds)* - 10
So the above
created Task synapse configuration should be as follows:
<task name="TheTask"
class="org.apache.synapse.startup.tasks.MessageInjector"
group="synapse.simple.quartz">
<trigger count="1" interval="25"/>
<property name="to"
value="http://localhost:9000/services/SimpleStockQuoteService"/>
<property name="soapAction" value="urn:getSimpleQuote"/>
<property name="format" value="soap12"/>
<property name="message">
<ser:getSimpleQuote xmlns:ser="http://services.samples">
<ser:symbol>IBM</ser:symbol>
</ser:getSimpleQuote>
</property>
</task>
- Create the Sequence:
Main Sequence synapse configurations should be as
follows :
<sequence name="main" trace="enable">
<in>
<log level='full' />
<send/>
</in>
<out>
<log level='full' />
<store messageStore="Queue1"/>
</out>
</sequence>
- Create a Message ProcessorClick on the Message Processors under Main → Manage → Service BusClick on Add Scheduled Message Forwarding Processor to create a processor.
Message Processor synapse configurations should be as
follows :
<messageProcessor class="org.apache.synapse.message.processors.forward.ScheduledMessageForwardingProcessor"
name="MyMsgProc"
messageStore="Queue1">
<parameter name="max.delivery.attempts">4</parameter>
<parameter name="interval">150000</parameter>
</messageProcessor>
You can view the stored messages, just by clicking on the Message Stores → Store Name (Queue1) → Show Envelope to view the particular stored message.
For more information, can refer : http://abeykoon.blogspot.com/2012/12/configuring-wso2-esb-451-with-wso2-mb.html
and
docs.wso2.org/wiki/display/ESB460/Sample+702%3A+Introduction+to+Message+Forwarding+Processor
Labels:
Enterprise Service Bus,
ESB,
JMS,
MB,
Message Broker,
Message Store,
Task Scheduler,
WSO2
Subscribe to:
Posts (Atom)