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 you will no longer will enable the debugging by using parameter true.

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 need to use the command -Desb.debug=super.

  • 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!!!🙂

 

 

WSO2 Data Mapper Common Type Operators

WSO2 Data Mapper Common Type Operators

INTRODUCTION

WSO2 data mapper is a data mapping solution that convert and transform one format of data to a different format. It provides a WSO2 Developer Studio based tool to create the graphical mapping configuration and generate the files needed to execute the mapping configuration by the WSO2 Data mapper engine.

If you first came to here look for the two previous posts which will give you the basic understanding of WSO2 Data Mapper and how to integrate it with WSO2 ESB.

  1. How to Use WSO2 Data Mapping Mediator in ESB (Updated for-ESB-5.0.0-Beta2)
  2. Understanding WSO2 Data Mapper 5.0.0

OVERVIEW

This post is one of many to introduce data mapper operations available and how to use it in mapping configuration. There are mainly six categories in the operator pallet as shown in the following diagram.

diagramEditor

They are,

  • Links
  • Common
  • Arithmetic
  • Conditional
  • Boolean
  • Type Conversion
  • String

In this post we will discuss about Common Operators, given in data mapper.

Constant Constant- define string, number or boolean constant values.

This operator is basically to define values we need to use in mapping. When you drag and drop the constant operator from the pallet to editor area you will get it as following diagram.

constantdefault

As you can see it only has a output connector. And that value can be a Number, String or Boolean. To configure it right click on constant operator and click the configure constant operator menu action. It will pop up a dialog box to configure the operator as follows.

configuremenuconstant.png

So you can define the value you need in here.

CustomFunction Custom Function – define custom function to use in mapping

Custom function is for more advanced users who need more functionality other than offered in the data mapper. And if you know Java Script well you could do many things by using custom functions with global variable operator. But here I will only describe the basic features and how to use this operator to define our own functionality.

When you drag and drop custom function operator for editor you will get the following default operator and the configuration.

defaultcustomfunctionconfiguratoncustomfunction

You should first give a name to your function in the Function Name text box. You can not use same name to two functions in the same mapping.

Then define the number of parameters/inputs you need in the Number of Inputs text box.

Then you need to define the parameters inside the function definition () according to the number of inputs you specified above. Use those parameters or any Global Variable value inside the custom function to do the functionality and return the value.

Properties Properties – use product specific runtime variables

This operator is discussed in great detail in the following post by Eranda.

GlobalVariable Global Variable – instantiate global variable to access from any where

Global variable operator is given to instantiate a variable and use in any where in the mapping. When you drag and drop the operator to editor you will see following default operator and the configuration.

GVoperatorGVconfiguration

This is basically a JavaScript variable defined in the outer scope so that any one can see and access it. You could use this variable in any custom function you define in the mapping. In the configuration you can change the name and default value of it.

Compare Compare – compare two inputs in the mapping

This operator can be used to compare any two values in the mapping. There are 8 different compare operations you could do. They are,

  • equal value (two inputs are equal or not)
  • equal value type (two inputs are equal in both value and type)
  • not equal value (two inputs are not equal or not)
  • not equal value type (two inputs are not equal in both value and type)
  • greater than
  • greater than or equal
  • lower than
  • lower than or equal

compareOperatorcompareconfiguration

 

 

Understanding WSO2 Data Mapper 5.0.0

Understanding WSO2 Data Mapper 5.0.0

INTRODUCTION

WSO2 data mapper is a data mapping solution that convert and transform one format of data to a different format. It provides a WSO2 Developer Studio based tool to create the graphical mapping configuration and generate the files needed to execute the mapping configuration by the WSO2 Data mapper engine.

This is the second of WSO2 Data Mapper posts which will explain about WSO2 Data Mapper from the user perspective. First post was to describe the end to end work flow on how to create, deploy and test data mapper configuration.(How to Use WSO2 Data Mapping Mediator in ESB)

COMPONENTS OF WSO2 DATA MAPPER

Before we going into look the operations lets look how things happen under the hood. WSO2 Data Mapper comes as two components ideally. They are Data Mapper Engine and Data Mapper Tooling component.

Data Mapper Tooling component

Data Mapper Tooling component is the interface to user to create configuration files needed for engine to execute the mapping. There are three configuration files needed by the Data Mapper engine. They are,

  1. Input schema file
  2. Output schema file
  3. Mapping configuration file

Input schema and output schema defines the input/output format of input message and required message. It is basically  a custom defined json schema. It will be generated by the Data Mapper tool for you when loading the input and output files.

inputType

As above image shows user can load input/output message format in several different ways. They are,

  • XML – Sample XML file
  • JSON- Sample JSON file
  • CSV  – Sample CSV file with column names as the first record
  • XSD  – XSD file which is actually schema for XML files
  • JSONSCHEMA – WSO2 data mapper json schema
  • CONNECTOR

I guess only CONNECTOR option is the confusing part for you. It is to use data mapper with connectors straightly. WSO2 connectors will contain json schemas for each operations which will define the message formats both it will respond and expect. So when user integrate connectors in a project this connector option will search through the workspace and find the available connectors. Then user can select the respective connector and the operation so that related json schema will be loaded for data mapper by the tool.

Mapping configuration file is simply a Java Script file generated looking at the diagram user will draw in the data mapper diagram editor by connecting input elements to output elements. Every operation user defines in diagram will convert to Java Script operation.

So these three files will be generated by the Data Mapper Tool and saved in a Registry Resource project to deploy in a wso2 server.

regresource.png

“.datamapper” and “.datamapper_diagram” files contain meta data related to Data Mapper Diagram. They will be ignored when trying to deploy in a server to use by data mapper engine. Only two schema files and .dmc (data mapper configuration) file will be deploy.

Need an Intermediate Component to Use With WSO2 Products

WSO2 Data Mapper is an independent component. It is not depending on any other WSO2 product. But other products can use data mapper to achieve/offer data mapping capability. For that we need a intermediate component. Data Mapper Mediator is this intermediate component which  will give the data mapping capability into WSO2 ESB.

DMMediator.png

Data Mapper Mediator will find the configuration files from the registry and configure data mapper engine with the input message type(XML/JSON/CSV) and output message type(XML/JSON/CSV) . Then it will take request message from ESB message flow and use configured data mapper engine to execute the transformation and output message will be added to ESB message flow.

Can Use Product Specific Runtime Variables

Data Mapper engine also given a way to use run time product specific variables in the mapping. The way it works is, intermediate component should construct a map object containing run time product specific variables and send it to  data mapper engine. So when the mapping happens in the data mapper engine, these variables will be available. For Eg: Data Mapper Mediator provides esb axis2/transport/synapse/axis2client/operation/.. properties like this. In the Data Mapper diagram user can use the Property operator and define the scope and the property name and use it in the mapping. Data Mapper Mediator will identify the required properties to execute the mapping and populate a map with the required properties and will send it to engine. We will look it with more detail when we discuss about Property Operator.

Data Mapper Engine

Data Mapper engine need basically following information to be configured,

  • Input Message Type
  • Output Message Type
  • Input schema
  • Output schema
  • Mapping configuration

At the runtime it will get the input message and runtime variable map object and output the transformed message. To execute the mapping configuration data mapper engine use java scripting api. So if your runtime is JAVA 7 rhino JS engine will be used and if your runtime is JAVA 8 nashorn JS engine will be used.

There are several limitations in the rhino engine that will directly affect data mapper engine when JAVA 7 is used. There are several functions that will not support in rhino,

for eg: String object functions like startsWith() endsWith()

So user may need to aware of that when using custom functions and operators, rhino may have limitations executing those.

OPERATIONS IN WSO2 DATA MAPPER

Let’s look into the operations we could use to do the mapping. Following diagram shows the WSO2 Data Mapping Diagram Editor.

diagramEditor.png

As you can see in the left side we have the operations pallet. These operations can be drag and drop to the Editor area.

There are six categories listed down

  • Links
  • Common
  • Arithmetic
  • Conditional
  • Boolean
  • Type Conversion
  • String

LINKS

DataMapperLink.gif Data Mapping Link- map elements with other operators and elements.

COMMON

Constant Constant- define string, number or boolean constant values.

CustomFunction Custom Function – define custom function to use in mapping

Properties Properties – use product specific runtime variables

GlobalVariable Global Variable – instantiate global variable to access from any where

Compare Compare – compare two inputs in the mapping

ARITHMETIC

Add Add – add two numbers

Subtract Subtract – subtract two or more numbers

Multiply Multiply – multiply two or more numbers

Divide Divide –  divide two numbers

Celi Ceiling – get the ceiling value of a number (closest larger integer value)

Floor Floor – get the floor value of a number (closest lower integer value)

Round Round – get the nearest integer value

SetPrecision Set Precision – Format a number into a specified length

AbsoluteValue Absolute Value – get the absolute value of a rational number

Min Min – get the minimum number from given inputs

Max Max – get the maximum number from given inputs

CONDITIONAL

IfElse IfElse – use a condition and select one input from two

BOOLEAN

AND AND – boolean AND operation on inputs

OR OR – boolean OR operation on inputs

NOT NOT – boolean NOT operation

TYPE CONVERSION

StringToNumber StringToNumber – convert string value to number (“0” -> 0)

StringToBoolean StringToBoolean – convert string value to boolean(“true” -> true)

ToString ToString – convert number or boolean to string

STRING

Concat Concat – concat two or more strings

Split Split – split a string by a matching string value

UpperCase Uppercase – convert a string to uppercase letters

LowerCase Lowercase – convert a string to lowercase letters

StringLength String Length – get the length of the string

StartsWith StratsWith – check whether string starts with a specific value (JAVA7)

EndsWith EndsWith – check whether string ends with a specific value (JAVA7)

Substring Substring – extract a part of the string value

Trim Trim – remove white spaces from beginning and end of a string

Replace Replace – replace the first occurrence of a target string with other

Match Match – check whether the input match with a (JS)regular expression

We will discuss more on some of the operations in the next post.

 

How to Use WSO2 Data Mapping Mediator in ESB (Updated for-ESB-5.0.0-Beta2)

How to Use WSO2 Data Mapping Mediator in ESB (Updated for-ESB-5.0.0-Beta2)

INTRODUCTION

WSO2 data mapper is a data mapping solution that convert and transform one format of data to a different format. It provides a WSO2 Developer Studio based tool to create the graphical mapping configuration and generate the files needed to execute the mapping configuration by the WSO2 Data mapper engine as shown in the below diagrams. As the this is really useful feature in message mediation, WSO2 ESB comes with a data mapper mediator which can be integrate into a mediation sequence since WSO2 ESB 5.0.0.

PREREQUISITES

First we need to have the data mapper mediator supported ESB distribution. WSO2 ESB 5.0.0 is the distribution packed with data mapper mediator. You can download beta2 pack from here.

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

For this post I will use 5.0.0-beta2 packs of wso2 esb runtime and tooling, which are the latest packs. So the operations mentioned here will be only available with 5.0.0 beta2 or onwards.

We will use the Postman as out client to send the requests to esb and receive responses.

OVERVIEW

Since our main focus is to check the functionality of the Data Mapper we will use a very simple configuration in the esb with a data mapping mediator and a respond mediator. We will check following message conversions,

  • XML->XML/JSON/CSV
  • JSON->XML/JSON/CSV
  • CSV->XML/JSON/CSV

To understand the data mapper further and to examine the operators provided in the data mapper, which we can use to map elements from input to output look in to Understanding WSO2 Data Mapper post.

CREATE ESB CONFIGURATION PROJECT

First this we would need to do is create esb configuration to contain the data mapper mediator. ESB Tooling now provides a new option to create a ESB Solution Project so that you can define the all different projects you need for the project in the wizard. Right click on the Project Explorer area and go to new-> ESB Solution Project

ESBSolutionProject

You will get the following wizard page and give project name and unpick the Connector Exporter Project since we are not going to need connector in our configuration.

ESBSolutionProjectWizard

And you will get the following project files created in your workspace.

ProjectExplorer

Now what we will do is create a new REST Api project in ESB and configure it to listen for POST requests on url “/convertMenu”.

RESTAPIfoodMenuAPI

Then create the API resource with data mapper mediator and listening to POST request.

createAPIAndDataMapperapiPropertiesTable

To configure data mapping mediator double click on the mediator and you will get a dialog box asking to create a registry resource project as below.

createMappingFiles

This name would be the prefix for the configuration files we will deploy in esb server related to data mapper. Since we created a ESB Solution Project we were directly pointed that project in here otherwise go to Create new project link and create a new Registry Resource project.

Then click OK after giving the prefix and pointing the Registry resource project to save it.  Following diagram editor will appeared in new perspective named “WSO2 Data Mapper Graphical”. You can switch this perspective as you wish by selecting in top tool bar tags or Window->perspective->Open Perspective->Other

dataMappingEditor

In the left hand side you can see the operation pallet and in the middle input output boxes. We need to provide the input and output message formats to begin the mapping. So right click on the top title bar of the input box and select command Load Input.

loadInputinputType

As you can see in the above image, there are several options for you to load the input and output message formats to data mapper.

You can select the resource type as XML, JSON, CSV ,XSD ,JSONSCHEMA or CONNECTOR.

If you selects XML, you can load a sample xml message you expect and WSO2 Data Mapper Editor will generate the JSON schema to represent the xml according to the WSO2 Data Mapper Schema specification.

Same as for XML, if you select  JSON/CSV as resource type you can load a sample JSON/CSV message. For CSV you need to provide the column names as the first record.

If you have a xsd schema which defines you xml message format, you can select the resource type as XSD and load the xsd file.

And also if you have the JSON schema for your message according to the WSO2 Data Mapper schema specification you can load it by selecting resource type as JSON schema.

Connector type will come if you are going to map message which is an output of a connector, in the input box you can select connector type and it will list down available connectors and then select the operation in-front of data mapper. This is not the time to explain the connector integration with data mapper. We will discuss it later in a different post.🙂

For this moment we will load from a sample XML file.

Input xml sample for food menu.

<?xml version="1.0" encoding="UTF-8"?>
<breakfast_menu>
<food>
<name>Belgian Waffles</name>
<price>$5.95</price>
<description>Two of our famous Belgian Waffles with plenty of real maple syrup</description>
<calories>650</calories>
<orgin>Belgian</orgin>
<veg>true</veg>
</food>
<food>
<name>Strawberry Belgian Waffles</name>
<price>$7.95</price>
<description>Light Belgian waffles covered with strawberries and whipped cream</description>
<calories>900</calories>
<orgin>Belgian</orgin>
<veg>true</veg>
</food>
<food>
<name>Berry-Berry Belgian Waffles</name>
<price>$8.95</price>
<description>Light Belgian waffles covered with an assortment of fresh berries and whipped cream</description>
<calories>900</calories>
<orgin>Belgian</orgin>
<veg>true</veg>
</food>
<food>
<name>French Toast</name>
<price>$4.50</price>
<description>Thick slices made from our homemade sourdough bread</description>
<calories>600</calories>
<orgin>French</orgin>
<veg>true</veg>
</food>
<food>
<name>Homestyle Breakfast</name>
<price>$6.95</price>
<description>Two eggs, bacon or sausage, toast, and our ever-popular hash browns</description>
<calories>950</calories>
<orgin>French</orgin>
<veg>false</veg>
</food>
</breakfast_menu>

Output xml sample for food menu.

<?xml version="1.0" encoding="UTF-8"?>
<menu>
<item>
<name>Belgian Waffles</name>
<price>$5.95</price>
<calories>650</calories>
<orgin>Belgian</orgin>
<veg>true</veg>
<description>Two of our famous Belgian Waffles with plenty of real maple syrup</description>
</item>
<item>
<name>Strawberry Belgian Waffles</name>
<price>$7.95</price>
<calories>900</calories>
<orgin>Belgian</orgin>
<veg>true</veg>
<description>Light Belgian waffles covered with strawberries and whipped cream</description>
</item>
<item>
<name>Berry-Berry Belgian Waffles</name>
<price>$8.95</price>
<calories>900</calories>
<orgin>Belgian</orgin>
<veg>true</veg>
<description>Light Belgian waffles covered with an assortment of fresh berries and whipped cream</description>
</item>
<item>
<name>French Toast</name>
<price>$4.50</price>
<calories>600</calories>
<orgin>French</orgin>
<veg>true</veg>
<description>Thick slices made from our homemade sourdough bread</description>
</item>
<item>
<name>Homestyle Breakfast</name>
<price>$6.95</price>
<calories>950</calories>
<orgin>French</orgin>
<veg>false</veg>
<description>Two eggs, bacon or sausage, toast, and our ever-popular hash browns</description>
</item>
</menu>

Load above files as input and outputs and look the input output boxes with sample message. Is the element types are correctly identified or not. (Arrays, Objects and Primitive values). Following signs will help you to identify it correctly.

  • {}  – represent object elements
  • []   – represent array elements
  • <> – primitive field values
  • A   – xml attribute values

Now use operators and do the mapping as you desire. You can only connect primitive data values such as Strings, numbers, boolean and etc. Array and object values can not be mapped.

mapping

What I have done here is name is mapped via uppercase operator and calories undergoes and mathematical calculation to the output.

output calories =Round( (calories*1.13) + 6.75)

Now save the all configurations. We can now deploy the created REST API in the ESB server and test our mapping.

To deploy our configuration we need to include these in a CAPP project. When we created the ESB Solution Project we created the CAPP project too. So open the CAPP project and double click on the pom file. You will get the following page to select project files into CAPP.

CAPPProject.png

Here you do not see the registry resource files. We need to refresh the page to see it. Use refresh button in the top right conner to load newly added registry files.

refreshBUtton

Then you will see the all artifacts in the workspace. Select REST API file and the three registry resource files containing mapping configuration , input schema and output schema.

cappProjectselection

 

  • Mapping Configuration : This file contain the script file used to execute the mapping
  • Input Schema: JSON schema which represent input message format
  • Output Schema: JSON schema which represent the output message format

And also see the data mapper mediator configuration in the REST API.

DMMconfig.png

 

  • Input Type : Expected input message type (xml/json/csv)
  • Output Type: Target Output message type (xml/json/csv)

If your mapping failed at the runtime the first thing you need check whether the mediator configuration. Is the input type and output type are set correctly.

Now start WSO2 ESB server and connect it to ESB tool as a remote server or start ESB server from inside the ESB tool. And add out CAPP to the server and deploy it.

addwso2servercappAdding

Then goto management console from https://localhost:9443/carbon

See the deployed API and get the url it is listening.

APIDeployed.png

Start the POST Man and send the request for the above url.

postMan.png

You will get the response with accordingly to post man when you send the message.

To see the XML -> JSON conversion  just go to REST API  configuration and data mapper properties. Select Output Type as JSON . Deploy the configuration and send the request. You will get the JSON message.

Do the same for see the XML->CSV.

But this is not guaranteed every occasion. If t you have defined complex XML output message with name spaces and attributes JSON message or CSV will not built as you will imagine. In this case output message format is fully compatible to represent as JSON and CSV.

Now you have the basic end to end knowledge to develop a ESB configuration with a data mapper mediator. So you can try this and report the bugs and suggest improvements from the following link as JIRAs.

 

 

How to Connect with WSO2 ESB Server in Debug Mode

How to Connect with WSO2 ESB Server in Debug Mode

I have written a post before on WSO2 mediation debugger as “How to Debug WSO2 Mediation Flow” which guides through the basic steps to use WSO2 Mediation Debugger. It may not contain each and every detail because then it would be a one large post (which no one will read).🙂🙂

This is a one of the posts in many to come which describes the WSO2 Mediation Debugger features in detail for users need more than the basic requirements. Here I will discuss about how to connect with WSO2 ESB Server in mediation debug mode.

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. (https://github.com/wso2/product-esb/releases/)

And also we need to have a debugger supported Developer Studio ESB Tool. You can follow this article to install the WSO2 ESB Tool 5.0.0. ( https://github.com/wso2/devstudio-tooling-esb/releases)

Some of you may confused in the previous post ESB Tooling version is 4.1.0 and now 5.0.0. We decided to change the Tooling version to 5.0.0 since it is the version of WSO2 ESB runtime. As you may already know from now onwards each wso2 product will ship with three components as runtime (WSO2 ESB server), tooling (WSO2 ESB Tooling) and analytics(WSO2 ESB Analytics). If we had different versions for these three components it may confuse the  user to find the compatible versions to work together for the one product.

RMCfLEWgTJmandVGXcSG_Confused Superman

 

 

So now all three components will come under same version. (For ESB it is 5.0.0)🙂

OVERVIEW

 

There are two ways we could connect ESB tool with ESB server to deploy artifacts. They are we could start esb server from terminal by executing wso2server.sh  script in the bin folder and add to ESB tool as a remote server or we could add a esb as a wso2 server in the ESB tool and start.

We can debug the esb mediation flow in both above mentioned occasions.

Starting WSO2 ESB Server with Independently and Connect ESB Tool to Debug

We can navigate to server file location bin folder from the terminal and execute wso2server.sh as follows to start esb server.

startserverterminal

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

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 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 ESB Tool before starting the ESB Server in the debug mode.

Go to Debug Configurations in the ESB Tool 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 9005 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=super” and click the Debug button when server listing to the ports as bellow.

listining.png

Then the server will be in the mediation debug mode and connected with ESB tool.

Starting WSO2 ESB Server with from ESB Tool and Connect to Server in Debug Mode

If you want to start esb server from esb tool and debug you need to give “-Desb.debug=true” argument to start the server.

First add esb server into ESB tool. Goto server view and create a new server.

serverview

selectESBserver

Actually ESB Server version is not much critical here, most important part is the Server runtime environment. It should be WSO2 Carbon 4.4 based server.

Then select WSO2 ESB Server 5.0.0 and give the esb server home folder location from the Add link.

browsetosetesbhome

Then finish the server configuration. This is the normal way to add a wso2 server for developer studio.

Now if we want to start esb server in the debug mode we have to provide the argument to server start up.So go to run/debug configurations and double click Generic server.

genericserver

argumentstab2.png

And go to Arguments tab and add Program arguments “-Desb.debug=super”. Apply the changes and finish the configuration.

Then start the server from the server view and esb server will listen to debug ports as we saw earlier.

Can We Remote Debug and Mediation Debug in the Same Time???

The answer is YES. You could start the esb server by giving the command

“sh wso2server.sh debug 5005 -Desb.debug=super”

It will first listen on the port 5005 to connect with esb source and then stop and listen to ports 9005 and 9006.

You can try ESB Mediation Debugger more and report the bugs and suggest improvements from the following link as JIRAs.

 

How Run Developer Studio Code from Source

How Run Developer Studio Code from Source

INTRODUCTION

This post is for developers who would like develop tooling for WSO2. WSO2 Developer Studio also moved in to a kernel-based model with its new architecture revamp in version 4.0.0. WSO2 Developer Studio Kernel provides a set of common plug-ins, which can be used to develop Eclipse plug-ins for WSO2 products that are based on WSO2 Carbon platform.  All the product specific plug-ins will use the Developer Studio Kernel as the base for their respective tooling implementation.

If you have used WSO2 Developer Studio you know that previous versions include tooling support for create many WSO2 product artifacts. But actually a user may not need tooling support for all of these products. User may only use few products in the production. So now onwards user can select what he only needs and install those.

PREREQUISITES

At the time I’m writing this post Developer Studio has released new version based on Eclipse mars2 as WSO2 Developer Studio Kernel 4.1.0. I will guide you to clone the source and how to run the code of ESB Tooling 5.0.0 which is based on 4.1.0 kernel of Developer Studio.

First you may need Eclipse Mars 2 distribution and you can it from here.

1. Install Required Developer Studio Features

The next step is to install the features required for the plug-ins we are going to develop. We need Developer Studio Kernel 4.1.0 and platform bundles for ESB Tooling plug-ins. So install the above features on the downloaded Eclipse.

2. Clone the Source to Local Machine

ESB Tooling repository can be found in here. Fork the repository and for your git and clone from there to your local machine.

git clone https://github.com/your-acount/devstudio-tooling-esb

3. Import Source to Eclipse

importCommand.png

existingProjectSection.png

sourcefolders

Now you will have the ESB Tooling source on your Eclipse and start implementing tooling.

4. Run Developer Studio from Source

You can run the developed plug-ins and test the code. You need to run it as Eclipse Application as shown in the following diagram.

Go to Run Configurations and Eclipse Application

runconfiguration

When you click the run button it will start a new Eclipse application with your plug-ins in the workspace.

Comparison of Java Script Modules and Dependency Managing Frameworks

Comparison of Java Script Modules and Dependency Managing Frameworks

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. Module based coding eases the effort for maintenance and increases re-usability.

However, managing dependencies between modules is a major concern Java Script developers faced. Hence there are several module and dependency management frameworks became famous among JS developers to give the responsibility to manage dependencies properly in larger projects.

For Eg:

 

 

But first three are the most popular and most used frameworks.

Choosing the right module loader is an important decision for any high quality web application. Large applications often require a number of JavaScript files. Generally, they are loaded one by one using <script> tags. Additionally, each file can potentially be dependent on other files. You don’t want to add script tags manually into the html because is not scalable (you have to manually order, no deploy minification…).

Following is a comparison listed in webpack documentation.

Feature webpack/webpack jrburke/requirejs substack/node-browserify jspm/jspm-cli
CommonJs require yes only wrapping in define yes yes
CommonJs require.resolve yes no no no
CommonJs exports yes only wrapping in define yes yes
AMD define yes yes deamdify yes
AMD require yes yes no yes
AMD require loads on demand yes with manual configuration no yes
ES2015 import/export no no no yes
Generate a single bundle yes yes♦ yes yes
Load each file separate no yes no yes
Multiple bundles yes with manual configuration with manual configuration yes
Additional chunks are loaded on demand yes yes no System.import
Multi pages build with common bundle with manual configuration yes with manual configuration with bundle arithmetic
Concat in require require(“./fi” + “le”) yes no♦ no no
Indirect require var r = require; r(“./file”) yes no♦ no no
Expressions in require (guided) require(“./templates/” + template) yes (all files matching included) no♦ no no
Expressions in require (free) require(moduleName) with manual configuration no♦ no no
Requirable files file system web file system through plugins
Plugins yes yes yes yes
Preprocessing loaders, transforms loaders transforms plugin translate
Watch mode yes not required yes not needed in dev
Debugging support SourceUrl, SourceMaps not required SourceMaps SourceUrl, SourceMaps
Node.js built-in libs require(“path”) yes no yes yes
Other Node.js stuff process, __dir/filename, global process, __dir/filename, global process, __dir/filename, global for cjs
Replacement for browser web_modules, .web.js, package.json field, alias config option alias option package.json field, alias option package.json, alias option
Minimizing uglify uglify, closure compiler uglifyify yes
Mangle path names yes no partial yes
Runtime overhead 243B + 20B per module + 4B per dependency 14.7kB + 0B per module + (3B + X) per dependency 415B + 25B per module + (6B + 2X) per dependency 5.5kB for self-executing bundles, 38kB for full loader and polyfill, 0 plain modules, 293B CJS, 139B ES6 System.register before gzip
Dependencies 19MB / 127 packages 11MB / 118 packages 1.2MB / 1 package 26MB / 131 packages

Following articles have much detailed comparison of above frameworks.

  1. What are the best client-side JavaScript module loaders?
  2. Module loader comparison: Webpack vs Require.js vs Browserify
  3. Webpack comparison

 

Comparison of Java Script Document Generators

Comparison of Java Script Document Generators

One of your least desirable and least rewarding tasks as a software developer is creating documentation. Whether it’s for code you’re creating, a change you’re contemplating, or a problem that you’re trying to resolve, the actual task of documentation is often dull and unimaginative. Yet detailed, accurate, up-to-date documentation is of enormous value.

  • It helps insure that changes made to the source code don’t create unforeseen problems. It speeds and focuses software peer review efforts.
  • It lowers the likelihood of misunderstandings among developers and quality assurance teams.
  • It alleviates the need to spend time hand-holding new engineers as they get up to speed.

So as documenting is essential in software development, in JavaScript world following are some famous document generator tools for documenting APIs.

  • DoccoLogodoxxDOCCO
  • YUI
  • JSDoc
  • Doxxyui-logo-2xjsdoc_featured

Following table compares the above generator tools each other.

JSDoc

YUIDoc

Doxx

Docco

Syntax

Structured

Structured

Structured

Unstructured

Accessibility
(default theme)

Low

High

High

High

Search feature

Yes, not by default

Yes

No

No

Extra themes

Docstrap

One bundled. Others available.

No.

Bundled

Learning curve

Medium

Medium

Low

None

Source parsing

Yes

No

No

No

Customization

High

Medium

Low

Very low

Extensibility

High

Medium

Low

None

Speed

Medium

Low

N/A

Very High

A more detailed comparison can be found in here.

And a great discussion of the importance of good documentation can be found here.

Sample documentation pages of above tools for the same source are given in below. Take a look of the visual appeal of each. But in JSDoc we could customize it as we wanted.

How to Use WSO2 Data Mapping Mediator in ESB

How to Use WSO2 Data Mapping Mediator in ESB

Please find the updated post from here

https://nuwanpallewela.wordpress.com/2016/07/16/how-to-use-wso2-data-mapping-mediator-in-esb-updated/

INTRODUCTION

WSO2 data mapper is a data mapping solution that convert and transform one format of data to a different format. It provides a WSO2 Developer Studio based tool to create the graphical mapping configuration and generate the files needed to execute the mapping configuration by the WSO2 Data mapper engine as shown in the below diagrams. As the this is really useful feature in message mediation, WSO2 ESB comes with a data mapper mediator which can be integrate into a mediation sequence since WSO2 ESB 5.0.0.

PREREQUISITES

First we need to have the data mapper mediator supported ESB distribution. WSO2 ESB 5.0.0 is the distribution packed with data mapper mediator. You can download alpha pack from here.

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

OVERVIEW

This post will focus on how to create a configuration with Data Mapper mediator. So I will chose a very simple ESB configuration with only a data mapper mediator and respond mediator to check the converted message.

 

employeeToEngineerUserCase.png

Our Employee message will be a xml message and we will send a JSON response to the client. We will use the Postman as out client to send the requests.

Creating Data Mapping Configuration

Lets create a ESB Configuration project named “DataMapperEmployeeToEngineerConfig” from the WSO2 Developer Studio ESB Tool and create a Rest API as follows.

RestAPiWizard.png

Then we can add the Data Mapper Mediator in to the API resource and a Respond mediator to send the converted message back to client.

apiconfig.png

Then double click on the data mapper mediator to configure the mapping. It will open a dialog box asking to create a Registry Resource project. This is to save and deploy the required configuration and schema files in the ESB Server to read at the runtime when message conversion happens. So name the configuration file as “EmployeeToEngineerMapping” and registry resource project as “EmployeeToEngineerRegistryResource”.registryresourcefile.pngIt will open the Data Mapper Diagram Editor where we should do the mapping.

diagrameditor.png

But first we need to complete the API configuration. So go back to ESB Diagram editor with the API Resource and click on the Data Mapper mediator. You will see the configurations of the Data Mapper mediator on the property table.

data mapper configuration.png

As you can see there are five configurations listed. They are

  • Input Type : Expected input message type (xml/json/csv)
  • Output Type: Target Output message type (xml/json/csv)
  • Configuration : This file contain the script file used to execute the mapping
  • Input Schema: JSON schema which represent input message format
  • Output Schema: JSON schema which represent the output message format

As we are going to convert xml message to json message change the output type to json.

propertytable.png

And then click on the API resource and  go to the property table. And change the configurations to following.

  • Url Style : URL_MAPPING
  • URL-Mapping : /employeetoengineer
  • Methods : POST

apiconfigchanges.png

Save the API configuration. Now lets move to data mapper editor to create the mapping from employee message to engineer.

First we need to load the input and output message formats into editor. For the right click on the input box title bar and select load input schema command.

loadschemafromfile.png

Then following dialog box appears and you will have multiple ways to load the input message format.

loadinputclose.png

You can select the resource type as XML, JSON, XSD or JSONSCHEMA.

If you selects XML, you can load a sample xml message you expect and WSO2 Data Mapper Editor will generate the JSON schema to represent the xml accoring to the WSO2 Data Mapper Schema specification.

Same as for XML, if you select  JSON as resource type you can load a sample JSON message.

If you have a xsd schema which defines you xml message format, you can select the resource type as XSD and load the xsd file.

And also if you have the JSON schema for your message according to the WSO2 Data Mapper schema specification you can load it by selecting resource type as JSON schema.

Lets use a sample xml message to load input format to the data mapper editor. Use following xml as the sample input.

<?xml version='1.0' encoding='utf-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body><ns1:employees xmlns:ns1="http://wso2.employee.info" xmlns:ns2="http://wso2.employee.address">
<ns1:employee>
<ns1:firstname>Mike</ns1:firstname>
<ns1:lastname>Jhonson</ns1:lastname>
<ns2:addresses>
<ns2:address location="home" >
<ns2:city postalcode="30000">KS</ns2:city>
<ns2:road>main rd</ns2:road>
</ns2:address>
<ns2:address location="office" >
<ns2:city postalcode="10003">NY</ns2:city>
<ns2:road>cross street</ns2:road>
</ns2:address>
</ns2:addresses>
</ns1:employee>
<ns1:employee>
<ns1:firstname>Patric</ns1:firstname>
<ns1:lastname>Jane</ns1:lastname>
<ns2:addresses>
<ns2:address location="home" >
<ns2:city postalcode="60000" >Melborne</ns2:city>
<ns2:road>park street</ns2:road>
</ns2:address>
<ns2:address location="office" >
<ns2:city postalcode="10003">NY</ns2:city>
<ns2:road>cross street</ns2:road>
</ns2:address>
</ns2:addresses>
</ns1:employee>
<ns1:employee>
<ns1:firstname>Thelesa</ns1:firstname>
<ns1:lastname>Lisbon</ns1:lastname>
<ns2:addresses>
<ns2:address location="home" >
<ns2:city postalcode="60000">Madrid</ns2:city>
<ns2:road>Palace street</ns2:road>
</ns2:address>
<ns2:address location="office" >
<ns2:city postalcode="10003">NY</ns2:city>
<ns2:road>cross street</ns2:road>
</ns2:address>
</ns2:addresses>
</ns1:employee>
</ns1:employees>
</soapenv:Body>
</soapenv:Envelope>

And use following JSON message as the sample output and load output message format to data mapper editor.

{
"engineers":{
"engineerList":[
{
"fullname":"Mike Jhonson",
"addresses":{
"address":[
{
"location":"home",
"city":{
"postalcode":30000,
"text":"AA"
},
"road":"BB"
},
{
"location":"office",
"city":{
"postalcode":10003,
"text":"BB"
},
"road":"CC"
}
]
}
},
{
"fullname":"Mike Jhonson",
"addresses":{
"address":[
{
"location":"home",
"city":{
"postalcode":30000,
"text":"AA"
},
"road":"BB"
},
{
"location":"office",
"city":{
"postalcode":10003,
"text":"BB"
},
"road":"CC"
}
]
}
}
]
}
}

Now the editor will have the input and output message formats as bellow.

operations.png

Now we can specify how the output message should build by using the input message. We have several operations given in the operations pallet in the left side.

Click on the operator and it will come to the editor. Then construct the mapping as the following diagram.

mappingdiagram.png

You can only connect primitive data values such as Strings, numbers, boolean and etc. Array and object values can not be mapped.

  • {}  – represent object elements
  • []   – represent array elements
  • <> – primitive field values
  • A   – xml attribute values

After loading the message formats you have to observe whether the formats are correctly identified by the data mapper diagram editor.

Now save the all configurations. We can now deploy the created REST API in the ESB server and test our mapping.

Deploy the REST API in ESB Server

We can create a CAPP including the WSO2 synapse configurations and the registry resource files as below.

DMCAPP.png

Start ESB server and add it to Developer Studio ESB Tool servers and deploy.

deployment.png

Then go to API’s list from the ESB management console and confirm the REST API invocation URL.

deployedAPIs.png

Invoke Created REST API

Open Postman and create the client message as follows.

postmanxmlmessage.png

Send the message from Postman and you will receive the respond message but in the xml format. This is since though we converted the message to type json in the axis2 level we need to change the property “messageType” to “application/json” too.

messagetypeproperty.png

So add a property mediator and configure the following parameters.

  • Property Name : messageType
  • Value : application/json
  • Property Scope : axis2

Then redeploy the CAPP and send the employee message again from the Postman. Then you will receive the expected json message as follows.

jsonresponse.png

{
"engineerList": [
{
"addresses": {
"address": [
{
"city": {
"postalcode": 30000,
"text": "KS"
},
"location": "home",
"road": "main rd"
},
{
"city": {
"postalcode": 10003,
"text": "NY"
},
"location": "office",
"road": "cross street"
}
]
},
"fullname": "Mike Jhonson"
},
{
"addresses": {
"address": [
{
"city": {
"postalcode": 60000,
"text": "MELBORNE"
},
"location": "home",
"road": "park street"
},
{
"city": {
"postalcode": 10003,
"text": "NY"
},
"location": "office",
"road": "cross street"
}
]
},
"fullname": "Patric Jane"
},
{
"addresses": {
"address": [
{
"city": {
"postalcode": 60000,
"text": "MADRID"
},
"location": "home",
"road": "palace street"
},
{
"city": {
"postalcode": 10003,
"text": "NY"
},
"location": "office",
"road": "cross street"
}
]
},
"fullname": "Thelesa Lisbon"
}
]
}

Now you have the basic end to end knowledge to develop a ESB configuration with a data mapper mediator. So you can try this and report the bugs and suggest improvements from the following link as JIRAs.

I will discuss more advanced discussion about how things work inside and mapping configuration is generated from the diagram which will help to understand the behavior of the data mapper and the limitations.

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.