Parameter values can be specified in code using a parameter filter. Note that there can be only one parameter filter per engine instance. The IParameterFilter replaces the deprecated IRuntimeConfig from prior releases.

public class MyParameterFilter 
    implements IParameterFilter, INodeGroupExtensionPoint {

    /**
     * Only apply this filter to stores
     */
    public String[] getNodeGroupIdsToApplyTo() {
        return new String[] { "store" };
    }

    public String filterParameter(String key, String value) {
        // look up a store number from an already existing properties file.
        if (key.equals(ParameterConstants.EXTERNAL_ID)) {
            return StoreProperties.getStoreProperties().
              getProperty(StoreProperties.STORE_NUMBER);
        } 
        return value;
    }

    public boolean isAutoRegister() {
        return true;
    }

}

Data can be filtered as it is loaded into the target database. It can also be filtered when it is extracted from the source database. As data is loaded into the target database, a filter can change the data in a column or save it somewhere else. It can also specify by the return value of the function call that the data loader should continue on and load the data (by returning true) or ignore it (by returning false). One possible use of the filter might be to route credit card data to a secure database and blank it out as it loads into a less-restricted reporting database.

An IDataLoaderContext is passed to each of the callback methods. A new context is created for each synchronization. The context provides methods to lookup column indexes by column name, get table meta data, and access to old data if the sync_column_level flag is enabled. The context also provides a means to share data during a synchronization between different rows of data that are committed in a database transaction and are in the same channel. It does so by providing a context cache which can be populated by the extension point.

Many times the IDataLoaderFilter will be combined with the IBatchListener. The XmlPublisherFilter (in the org.jumpmind.symmetric.ext package) is a good example of using the combination of the two extension points in order to create XML messages to be published to JMS.

A class implementing the IDataLoaderFilter interface is injected onto the DataLoaderService in order to receive callbacks when data is inserted, updated, or deleted.

public MyFilter implements IDataLoaderFilter {
                
    public boolean isAutoRegister() {
        return true;
    }
 
    public boolean filterInsert(IDataLoaderContext context,
        String[] columnValues) {
        return true;
    }
    
    public boolean filterUpdate(IDataLoaderContext context, 
        String[] columnValues, String[] keyValues) {
        return true;
    }
    
    public void filterDelete(IDataLoaderContext context, 
        String[] keyValues) {
        return true;
    }

}

The filter class is specified as a Spring-managed bean. A custom Spring XML file is specified as follows in a jar at META-INF/services/symmetric-myfilter-ext.xml.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-3.0.xsd">
 
    <bean id="myFilter" class="com.mydomain.MyFilter"/>
     
</beans>

Implement this extension point to filter out specific columns from use by the dataloader. Only one column filter may be added per target table.

This extension point is called whenever a batch has completed loading but before the transaction has committed.

Implement this extension point to receive callback events when a batch is acknowledged. The callback for this listener happens at the point of extraction.

Implement this extension point to listen in and take action before or after a reload is requested for a Node. The callback for this listener happens at the point of extraction.

This extension point is called after data has been extracted, but before it has been streamed. It has the ability to inspect each row of data to take some action and indicate, if necessary, that the row should not be streamed.

This extension point is used to select an appropriate URL based on the URI provided in the sync_url column of sym_node.

To use this extension point configure the sync_url for a node with the protocol of ext://beanName. The beanName is the name you give the extension point in the extension xml file.

This extension point allows SymmetricDS users to implement their own algorithms for how node ids and passwords are generated or selected during the registration process. There may be only one node generator per SymmetricDS instance.

Implement this extension point to get status callbacks during trigger creation.

Implement this extension point and set the name of the Spring bean on the batch_algorithm column of the Channel table to use. This extension point gives fine grained control over how a channel is batched.

Implement this extension point and set the name of the Spring bean on the router_type column of the Router table to use. This extension point gives the ability to programatically decide which nodes data should be routed to.

Implement this extension point to get callbacks during the heartbeat job.

Implement this extension point to get callbacks for offline events on client nodes.

Implement this extension point to get callbacks for offline events detected on a server node during monitoring of client nodes.

Implement this extension point to intercept the saving and rendering of the node password.

Implement this extension point to allow additional Servlets to be registered with SymmetricDS. This is probably only useful if SymmetricDS is running in standalone or embedded mode.