- What is new in this release?
- What has changed?
- Compatible WSO2 product versions
- Fixed issues
- Known issues
In this first part I will show you what is new in this release.
In the table below you have a comparison between the previous version WSO2 ESB 4.9.0 and the latest version WSO2 ESB 5.0.0:
What is new in this Release?
- WSO2 ESB tooling
-
Installing the ESB Tooling Plug-in
-
Creating ESB Artifacts
-
- WSO2 ESB analytics
- JMS 2.0
- WebSockets
- Data Mapper Mediator
- Debugging Mediator
1. WSO2 ESB tooling
Installing the ESB Tooling Plug-in
- Tooling support to create and manage ESB artifacts (http://product-dist.wso2.com/downloads/enterprise-service-bus/5.0.0-beta/v5.0.0-beta.zip)
- Based on WSO2 Developer Studio Kernel 4.1.0.
- You can develop services, features and artifacts and manage their links and dependencies.
- 3 possible methods you can follow to install the ESB tooling plug-in:
1: Install the plug-in with pre-packaged Eclipse (ESB 5.0.0 GA release).
2: Install the plug-in on Eclipse Mars using the P2 URL.
Install Eclipse IDE for Java EE Developers (Mars 2): (Https://eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/mars2)
Eclipse>Help>Install New Software>Add
Location: http://builder1.us1.wso2.org/~developerstudio/developer-studio-kernel/4.1.0/esb-tooling/releases/5.0.0/beta/
3: Install the plug-in on Eclipse Mars using the P2 .zip file
Install: Eclipse IDE for Java EE Developers (Mars 2)
Download the P2 .zip file: http://builder1.us1.wso2.org/~developerstudio/devstudio-tooling-esb/5.0.0/Beta/composite/
Eclipse>Help>Install New Software>Add
Creating ESB Artifacts
- How does it work?
- Getting help in the source view
- Press Ctrl + Space
- Hover your mouse over any element
- Creating an ESB Config project, to save all the ESB related artifacts such as proxy services, endpoints, sequences, and synapse configurations: Eclipse>Developer Studio>Open Dashboard>ESB Config Project.
- Importing a Synapse configuration: Developer Studio>DashBoard>Synapse
- Creating a Smooks configuration artifact.
Smooks is an extensible framework for building applications for processing XML and non XML data (CSV, EDI, Java etc) using Java. (http://smooks.org/mediawiki/index.php?title=Main_Page)
To create a Smooks configuration artifact, you must create a registry resource:
Add libraries from the Smooks framework to your registry resources project: Right-click the registry resources project in the Project Explorer > click Properties
Now run the Smooks configuration file by right-clicking the file and choosing Run As > Smooks Run Configuration. If your Smooks configuration is correct, the console displays the results according to the input model and output model you specified.
Now add the Smooks configuration artifact to a proxy service or sequence to use it in the ESB.
- Moving ESB artifacts between projects.
- Deploying the ESB Config project.
Packaging Artifacts Into Deployable Archives
- Packaging Artifacts into Deployable Archives. Package your artifacts into archives that you can deploy to the ESB.
- Packaging individual artifacts
2. WSO2 ESB Analytics
Prerequisites to Publish Statistics.
- To publish information that is related to the processing carried out in WSO2 ESB to the Analytics Dashboard.
- Prerequisites to Publish Statistics:
Downloading WSO2 Analytics – ESB -> https://docs.wso2.com/display/CEP410/Building+from+Source - Running WSO2 Analytics – ESB <PRODUCT_HOME>/bin/wso2server.sh or <PRODUCT_HOME>/bin/wso2server.bat
- Running WSO2 ESB <PRODUCT_HOME>/bin/wso2server.sh or <PRODUCT_HOME>/bin/wso2server.bat
- Enabling statistics for the mediation flow <ESB_HOME>/repository/conf/synapse.properties
- Setting up the DAS configuration.
The information required by WSO2 ESB to publish data to the DAS server in order to analyze the data using the Analytics Dashboard.
WSO2 ESB Management Console > Configure tab > DAS Configuration > DAS Servers List > Add Server > DAS Publisher Configuration:
- Enabling Statistics for ESB artifacts.
Analyzing ESB with the Analytics Dashboard
- Login to WSO2 DAS > Main > Analytics DashBoard
- Analyzing ESB Statistics Overview. Performance of web services and applications
Request Summary
Purpose:Understanding to which the ESB was utilized during a selected time interval. Checking success rate of the ESB during a selected time interval.
Recommended Action: If success rate is too low -> check proxy services and REST APIs individually.
Overall TPS
Purpose:Overall efficiency of the ESB in terms of the request processing speed.
Recommended Action:Add more ESB nodes if required.
Overall Message Count
Description:Total number of successful messages as well as failed messages per time period.
Purpose:Correlations that may exist during message failure and time.
Recommended Action:Unusual occurrences (e.g., system downtime)
Top APIs by Request Count
Description:The most frequently used REST APIs.
Purpose:Usage patterns relating to your applications and services.
Recommended Action:Rest API with a high rate of request failure
Top Proxy Services by Request Count
Purpose:Usage patterns related with time.
Recommended Action:Proxy services with a high rate of request failure
Top Sequences by Request Count
Purpose:The most frequently used mediation patterns.
Recommended Action:Sequences with a high rate of request failure
Top Endpoints by Request Count
Description:The most frequently used endpoints.
Purpose:Usage patterns relating to your applications and services.
Recommended Action:Endpoints with a high rate of request failure
Top Inbound Endpoints by Request Count
Description:The most frequently used inbound endpoints.
Purpose:Usage patterns relating to your applications and services.
Recommended Action:Endpoints with a high rate of request failure
- Analyzing Statistics for Proxy Services. Statistics relating to a selected proxy service.
Proxy Request Count
Purpose:To understand the usage patterns by applications/services.To identify any unusual occurrences that have taken place during specific times (e.g., system downtime).
Recommended Action Identify system downtime, unavailability of the backend service etc., artifacts used by the proxy service (i.e. sequences, endpoints etc.) for errors.
Message Count
Description:The count for both successful and failed messages for a proxy.
Purpose:This allows you to identify any correlation that may exist between message failure rate, throughput and time.
Recommended Action Check whether any unusual occurrences have taken place during that time (e.g., system downtime, unavailability of the back-end service)
Message Latency
Purpose:The efficiency of a proxy service.
Recommended Action:Check overload of requests.
Message Flow
Description The mediation flow through which the messages handled by a proxy service have passed.
Purpose:The different stages of mediation that a selected message ID has passed.
Recommended Action:Check the message flow is correctly configured.
Messages
Purpose:To identify the messages not successfully processed.
Recommended Action:Check whether message failure correlates with specific time intervals, a specific host.
- Analyzing Statistics for REST APIs. To analyze the performance of REST APIs in ESB.
API Request Count
Purpose:To understand the usage patterns by applications/services.
Recommended Action:Check for unusual activities (e.g., system downtime, unavailability of the backend service etc.). Check the REST API configuration and other artifacts used by the REST API (i.e. sequences, endpoints etc.) for errors.
Message Count
Purpose:To identify any correlation between message failure rate, throughput and time.
Recommended Action:Check system downtime, unavailability of the back-end service, etc.
Message Latency
Purpose:The efficiency of a REST API.
Recommended Action:Check overload of requests.
Messages
Description:The list of message IDs that were processed.
Purpose:To identify the messages not successfully processed.
Recommended Action:Check whether message failure correlates with specific time intervals, a specific host.
Message Flow
Description:The mediation flow through which the messages handled by a REST API have passed.
Purpose:The different stages of mediation that a selected message ID has passed.
Recommended Action:Check the message flow is correctly configured.
- Analyzing Statistics for Sequences.
Sequence Request Count
Description:The total number of requests handled by a mediation sequence.
Purpose: To understand the usage patterns by applications/services.
Recommended Action: Check for unusual activities (e.g., system downtime, unavailability of the backend service etc.). Check the sequence configuration for errors.
Message Count
Purpose:To identify any correlation between message failure rate, throughput and time.
Recommended Action Check system downtime, unavailability of the back-end service, etc.
Message Latency
Purpose:The efficiency of a mediation.
Recommended Action:Check configuration of mediation.
Messages
Description|:The list of message IDs that were processed by selected sequence.
Purpose:To identify the messages not successfully processed.
Recommended Action:Check whether message failure correlates with specific time intervals, a specific host.
Message Flow
Description:The mediation flow through which the messages handled by a sequence have passed.
Purpose:The different stages of mediation that a selected message ID has passed.
Recommended Action Check the message flow is correctly configured.
- Analyzing Statistics for Endpoints.
Endpoint Request Count
Purpose:To understand the usage of an endpoint and its validity
Recommended Action:Check for unusual activities (e.g., system downtime, unavailability of the backend service etc.).
Message Count
Purpose:To identify any correlation between message failure rate, throughput and time.
Recommended Action:Check system downtime, unavailability of the back-end service, etc.
Message Latency
Purpose:The efficiency messages are sent to endpoint.
Recommended Action:Check endpoint availability.
Messages
Purpose:To identify the messages not successfully processed. Recommended Action:Check whether message failure correlates with specific time intervals, a specific host.
- Analyzing Statistics for Inbound Endpoints. (An inbound endpoint is a message entry point that can inject messages directly from the transport layer to the mediation layer, without going through the Axis engine. *)
Inbound Endpoint Request Count
Purpose:To understand the usage of an Inbound endpoint and its validity
Recommended Action:Check for unusual activities (e.g., system downtime, unavailability of the backend service etc.), Check the configuration of the inbound endpoint.
Message Count
Purpose:To identify any correlation between message failure rate, throughput and time.
Recommended Action:Check system downtime, unavailability of the back-end service, etc.
Message Latency
Purpose:The efficiency messages are sent to Inbound Endpoint.
Recommended Action:Check overload of requests.
Messages
Purpose:To identify the messages not successfully processed.
Recommended Action:Check whether message failure correlates with specific time intervals, a specific host.
Message Flow
Purpose:The different stages of the message flow.
Recommended Action:Check the message flow is correctly configured.
- Analyzing Statistics for Mediators.
Mediator Request Count
Purpose:The different stages of the message flow.
Recommended Action:Check the message flow is correctly configured.
Message Count
Purpose:To identify any correlation between message failure rate, throughput and time.
Recommended Action:Check system downtime, unavailability of the back-end service, etc.
Message Latency
Description:The time taken to process message by mediator.
Purpose:The efficiency mediator has.
Recommended Action:Check the mediator configuration or check the complete mediation flow.
Messages
Purpose:To identify the messages not successfully processed. Recommended Action: Check MEDIATOR PROPERTIES (payload, transport properties and context properties) in the message before and after the mediation was carried out by the mediator. Analyze the differences to identify errors in the mediation performed.
- Analyzing Statistics for Messages.
Message Flow
Purpose:If message fails, the failure can be attributed to a specific mediator/endpoint in the message flow.
Recommended Action:Check the sequence and endpoints and Check MEDIATOR PROPERTIES.
Message Properties
Purpose:If a message has failed, this gadget allows you to identify the exact stages in the message flow where the errors have occurred.
Recommended Action Consider the Before section as the input of the selected artifact, and the After section as the output. Check whether the transformation that has been made is the the same as what is required.
Monitoring WSO2 ESB with WSO2 Analytics.
- Prerequisites: Install WSO2 ESB, WSO2 AS, WSO2 Analytics ESB.
- Step 1 – Configure WSO2 ESB to publish statistics.
<ESB_HOME>/repository/conf/synapse.properties
- Step 2 – Deploy the required ESB artifacts.
- Step 3 – Set up the Stockquote service.
<ESB_HOME>/samples/axis2Server/src/SimpleStockQuoteService> ant
<ESB_HOME>/samples/axis2Server ./axis2server.sh
- Step 4 – Send JSON requests
curl -X POST http://localhost:8280/stockquote/getQuote -d ‘{“name”:”WSO2″}’ -H “Content-Type:application/json”
https://<DAS_HOST>:<DAS_PORT>/carbon/
- Step 5 – Analyze statistics
3. JMS 2.0
- Java Message Service
- Advantages:
- Simplified API in order to reduce the amount of code that needs to be written by the programmer.
- Shared Subscription:
- Delivery Delay: Delivery delay can be added to the JMS Producer so that the publisher will not deliver the message until that time interval is elapsed.
- JMSX Delivery Count: This property allows the message consuming application to know how many times a particular messages has been redelivered.
4. WebSockets
- WebSockets is an advanced technology that makes it possible to open an interactive communication session between the user’s browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
- The WSO2 ESB WebSocket transport implementation is based on the WebSocket protocol, and consists of an Axis2 sender implementation for WebSockets and secure WebSockets. This transport supports bidirectional message mediation.
- Enabling the transport:
org.wso2.carbon.websocket.transport.WebsocketTransportSender (class to be included into ESB configuration)<ESB_HOME>/repository/conf/axis2/axis2.xml
To enable the WebSocket transport sender:
To enable the secure WebSocket transport sender:
5. Data Mapper Mediator
- It converts and transforms one data format to another, or changes the structure of the data in a message. It provides a WSO2 Developer Studio-based tool to create a graphical mapping configuration, and generates the files required to execute this graphical mapping configuration by the WSO2 Data Mapper engine.
- Prerequisites
- Install the WSO2 Developer Studio ESB Tool 4.1.0 to use the Data Mapper mediator.
- Syntax:
- I configuration
- Example: Creating a SOAP payload with namespaces
Input JSON payload
Output XML payload
- Example : Mapping SOAP header elements
Using Data Mapper Mediator in WSO2 ESB
- Example:
ESB Config Project
Project name
To create a new REST API
Enter a name and context for the new REST API 
6. Debugging Mediator
- What is debugging with respect to mediation: To debug the ESB message mediation flow in the server.
- Creating the ESB artifact.
- Install the WSO2 ESB Tooling Plugin and run it.
- Create the ESB artifact using the WSO2 ESB Tooling Plugin.
- Deploy the artifact you created on WSO2 ESB.
- Enabling mediation debugging: WSO2 ESB Tooling Plugin > Run > Debug Configurations > ESB Mediation Debugger
- Start WSO2 ESB server: sh wso2server.sh -Desb.debug=true
- Click Debug in the WSO2 ESB Tooling Plugin when the WSO2 ESB Console indicates the following:
- WSO2 ESB Tooling Plugin, right click and add breakpoints
- Information provided by the Debugger Tool: the message envelope, message mediation properties.
- Add Property
- Changing the property values: Injecting new properties and Clearing a property, Modifying a property.
- Viewing wire logs of a specific mediator
while debugging
After debugging execution of mediator
A proxy service after debugging 
In the next blog I will explain what has been changed in WSO2 5.0.0 beta comparing WSO2ESB 4.9.0, something about the compatible WSO2 product version and something about the fixed and known issues. If you have any questions or want to share your thoughts, leave a comment below!
{{cta(‘a0eeb79a-3a7c-4c58-bca6-dc38b7bc3b7d’)}}
