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.
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.
How it works
The following diagram summarizes everything that we will cover:
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.
Selecting ‘Local Entries’ will show the contents of the local registry:
Inlined Text stores a text entry without format, and by selecting ‘Edit’ we will be able to see its contents:
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:
After that, to send the request from the client, we must go to:
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:
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 direction
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:
Finally, the client can see the result in the 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.’
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.
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.
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?