Category: wso2

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
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 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.

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.

 

How to Install Developer Studio ESB Tool

How to Install Developer Studio ESB Tool

As you may already know WSO2 have changed the product strategy to provide a runtime along with tooling and analytics. So now on wso2 each product will come with a runtime, tooling and analytics.

Screen Shot 2015-12-08 at 1.11.43 PM
WSO2 Product Strategy

For example for the latest product ESB you will find three components.

  • Runtime : WSO2 ESB 5.0.0
  • Tooling : WSO2 Developer Studio ESB Tooling 5.0.0
  • Analytics : WSO2 ESB Analytics 5.0.0

This tutorial will guide you install WSO2 Developer Studio ESB Tooling with the new tooling strategy.

New WSO2 Developer Studio Tooling Strategy

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.

So now you can install only the ESB tooling support with developer studio. There are several ways to get this done.

  1. Install on top of Eclipse distribution
  2. Install on top of WSO2 Developer Studio Kernel
  3. Download the WSO2 Developer Studio ESB Tool Installed Distribution

1. Install on top of Eclipse distribution

Lets install WSO2 Developer Studio ESB Tooling 5.0.0.

First we need to have a compatible Eclipse Distribution. WSO2 Developer Studio ESB Tooling 5.0.0 is based on WSO2 Developer Studio Kernel 4.1.0. As WSO2 Developer Studio Kernel based on Eclipse mars ( Eclipse 4.5) we need to have Eclipse Mars distribution. You  can download it from here. Download the respective version according to your OS.

Now you have the Eclipse compatible eclipse distribution to install WSO2 Developer Studio ESB Tooling. You can download the beta2 composite P2 from here. Composite P2 will contain both ESB tooling and Developer Studio kernel features bundled together. So You can directly install the downloaded composite p2 in Eclipse.

Following are the steps to install composite p2 to Eclipse.

  1. Goto Eclipse help->Install New Software… installNewSoftwareClose
  2. Add composite P2 as a repositoryinstallDialogAddRepository
  3. Click Archive button and select the composite p2 form the file system
  4. selectcompositezipThen software installation dialog will show the feature list of the composite p2. Select all features.esbtoolfeatures
  5. Remove the check of Contact all update sites check box and click the next button.untickbutton
  6. Then you will ask to accept license of the software and to restart after installation.

After restating the Eclipse you will have a Eclipse with WSO2 Developer Studio ESB Tooling capabilities.

 

2. Install on top of WSO2 Developer Studio Kernel

If you already have a Eclipse with WSO2 Developer Studio Kernel, you only need to install  ESB Tooling features. You can download the beta2 main p2 of WSO2 Developer Studio ESB Tooling from here.

You can install the downloaded main p2 on WSO2 Developer Studio Kernel by following the above mentioned steps.

3. Download the WSO2 Developer Studio ESB Tool Installed Distribution

If you don’t have a compatible eclipse distribution you can download WSO2 Developer Studio ESB Tooling install distribution which contain Eclipse distribution, developer studio kernel and esb tooling together. You only need to extract and run.

You can see the all beta2 release in here.

Download Links

 

 

How to Change the Default Editor in the WSO2 Developer Studio

How to Change the Default Editor in the WSO2 Developer Studio

WSO2 Developer Studio is an Eclipse-based SOA development environment for develop artifacts and deploy them in WSO2 products. Generally it provides both diagram editor and source editor to create artifacts as shown in the following diagrams.

sourceEditor
Source Editor
diagramEditor
Diagram Editor

Preference can be changed from developer to developer which editor to use. So developer studio now provides the capability to select the preferred editor as the default editor and continue developing as developer’s preference.
Following are the steps to change the default editor.

  1. Go to Eclipse preferencespreferencetabclose
  2. Go to File Associations property viewfileAssociationsclose
  3. Select *.xml file type and it will show associated editors list.associatedEditors
  4. To change it to XML Editor as the default editor select XML Editor from the Associated editors list and select as Default.setXMLasdefualt
  5. Then XML editor will come to the top of the list and then click OK button to close preference dialog.finishclose
  6. After configuring as above when you open an artifact it will open with XML editorxmleditorview

If you want to change the default editor back to ESB diagram editor, you can follow the same steps and set the ESB Editor as the default editor.

 

 

 

How to Deploy Web Services in WSO2 Application Server using WSO2 Developer Studio

How to Deploy Web Services in WSO2 Application Server using WSO2 Developer Studio

Introduction

This post mainly target to give you the process of deploying web services in WSO2 Application Server. We will use WSO2 Developer Studio 3.8.0 and WSO2 Application server 5.3.0 for this tutorial.

Create a simple Web Service

Create a simple JAX-RS service following the post “Develop JAX-RS Web Service Easily Using WSO2 Developer Studio”

webserviceprojectCreate a C-APP Project

Go to Developer Studio Dashboard and click Composite Application Project listed in Distribution section. And create a CAPP project named CAPP_Application_server and select check button of the Web service project you want to host in Application Server.capp_creation

Developer Studio will create you a CAPP project which can be deploy directly into WSO2 Application server. Isn’t that great!!!

Add and Start WSO2 Application Server from Developer Studio

There are two ways to do this.
  1. Application server can be add to Developer Studio as a server and then you can do every server operation through Developer Studio.
    • Go to Server tab in Developer Studio. This window can be found in bottom section or by following
      • Menu-bar-> Window -> Show view->Serversservers_tab
    • Right click inside window and go for New->Server Menu. Select
      • WSO2 -> WSO2 Carbon 4.4 based server (Since WSO2 AS 5.3.0 is based on WSO2 Carbon 4.4.0)add_new_server
    • Go to Next page of wizard add AS server distribution home folder location as CARBON_HOME section.carbon_server_path
    • Next page shows port configurations and other useful information. Then finish the configuration and start server.
  2. Application server can be started externally and add to Developer Studio as a remote server.
    • Start Application Server externally server_externally_startAS_server_started_externallyhttps://192.168.1.4:9443/carbon/ will be the default server url.
    • Go to server tab and New-> Server menu. Select
      • WSO2 -> remote Serverremote_server_urlFill the server url with running server url and finish the configuration.

Add CAPP to Application Server

Now WSO2 server is up and running in our system. You can now deploy the your web service.

  • Right click on Developer Studio server tab we created in previous step and goto command Add and Removeadd_remove
  • Then Dialog will pop-up listing available CAPP’s in the workspace. Select your CAPP created in previous step and finish the configuration.
  • Your service will deploy in to Application server and up and running.succesfullydeployed
  • You can go to Application Server management console from browser and see your service

servicemanagementconsole