Tuesday, December 19, 2017

How to change the super admin password in WSO2 products

If you want to change the existing super admin credentials in any WSO2 product, without login to the server, you can use the chpasswd scripts provided in the pack.

Super admin credentials are saved in the default user store configured in user-mgt.xml. If the default primary user store uses JDBC database (by default it's H2) by running above script will change the stored admin credentials in the database.

Please find the sample command to execute change super admin credentials.

First go into the PRODUCT_HOME directory (ex :  /Users/chamara/wso2/products/esb/wso2esb-4.8.1/)

Then run below command. Here, I am having default H2 database as a primary JDBC user store.


./chpasswd.sh --db-url "jdbc:h2:PRODUCT_HOME/repository/database/WSO2CARBON_DB" --db-driver org.h2.Driver --db-username DB_USERNAME --db-password DB_PASSWORD --username admin --new-password NEW_PASSWORD


./chpasswd.sh --db-url "jdbc:h2:/Users/chamara/wso2/products/esb/wso2esb-4.8.1/repository/database/WSO2CARBON_DB" --db-driver org.h2.Driver --db-username wso2carbon --db-password wso2carbon --username admin --new-password admin123

Monday, September 11, 2017

How to enable Message Tracing in WSO2 ESB 4.9.0

Message tracing feature is useful feature when it come to monitoring messages which are going through the ESB. In WSO2 ESB 4.8.1 or earlier version it's already available by default. But ESB 4.9.0 message tracing feature not enabled by default.
In following way you can enable the message tracing feature into ESB 4.9.0.

  • Download required jars and configuration files from here.
  • Extract "message-trace.zip".
  • Copy below jar files from "message-trace" directory to ESB4.9.0/repository/components/dropins/ directory.
           a. org.wso2.carbon.analytics.message.tracer.handler1.0.2.jar
           b. org.wso2.carbon.analytics.message.tracer.handler.stub1.0.2.jar
           c. org.wso2.carbon.analytics.message.tracer.handler.ui1.0.2.jar

  •  Copy messagetracerconfig.xml from from "message-trace" directory to ESB4.9.0/repository/conf/etc/ directory.
  • Finally restart server.
You will see "Message Tracing" feature enable under "Configuration" tab in ESB 4.9.0

Thursday, August 10, 2017

4 Common mistakes are doing in customer support

In day to day customer support operations we win the customers and sometime we lose them due to the various reasons. According to my experience, I would like to note, what are the common mistakes we do for lost the customers.

"Not a listener"

 Listing is the major fact, when it comes to the effective customer support. The human brain can listen 500 - 550 words per minute. But can talk only 200 - 250 words. That mean brain always set to listen more than the talking. But most of the customer support engineers tend to talk to the customer what they know rather than listening to the customer. Sometime they talk much to defend the problems rather than solving it.

"Not understanding customer" 

Did you understand your customer always before solving their problems? Most of the time answer is "No".  When you talk or solving customer problems, It is vital understand real situation of the customer, need to feel the pain of the customer. This we call as "Empathy". It always easy for you to drive you to the perfect solution.

"Stupid customer mindset"

Some customer support engineers think like"this customer doesn't know anything !!" , "customer always wrong !!". This is a dangerous attitude for support engineer as well as the organization. Because Customer always tried something and come up with some experience. They get into the problem after doing something with your product or the service. because of that, If you think like above your customer, It always drive you into the wrong answer or the incorrect solution. Bad impact is, It may ended up with frustrating your customer.

"Thinking customers are depending on you" 

This attitude always presents you as an impolite person in front of the customer. If you are working with traditional customer service and if customer frustrate because of above reason, they will tell their 500 friends about you. It will lose only 500 potential customers. But if yo working with internet world they will tell you 5 million people. It can be effect to completely close your business.Customers always have many alternatives. Because they are not always depends on you. You depend on them.

Wednesday, May 31, 2017

Understanding WSO2 ESB timeout configurations (ESB Story - 2)

When the message flowing through the ESB, It's having two main paths.
  • Message In sequence low (Client connection)
  • Message out sequence flow(back-end connection)

Aforementioned both flows having multiple timeout configurations and these configurations help to manage the connections properly in several situations. It is worth of know understand what are those timeout values and how it correctly configure to get reliable throughout form the WSO2 ESB.

To explain this story I am talking sample proxy service and how it going through the WSO2 ESB.

As I explained in my previous blog post (How WSO2 Enterprise Service Bus Works (ESB Story - 1), When the client application or the external client invoke the proxy service, That request message arrive to the Transport layer. From this point ESB engaged with four main point which are handle the connections.
  • Message listener (Http Listener)
  • Message Sender (Http Sender)
  • Endpoint timeout config
  • Global timeout config
[Please refer below diagram]

Message Listner/Sender Timeouts

When client sending message to the ESB Passthrough transport creating a connection. Same way another connection will be created from ESB to backend to sent request to the back end server. Timing out of either connection will be happen based on the the "http.socket.timeout" set in the passthru-http.properties file located at /repository/conf directory.

ex : http.socket.timeout=180000

Let say, client sent the request to the ESB and ESB sent again same to the backend. In that case back end talking long time to respond back. In such a case you will see source handler (which is in the request side) will get timeout as below. But it is expected to timeout ESB to backend connection (TargetHandler).

WARN {org.apache.synapse.transport.passthru.SourceHandler} - Connection time out after request is read: http-incoming-33855 {org.apache.synapse.transport.passthru.SourceHandler} 

Problem here is, both connection uses same timeout configuration. Once message received to the ESB from the external client SourceHandler timeout value will start counting and then message goest to the target handler. then only TargetHandler time out counter start. IIn such a case source handler will be timed out before TargetHandler timeout becase both are uses same timeout value. But the actual timeout value happens in the Targethandler side. This is most important situation when you are tracing down the timeout issues in ESB.

[Please refer previous blog post "How Messages are Flow Inside the WSO2 ESB (ESB Story - 3)" to understand SourceHandler and TargetHandler]

Endpoint timeout config

When the proxy service or the sequence having multiple endpoints, each endpoint can be set to separate timeout values. Once the timeout is reached, esb can trigger the fault sequence as a response action.Timeout value can be set as a "duration" parameter and fault sequence can be configure the "responseAction" parameter in endpoint configurations.

Tip :  Endpoint timeout value always need to be set to smaller value than the "http.socket.timeout" value configured in "passthru-http.properties" file

Global timeout config

Synapse which is the underlying mediation engine of WSO2 ESB is a complete asynchronous messaging engine which does not block its worker threads on network io. Instead of waiting the threads for responses, it registers a Calllback for a particular request and return. When the response is received, the registered callback is used to correlate it with the request and do the further processing. If the back end server not respond back, it is required to clear the registered Callbacks after sometime preventing possible memory leaks. It is done by a timer task called TimeoutHandler. ‘synapse.global_timeout_interval’ parameter represents the time duration which a Callback should be kept in the Callback store. If we have configured a timeout duration at the endpoint level, this global timeout value is not taken into consideration for that particular endpoint. For all the other endpoints which doesn’t have a timeout configuration, this global parameter value is considered as the timeout duration.

synapse.global_timeout_interval can be configured from the synapse.properties file. synapse.properties file is located at /repository/conf directory. Default value is 120 seconds.

Thursday, May 25, 2017

How WSO2 Enterprise Service Bus Works (ESB Story - 1)

WSO2 ESB is an open source integration solution which is built from the WSO2 CARBON platform. ESB is capable of supporting various transport types and do various kinds of message mediation according to the use case.
WSO2 ESB consist of set of major components which are allocated to specialized operation. Those are,
  • Transports layer

  • Message Builder/Formatter Layer

  • QOS Layer

  •  Mediation Engine

When a message sent to the ESB, ESB always uses SOAP message inside the ESB. Because of that, whatever the message come to the ESB, It will transport to the SOAP message. Below are the high-level way which message going through the ESB.
  • First, It is going through the transport layer which is handle the incoming transport.
  • Then It will move to the message builder engine to build the message.
  • There after, It will move to the QOS layer to do the QOS tasks to the message.
  • Then message will arrive to the mediation engine to do the specified inflow (in-sequence) mediation.
  • Finally, Message will sent out to the specified endpoint from the mediation engine.
Above message path we called as a "Request Path" and "Response Path" will be as follow.

  • Once response received from the endpoint, It will arrive to the mediation engine again and it will again do the mediation task which are configured in ESB out sequence.
  • After the mediation task done, Message will move to the QOS later again to the message to do the QOS again. 
  • There after, It will move to the message formatter to format the message again which are equal to the incoming message.
  • Finally it will move to the transport layer again and convert SOAP to specified transport which message was had in in-comming message.

This will give you a very basic idea how message go inside the ESB. But I will provide another post about detail explanation how above each layer works and what happen to the message which it is going though the each and every layer.