This sample demonstrates the functionality of local registry entry definitions, reusable endpoints and sequences.
For a list of prerequisites, see Prerequisites to Start the ESB Samples.
Building the Sample
The XML configuration for this sample is as follows:
This configuration file
synapse_sample_3.xml is available in the
To build the sample
Start the ESB with the sample 3 configuration. For instructions on starting a sample ESB configuration, see Starting the ESB with a sample configuration.
The operation log keeps running until the server starts, which usually takes several seconds. Wait until the server has fully booted up and displays a message similar to "WSO2 Carbon started in n seconds."
Deploy the back-end service SimpleStockQuoteService. For instructions on deploying sample back-end services, see Deploying Sample Back-End Services.
Start the Axis2 server.For instructions on starting the Axis2 server, see Deploying Sample Back-End Services.
Now you have a running ESB instance and a back-end service deployed. In the next section, we will send a message to the back-end service through the ESB using a sample client.
Executing the Sample
This example uses a sequence named main that specifies the main mediation rules to be executed. This is equivalent to directly specifying the mediators of the main sequence within the <
definitions> tag. This sample scenario is a recommended approach for non-trivial configurations.
The sample client used here is the Stock Quote Client, which can operate in several modes. For further details on this sample client and its operation modes, see Stock Quote Client.
To execute the sample client
Run the following command from the
<ESB_HOME>/samples/axis2Clientdirectory, to trigger a sample message to the back-end service.
Analyze the mediation log on the ESB start-up console.
You can see that the sequence named main is executed. Then, for the incoming message flow, the executes and it calls the sequence named stockquote.
You can also see that the stockquote sequence is executed. and that the ldumps a simple text/string property which is the result of an XPath evaluation, that picks up the key named version, and a second result of an XPath evaluation that picks up a local message property set previously by the p . The
get-property()XPath extension function is able to read message properties local to the current message, local or remote registry entries, Axis2 message context properties as well as transport headers. The local entry definition for version defines a simple text/string registry entry, which is visible to all messages that pass through ESB.