[WSO2 ESB] XSLT Mediator - XSLT Imports

There can be situations where we want to import xslt scripts to the main xslt script defined in XSLT mediator.
This requirement can be achieved using Resources in XSLT mediator.

Imported xslt file has to be defined as a XSLT Resource.

Following is a sample.

I have following two xslt files.

xslt1.xslt

xslt2.xslt

xslt1.xslt is included by the xslt2. Both files are stored in the registry under conf:/

Following is a sample proxy service configuration.

Note the resource element of xslt mediator configuration.

Here location should be matched to the 'href' of and key should point to the registry path of the included xslt file. 

Following is the request format to test this proxy configuration.

 
     
     
         
             
                Isuru 
                Udana 
                Male 
                26 
                SriLanka 
             
             
                Ishan 
                Jayawardena 
                Male 
                26 
                SriLanka 
             
         
     

Synapse get-property function

Get property function retrieves a property from the message context at the given scope. If the scope is not specified, property is retrieved from the default synapse scope.

Syntax:
get-property(String scope, String propertyName)
get-property(String propertyName)

Supported Scopes

• default
• axis2
• transport
• registry
• system

Default scope

Message context properties resides in synapse scope can be retrieved from the default scope. Apart from user defined properties, following special properties can be retrieved from the default scope.
Syntax:

get-property('default', String propertyName)
get-property(String propertyName)


Special Properties supported by get-property function in Default Scope
(Extracted from http://docs.wso2.org/display/ESB470/XPath+Extension+Functions)

Name	Return Value
To	Incoming URL as a String or empty string if a To address is not defined.
From	From address as a String or empty string if a From address is not defined
Action	SOAP Action header value as a String or empty string if a Action is not defined
FaultTo	SOAP FautTo header value as a String or empty string if a FaultTo address is not defined
ReplyTo	ReplyTo header value as a String or empty string if a ReplyTo address is not defined
MessageID	A unique identifier (UUID) for the message as a String . This id is guaranteed to be unique.
FAULT	TRUE if the message has a fault or empty string if message doesn't have a fault
MESSAGE_FORMAT	Returns pox, get, soap11, soap12 depending on the message. If a message type is unknown this returns soap12
OperationName	Operation name corresponding to the message.

Axis2 scope

Message context properties resides in axis2 scope can be retrieved from the axis2 scope.
Syntax:
get-property('axis2', String propertyName)

Transport scope

Message context properties resides in transport scope can be retrieved from the transport scope.
Syntax:
get-property('transport', String propertyName)

Registry scope

Properties resides in registry can be retrieved from the registry scope.
Syntax:
get-property('registry', String registryPath@propertyName)
get-property('registry', String registryPath)

System scope

Java System properties can be retrieved from the system scope. Syntax:
get-property('system', String propertyName)

Note: system scope is only available in synapse 3.0 or later versions and WSO2 ESB 4.8.0 or later versions.

Maven Archetypes for WSO2 ESB Customizable Artifacts

WSO2 ESB provides most of the features you need to build your integration scenarios.
But there can be situations where built-in functionality is not sufficient to implement your requirement.
To cope with those situations WSO2 ESB has given you the enough freedom to simply extend the functionality by implementing custom artifacts.

Following are some of the main extension points where you can extend the functionality.

1. Class Mediators
2. Custom Tasks
3. Message Builders
4. Message Formatters

I am not going to discuss much on these artifacts here. Intention of this post is to provide you an easy way of creating these artifact projects.
I have created maven-architypes for above four artifacts.

You can checkout them from here.

Example usage

Let's create a project structure for a Class mediator.

1. Go to maven-archetype-classmediator directory.
Execute the command
mvn install

This will install classmediator maven archetype to your maven repository.

2. Go to the location where you want to create a new project structure.
Execute the command
mvn archetype:generate -DarchetypeCatalog=local -DarchetypeGroupId=org.wso2.carbon  -DarchetypeArtifactId=maven-archetype-classmediator

3. You will be prompted to enter following details.
groupId
artifactId
version
mediator_name

This will create the project structure for your class mediator.
Now you can edit the Mediator java class and write your logic in the mediate() method.

4. After writing the code, you can simply execute the command
mvn clean install
to compile and create the jar file of the class mediator.

[WSO2 ESB] Generate an UUID using a script mediator

Following is a simple sequence which generates an UUID using a script mediator.

Generated UUID is saved as a message context property.

[WSO2 ESB] Improve Callout Mediator Performance

Callout mediator internally uses the axis2 CommonsHTTPTransportSender to invoke services.

According to [1] MultiThreadedHttpConnectionManager which manages the connections, only allow two simultaneous connections at a time per a host. So with slow back-end services we will experience a significant degrade in the performance.

To overcome this issue we can alter the default configuration and increase the number of simultaneous connections.

We can set the CommonsHTTPTransportSender parameters as follows at

<ESB_HOME>/samples/axis2Client/client_repo/conf/axis2.xml

        HTTP/1.1
        chunked
        true
        100

In the above configuration, defaultMaxConnectionsPerHost parameter has increased to 100.

For more information about improving axis2 http transport client, refer to the resource available at [1].

[1] http://amilachinthaka.blogspot.com/2010/01/improving-axis2-http-transport-client.html

[WSO2 ESB] All About Wire Logs..!

Intention of this post is to give you an idea of what you should know about wire logs in WSO2 ESB.

While working with ESB, sometimes we come across situations where we want see the actual http messages which goes out from the ESB or coming into the ESB. Wire logs functionality is there to fulfill that requirement.

Passthrough http transport is the main transport which handles http/https messages in WSO2 ESB. Following is how we can enable wire logs for Passthrough http transport.

Enabling wire logs

1. open log4j.properties file from a text editor.

log4j.properties file is located in /repository/conf directory.

2. Un-comment the following entry.

log4j.logger.org.apache.synapse.transport.http.wire=DEBUG

Above described procedure applies to WSO2 ESB 4.7.0 or higher versions.

Entry to un-comment in log4j.properties is slightly different in previous versions.

For ESB 4.6.0 :

log4j.logger.org.apache.synapse.transport.passthru.wire=DEBUG

For ESB 4.5.1 or previous versions :

log4j.logger.org.apache.synapse.transport.nhttp.wire=DEBUG

Reading wire logs

Following is a sample wire log get printed for the above scenario for a one request.

[2013-09-22 19:47:57,797] DEBUG - wire >> "POST /services/StockQuoteProxy HTTP/1.1[\r][\n]"

[2013-09-22 19:47:57,798] DEBUG - wire >> "Content-Type: text/xml; charset=UTF-8[\r][\n]"

[2013-09-22 19:47:57,798] DEBUG - wire >> "SOAPAction: "urn:getQuote"[\r][\n]"

[2013-09-22 19:47:57,799] DEBUG - wire >> "User-Agent: Axis2[\r][\n]"

[2013-09-22 19:47:57,799] DEBUG - wire >> "Host: localhost:8280[\r][\n]"

[2013-09-22 19:47:57,799] DEBUG - wire >> "Transfer-Encoding: chunked[\r][\n]"

[2013-09-22 19:47:57,800] DEBUG - wire >> "[\r][\n]"

[2013-09-22 19:47:57,800] DEBUG - wire >> "215[\r][\n]"

[2013-09-22 19:47:57,800] DEBUG - wire >> "http://localhost:8280/services/StockQuoteProxyurn:uuid:9e1b0def-a24b-4fa2-8016-86cf3b458f67urn:getQuoteIBM[\r][\n]"

[2013-09-22 19:47:57,801] DEBUG - wire >> "0[\r][\n]"

[2013-09-22 19:47:57,801] DEBUG - wire >> "[\r][\n]"

[2013-09-22 19:47:57,846]  INFO - TimeoutHandler This engine will expire all callbacks after : 120 seconds, irrespective of the timeout action, after the specified or optional timeout

[2013-09-22 19:47:57,867] DEBUG - wire << "POST /services/SimpleStockQuoteService HTTP/1.1[\r][\n]"

[2013-09-22 19:47:57,867] DEBUG - wire << "Content-Type: text/xml; charset=UTF-8[\r][\n]"

[2013-09-22 19:47:57,867] DEBUG - wire << "SOAPAction: "urn:getQuote"[\r][\n]"

[2013-09-22 19:47:57,867] DEBUG - wire << "Transfer-Encoding: chunked[\r][\n]"

[2013-09-22 19:47:57,868] DEBUG - wire << "Host: localhost:9000[\r][\n]"

[2013-09-22 19:47:57,868] DEBUG - wire << "Connection: Keep-Alive[\r][\n]"

[2013-09-22 19:47:57,868] DEBUG - wire << "User-Agent: Synapse-PT-HttpComponents-NIO[\r][\n]"

[2013-09-22 19:47:57,868] DEBUG - wire << "[\r][\n]"

[2013-09-22 19:47:57,868] DEBUG - wire << "215[\r][\n]"

[2013-09-22 19:47:57,868] DEBUG - wire << "http://localhost:8280/services/StockQuoteProxyurn:uuid:9e1b0def-a24b-4fa2-8016-86cf3b458f67urn:getQuoteIBM[\r][\n]"

[2013-09-22 19:47:57,868] DEBUG - wire << "0[\r][\n]"

[2013-09-22 19:47:57,869] DEBUG - wire << "[\r][\n]"

[2013-09-22 19:47:58,002] DEBUG - wire >> "HTTP/1.1 200 OK[\r][\n]"

[2013-09-22 19:47:58,002] DEBUG - wire >> "Content-Type: text/xml; charset=UTF-8[\r][\n]"

[2013-09-22 19:47:58,002] DEBUG - wire >> "Date: Sun, 22 Sep 2013 14:17:57 GMT[\r][\n]"

[2013-09-22 19:47:58,002] DEBUG - wire >> "Transfer-Encoding: chunked[\r][\n]"

[2013-09-22 19:47:58,002] DEBUG - wire >> "Connection: Keep-Alive[\r][\n]"

[2013-09-22 19:47:58,002] DEBUG - wire >> "[\r][\n]"

[2013-09-22 19:47:58,014] DEBUG - wire << "HTTP/1.1 200 OK[\r][\n]"

[2013-09-22 19:47:58,015] DEBUG - wire << "Content-Type: text/xml; charset=UTF-8[\r][\n]"

[2013-09-22 19:47:58,015] DEBUG - wire << "Date: Sun, 22 Sep 2013 14:17:58 GMT[\r][\n]"

[2013-09-22 19:47:58,015] DEBUG - wire << "Server: WSO2-PassThrough-HTTP[\r][\n]"

[2013-09-22 19:47:58,016] DEBUG - wire << "Transfer-Encoding: chunked[\r][\n]"

[2013-09-22 19:47:58,016] DEBUG - wire << "[\r][\n]"

[2013-09-22 19:47:58,016] DEBUG - wire >> "4d8[\r][\n]"

[2013-09-22 19:47:58,017] DEBUG - wire >> "urn:getQuoteResponseurn:uuid:9e1b0def-a24b-4fa2-8016-86cf3b458f673.827143922330303-8.819296796724336-170.50810412063595170.73218944560944Sun Sep 22 19:47:57 IST 2013-170.472077024782785.562077973231586E7IBM Company178.0616712932281324.9438904049222641.9564266653777567195.61908401976004IBM6216[\r][\n]"

[2013-09-22 19:47:58,017] DEBUG - wire >> "0[\r][\n]"

[2013-09-22 19:47:58,018] DEBUG - wire >> "[\r][\n]"

[2013-09-22 19:47:58,021] DEBUG - wire << "4d8[\r][\n]"

[2013-09-22 19:47:58,022] DEBUG - wire << "urn:getQuoteResponseurn:uuid:9e1b0def-a24b-4fa2-8016-86cf3b458f673.827143922330303-8.819296796724336-170.50810412063595170.73218944560944Sun Sep 22 19:47:57 IST 2013-170.472077024782785.562077973231586E7IBM Company178.0616712932281324.9438904049222641.9564266653777567195.61908401976004IBM6216[\r][\n]"

[2013-09-22 19:47:58,022] DEBUG - wire << "0[\r][\n]"

[2013-09-22 19:47:58,022] DEBUG - wire << "[\r][\n]"

To read the wire log, first we have to identify message direction.

DEBUG - wire >>    - This represent the message coming into ESB from the wire

DEBUG - wire <<    - This represent the message goes to the wire from ESB

As you can see there are two incoming messages and two outgoing messages in the above log.

First part of the log of a message contain the http headers and it is followed by the message payload.

Wire logs are very useful when it comes to troubleshooting unexpected issues occurring while integrating systems. 

We can verify whether message payload is correctly going out from the ESB, http headers like Content-Type is properly set in the outgoing message, etc. by looking at the wire logs.

Please note that wire logs should be enabled for the troubleshooting purposes only. Running productions systems with wire logs enabled is not recommended.

Wire logs for Callout Mediator

Callout mediator uses the Axis2 CommonsHTTPSender to invoke services. It does not leverages the non blocking nhttp/passthrough transports. So to enable wire logs, we have to follow a different approach as follows.

1. open log4j.properties file from a text editor.

2. Put the following two entries to the log4j.properties.

log4j.logger.httpclient.wire.header=DEBUG

log4j.logger.httpclient.wire.content=DEBUG

[WSO2 ESB] How to set an enclosing element for Aggregated Messages

In this post I am describing how we can add an enclosing element (root element) for the aggregated message of the Aggregate mediator.

To explain the scenario I am using the sample 400 which is shipped with WSO2 ESB.

Setup and run the sample following the instruction given in this link.

Inspect the response received to the axis2Client by placing TCPMon in between axis2Client and ESB.

Following is a sample response message.

  
      
         
            
               4.090953902529174
               12.85037561648507
               82.1992668503766
               79.11591459453155
               Thu Jul 04 19:12:12 IST 2013
               82.07587397906588
               -6710370.759280889
               IBM Company
               82.63216328626984
               -17.95776979490757
               -5.425366866770642
               -75.40418930165814
               IBM
               18847
            
         
         
            
               -2.7046470446807556
               12.566122355911308
               95.09065335757121
               90.75101849376846
               Thu Jul 04 19:12:12 IST 2013
               -90.38486186977777
               4.217188439214337E7
               IBM Company
               94.37670271591331
               25.37945343517513
               3.0241695702614373
               -89.43437138172582
               IBM
               19672
            
         
         
            
               4.170662251407396
               12.24073118459008
               57.80396418762341
               55.33092046169671
               Thu Jul 04 19:12:12 IST 2013
               -54.950295275739805
               6356550.833371431
               IBM Company
               -54.49917237967579
               -17.964379539768633
               -8.124197423811651
               -51.336298637738366
               IBM
               18228
            
         
         
            
               -2.298457196037509
               13.480896570232673
               59.92552901947371
               58.08646649831848
               Thu Jul 04 19:12:12 IST 2013
               60.343852005584246
               1528927.6138464957
               IBM Company
               -57.030367770791436
               24.09552605569928
               -3.6045836945736744
               63.76484473082417
               IBM
               8436
            
        

You can see this message contains multiple root elements (getQuoteResponse).
Having message in this format causes difficulties in mediating the message further using other mediators.
To overcome this we have to enclose these elements with a single root element.

In ESB 4.7.0 a new configuration option for aggregate mediator has introduced to simply achieve this requirement.
We can define the root element in a property of type "OM" in the mediation follow.
To refer to it, we have the configuration option in the aggregate mediator called "enclosingElementProperty". Following is the modified configuration of sample 400 with setting the enclosingElementProperty.

Following is the new response after specifying the enclosing element.

      
         
            
               
                  3.9054693448138935
                  12.335281253927821
                  -177.97866140275778
                  180.6047969462028
                  Thu Jul 04 20:16:43 IST 2013
                  -178.7391258359091
                  1.3120681155222666E7
                  IBM Company
                  188.41308732511013
                  -18.48633858561689
                  -2.1801479505634216
                  -179.1378123583123
                  IBM
                  17410
               
            
            
               
                  4.335889120902175
                  13.604356794261104
                  91.1089618318819
                  87.11090922338691
                  Thu Jul 04 20:16:43 IST 2013
                  91.25197685882299
                  -9612036.072947197
                  IBM Company
                  89.76683766211949
                  23.079190443619655
                  4.535561151210772
                  95.59763337651628
                  IBM
                  19489
               
            
            
               
                  3.904415274394834
                  -9.582989781384908
                  164.68152083949627
                  159.73864569317885
                  Thu Jul 04 20:16:43 IST 2013
                  165.07866093659734
                  1.4527017539759804E7
                  IBM Company
                  164.61880563666864
                  -18.161817565866475
                  -2.4852000517090636
                  -157.1066792675214
                  IBM
                  7699
               
            
            
               
                  -2.457821949254824
                  -8.469473263282257
                  87.5648992841946
                  83.84165661337398
                  Thu Jul 04 20:16:43 IST 2013
                  87.65683642867681
                  5.546665982864492E7
                  IBM Company
                  -81.82301069483687
                  -18.228056188981697
                  -2.6735315383132683
                  91.93166095229475
                  IBM
                  19549
               
            
         
      
   

WSO2 Enterprise Service Bus (ESB) 4.7.0 Released!

Version 4.7.0 of WSO2 ESB, the High Performance, lightweight Open Source ESB was released yesterday.

Following are the brand new features introduced in this release.

Comprehensive REST integration support with HTTP Endpoints

HTTP Endpoint has made the integration with REST services much simpler by allowing us to specify URI Template like endpoint addresses. Endpoint URI can contain variables which can be populated at the runtime.

HTTP method also can be specified within the HTTP Endpoint itself.

JSON support for Payload Factory Mediator

Payload Factory mediator is one of the widely used mediators to do message format transformations. In previous versions, payload format can be specified only in XML. If we want to integrate with services which expect the message in JSON format, we have to construct the message in XML format and set the message type property to application/json to get the message converted to JSON.

In ESB 4.7.0 payload format can be specified directly in JSON format. This is a very useful feature which makes the integration with REST services much simpler.

SSL Tunneling Support

SSL Tunneling support is introduced to both PassThroughHttp and Nhttp transports.

SSL Profiles for both inbound and outbound scenarios

SSL Profiles are supported only for Outbound scenarios in previous versions. In this version of WSO2 ESB we can configure SSL profiles for both Inbound and Outbound scenarios.

ESB can listen for the incoming HTTPS connections from different host IPs and Ports. Inbound SSL profiles feature allows us to have a separate SSL profile for different hosts. We can have a separate trust store and a key store for a SSL profile.

Inbound Connection Throttling support for Pass-Thru and NHTTP transports

With this feature we can limit the number of simultaneous connections which can be established with the ESB.

CRL/OCSP Certificate Revocation Verification

This feature allows to check whether the the given X509 certificate is still a valid certificate (not revoked by CA) at the verification phase of SSL handshake. OCSP/CRL certificate verification process is widely used where high computer security is concerned.

Enhancements

Following are the other major enhancements in this release.

• Enhanced Message Stores and Processors for Guaranteed Delivery and Rate Matching Scenarios
• High Performance Multitenant REST APIs support with Pass-Thru Transport
• Stabilizing Registry Based Deployment Synchronizer
• Invoking Sequences and Proxy Service from Scheduled Tasks
• HL7 Enhancements to support Application-Acknowledgement and Auto-Acknowledgement scenarios
• Transport Header manipulation in Header Mediator
• Enhancement on Content Negotiation in RESTful integration(ie: POX with text/xml)
• JMS MapMessage compatibility for JMS Transport

Apart from the above new features and enhancements, this release of WSO2 ESB comes with significant number (393) of bug fixes.

You can download the distribution of WSO2 ESB 4.7.0 from http://wso2.com/products/enterprise-service-bus/ and give it a try.

[WSO2 ESB] XSLT Mediator Properties

In this post I am discussing how we can use "Properties of the XSLT mediator" in XSLT transformations.

We can inject Properties which we set in the mediation flow to the XSLT script as a XSLT parameter.

Following is a sample configuration of a XSLT mediator having a property.

Here PARAM_NAME is the name of the Property and the value is calculated using a xpath expression. Here we assign the value of the "ORDER_ID" property which is in the default scope.

Following is a sample XSLT script.

First we have to define the parameter as follows. Name should be identical to the name of the property.

Then we can access the value of the parameter as follows.

My Experience with World's Fastest ESB

The world's fastest ESB, 4.6.0 version of WSO2 ESB got released few days ago.
Comparing to earlier versions of WSO2 ESB, this version has improved significantly in mediation performance.

In this version, Pass-through HTTP transport is used as the default http transport.
Pass-through transport is there since ESB 4.0.0 but the major disadvantage in previous versions is, Pass-through transport was supported only for pass through mediation scenario (pass through proxy) and for the transport header based routing. Content aware mediation scenarios like CBR (content based routing) was not supported by Pass-through transport. That prevented making the Pass-through the default transport for HTTP even though it performs well over NHTTP transport. 

In 4.6.0, Pass-through transport supports both content aware and content unaware mediation scenarios, so now there is nothing preventing from making it the default transport for http. Hiranya has written a very nice detailed post on “How the World's Fastest ESB was Made” explaining the history and the technology behind the Pass-through transport.

Recent performance evaluation, ESB Performance Round 6.5 shows how well the WSO2 ESB 4.6.0 outperforms the others. Following is a graph extracted from the results published in ESB Performance Round 6.5.

 

Following graph illustrate the memory usage throughout 40 hours of long running performance test. 

It indicates how stable ESB 4.6.0 under high load for a long period of time.  

Last week I got a chance to work on implementing an integration scenario for a tutorial session of WSO2Con 2013 together with Kasun and Ishan.
The scenario is an extended version of well known “How to GET a Cup of Coffee the WSO2 Way” integration scenario.
Following are some of the key parts of that scenario.

• Exposing a REST API for a SOAP service through ESB
• JSON Handling
• XSLT transformations
• User authentication through Oauth
• JMS Message Stores and Message Processors
• Content based routing
• Protocol switching
• Many other EIP patterns like Message cloning/Iteration/aggregation
• Integration with Data services
• Integration with Message brokers
• Sending Email notifications
• Sending Tweets

We managed to implement all above scenarios using ESB 4.6.0.
That indicates how well the default Pass-through Http transport behaves for both content aware and content unaware scenarios.

Some of the minor but very useful improvements done in 4.6.0 is yet hidden under the shadow of this huge performance improvement.

Callout mediator has improved significantly. Now Callout mediator supports following features.

• Can specify a security policy to invoke secured services
• Has an option to specify different security policies for inbound and outbound paths
• Can specify an Address Endpoint instead of the service url
• Support sending soap headers
• Support sending transport headers

Deploying API configurations from CAR files is now supported in this release.

These facts clearly indicates that WSO2 ESB 4.6.0 release is not just about performance.

[WSO2 ESB] Enable XPath 2.0

XPath 2.0 support is available in WSO2 ESB 4.5.0 and later versions.

To enable XPath 2.0 functions, we have to uncomment following entry in the synapse.properties file.

synapse.xpath.dom.failover.enabled=true

synapse.properties file is located at $ESB_HOME/repository/conf directory.
After enabling xpath 2.0, you will able to use xpath functions like "codepoint-equal()" in your synapse configuration.

If you are using synapse specific xpath functions like "get-property()" within a xpath 2.0 function you have to use them with the prefix "syn".

Follwoing is an example for a such usage.

Above function uses "codepoint-equal()" xpath 2.0 function to compare two properties.

[WSO2 ESB] Sending SMS Alerts for failures

SMS Notifications has become a popular feature for many services.
Isn't it nice if you can get a SMS Alert for a failure in ESB server?
In this post I am discussing how we can send a SMS Alert for a system failure in WSO2 ESB.

Required materials

* Axis2 SMS Transport binary. (download from here)
The Axis2 SMS Transport enables SMPP protocol support for Axis2. It allows Axis2 to connect to a SMSC and send/receive sms. Apart from that it also has a GSM implementation which we can use to connect to a modem and send/receive sms over it.
Please visit [1] for more information.

* JSMPP 2.1.0 binary (download from here)
JSMPP is a java implementation of SMPP protocol. It provides an API to communicate with a SMSC.
Please visit [2] for more information.

* A SMSC Simulator
SMSC Simulator is an application which can be act like a SMSC. Using a simulator we can test our scenario without having access to a real SMSC. For the real production servers we have to use a real SMSC. A simulator is good enough for us for now. I am going to use logica SMSC Simulator for this tutorial.
Download and setup the Simulator following the instruction given at [3].

Now let's move on to the steps.

Step 1

Copy following libraries to $ESB_HOME/repository/components/lib directory.
axis2-transport-sms-1.0.0.jar
jsmpp-2.1.0.jar

Step 2

Enable SMS Transport by adding following configuration under “Transport Senders” section in axis2.xml.
axis2.xml is located at $ESB_HOME/repository/conf/axis2 directory in WSO2 ESB 4.5.x.

    
    
    esb1
    esb123
    localhost
    2775
    ESB1
    

Please refer to [1] to find more details on above parameters.

Step 3

Goto SMSC Simulator directory. You should have following 3 files at there.
smpp.jar
smscsim.jar
users.txt

Edit the users.txt file and add following name-value pairs to it.

name=esb1
password=esb123
timeout=unlimited

Note that ‘name’ is the ‘systemId’ parameter which we have specified at sms transport sender configuration.

Start SMSC Simulator by executing the following command.

java -cp smpp.jar:smscsim.jar com.logica.smscsim.Simulator

You will see a screen like follows.



Enter 1 for the prompt to start simulation.
Enter 2775 as the port number. Note that it is equal to the port which we specified in sms transport sender configuration.

You will see the “Starting listener... started.” log on the console.

Now leave the SMSC Simulator running and let’s go back to configure the ESB server.

Step 4

Start the ESB server and create a proxy service with the following configuration.

   
      
         

         

      
         
      
      
         
            
               $1
            
            
               
            
         
         
            
               

               

         
      
   
 

Let me describe the proxy service configuration in brief.

This configuration is very much similar to the ESB sample 150 configuration [4]. The only difference is, this has a fault sequence specified.
Fault sequence is triggered whenever some failure occurs in the mediation flow.
Here at the fault sequence, we are constructing the message which is to be sent as a SMS using the payload factory mediator.
Error message is extracted and set to the sms body from the ERROR_MESSAGE property.
Finally message is sent over sms transport using an Address Endpoint having the following uri.
sms://94777179968"
94777179968 is the phone number which sms has to be sent.

Step 5

Now let’s run and see how this scenario works.

Start the sample Axis2 server and deploy the SimpleStockQuoteService.
Please refer to [5] for find how to do it.

Now let’s execute the stock quote client by requesting for a stock quote on the proxy service as follows:
ant stockquote -Daddurl=http://localhost:8280/services/StockQuoteProxy

Refer to [6] to find more information on sample clients.

You will see the following log get printed on the Simple axis2 server console.
samples.services.SimpleStockQuoteService :: Generating quote for : IBM

And following get printed on the sample client shell.
Stock price = $98.58846106288853

So that is the success case.

Step 6

Now let’s stop the sample Axis2 server and execute the client again.
ant stockquote -Daddurl=http://localhost:8280/services/StockQuoteProxy

Since sample Axis2 server is not running, SimpleStockQuoteService will not be available at this moment. So the Endpoint will get suspended and the fault sequence will get executed.
A sms containing the error message will be sent to SMSC server.

You will see the following log get printed on the SMSC server.

08:35:05 [sys] new connection accepted
08:35:05 [] client request: (bindreq: (pdu: 33 2 0 1) esb1 esb123  52 (addrrang: 0 0 ) )
08:35:05 [esb1] authenticated esb1
08:35:05 [esb1] server response: (bindresp: (pdu: 0 80000002 0 1) Smsc Simulator)
08:35:05 [esb1] client request: (submit: (pdu: 204 4 0 2) (addr: 0 0 ESB1)  (addr: 0 0 94777179968)  (sm: msg: Alert..! Error In StockQuoteProxy, Connection refused or failed for : localhost/127.0.0.1:9000, IO Exception occured : Connection refused)  (opt: ) )
08:35:05 [esb1] putting message into message store
08:35:05 [esb1] server response: (submit_resp: (pdu: 0 80000004 0 2) Smsc2001 )

In the SMSC command prompt enter 5 to view list of messages.
You will see the sms sent from the ESB server as follows.

For this post I have used the SMPP implementation of Axis2 SMS Transport. You can use the GSM implementation of it also to test this. Please refer to blog post[7] written by Charith to find how to use GSM implementation. And also he has written a comprehensive post [8] on Axis2 SMS transport.

[1] http://ws.apache.org/commons/transport/sms.html
[2] http://code.google.com/p/jsmpp/
[3] http://opensmpp.logica.com/CommonPart/Introduction/Introduction.htm#simulator
[4] http://wso2.org/project/esb/java/4.0.3/docs/samples/proxy_samples.html#Sample150
[5] http://wso2.org/project/esb/java/4.0.3/docs/samples_setup_guide.html#Starting
[6] http://wso2.org/project/esb/java/4.0.3/docs/samples_setup_guide.html#Using
[7] http://charithwiki.blogspot.com/2009/12/invoking-webservices-using-axis2-sms.html
[8] http://charithwiki.blogspot.com/2009/06/axis2-sms-transport.html