Elektron SDK - Java

API Family: Elektron

ETA Tutorial 3 - Establishing a session with a Provider

Download tutorial source code

Click here to download

Last update May 2018
Environment Windows, Linux
Compilers JDK 1.7 or greater
Prerequisite ETA Tutorial 2 - Establishing a connection to a Provider

Login credentials

Introduction

The goal of this tutorial is to extend Tutorial 2 by establishing a session to the OMM-based Provider. Session establishment involves the submission of valid login credentials as well as the retrieval of the source directory. The source directory contains a number of important details related to the available services within the Provider. Depending on the features of your application, the details retrieved from the source directory are required to be used when requesting for additional content from the OMM-based Provider.

Description

In this tutorial, we introduce a new class basicDirectoryHandler to process events related to the source directory details provided by our OMM-based Provider. Derived from Tutorial 2, we will enhance the basicConsumer.java functionality to define our login and directory requests to our Provider. One of the key benefits of the ETA Reactor module is the management of the RDM administrative functions, login and directory. By registering interest in these capabilities, the Reactor will manage the submission and event processing on the consumer's behalf.

Implementation Overview - Establish a session with our OMM-based Provider

Piggybacking off of our existing code, to handle these new RDM administrative capabilities, we define the following:

		private void init() 
{ 
    ... 
    // After this consumer successfully connects into a server (TREP), we must log in 
    // Initialize a default login request 
    consumerRole.initDefaultRDMLoginRequest(); 

    // Initialize the default directory request 
    consumerRole.initDefaultRDMDirectoryRequest(); 

    ... 
}
	

In the above code segment, we have registered interest within the consumer role by initializing both the login and directory request details. By doing this, we instruct the consumer to attempt to establish a session on our behalf. That is, once the consumer successfully connects into the Provider, the reactor will automatically attempt to login, then if successful, request for the source directory from the Provider.

To login, you will require a valid ID as defined by your market data administrator.  By default, the ValueAdd libraries will conveniently attempt to use your system login credentials as the ID to login to your market data system.  However, if your market data login is different than your system login, you can optionally override the default credentials by explicitely defining a LoginRequest object including specific attributes. Refer to the ETA Java Edition Value Add Developers Guide - RDM Login Domain for more details.  The above code segment uses the default login request.

Once the ValueAdd layer connects, a login request is submitted and the response is captured within the specified callback:

		@Override 
public int rdmLoginMsgCallback(RDMLoginMsgEvent event) 
{ 
    LoginMsgType msgType = event.rdmLoginMsg().rdmMsgType(); 

    switch (msgType) 
    { 
        case REFRESH: 
            System.out.println("Received Login Refresh for Username: " + 
                                    ((LoginRefresh)event.rdmLoginMsg()).userName()); 
            break; 
        case STATUS: 
            LoginStatus loginStatus = (LoginStatus)event.rdmLoginMsg(); 
            System.out.println("Received Login StatusMsg"); 
            if (loginStatus.checkHasState()) 
                System.out.println(" " + loginStatus.state()); 
            break; 
        default: 
            System.out.println("Received Unhandled Login Msg Type: " + msgType); 
            break; 
    } 
    return ReactorCallbackReturnCodes.SUCCESS; 
}
	

The above code segment simply reports the result of the login. Assuming we return success from our login callback, the ETA Reactor will evaluate the details of the login result to determine if it should submit a directory request.

The directory callback is responsible for processing the details of the Directory response from the Provider. Depending on the requirements of an application, some of the details returned within the directory are required to be used for additional communication to the OMM-based data Provider. The Directory response provides a list of services with the following details:

  • Service name (eg, ELEKTRON, IDN_RDF, etc.)

    The service name can vary depending on the installation.
  • The corresponding service ID

    The service ID is a mandatory element necessary when requesting market data - which will be used in future tutorials within this series.
  • Status of the service (UP/DOWN)
  • Service capabilities (the type of data it provides, i.e. Market Price, Market By Order, etc.)

    The Service capabilities define the scope of data supported by the provider.
  • Dictionary details related to the service

    These details are automatically used if we instruct the reactor to request the download of data dictionaries from the provider.  We use this capability in later tutorials.

Within our callback, we execute the call to process the Directory details. Although we could have housed the entire processing within the basicConsumer class, the intention was to offload the functionality into a separate class basicDirectoryHandler for purposes of modularity and possible future enhancements.

		// Service name 
private static final String serviceName = "ELEKTRON_AD"; 
... 
@Override 
public int rdmDirectoryMsgCallback(RDMDirectoryMsgEvent event) 
{ 
    // Process the directory response and capture the service details associated with our serviceName of interest 
    return( directoryHandler.processDirectoryResponse(event, serviceName) ); 
}
	

The processDirectoryResponse method defined within the basicDirectoryHandler.java source file contains the details to walk through and pull out the relevant elements of interest. In our case, we're interested in retrieving the service with the service name of interest, i.e. serviceName. While the processing details are important, the codebase and the decoding of elements are beyond the scope of this tutorial. The basic processing was derived from the ValueAdd example consumer which will act as a good reference for additional processing requirements.

Setup and Configuration

Refer to Setup and Configuration section within the ETA Tutorial 2 - Establishing a connection to a Provider prior to building and running this tutorial.

Build and run

Refer to the Build and run section within the ETA Tutorial 1 - Creating a starter consumer application for instructions to successfully execute this tutorial.

Eg (Windows):

> buildConsumer 3 

> runConsumer 3

Running the Tutorial will display the login results and some general statistics regarding the Directory response from the OMM-based Provider.

Note: The OMM-based Provider you are connected to will yield different Directory details.

Running tutorial 3...
Ultra Performance API (UPA), Java Edition, LibraryVersionInfo
        productVersion: etaj3.0.0.L1.all.rrg
        productInternalVersion: etaj3.0.0.L1
        productDate: Fri April 29 12:24:15 CST 2016 Thomson Reuters
basicConsumer initializing...

Connection up!  Registering our connection within our event loop

Received Login Refresh for Username: U8007876
Received serviceName: DDN_SSL. State:           StateFilter:
                        ServiceState: 1
                        AcceptingRequests: 1

Received serviceName: ELEKTRON_AD. State:               StateFilter:
                        ServiceState: 1
                        AcceptingRequests: 1

Found service of Interest: ELEKTRON_AD.  Using serviceId: 356

Received serviceName: DDN_RDF. State:           StateFilter:
                        ServiceState: 1
                        AcceptingRequests: 1

Received serviceName: EZD_RSSL. State:          StateFilter:
                        ServiceState: 1
                        AcceptingRequests: 1

Received serviceName: EZD_SSL. State:           StateFilter:
                        ServiceState: 1
                        AcceptingRequests: 1

Channel is ready
				

References

For more information, refer to the ETA Java Development Guides.

Tutorial Group: 
ETA Consumer