WSO2 ESB: Polling a database for changes

WSO2 ESB has DBLookup mediator to read data from a database. But in some cases, you may need ESB to keep polling a database and proceed with some operations only if there's a change in it. Although this is not supported out-of-the-box, we can easily write a simple class mediator to implement this requirement.

One problem that arises when doing this is that there's no way to keep a value in-memory across multiple messages, since the properties used in ESB artifacts are local to the message context. To overcome this, we can consider two options:

1. Writing a class mediator that keeps the last read value in an instance variable and performs any comparisons required to identify changes in the database.


2. Simply store the last read value to another table/field and compare it with the current field (this requires multiple DBLookup/Report calls).

In this blog post, we'll explore how we can implement the first option.

So the basic flow will be:

• A scheduled task keeps calling a sequence
• In the called sequence, we have a DBLookup mediator that fetches a field from a database table (includes a column that indicates a change, such as a timestamp)
• The change indicator field is extracted and added to a property
• Class mediator is called, it compares the property's current value with the previously stored value and sets the result (changed or not) to another property
• With a filter on the resultant property, we can identify a change and proceed with necessary operations

A sample configuration is as follows.

The scheduled task that keeps calling a sequence:

The sequence that does the DB lookup and identifies if there's a change:

Sample code for the class mediator used in the above sequence can be found here.

WSO2 ESB: Transferring data from files to a database

In some integration scenarios you may want to use ESB to poll a directory for files and store the content to a database.

Following steps can be used to read CSV files from a directory, extract their data and then store them in a database.

We use a VFS proxy to poll the directory and look for new files. The parameters transport.vfs.FileURI and transport.vfs.FileNamePatter are used to indicate where/what types of files to look for (any regular expression can be used here).
Once a file is read, we need to convert it to a format that is supported by the DB Report mediator of the ESB. In this case we convert the csv data to xml using the Smooks mediator.

Once the conversion is done, we can easily use the converted xml data inside the DB Report mediator to enter them to a DB with XPath expressions.

In addition, we can specify some actions such as where the file to be placed (or deleted) after storing in the DB (transport.vfs.ActionAfterProcess),  what actions to be taken if a failure occurs (transport.vfs.ActionAfterFailure) etc

The complete proxy configuration is given below. Please note that you have to enable vfs transport in axis2.xml in order to get this working.

In addition to the above proxy, you have to add the smooks-config xml file to the location specified in the proxy configuration. The smooks configuration for this sample is as follows:

You also need to add a local entry to the esb configuration to point to the smooks config file. (the above proxy configuration points to this local entry key for smooks configuration)

Switching from HTTP/HTTPS to VFS in WSO2 ESB

In some cases, there can be requirements to transfer some content arriving through the HTTP transport to an FTP/SFTP location synchronously and then acknowledge the http client with the status of the transfer. This can easily be accomplished with a proxy similar to the following in WSO2 ESB 4.8.x.

Here we use the OUT_ONLY property when calling the VFS endpoint since we are not going to receive a response from it. We use the call mediator to synchronously call it. Also we append retry counts and and reconnection timeouts to the VFS URI to retry transfer in case the endpoint is temporarily unavailable. Finally we build a payload with the status and send it back to the client using respond mediator. 

Disabling http access logs in WSO2 CEP and other carbon products

When you use the http input adaptor of CEP 3.1.0, after some time you may notice that the http access log files are growing large when there are frequent http requests.  (this happens when we use the servlet transport, hence this does not apply to ESB and other products with synapse engine)

You can disable the http access logs as follows:

Goto repository/conf/tomcat/catalina-server.xml. At the bottom part of the file, you'll find an entry like following

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="${carbon.home}/repository/logs" prefix="http_access_" suffix=".log" pattern="combined" />

Comment this out or remove this entry to disable the access log and restart the server.