Create a Java-based Transformer Service blade

Here we explain how to create a simple Service blade for Transformer, where the blade is written as a Transformer modulein the Java programming language. The core of Transformer is written in C, so to create a module in Java, you use Transformer’s Java Module API.

If you’ve already read How Can I…​ Create a Lua-based Transformer Service blade, you’ll notice that the Lua blade described there does exactly the same thing as the blade we create here. This is entirely deliberate, and should allow you to see the differences and similarities between using Java and Lua for creating Transformer Service blades.

Before you start

This example shows how to create a Java-based Service blade called SpreadJavaBlade that calculates the spread between Bid and Ask prices. At run time, the Transformer receives the prices from a Pricing Adapter (an Integration Adapter), and passes them on to the SpreadJavaBlade Transformer module, which calculates the price spread from the Bid and Ask prices. The Transformer sends the prices, including the new spread field, on to a Liberator, which forwards them to subscribing client applications, as shown in this diagram:

Diagram showing the SpreadJavaBlade module in Transformer

You’ll need a Transformer and Liberator to help test your Service blade while you develop it, and a Pricing Adapter that can supply the Bid and Ask prices. In this example we’ve assumed that the corresponding record fields are called bidPrice and askPrice respectively.

If you don’t have Transformer and Liberator already deployed on a machine for this purpose, you’ll need to deploy one or both of these components to the Deployment Framework on your development machine. To do this, follow the instructions in How can I…​ Deploy Platform components to the Framework. You won’t need to set up HTTPS connections or KeyMaster while you’re developing the blade, so you can ignore the topics about those things.

If you need to develop a suitable Pricing Adapter first, see How can I…​ Create a Java-based Adapter blade.

In the following steps you’ll be using the dfw command of the Deployment Framework. Before entering any dfw command as ./dfw <command-name>, make sure your current (working) directory is set to the Deployment Framework’s topmost directory.

For a list of dfw commands, click here.

Blade structure

What’s in a Java Service blade? Assuming the blade is located in in the Deployment Framework at <Framework-root>/kits/<blade_name>/<blade_name>/, relative to this path:

  • the blade type and blade compatibility information are in the control file

  • the blade’s field definitions are in blade_config/fields.conf

  • Liberator related configuration for the blade is in Liberator/etc/rttpd.conf

  • Transformer related configuration for the blade is in Transformer/etc/java.conf and Transformer/etc/spreadjava.conf

  • the Transformer module’s Java JAR file compiled from the Java source file is in Transformer/lib/java

Create the blade’s directory structure

In a directory that’s outside the Deployment Framework (say Temp_Java_blade), create the following directory structure:

Directory structure of a Java-based Transformer Service Blade

At this stage, you don’t need to create the control file and the .conf and .jar files that are also shown in the structure - you’ll do that in subsequent steps.

Define the new fields

The blade must define any new fields that it will use, which in this instance means our new Spread field.

  • Create a text file called fields.conf in Temp_Java_blade/SpreadJavaBlade/blade_config/

  • Using a suitable text editor, add the following configuration to fields.conf

    #
    # Field definitions for the Transformer SpreadJavaBlade
    #
    add-field Spread 45036
    You don’t have to use the field number we’ve shown here; you can choose your own value as long as it’s unique within your particular Caplin Platform installation.

You don’t have to list in the fields.conf file all the fields belonging to the incoming records that the blade will receive, because they’re already defined in the Pricing Adapter’s fields.conf file. For example, The BidPrice and AskPrice fields used in the code samples further down this page would have been defined there. When you deploy your new SpreadJavaBlade blade, the Deployment Framework will make the Pricing Adapter’s field definitions available to it (since the Pricing Adapter will also have been deployed as a blade).

For more about defining fields, see Field definitions in the DataSource Features and Concepts, and Field definition format.

Update the core component configuration

The new blade has to include configuration for the core Platform components that it interacts with. In this case, the core components are: Liberator, which will subscribe to data supplied by the Transformer module, and Transformer, which houses the module.

Define additional Liberator configuration

Configuration details for the Liberator are stored in the rttpd.conf file

  1. Create a text file called rttpd.conf in Temp_Java_blade/SpreadLuaBlade/Liberator/etc/

  2. Using a suitable text editor, add the following configuration to rttpd.conf

    #
    # Liberator configuration for data from
    # the SpreadJavaBlade Java-based Transformer Service blade.
    #
    add-data-service
       service-name SpreadJavaBlade${THIS_LEG}
       include-pattern ^/FX/
       add-source-group
          required true
          add-priority
             remote-label transformer${THIS_LEG}
          end-priority
          if "${FAILOVER}" == "ENABLED"
             add-priority
                remote-label transformer${OTHER_LEG}
             end-priority
          endif
       end-source-group
    end-data-service

    This configuration defines a data service through which the Liberator requests the data supplied by the SpreadJavaBlade. It also defines, through the add-source-group …​ end-source-group block, how the Liberator should fail the data service over to an alternate Liberator (this only applies if failover has been enabled for the deployment - see How can I…​ Set up server failover capability).

This is fairly standard configuration. The important points to note are:

  • The service-name configuration item defines the name of the data service, which in this case is (by convention) the name of the blade, SpreadJavaBlade, that supplies the data.

  • The include-pattern item specifies that the data service is to supply data for all subscriptions whose subjects start with the string /FX/

  • The macros THIS_LEG and OTHER_LEG are used to differentiate the configuration of primary and secondary failover legs.

Define the Java module configuration in Transformer

Configuring Transformer for a Java module is a bit more involved than doing so for a Lua module, as the Transformer has to know the location of the Java Virtual Machine (JVM) in order to start it.

  1. Create a java.conf file in Temp_Java_blade/SpreadJavaBlade/Transformer/etc/

  2. Using a suitable text editor, add the following configuration to java.conf:

    #
    # Java module configuration for the
    # SpreadJavaBlade Java-based Transformer Service blade.
    #
    jvm-location       "${JVM_LOCATION}"
    
    jvm-global-classpath    %r/lib/java/transformermodule.jar
    
    modules-dir ${ccd}/../lib
    add-module SpreadJavaBlade
    
    add-javaclass
        class-name example.spreadmodule.SpreadModule
        class-id   SpreadJavaBlade
        classpath  "${ccd}/../lib/java/SpreadModule.jar"
    end-javaclass

    The important points to note about this configuration are:

    • jvm-location defines the path of the JVM. It refers to the master definition through the macro JVM_LOCATION, which is defined in <Framework-root>/global_config/environment-defaults.conf

    • jvm-global-classpath defines the classpath of the Java library underlying Transformer’s Java Module API.

    • modules-dir defines the directory path to the java directory, which contains the Java module’s JAR file.

      (The ccd macro in the path name defines the current directory path of the file in which it is referenced. So in this example, because the ccd reference is in the file SpreadLuaBlade/Transformer/etc/java.conf, the macro defines the path SpreadLuaBlade/Transformer/etc/ The directory path for the Java Module is therefore SpreadLuaBlade/Transformer/lib)

    • add-module defines an identifier for the Transformer Java module. This must be the blade name, so in this example it’s SpreadJavaBlade.

    • add-javaclass defines:

      • The fully qualified name of the Java class that implements the Java module (class-name example.spreadmodule.SpreadModule).

      • class-id - a short identifier of the Java class. For blade implementations this must be the blade name, so in this example it’s set to SpreadJavaBlade.

      • The classpath on which the module’s JAR file can be found (classpath "${ccd}/../lib/java/SpreadModule.jar" ). You generate the JAR from the SpreadModule.java file where the Java source code for the module resides.

  3. Create a configuration file spreadjava.conf in Temp_Java_blade/SpreadJavaBlade/Transformer/etc/ and add the following lines:

    include-file ${ENV:CONFIG_BASE}bootstrap.conf
    module-logfile spreadjava.log
    module-classid spreadjava
    include-file ${BASE}/global_config/overrides/SpreadJavaBlade/Transformer/etc/spreadjava.conf
    • include-file ${ENV:CONFIG_BASE}bootstrap.conf allows access to some common definitions that the blade requires.

    • module-logfile specifies the name of the log file in Transformer/var that the spreadjava module writes errror and information messages to at run time.

    • module-classid specifies the class ID of the Java Module. This must match the class-id defined in java.conf.

    • The final include-file item allows you to override the blade’s standard configuration after it has been deployed, by putting a different spreadjava.conf configuration file in the Deployment Framework’s overrides directory for the blade.

Add the blade control file

The Deployment Framework needs to take some specific actions to allow a Java Transformer module blade to work correctly. So the Framework needs to have a way of knowing the blade is a Java Transformer module. This is done through a blade control file located in the root directory of the blade.

  1. Create a text file called control in Temp_Java_blade/SpreadJavaBlade/

    This is the blade control file

  2. Add the following single line to the blade control file:

    Type: JTMBlade
  3. You would normally also record any blade compatibility information in the control file as well (for details, see the Reference information about the blade control file), but for this simple example there’s nothing to record.

That’s all the configuration changes you need for the time being.

Integrate the initial core component configuration with the Deployment Framework

Now you’ve created the initial configuration for the core components that use your Transformer Service blade, you can deploy this configuration in your development environment.

  1. Zip up the blade directory structure in your temporary work area into a skeleton blade kit. The name of the .zip file must be of the form <blade_name>-<version_number>.zip, and the topmost directory in the .zip file must be the top level directory of the blade.

    So in our example, the .zip filename is SpreadJavaBlade-<version_number>.zip (say SpreadJavaBlade-000001.zip), and the topmost directory in the .zip file is SpreadJavaBlade.

  2. Navigate to <Framework-root> and deploy the skeleton blade kit:

    ./dfw deploy ../Temp_Java_blade/SpreadJavaBlade-000001.zip

    The ./dfw deploy command should respond with:

    Boot-strapping the Deployment Framework
    
       Unpacking SpreadJavaBlade kit SpreadJavaBlade-000001.zip
       SpreadJavaBlade-000001.zip successfully unpacked and stored in kits/archive
    
       Activating SpreadJavaBlade
    
       Blades ok

    And then ./dfw versions should show the new blade:

    Deployment Framework           6.0.4-267113
    
       Core components                Version
       -----------------------------------------------------------
       Liberator                      6.1.0-275608
       Transformer                    6.1.0-275716
    
       Deployed blades                Version            State
       -----------------------------------------------------------
       PricingAdapter                 2013.09.27.1138    Active
       SpreadJavalade                                    Active
    
       Built-in blades                                   State
       -----------------------------------------------------------
       BlotterExport                                     Inactive
       DemoDataSource                                    Inactive
       DirectConnection                                  Active
       HTTP                                              Active
       HTTPS                                             Inactive
       JavaOpenPermissioning                             Inactive
       LiberatorJMX                                      Active
       LiberatorWebsite                                  Active
       MinimalLiberatorWebsite                           Inactive
       OpenPermissioning                                 Active
       ServerIdentification                              Active
       TransformerJMX                                    Active

    Note that deploying the skeleton SpreadJavaBlade has automatically put it in the active state.

  3. Start the deployed core components and the SpreadJavaBlade blade: ./dfw start

At this stage the Liberator and Transformer are running with the new configuration. The new blade won’t run of course, because no executable code has been written for the Java module.

In a Web browser, navigate to the Liberator’s status page, where you should see the SpreadJavaBlade data service:

 Liberator status page showing SpreadJavaBlade data service

The URL of the Liberator is of the form http://<URL_of_liberator_server>:<liberator_port>. You can find the <URL_of_liberator_server> and <liberator_port> by entering the command ./dfw info. In a development enviroment, the URL would typically be http://localhost:18080.

When the Liberator home page is displayed, select the View Status button.

Write the Java module

This is the functional part of the Java module that defines the actions you need it to perform. In this example, the Java source is in a single file called SpreadModule.java. Create this file in a suitable place within your development environment.

The example code is quite long, so we’ll break it up into sections in order to explain it. It uses Transformer’s Java Module API.

Section 1:

package example.spreadmodule;

import com.caplin.transformer.module.*;

public class SpreadModule  implements TransformerModule, SubscriptionListener
{
   private int bidFieldNumber;
   private int askFieldNumber;
   private int spreadFieldNumber;

   @Override
   public void initialise(String moduleName, TransformerAccessor transformerAccessor)
   {
       bidFieldNumber = transformerAccessor.getFieldManager().getFieldByName("BidPrice").getNumber();
       askFieldNumber = transformerAccessor.getFieldManager().getFieldByName("AskPrice").getNumber();
       spreadFieldNumber = transformerAccessor.getFieldManager().getFieldByName("Spread").getNumber();

       transformerAccessor.getSubscriber().addSubscriptionListener("/FX/*", this);
   }

This first section identifies defines the SpreadModule class which implements the TransformerModule and SubscriptionListener interfaces of the Transformer Java Module API. It defines three integers to contain the numbers of the relevant record fields, and, in the initialise() method, populates these integers using the getFieldByName() method. initialise() also creates a subscription listener, to listen for messages from the Pricing Adapter that have subjects in the "/FX/" namespace.

Section 2:

@Override
   public void setFileReading(boolean b) {
   }

   @Override
   public void shutdown() {
   }

   @Override
   public String getLoggerName() {
      return "example.spreadmodule.SpreadModule";
   }

   @Override
   public void objectDeleted(String objectName) {
   }

   @Override
   public void status(String objectName, ObjectStatus objectStatus) {
   }

The above method implementations just define the default settings for some methods of the TransformerModule and SubscriptionListener interfaces.

Section 3:

@Override
   public void update(DataSourceUpdateEvent dataSourceUpdateEvent) {
      String bidValue =
         dataSourceUpdateEvent.getTransformerData().getFieldByFieldNumber(bidFieldNumber).getValue();
      String askValue =
         dataSourceUpdateEvent.getTransformerData().getFieldByFieldNumber(askFieldNumber).getValue();

This implementation of the SubscriptionListener interface’s update() method obtains the AskPrice and BidPrice field values from an incoming record message with a subject that begins with "/FX/". It uses the field numbers obtained when the module was initialised (see section 1 of the example).

Section 4:

if ( askValue != null && bidValue != null ) {
         double spreadValue =
            Double.parseDouble(askValue) - Double.parseDouble(bidValue);
         dataSourceUpdateEvent.getTransformerData().addData(spreadFieldNumber, spreadValue);
      }
   }
}

Having retrieved the AskPrice and BidPrice field values, the subscription listener’s update() method checks that neither of them are null, calculates spreadValue, by subtracting one value from the other, and uses the addData() method to add this calculated spread value to the Spread field that was defined earlier.

  • When you’ve completed the code in the SpreadModule.java file, compile it into a JAR file (SpreadModule.jar).

    Ensure that the JAR containing the Transformer’s Java Module API is in the compilation classpath. This JAR is called transformermodule.jar and it’s located in the lib/java directory of the deployed Transformer in the Deployment Framework.

  • Put the JAR in the directory <Framework-root>/kits/SpreadJavaBlade/SpreadJavaBlade/Transformer/lib/java/

Start the new Transformer Service blade

  1. If you have exclusive use of the Pricing Adapter in your development environment, restart the whole system on your development server machine:

    ./dfw start

    This stops the deployed core components and the Pricing Adapter blade and restarts them; in this case the Liberator, Transformer and the new Integration Adapter. (The command works out from the configured hostname settings which components it needs to start on the machine where the command is running.)

  2. Alternatively, if you share Pricing Adapter with other developers, so you don’t want to shut it down just to get your new Integration Adapter running:

    1. Make sure the Pricing Adapter is running:

      ./dfw status
    2. Then start the Liberator and Transformer:

      ./dfw start Liberator
      ./dfw start Transformer
  3. When the everything is running:

    1. Look at the Liberator’s status page to check that the Liberator is connected to the Transformer and can see the data service (SpreadJavaBlade in our example) for which the new Java-based Transformer Service blade supplies data.

    2. Use the Liberator’s Liberator Explorer to request data for the relevant subjects supplied by the Transformer Service blade, and check that the data is returned (via Transformer) as expected, with a correctly calculated Spread field included.

      Liberator Explorer view of /FX/AUDGBP with Spread field added by Lua -based Transformer Service blade

Package the new blade

When you’ve developed and tested the new blade to your satisfaction, you’ll need to package it up so it can be deployed on your production system - see How can I…​ Package a custom blade.


See also: