ESB 12 WSO2 ESB Tutorial: Introduction to Dynamic Sequences with Registry

ESB 12

WSO2 ESB Tutorial:
Introduction to
Dynamic Sequences with
Registry

Index

1. Introduction
2. EI configuration Example
3. Running Example
4. Conclusion

1. Introduction

As we show in previous blog with XSLT mediator, a sequence can be defined dynamically through the registry. Artefact that can be configured dynamically are: sequences, endpoints and configuration resources. On the following example the sequence is referenced as a key. That key is related with a value stored into the registry. That value is loaded dynamically by the ESB at runtime and cached. After the cache duration time expired the resource is reloaded if needed.

2. EI configuration Example

The following image shows Enterprise Integrator configuration:

The resource that main sequence key makes reference, and is dynamically loaded, is this one: file:

samples/service-bus/resources/sequence/dynamic_seq_1.xml

The content of that sequence is displayed below the definition XML file. A log mediator displays a message and the request is redirected to the endpoint. The response is directed to the Client by the send mediator.

3. Running Example

There are two ways to launch the request:

- In the folder /samples/axis2Client with the command line:

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

- Or using SOAPUI and writing the request. 

The next image displays SOAPUI Request. Do not forget to include the header: SOAPAction with the value: urn:getQuote to invoke the appropriate method on Server side.

When executing the example for second time and after less than 15 secongs since the previous request was launch, the resource continues into the cache. If dynamic_seq_1.xml is modified and after more than 15 seconds, the sequence is going to be reloaded. 

Next images displays Request and Response:

This is the response coming from the backend:

4. Conclusion

Thanks to the dynamic behaviour of Synapse through the use of a registry there are a few resources that can be modified and loaded without EI restarting.

ESB 11 WSO2 ESB Tutorial: Introduction to Static and Dynamic Registry Resources, and Using XSLT Transformations.

ESB 11

WSO2 ESB Tutorial:
Introduction to Static and
Dynamic Registry Resources,
and Using XSLT
Transformations

Index

1. Introduction
2. EI configuration Example
3. Running Example
4. Conclusion

1. Introduction

XSLT mediator is a useful component to transform a message to other format. It is used for example when we are interconnecting two external applications that use different message format. On the other hand we will study this time how to store configuration metadata into local registry and remote registry. On the example the XSLT transformations are specified as a registry resource.

2. EI configuration Example

This is the configuration for the EI:

The XSLT are identified as registry resources. Local entries do not place the resource on the registry, but simply make it available to the local configuration. If a local entry is defined with a key that already exists in the remote registry, the local entry will get higher precedence over the remote resource. Remote means that we can have Governance Registry configured in another host. On this way registry space can be shared among multiple product. The following picture shows a remote Governance Registry configuration:

Synapse uses a simple URL based registry implementation (SimpleURLRegistry): org.apache.synapse.registry.url.SimpleURLRegistry
WSO2 has implemented this other one:
org.wso2.carbon.mediation.registry.ESBRegistry

The parameters of the registry are:

• root=  which specifies a prefix for the registry keys used later. This root is prefixed to the entry keys to form the complete URL of the resource being looked up.
• cachableDuration= The resource is going to be stored locally for a specified duration. After that time the resource is reloaded and cache refreshed. Because of the cache, it is not needed to restart Synapse (EI) if there is a change on a resource.

XML transforms the request to a standard stock quote request. And the response from the SimpleStockQuoteService is converted back into the custom format as expected by the client during the out message processing.

• This is the flow: Request -> transform.xslt -> Request after transform

• This is the flow: Response -> transform_back.xslt -> Response after transform_back

3. Running Example

To test the example you can use SOAPUI with the requests from point 2. This is an example of how the request would look like in SOAPUI:

The first time the response is processed by the EI the class ESBRegistry load in memory the resource: transform/transform_back.xslt

That resource is going to last 15000 ms in memory as a cash. After that time and if the resource is requested again the cache reload it. If the resource is in memory when a new response is in process the cache is not going to be reloaded. If the resource has been modified the cache is refreshed.

4. Conclusion

To summarise, the static resource is the one loaded with the Local Entry, and the dynamic is the one that refers to the root value in the registry configuration. Something important to remember is the fact that the middleware interconnect different applications and because of that maybe every one use a different format of the messages. The solution to interconnect both applications is with the Message Translator pattern that WSO2 implements with the XSLT mediator.

ESB 10 WSO2 ESB Tutorial: Introduction to Local Registry Entries & Using Schema Validation

ESB 10

WSO2 ESB Tutorial:
Introduction to
Local Registry Entries &
Using Schema Validation

Index

1. Introduction

2. EI configuration Example

3. Running Example

4. Conclusion

1. Introduction

The validation of incoming messages is very important task. It is the way to avoid to process messages bad formatted or with no sense. Following the good practices those invalid messages must to be redirected to an Invalid Message Channel. For now we are going to study how to use an XSD schema file to validate its XML file related.

2. EI configuration Example

As you know EI (Enterprise Integrator) is our middleware. The client, can be SOAPUI, sends a request to the backend SimpleStockQuoteService through the EI. In the in sequence there is a validate mediator (for XML schema validation) that filter those inconsistent messages. The mediator uses an XSD schema of the XML request and validates the content of the first child of the message with the following path:
getQueote > request > stocksymbol.
The problem is that the request contains this other path:
getQueote > request > symbol
and because it is not the same path an error message is returned to the client. On the other hand, the XSD schema is stored statically as a localEntry. In general, the resources defined in the local registry are static (never changes over the lifetime of the configuration) and may be specified as a source URL, inline text or inline XML.

3. Running Example

After starting SimpleStockQuoteService send the following request with SOAPUI:


This is a screenshot of SOAPUI with the request and response from EI:


Because the request is using a wrong element name the response from EI is an error message:

4. Conclusion

The validation mediator is key to follow good practices when integration applications. It is a way to minimize the time lost in processing erroneous requests. The Validate mediator validates XML/JSON messages against a specified schema. You can specify an XPath/JSONPath to extract and validate a specific part of the message. Otherwise, the mediator validates the first child of the SOAP body of the current message or the complete content of the current message for a JSON request.

ESB 9 WSO2 ESB Tutorial: Manipulating SOAP Headers & Filters Incoming/Outgoing Messages

ESB 9

WSO2 ESB Tutorial:
Manipulating SOAP Headers &
Filters Incoming/Outgoing
Messages

Index

1. Introduction

2. EI configuration Example

3. Running Example

4. Conclusion

1. Introduction

The header mediator is useful for handling SOAP headers and the in/out mediators for filtering requests and responses. I mean, the requests are redirected to the in channel and the responses are redirected to the out channel.

2. EI configuration Example

The client sends the request to the EI and it is processed by the main sequence and redirected to the in mediator. There is another mediator inside, a header mediator. The header mediator allows you to manipulate SOAP and HTTP headers. This time we are going to experiment with to Soap Header. The header mediator sets the WS-Addressing 'To' header on the request. It specifies the address URI of the ultimate receiver of this message. The last mediator, send, it sends the message to the endpoint specified by the to header. The responses from the backend are redirected to the main sequence, but because it is a response, it does not go through the main sequence, it goes to the send mediator directly, and that mediator sends the response back to the client.

3. Running Example

Start the Axis2 server with the back-end service SimpleStockQuoteService:


Configure the EI with the code shown on EI configuration Example. It is better to write it than to copy and paste the code to remember better the key mediators and EI configuration in general. Now, type this command line to send the request:

$ ant stockquote -Dtrpurl=http://localhost:8280/



The request sent is this one:


You can use SOAPUI to replicate the request:


The request is correctly sent to the backend specified in TO header. This is the request that is sent from EI to the backend:


And this is the response coming from the backend:

4. Conclusion

As you can see there are two important concepts here. That is, to understand what mediator processes the request and the response, IN and OUT respectively. The SEND mediator, on our example, is always executed by the response and never pass through the IN sequence. Other cases the response will be processed by the OUT sequence. On the other hand, we have shown the big utility that is TO header to change the endpoint where the request is redirected. This can be very useful for instance with Message Router channel, where depending on the value of the payload or some header fields the message can be redirected to different endpoints.