ESB 6
WSO2 ESB Tutorial:
Local registry entries, reusable
endpoints and sequences
Local registry entries, reusable
endpoints and sequences
Index
1. Introduction
2. Configuring the ESBa) How it works
b) Testing the configuration.
3. Conclusion
1. Introduction
Now we will learn how to reuse endpoints and sequences for your development projects, using the key
name of each one of them.
name of each one of them.
2. 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.
a. 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.
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.
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:
b. 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$ ./axis2server.sh
After that, to send the request from the client, we must go to:
wso2esb-4.9.0/samples/axis2Client$
And type:
-Daddurl=http://localhost:9000/services/SimpleStockQuoteService
-Dtrpurl=http://localhost:8280/
-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
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.
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.'
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.'
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.
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.
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.
ERROR_CODE and ERROR_MESSAGE.
3. Conclusion
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.
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?
configurations. It's great, don't you think so?
No comments:
Post a Comment