Showing posts with label WSO2 ESB. Show all posts
Showing posts with label WSO2 ESB. Show all posts

Tuesday, January 26, 2016

Fail safe Mode in WSO2 ESB / WSO2 API manger

By default WSO2 ESB/APIM servers will start in fail Safe mode by ignoring the failure of artifacts. Server will rename the failed artifact with .back file and move forward with rest of the artifacts. However there are situation where you do not want to deploy the server even a single artifact fails, This is typical situation in micro services concept. 


By disabling the fail safe mode in WSO2 ESB/APIM, it is possible not to deploy all the services even a single artifacts get fails during the deployment.


Add failsafe.mode.enable=false in WSO2_HOME/repository/conf/synapse.properties

Thursday, September 17, 2015

Recursively get the property value in synapse

There are certain situation that you may know only the one property name but there might be some other property



Thursday, April 23, 2015

WSO2 ESB send same request to different Rest services

In this scenario I need to send a post request to two different REST services, I am using REST API configuration of WSO2 ESB First I need to post a request to first service and based on successful posting then need to post this same original request to another service and also But I need to obtain the response from first service and send it to client.However I do not need to obtain the response from second service.

I have illustrate this scenario in the simple flow diagram.



Relevant Synapse configuration.





Tuesday, March 31, 2015

Invoking WSO2 ESB proxy which uses Entitlement Mediator to evaluate a XACML rule in the WSO2 Identity Server in WSO2 Stratos 1.6

In this blog, I am assuming that you have an understanding on XACML Policy Language and use of WSO2 Stratos 1.6





This it the full synapse configuration that has been used in this sample.

Wednesday, February 18, 2015

WSO2 ESB SOAP headers lost

 During the connector and we experience some of the SOAP header information are being dropped by the ESB.

Please find the retrieved SOAP headers from direct API call and ESB call below.

Response from Direct API call
Response from ESB call
   <soap:Header>
      <wsa:Action>RetrieveResponse</wsa:Action>
      <wsa:MessageID>urn:uuid:7607e97e-463e-4fa2-92e9-afb48b90acda</wsa:MessageID>
      <wsa:RelatesTo>urn:uuid:a7ddc645-63fa-471b-8dad-e5a7909e25a2</wsa:RelatesTo>
      <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
      <wsse:Security>
         <wsu:Timestamp wsu:Id="Timestamp-abd7433b-821f-4a23-861e-83ade6857961">
            <wsu:Created>2015-02-17T11:39:37Z</wsu:Created>
            <wsu:Expires>2015-02-17T11:44:37Z</wsu:Expires>
         </wsu:Timestamp>
      </wsse:Security>
   </soap:Header>
<soap:Header>
      <wsse:Security>
         <wsu:Timestamp wsu:Id="Timestamp-ec0a6c73-4633-437a-a555-6482f6a72f5d">
            <wsu:Created>2015-02-17T11:57:44Z</wsu:Created>
            <wsu:Expires>2015-02-17T12:02:44Z</wsu:Expires>
         </wsu:Timestamp>
      </wsse:Security>
   </soap:Header>


We can observe that the API is returning complete set of header information to the ESB in wire log, yet ESB returns only a selected set from it as shown above.

Reason for this issue is WS Addressing headers are removed while sending out. This can be solved by introducing Synapse Property "PRESERVE_WS_ADDRESSING" ( <property name="PRESERVE_WS_ADDRESSING" value="true" scope="default" /> )

Further detail can be found in [1]

Wednesday, December 10, 2014

Remove the payload and send POST request to backend via wso2 esb

There are situations where back-end does not need a payload for POST request. However in wso2 ESB has the payload that mediate before the back-end call. In order to drop the message payload you need to perform two tasks in the wso2 ESB.



Example is given below that demonstrate the use case. 

Tuesday, August 26, 2014

List of "conditional content aware mediators" and "content aware mediators"

I have Listed down set of "conditional content aware mediators" and "content aware mediators"

conditional content aware mediator

fastXSLT
filter
header
log
property
switch

content aware mediators

bean
cache
callout
clone
command
conditional router
dblookup
dbreport
ejb
enrich
event
payloadfactory
script
spring
store
validate
xquery
xslt
iterate


How to log the Content-Type in WSO2 ESB


To identify the Content-Type in the mediation in wso2 esb.
Please refer to configuration given below. I have modified the sample given in the wso2 esb


Tuesday, February 18, 2014

ESB performance benchmark 2014

Competition is unavoidable in this current technology world. Since 2007, WSO2 ESB team is conducting a ESB performance evolution and these evaluations are the hot topics in the current ESB market like a 100m sprint race in Olympi


Feburary 2014, Once again WSO2 ESB has been proofed and bench marked them self as leader in the ESB performance space.


In the performance race, WSO2 has evaluated the speed against number of leading open source ESBs and WSO2 ESB defeats all others like a champion!



Results of the ESB performance round 7.5 can be found in the WSO2 Library.


Monday, November 4, 2013

JMS Correlation ID in WSO2 ESB


You can retrieve original message id from the $header Synapse XPath expression and set it as the JMS_COORELATION_ID property in your message flow. That'll set as the correlation id of the underline JMS message.

<property name="JMS_COORELATION_ID" action="set" scope="axis2" expression="$header/wsa:MessageID" xmlns:wsa="http://www.w3.org/2005/08/addressing"/>

You'll need to define the Xpath appropriately to make sure that it address the both SOAP 1.1 and 1.2 messages.

Or else you can work around it in following method aslo.

1) In the request sequence we grab the message id:
 <property name="msgID" expression="get-property('MessageID')" />
2) In the response sequence we set the correlation id using:
 < roperty name="JMS_COORELATION_ID" expression="get-property('msgID')" scope="axis2" />






Friday, August 9, 2013

JMS Messagen Store and JMS Message Processor Behavior - WSO2 ESB - Part 3

So why did we meet the EVIL in the my last blog post? Why? yes that is the main reason behind this blog series!!

Now we have to take a deep breath before we dive into the WSO2 ESB and see why this has happened!!

If you carefully study the illustration shown in Figure 1, You will understand whats goes wrong ;)
Figure 1
Anyway, let me take some more time to explain little bit further.
Client sends message to Proxy. "Message Store" persist the message in the message store(JMS Queue). "Message Store" does not persist the message as it is in the JMS Queue. it serializes the message and other information into java serialized object and put it into JMS Queue.When "Message Processor" processes the message, it pulls Messages from JMS Queue and deserializes the java serialized object to further process.

So why did we encounter some exception and other problems in issue 1?
When Message Processor Pull the message from JMS Queue and try to deserialize, Deserilzation process fails since the fetched message is not Serialized by Message Store.

So is that possible to put message into Message Stores's "JMS Queue" ?? NO it is not possible!!!


So whats wrong with Issue 2?
Different JMS listener dose not know how to deserialize the message that fetched from JMS Queue(Message Store)!

Conclusion   

Messages that are put into "JMS Queue" by "Message Store" are can be read only by "Message Processor" and "Message Processor" only capable of understanding the messages that are put by "Message Store".





  

Thursday, August 8, 2013

JMS MessagenStore and JMS Message Processor Behavior - WSO2 ESB - Part 2

I believe that you have referred my last post that elaborates simple use case of "Message Store" and "Message Processor" of WSO2 ESB.

There can be several issues occur in Real time or mistakes made by user
Lets take it one by one!

Issue #1 - Real Time

There can be network loss in between Backend and ESB!! Or Backend can be fail in the real world situation. Nevertheless, these situations are handled by several Enterprise Integration Patterns. And also above situation can be over come with use of Message Store and Message processor. That i have already mentioned in my last post.

Issue #2 - User Error

User error is mainly occur due to lack of knowledge on concept of  "Message Store" and "Message Processor" of WSO2 ESB. As I have noticed several time, Users are making two main issues, that i have mentioned below.

Message Insertion manual in JMS Queue  -Figure 1
As figure-1 illustrated, "Message Store" and "Message Processor" are configured to persist the message and send to Backend. However, User or Client is trying to manually add a message into the give JMS Queue!! 

So lets experiment this and see!

Step 1 - Deactivate the Message Processor and Shutdown the Backend.
Step 2 - Go to you Message Broker (I am using ActiveMQ in this scenario) and try to insert message manually.

Click on "Send To" to insert message manually in ActiveMQ - Figure 3
Add your message into Message body and Click on Send in ActiveMQ - Figure 4
As a result of Step 2, you can notice that in the "JMSMessageStore_Queue"  will be having a message that we inserted now!!!  Hmmmm So far so Good!!!!

Step 3 - Start-up the Backend and Reactivate the "Message Processor" in WSO2 ESB and have a look at the Carbon Log!

What ?? something gone wrong!!!!

Step 4 - Send some messages from client and observe what is happening!!

What ??? Nothing is happening!!!! Hmmmm... Until i explain next situation.... keep on thinking.

Note - you will see the error log In WSO2 ESB 4.6.0. Nonetheless, WSO2 4.7.0 does not show any error log until you enable debug log.  However, end of the day nothing will happen!!!

Fetch the message from JMS Queue using JMS Listener  - Figure 2

Other scenario also quite interesting!! As you see in Figure 2, another different JMS Listener is trying to access the persisted message in our JMS Queue.  So what are you going to do with the message that you got from JMS Queue???? Nothing can do!!! 

Why????? So until i write my next blog keep on thinking!!!!!






JMS Message Store and JMS Message Processor Behavior - WSO2 ESB - Part 1

I have seen lot of users of WSO2 ESB misunderstood the usage of "Message Stores" and "Message Processor" of the WSO2 ESB. In this Blog series, I will explain further about "Under the Hood" functionalists of the "Message Stores" and "Message Processor" to clear the doubts and myths behind those.

Lets take a very simple use case that i have illustrated bellow,


End of the day, Client is sending a message to Backend in this scenario. Nevertheless, under the hood we are persisting message in JMS queue using "Message Store" and sending it to backend using "Message Processor". This will make sure, we never loss any transaction even backend is fail.
When backend is up and running "Message Processor" send the persisted messages to Backend.

Lets try this concept using WSO2 ESB and ActiveMQ as a message broker. Please refer [1] to understand how to configure WSO2 ESB and ActiveMQ. 

As a Backend and Client, I am using WSO2 ESB SimpleStockQuoteService and Axis2 Client. Please note that, these are packed with WSO2 ESB by default. You can find more detail in [2].

Please refer to the Synapse configuration that has been given bellow which demonstrates the concept above. 




 Use the ant command as given bellow in order to invoke the proxy from client.

ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/services/MessageReciveProxy -Dmode=placeorder


As result you, can notice in the Backend, there will be transaction has happened. So underneath, our "MessageReciveProxy"  Proxy received the message and persisted in "JMSMessageStore"  Message Store. Thereafter, "SampleMessageForwardingProcessor"  Message Processor took the message from "JMSMessageStore" and send it to Backend for further process.


So far so good! Hmmmm

In my next post I will introduce the evil ;)


Evil Mirror wallpaper from Evil wallpapers


[1]http://docs.wso2.org/wiki/display/ESB470/Configure+with+ActiveMQ
[2]http://docs.wso2.org/wiki/display/ESB470/ESB+Samples+Setup#ESBSamplesSetup-StartingSampleBack-EndServices










Tuesday, July 30, 2013

Retry Configuration for Error Handling in Endpoint


“retryConfig” element in WSO2 ESB facilitates developer to retry the endpoint on failure of known error codes. “retryConfig” has two different extreme flavours known as “disabledErrorCodes”  and “enabledErrorCodes” to enhance user to manage known error codes on endpoint failures.


Lets take an Example based on WSO2 ESB sample 52 [1]




Above image is illustrating a simple use case of demonstrate simple load balancing among a set of endpoints use.

Given Synapse Configuration below meet above mentioned objective.



Nevertheless, system admin or developer might already know about the Error Codes [2] that occurs during the endpoint failure, In order to avoid above circumstance it is possible to use “retryConfig”.

In known Error occurring situation, “disabledErrorCodes” disables the retry only for defined error codes within the configuration. Whereas, “enabledErrorCodes” will enable the retry only for defined error codes. Furthermore, it is not possible to have both keywords at the same time for given endpoint.By default, WSO2 ESB accepts only  the “disabledErrorCodes” keyword in above mentioned situation.



Above Synapse configuration demonstrate the basic usage of “retryConfig”.


Follow the WSO2 ESB sample 52 [1] and configure the axis2servers, As per given Synapse configuration, load balancer won't retry on “server 1”s connection failure and print “COULDN'T SEND THE MESSAGE TO THE SERVER” on client side. Whereas, if “server 2”s connection failure only it will retry the other end points.

[1] http://docs.wso2.org/wiki/display/ESB470/Sample+52%3A+Sessionless+Load+Balancing+Between+3+Endpoints



Monday, July 29, 2013

JSON to XML conversion using WSO2 ESB

I am using WSO2 ESB 4.6.0 version to demonstrate this sample, simple yet powerful.

You do not need to write your own code or relay on other library to convert json to xml. Simple WSO2 esb proxy can do the conversion for you, so we will try that. 

Lets set the requirement is to use a parameter to the methods to control whether to return JSON or XML. 

Given synapse configuration below has the very basic configuration to solve this requirement.


"JsonToXmlApi" rest api has two resource in the "Test" context. "/xml/" resource will covert the incoming json payload into xml format and send that back to client. whereas,  "/json/" resource without converting which will echo back to the client.

You can test this using curl commands that have given below,





Wednesday, July 3, 2013

Mount WSO2 Governance Registry to WSO2 ESB with Read only Mode

As most of you all know, we have a product called WSO2 Governance Registry which is known as GReg to facilitate and cater the right level of structure straight out of the box to support SOA Governance, configuration governance, development process governance, design and run-time governance, life-cycle management, and team collaboration.

So in this example I am going to use our GReg as registry for WSO2 ESB's resources.

Furthermore, the main intention of this demonstration is to showcase "how to configure WSO2 ESB in Read Only/Read Write mode for WSO2 GReg. Following illustration shows the conceptual deployment architecture. Where we have two WSO2 ESB, First is on READ and WRITE mode(Offset 1) and the latter one is with READ only mode(offset 2).




Before dirt our hands!! we have to do some prerequisite tasks!! Yes first of all download the products from wso2 product site.

Well it is not enough, we have to setup underlying storage for WSO2 Greg to Demonstrate this sample. Thus, we will use MYSQL as a database.

So lets take a step ahead and do the work,

Step 1
Create a Database in mysql (Lets say database name as “gregMount”)
CREATE DATABASE gregMount;

Step 2
Grant the permission to the created database.

GRANT ALL ON gregMount.* TO regadmin@localhost IDENTIFIED BY "regadmin"

Alright, We have just finished the very basic step of this example!

Step 3
Well ESB and GReg need the MySql libraries to understand the MySql API. Thus put the MySQL driver into <home>/repository/components/lib/

Step 4
We will step into the Greg configuration Changes! Open up
<home>/repository/conf/datasources/master-datasources.xml

Add a data source that look like following configuration

      <datasource>
            <name>WSO2_CARBON_DB</name>
            <description>The datasource used for registry and user manager</description>
            <jndiConfig>
                <name>jdbc/WSO2CarbonDB</name>
            </jndiConfig>
            <definition type="RDBMS">
                <configuration>
    <url>jdbc:mysql://localhost:3306/gregMount</url>
                    <username>regadmin</username>
                    <password>regadmin</password>
                    <driverClassName>com.mysql.jdbc.Driver</driverClassName>
                    <maxActive>50</maxActive>
                    <maxWait>60000</maxWait>
                    <testOnBorrow>true</testOnBorrow>
                    <validationQuery>SELECT 1</validationQuery>
                    <validationInterval>30000</validationInterval>
                </configuration>
            </definition>
        </datasource>

Step 5
Start the GReg first time with  <home>/bin sh wso2server.sh -Dsetup

Lets step into the WSO2 ESB and do the Read and Write mode configuration!

Step 6
Since we have used WSO2 GReg with default offset, we have to change the offset of the ESB (ReadWrite mode ESB) to <Offset>1</Offset>

In order to do this you have to change the default value of  Offset of  <home>/repository/conf/carbon.xml



Step 7

As mentioned bellow,add DataSource configuration into ESB's <home>/repository/conf/datasources/master-datasources.xml

     <datasource>
            <name>WSO2_CARBON_DB_GREG</name>
            <description>The datasource used for registry and user manager</description>
            <jndiConfig>
                <name>jdbc/WSO2CarbonDB_GREG</name>
            </jndiConfig>
            <definition type="RDBMS">
                <configuration>
                   <url>jdbc:mysql://localhost:3306/gregMount</url>
                    <username>regadmin</username>
                    <password>regadmin</password>
                    <driverClassName>com.mysql.jdbc.Driver</driverClassName>
                    <maxActive>50</maxActive>
                    <maxWait>60000</maxWait>
                    <testOnBorrow>true</testOnBorrow>
                    <validationQuery>SELECT 1</validationQuery>
                    <validationInterval>30000</validationInterval>
                </configuration>
            </definition>
        </datasource>

Step 8
You need to do the following changes in the registry.xml that could be find in <home>/repository/conf/registry.xml.

Adding database configuration.

<dbConfig name="wso2registryRemort"> <dataSource>jdbc/WSO2CarbonDB_GREG</dataSource> </dbConfig>

add remote instance that point to Wso2 Greg
  <remoteInstance url="https://localhost:9443/registry">
        <id>instanceid</id>
        <dbConfig>wso2registryRemort</dbConfig>
        <readOnly>false</readOnly>
        <enableCache>true</enableCache>
        <registryRoot>/</registryRoot>
    </remoteInstance>

Mount the config and governance


  <mount path="/_system/config" overwrite="true">
        <instanceId>instanceid</instanceId>
        <targetPath>/_system/nodes</targetPath>
    </mount>
   <mount path="/_system/governance" overwrite="true">
        <instanceId>instanceid</instanceId>
        <targetPath>/_system/governance</targetPath>
 </mount>



If you notice the remoteInstance configuration carefully, we have configured this ESB as readOnly false mode, it means we can Read and Write to the GReg.

Perfect!!! now we have completed almost everything that is needed for this demonstration. Lets see how to configure the Read only mode ESB in this demonstration.

Step 9
follow the above steps 6 to 8 to the second instance of ESB but make the Offset as <Offset>1</Offset> and Read only mode as True



Now you have the GReg and two ESB to test the Read only Mode

Test cases :- Try to add endpoint using ReadOnly ESB to registry.