Tag: mediation debugger

How To Debug WSO2 ESB in Different Tenants

How To Debug WSO2 ESB in Different Tenants

INTRODUCTION

WSO2 Enterprise Service Bus is a lightweight, high performance, and comprehensive ESB. 100% open source, the WSO2 ESB effectively addresses integration standards and supports all integration patterns, enabling interoperability among various heterogeneous systems and business applications.

And now it also contains message mediation debugging support with the release version 5.0.0. In this post I will deploy a simple proxy on WSO2 ESB and debug the message mediation flow.

PREREQUISITES

First we need to have the mediation debugger supported ESB distribution. WSO2 ESB 5.0.0 is the distribution packed with mediation debugger. You can download RC2 pack from here.

And also we need to have a debugger supported Developer Studio ESB Tool. You can follow this article to install the WSO2 Developer Studio ESB Tool 5.0.0

If you have never tried the wso2 mediation debugger before follow previous post to understand the basics to use debugger.

============================================================================

WHAT ARE TENANTS

The goal of multitenancy is to maximize resource sharing by allowing multiple organizations (tenants) to log in and use a single sever/cluster at the same time, in a tenant-isolated manner. That is, each user is given the experience of using his/her own server, rather than a shared environment. Multitenancy ensures optimal performance of the system’s resources such as memory and hardware and also secures each tenant’s personal data.

You can register tenant domains using the Management Console of WSO2 products.

Please follow following two articles to know more about WSO2 tenant architecture and how to use it.

  1. WSO2 Multi tenant Architecture
  2. Managing tenants in WSO2 products

How To Debug Tenants

If you have followed my previous post you know that first we need to start the esb in debug mode. For that we need  to use command -Desb.debug=true. Now we have changed this and you need to use -Desb.debug=$tenantDomain.

So for example if you need to debug the super tenant (It is the default one. If you have no idea about a tenant, that means you are working as super tenant 🙂 ) you can use the command -Desb.debug=super or -Desb.debug=true.

  • Start Debugger in super tenant : -Desb.debug=super

Since the esb server will start in the super tenant mode, the server starting will be suspend till you connect the ESB Tool with server on two ports. So what you need to understand is to connect the server with tool to enable debugging you need to start the server in that specific tenant mode. If you are trying to debug a tenant which is not the super tenant, you may not get the server listening state as it for super tenant. That is because the lazy loading behavior of the wso2 tenants.

[Note-Lazy loading is a design pattern used specifically in cloud deployments to prolong the initialization of an object or artifact until it is requested by a tenant or an internal process.]

Lazy loading of tenants is a feature that is built into all WSO2 products, which ensures that in an environment with multiple tenants, all tenants are not loaded at the time the server starts. Instead, they are loaded only when a request is made to a particular tenant.

So server will start listening to connect with tool when the first request is made for that specific tenant. Lets say you have defined a tenant domain as “foo.com”. You need to start the server as -Desb.debug=foo.com. Server will start normally in the super tenant mode. Then send a request to proxy/inbound/API in the foo.com domain as “http://%5Byour-ip:port%5D/t/foo.com/%5Byour-service%5D”. Then the server will start to listen in the two ports to connect with ESB tool to debug.

  • Start in foo.com tenant domain :-Desb.debug=foo.com

Let’s do a simple scenario to do this. First we need to create a tenant domain. Start esb server and go to configure section in the management console.

esbconfiguretab.png

You will see Multi-tenancy section at the bottom. Click on Add new Tenant.

addnewdomain.png

Configure the required fields. And sign in to esb server using entered username and password.

  • User name  : adminfoo@foo.com
  • Password    : ******       🙂

Then deploy your artifacts to this tenant. And you will get endpoint urls for your tenant domain foo.com.

I have created very basic artifact API to test this scenario.

sampleArtifact.png

To deploy it to foo.com tenant add the started server as a remote server and use tenant credentials.

tenantserver.png

Then add the capp to server and deploy it.

artifacts_deployed.png

Now shutdown the server and start it with command sh wso2server -Desb.debug=foo.com.

serverStarts.png

So the server will start in the super tenant mode. Now send a request to our deployed API in the tenant.

sampleRequest.png

Now you will observe that the server starting to listen on two ports to connect with ESB tool.

serverListens.png

Now connect with server form the ESB tool.

connectWithserverTodebug.png

Then resend/send breakpoints to server.

resendESBBreakpoints.png

And send the request again. ESB will suspend on the breakpoint.

debuggerInvoked.png

What if you do not want to wait to connect the tool when the first request comes. You need to do it in the server start up. Can you do it???

Of course you can. 🙂

What you need to do is disable the Lazy loading of the server and enable the Eager Loading.

How can you do it?

Go to [ESB_HOME]/repository/conf/ and open the carbon xml file. Go to Tenent/LoadingPolicy configuration and comment the LazyLoading policy and uncomment the EagerLoading policy to start all tenants or just foo.com.

 

enableEagerLoading.png

Now the server will suspend and listen on ports to connect with ESB tool debugger at the server startup.

So I now you can debug different tenants too… Happy debugging!!! 🙂

 

 

Advertisements
How to Debug WSO2 ESB Mediation Flow

How to Debug WSO2 ESB Mediation Flow

INTRODUCTION

WSO2 Enterprise Service Bus is a lightweight, high performance, and comprehensive ESB. 100% open source, the WSO2 ESB effectively addresses integration standards and supports all integration patterns, enabling interoperability among various heterogeneous systems and business applications.

And now it also contains message mediation debugging support with the release version 5.0.0. In this post I will deploy a simple proxy on WSO2 ESB and debug the message mediation flow.

PREREQUISITES

First we need to have the mediation debugger supported ESB distribution. WSO2 ESB 5.0.0 is the distribution packed with mediation debugger. You can download latest pack from here.

And also we need to have a debugger supported Developer Studio ESB Tool. You can follow this article to install the WSO2 Developer Studio ESB Tool 4.1.0.

OVERVIEW

Lets create a simple scenario where we have a  client, ESB Server and Service.

ESB Debugger Simple USecase(1)

We can use WSO2 try it tool or SOAP UI to send a request from client side. And as this is just to check the ESB Mediation Debugger functionality we will use WSO2 server inbuilt echo service as our service.

Creating Proxy Service

So first now we have to built a proxy service to WSO2 ESB which will get the client request and do some modifications on the received message and sent it to our echo service and get the response from the echo service and sent it back to client after some modifications.

So start WSO2 Developer Studio ESB Tool and create a proxy service with name “EchoServiceWithName”.

It will simply get the following request from the client.

<login>
<user>
<displayname>Mike</displayname>
</user>
</login>

Modify it to following message before sending it to echo service.

<echoString xmlns:ns1="http://echo.services.core.carbon.wso2.org"><in>Mike</in>
</echoString>

And we will receive a message like below.

<echoStringResponse xmlns:ns="http://echo.services.core.carbon.wso2.org">Mike</ns:echoStringResponse>

 

 

Then we will modify it to following message and send it back to client.

<user>
<message>
<welcome>Welcome</welcome>
<name>Mike</name>
<end>for WSO2 technologies !!!</end>
</message>
</user>

This is done by the following configuration.

<proxy name="EchoServiceWithName" startOnLoad="true" trace="disable" transports="http https" xmlns="http://ws.apache.org/ns/synapse">
<target>
<inSequence>
<log/>
<property expression="/login/user/displayname" name="Name" scope="default" type="STRING"/>
<payloadFactory media-type="xml">
<format>
<ns1:echoString xmlns:ns1="http://echo.services.core.carbon.wso2.org">
<in>$1</in>
</ns1:echoString>
</format>
<args>
<arg evaluator="xml" expression="get-property('Name')"/>
</args>
</payloadFactory>
<send>
<endpoint>
<address trace="disable" uri="http://localhost:8280/services/echo"/>
</endpoint>
</send>
</inSequence>
<outSequence>
<log/>
<property expression="/ns:echoStringResponse" name="EchoName" scope="default" type="STRING" xmlns:ns="http://echo.services.core.carbon.wso2.org"/>
<payloadFactory media-type="xml">
<format>
<user>
<message>
<welcome>Welcome</welcome>
<name>$1</name>
<end>for WSO2 technologies !!!</end>
</message>
</user>
</format>
<args>
<arg evaluator="xml" expression="get-property('EchoName')"/>
</args>
</payloadFactory>
<send/>
</outSequence>
<faultSequence/>
</target>
</proxy>

After creating proxy service with above configuration it should be as follows.

proxyDiagramEditor

Now we are all set to debug. We have all components ready to test out proxy service with debugger.

Starting WSO2 ESB Server with Developer Studio ESB Tool to Debug

There are two ways to start a wso2 esb server.

  • First way is from the terminal we can navigate to server file location bin folder and execute wso2server.sh as follows.startserverterminal
  • Second way is we can start esb server from Developer Studio ESb Tool by adding it from the Servers view.serverTab

 

But to support mediation debugging we need to provide command line arguments as “-Desb.debug=true”.

Then the ESB server will listen on two ports to connect with Developer Studio ESB Mediation Debugger as configured in the [esbserver]/repository/conf/sypanse.properties file.

#configuration for the external debugger channels if server is started in debug mode
synapse.debugger.port.command=9005
synapse.debugger.port.event=9006

Then we have to connect developer studio esb tool with esb server by execution above created debug configuration. We have roughly 1 minute time span to connect, otherwise esb server will stop listening and start the server without connecting with debugger tool.

So we should first build the debug configuration from the WSO2 Developer Studio ESB Tool before starting the ESB Server in the debug mode.

Go to Debug Configurations in the Developer Studio and you will see a type of debug configuration named ESB Mediation Debugger

debugconfigclosemediationdebugger.png

Then double click on ESB Mediation Debugger and you will get configuration dialog as below.

defaultconfig.png

It will contain the default command port and event port as 905 and 9006 with your local host name.

If you want to change the default ports, you should modify both server synapse.properties file and this configuration parameters.

And you can remote debug a server which is running in a different host by modifying the Server host with it’s ip.

Now start the ESB Server in the mediation debug mode with the command “sh wso2server.sh -Desb.debug=true” and click the Debug button when server listing to the ports as bellow.

listining.png

Deploy Created Artifacts in Server

Now we have to deploy the previously created proxy service in ESB Server. For that we can create a CAPP using developer studio.

Capp.png

To deploy it from developer studio we need to have the ESB server in the Servers of developer studio. If you started the ESB server from developer studio you can noe directly add the CAPP. Otherwise add the ESB server by going to Servers view-> Add New Server -> WSO2 -> carbon remote server , and specify the host name as follows.newServer.pngremoteip.png

Now you can add and deploy the capp in the server.

addremoveclose.png
deploy.png
serverdeployment.png

Our use case should work. So go to the ESB Server Management Console and select our proxy service try this service tool.

And send the request message as we discussed above. But we will not get the expected output.

Request.pngresponse

Our response doesn’t contain the name. So lets debug the message flow. Put debug breakpoints by right click on the mediators.

breakpoint.png

And send the request again. ESB Message mediation will stop at the first breakpoint position.

debughitpoint.png

There you can see in the variables table under Synapse Scope Properties “Name” property we defined  is empty. There should be an error of out expression. Oh!! yap, it is wrong the expression should be start with double slashes like this “//login/user/displayname” .

Lets look that do we have more errors. If above expression was correct now we have a the value of property “Name” as Mike. So put the value in the variable table and enter. Now the property  value will be changed to “Mike” in the ESb Server.

mikeedit.png

Lets resume the process. It will stop at send mediator. And we will have the expected message after the payload factory mediator. So we can continue.

Oh then another mistake. The returned message from the Echo service is not what we expected.

returnMessage.png

It contain another element named “return” inside the “echoStringResponse” element. So we need to modify the expression of the  property mediator in the out sequence too. It should be “//ns:echoStringResponse/return”.

Lets again put the property value as “Mike” for the property “EchoName” so that we could check the next steps.

modifyedMessage.png

Now we can see the final message is what we expect. So save the modifications done and redeploy the proxy to the server.

And send the request again. We now get the expected response. Great!!!

You will observe that after we redeploy the proxy ESB didn’t suspended at the breakpoints. That is because when the configuration changed in the ESB Server all breakpoint information will be lost. So if we want to debug it we have to re send the breakpoints. For that you only need to right click on ESB diagram editor and in the context menu you will see command Resend ESb Breakpoints. Thats it.

 

resendclose.png

We will discuss more on other features of WSO2 ESB Mediation Debugger in the next post. Since this covers the how to debug ESB Mediation you can also self observe the other features.

You can try this and report the bugs and suggest improvements from the following link as JIRAs.