Skip to Main Content

WSO2 ESB Tutorial: Local registry entries, reusable endpoints and sequences

In this article, we will learn how to reuse endpoints and sequences for your development projects, using the key name of each one of them.

-Before we begin, if you missed the previous tutorial, catch up right now!-

Configuring the ESB

The following diagram is a configuration example that is to be deployed in the ESB. In definition, a LocalEntry or local registry is used. Said local registry acts as a memory registry where you can store text strings, XML code, or a URL. These entries can be referenced from mediators. Also, they can be created directly from the Enterprise Service Bus configuration, or through the User Interface.

-Find out why WSO2 ESB is the best enterprise integration solution for your business –

How it works

The following diagram summarizes everything that we will cover:

diagram platform wso2

-WSO2 ESB Tutorial 1: Simple Message Content-Based Routing using Filter Mediator-

In this instance, the element <localEntry key=”version”>0.1</localEntry> has generated a memory zone with the value 0.1. This local registry entry can be seen by using the interface. In order to do that, we must navigate to the left side of the screen, where ‘Service Bus’ appears, as it is shown in the picture.

WSO2 Enterprise Service Bus

Selecting ‘Local Entries’ will show the contents of the local registry:

local register wso2

Inlined Text stores a text entry without format, and by selecting ‘Edit’ we will be able to see its contents:

Inlined text entry

-Don’t miss the success case of the WSO2 systems integration in a market-leader automobile company-

Testing the configuration

Now we can test the ESB configuration. In order to do that, what we must do first is run the backend, and to start the AXI2Server server:

wso2esb-4.9.0/samples/axis2Server$ ./

After that, to send the request from the client, we must go to:

And type:

ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/

This is the request that is sent from the client to the ESB:

answer client to ESB

The request enters through the ‘main’ sequence. The main sequence acts as a default entry point for the messages received through Synapse. In that sequence, a ‘direction’ property with the value ‘incoming’ is created. Next, the ‘stock quote’ sequence is called, which is defined as an independent sequence with a name and is therefore reusable. This sequence prints the value of the property in the console: Text, version (defined in the LocalEntry), and directionTEXT VERSION WSO2

The XPath get-property () function can look up the properties of the local messages to the current message, remote and local registry entries, Axis2 message context properties, and the transport headers.

At the end of the sequence, there is a mediator that sends the request to the endpoint previously defined with the name ‘simple.’

The request reaches the endpoint and it returns a response that goes through the ‘out’ mediator:

mediator out wso2

Finally, the client can see the result in the command line:

command line

To obtain more information regarding the log exit in the console, it is better to activate the wire log. In this way, we will obtain details regarding the message header and the payload. In order to do that, we must navigate to ‘Configure,’ ‘Logging.’

wso2 esb logging

In the ‘Filter Loggers by’ text box, we must type: ‘wire’ and select ‘Contains.’ As we can see, three types of loggers will appear, and we must select ‘TRACE’ for all of them, as the following picture shows.

logging configuration wso2

On the other hand, to test the functioning of the ‘fault’ sequence, we can stop the backend with Ctrl+C. Afterwards, we must send another request from the client (we previously taught how to do it) and observe the console logs from the Enterprise Service Bus. Now we can see how the values of the properties defined in this sequence are printed: MESSAGE, ERROR_CODE and ERROR_MESSAGE.

message wso2


Thanks to the fact that sequences and endpoints can be labeled with their names, these can be reused in different points of the Enterprise Service Bus configuration. It allows for the good practice of code reuse and the generation of sequence libraries—something similar to what happens in the world of programming. In addition to this, the ESB has the ability to create for us a memory space that is defined in the LocalEntry, where we can store our static variables and use them as variables in the code. As you can see, this allows for another good practice to not include static values in the code of our configurations. It’s great, don’t you think so?