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.

Tuesday, May 23, 2017

How Messages are Flow Inside the WSO2 ESB (ESB Story - 3)

WSO2 ESB is an open source middleware application which developed on top of the WSO2 carbon. ESB mainly underlying with Apache Axis2 and synapse.

If you are already ESB user, you know ESB received the message from external client or the user and of various transformation and send back to the separate endpoint or the back end. Then same way ESB, will get the response from endpoint or the backed and forward to the end user with transformation or without transformation. 

In this blog post I am trying to explain how the message flows inside the ESB specifically inside the mediation engine.

Mediation engine logics are written inside the Synapse-Core carbon component. Please find the Git location for checkout the code. I am specifically using ESB 5.0.0 for demonstrate this flow. Please note that ESB 5.0.0 uses synapse-core_2.1.7.wso2v7 version.

Message Flow
Message flow are separated to two main paths. 

1. Request path - In sequence flow
2. Response path - Out sequence flow


Request path - In sequence flow
In Axis2 level having "MessageReceiver" interface. Synapse core having implementation of "MessageReceiver" interface and it was implemented as a "SynapseMessageReceiver". This is the default message receiver which is configured in the Axis2. It will handle the incoming message through the synapse message mediation. 
If the ESB having proxy service, There is another implementation called "ProxyServiceMessageReceiver" do the same aforementioned task only for the proxy services. 

1. Once ESB received request to proxy service it will arrive to "receive" method.
 
org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive()



2. When message comes to the Axis2 level it will create axis2 message context. But mediation engine uses different message context to do the mediation. Because of that, "MessageContextCreatorForAxis2" class will convert into synapse message context in "
org.apache.synapse.core.axis2.MessageContextCreatorForAxis2.getSynapseMessageContext()" method. This method will call via the "ProxyServiceMessageReceiver" class.



3. After create synapse message context, it will forward to the message mediation. Main sequence also considered as a one specific mediator.Therefore it will trigger the "mediate"method in "sequence mediator"class. 



org.apache.synapse.core.axis2.ProxyServiceMessageReceiver





org.apache.synapse.mediators.base.SequenceMediator.mediate()


4. Inside the "mediate" method in "org.apache.synapse.mediators.base.SequenceMediator" class, calls the "org.apache.synapse.mediators.AbstractListMediator.mediate()" method. 


org.apache.synapse.mediators.base.SequenceMediator



org.apache.synapse.mediators.AbstractListMediator

5. Inside the "AbstractListMediator" class will go through the entire mediation flow and verifies the content aware mediators are exists. 

6. Then it trigger the  "org.apache.synapse.endpoints.send()" method to send request to the endpoint.

7. Now it will be trigger the "org.apache.synapse.core.axis2.Axis2SynapseEnvironment.send()" method to send it from the the axis2 level.


8. After that it will send to "sendOn" method in "org.apache.synapse.core.axis2.Axis2Sender" class. Here, it will retrieve all handlers associate with that.

 9. After above task, "org.apache.synapse.core.axis2.Axis2Sender.sendOn()" method will be called. this is the class send message out from the ESB engine. 


10. Finally It will be send to the "org.apache.synapse.core.axis2.Axis2FlexibleMEPClient.send()" method.





Response path - Out sequence flow
 
11. Once message received from the endpoint, It will arrive to the "org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive()" Method. 




12.Here, It reads all the information from the Message context and move forward to the "org.apache.synapse.mediators.base.SequenceMediator.mediate()" method as explained in aforementioned 3rd point. Out sequece also working as same way which is works in workflow.

13. After above, It will move to the "AbstractListMediator" as in above 4th point and then it will trigger the "org.apache.axis2.engine.AxisEngine.receive()" method.



I hope this will give you the brief idea how the message mediation happen inside the WSO2 ESB.






Friday, May 19, 2017

How to view Admin Services given WSO2 product

WSO2 products are uses SOAP services to communicate internally in-between UI and the back end. Sometime you may want to do direct invocation on particular admin service to do several task.

As a example if you want to add new users without using admin service, It can be achived by invoking the UserManagementAdminServie. Likewise you can use inbuilt admin services to do such kind of operations.

Some people does not know what are the admin services available in running WSO2 instance. Please find the easiest way to find the admin services and it's endpoints.

I am using WSO2 API Manager.

1. Please download WSO2 API Manager from above location.
2. Start API Manager with following property.
    Ex : wso2server.sh -DosgiConsole 

You will notice server is starting as below

Chamaras-MacBook-Pro:wso2am-2.0.0 chamara$ ./bin/wso2server.sh -DosgiConsole
JAVA_HOME environment variable is set to /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
CARBON_HOME environment variable is set to /Users/chamara/wso2/products/apim/wso2am-2.0.0
Using Java memory options: -Xms256m -Xmx1024m
OSGi console has been enabled with options: -console



3. By pressing "Enter" in terminal (after start server) you will landed to the OSGI console.


4. Now add below command and it will show all the admin services available in server.
"listAdminServices"








Tuesday, February 28, 2017

How to operate P2 repositories through the admin service

Even the WSO2 product comes with the default set of features, Anybody can install additional features based on their requirements. During the product release, WSO2 release feature repository aligns with the product release. It contains all the features can be installed in each product. Feature repository we called as a P2 repository and it's hosted on location again the to the product release version.

P2 repository can be installed via the "features" menu in each product UI console.

But some users may want to automate this process without logging to the management console UI. Following are the way It's can automate.

WSO2 product having set of admin services (SOAP service) which id do various operations.  For the P2 repository operations, there is an admin service called "RepositoryAdminService" and it's having all the operation which are doing through the admin console UI. you can call these admin service operation from the external client (soap client or java client) according to your requirement.
Please find the sample way to call these operations. In here I am using SOAP UI tool to call admin service operations.

1. Open PRODUCT_HOME/repository/conf/carbon.xml

2. Find proipertuy and change the value to false. 

ex :  false

In this way you can see the all admin service WSDL's from the browser.



 3. Start WSO2 prodcut with "-DosgiConsole" option.

ex :  Chamaras-MacBook-Pro:wso2greg-5.2.0 chamara$ ./bin/wso2server.sh -DosgiConsole

 4. Once server start, press enter button and it will direct you to the osgi console. Then type "listAdminServices" command. It will list down all admin services available in the product.


5. In here you will find the repository management admin service.

ex: https://10.100.1.36:9443/services/RepositoryAdminService

6. you can see the RepositoryAdminService wsdl with below URL.

"https://10.100.1.36:9443/services/RepositoryAdminService?wsdl"

7. Import above wsdl url  as a SOAP UI project.


















8. Now you can call admin service operation based on the requires functionality. 

Add Repository




Delete Repository


Enable Repository

Disable Repository



Update existing repository
This way you can do the repository operations from the outside.