About this article

This article is intended for anyone who is interested in using Thomson Reuters Enterprise Platform (TREP) as a messaging medium for internal business workflows i.e. publishing his own data services using custom fields to TREP. For example, an application could subscribe to some Refinitiv fields in real-time, and then publish custom fields calculated from the Refinitiv fields back to TREP.  This article explains how to leverage Elektron Message API Java to write an Interactive Provider application that publishes custom fields to TREP. 

The Elektron Message API (EMA) is a data-neutral, multi-threaded, ease-of-use API providing access to OMM and RWF data. As part of the Elektron Software Development Kit, or Elektron SDK/Elektron APIs, the Elektron Message API allows applications to consume and provide OMM data at the message level of the API stack. The message level is set on top of the transport level which is handled by the Elektron Transport API (also known as UPA). To understand EMA better e.g. concept, functionality and capabilities, please refer to the API Concepts Guide 

Custom Fields Overview

Custom fields are non-Refinitiv fields that are distinguished by negative field numbers. All fields must be managed on TREP to avoid situations where the same field numbers are used by different products for different purposes. TREP can manage all fields by specifying the field dictionary in the TREP configuration file. The field dictionary file contains the definition e.g. field numbers, field names of all fields that TREP supports. Normally, the field dictionary name is RDMFieldDictionary

Refinitiv has a FID (field identifier) Number Policy to define some ranges for specific types of users/developers to reduce the risk of clashing field numbers. These ranges cannot be reserved and can only be used by that type of user/developer as explained below:

  • All clients are free to use any FID numbers in the range -4,001 to -8,000 for client specific development purposes.
  • All third parties developing products for sale into client sites are free to use any FID numbers in the range -10,001 to -20,000.

To use the custom fields, modifications are required to the field dictionary used by TREP. The FID Number Policy must be applied to your custom fields defined in the field dictionary. For more details of the policy, please refer to the FID Number Policy section below.

FID Number Policy

Introduction

The use of non-Refinitiv FIDs (sometimes referred to as negative FIDs) must be managed on TREP to avoid situations where the same FID numbers are used by different products for different purposes.

The FID range reserved for TREP use is -1 to -32K. The FID range reserved for Elektron Real-Time use is +1 to +32K.

Although 32K may seem like a large number of FIDs, it is NOT enough to accommodate all Refinitiv clients, third-party developers, local Refinitiv developments and International Refinitiv products with unique FID numbers. To resolve this, some ranges have been established for specific types of users/developers to reduce the risk of clashing FID numbers. These ranges cannot be reserved and can only be used by that type of user/developer.

All Refinitiv clients are free to use any FID numbers in the range -4,001 to -8,000 for client specific development purposes.

All third parties developing products for sale into client sites are free to use any FID numbers in the range -10,001 to -20,000.

By following these rules, a Refinitiv client may use additional FID definitions/numbers knowing that any third party or Refinitiv products they purchase will not cause any problems with clashing FIDs.

Ranges

From To User
-1 -500 Local (within the box) use by any application
-501 -1000 Reserved (Refinitiv Global Products)
-1001 -3,000 FLBU's
-3,001 -4,000 Reserved (Refinitiv Global Products)
-4,001 -8,000 Clients
-8,001 -10,000 Reserved (Refinitiv Global Products)
-10,001 -20,000 Third party developers
-20,001 -32,767 Reserved (Refinitiv Global Products)

Implementation

  1. Clients: A client may use any FID number he or she wishes when developing an application, provided it falls within the Refinitiv published 'Client' free range of FIDs (i.e. -4,001 to -8,000). The client is entirely responsible for tracking and managing all FIDs in this range. If a Refinitiv client requires more than 4,000 FIDs (a very rare situation), then additional FID numbers may be taken from the 'Third party' range. However, caution should be used in selecting FID numbers in this range, and applications MUST offer the facility to easily select the range to be used if future clashes are to be avoided. See Section Rules.
  2. Third Party Developers: Third party developers are required to stay within the third party range (i.e. -10,001 to -20,000). They MUST also follow the Rules. Out of all of the ranges, this is the most likely to involve clashes and so the modification of FID number usage by installer is very important. No tracking and management of this range of FIDs will be provided by Refinitiv. It is felt that to do so would only be asking for disaster in that all FIDs would be allocated in no time.
  3. Local Use (within the box):Local use FIDs (-1 to -500) are for any developer who wishes to pass additional information, INTERNALLY, on a per RIC basis. These FIDs MUST NOT be used outside the application. It is the responsibility of the developer to manage the FIDs within this range.

Rules

In creating a new record-based source application that publishes data via the Marketfeed protocol, the following rules MUST be used.

  1. If a piece (field) of information to be published can be readily identified as being identical to an existing Core FID (as defined in the Master FID List) then the existing published FID should be used.
  2. If a new FID must be created, then it should be given a unique identifying name. This name should be chosen to avoid possible confusion with names used in the Master FID List and by other applications - for example, by using a clearly identifiable prefix. This name should be used by the application to refer to the FID. The actual numerical value should be stored in a configuration file.
  3. You must store your FID definitions in the same format as the Master FID List for consistency. This approach ensures that it is easy to integrate the new FID definitions into the files used by the TREP and subscriber applications. The same FID definition files may then be used throughout a site by all applications
  4. The new FIDs should be provided with 'default' numbers which have been taken from the appropriate FID free range published by Refinitiv. For example, for a third party developed an application, the installer should be offered a 'default' set of numbers taken from the Refinitiv published range of -10,001 to -20,000. The installer MUST be able to override the application’s suggested FID numbers at installation time in order to avoid a clash at a client site where necessary.

Local Use FIDs

These FIDs do not follow the above rules in that they exist entirely within the application being developed. They must not be defined in the Master FID List as this would prevent the same files being used throughout a site. Different applications will have different definitions in this range.

Publisher / Provider Concepts

If you would like to expose a specific data service to consumer applications, building a Provider application should be considered. Provider applications are able to connect to a TREP to leverage its real-time and streaming distribution system to publish data. This is an efficient solution to make your own set of capabilities (e.g. content, workflow, etc.) available to any consumer applications.

Provider applications can be either non interactive or interactive. 

  • Non Interactive Providers (NIP) are not solicited by infrastructure requests but instead they publish information (e.g. Available services, data items…) following their own timing. In this model Thomson Reuters Enterprise Platform (TREP) caches the published information and serves it to the demanding consumer applications.
  • Interactive Providers (IP) receive requests from the infrastructure and must respond interactively to these requests. With these requests, the infrastructure may ask for information about the provided services and capabilities of the provider. The infrastructure also forwards consumer requests demanding for specific data items. For all these requests, the Interactive Provider must respond interactively by either providing the requested information or by rejecting the demand as shown in Interactive Provider Feature Diagram below:

This article focuses on Interactive Providers only.

Solution

When a consumer application logs in to TREP and sends an item request, the provider responds interactively to the request received from TREP by sending a refresh message and all subsequent updates messages. 

The consumer application needs to use a dictionary consistent with the provider application. An inconsistent dictionary may result in decoding errors on the consumer application. TREP enables the dynamic download of the data dictionary for applications (publisher or consumer) to instantiate their instances with the same version available from the infrastructure they connect to.

In this article, I will develop an Interactive Provider which downloads a dictionary containing custom fields from TREP.

Prerequisites

  1. Download the Elektron SDK Java Package which provides EMA, its dependency libraries, documents and the example applications.

 

  1. In this article, the service named INTERNAL_FEED will be used for the Interactive Provider. The service info including the service name used by the Interactive Provider is configured in the EmaConfig.xml file shipped in the Elektron SDK Java Package .Hence, we modify this file at the "Directory_2"  Directory node to use the service named INTERNAL_FEED instead of DIRECT_FEED (the default service name)as shown below:
		<Directory>
			<Name value="Directory_2"/>
			<Service>
				<Name value="INTERNAL_FEED"/>
                                 ...
                        </Service>
		</Directory> 

For more details of Interactive Provider configuration parameters, please refer to the EMA Java Configuration Guide 

 

The following prerequisites must be executed by your TREP administration team to prepare TREP for the Interactive Provider that you are going to develop. If your TREP administration team requires any TREP (ADS and ADH component) assistance, they can contact the TREP support team directly by submitting a query via Get Support.

 

  1. Configure TREP by adding a new route to connect to the machine that runs the interactive provider, and add the service provided by the interactive provider.  Please make sure that the service name used by the interactive provider in TREP configuration is INTERNAL_FEED which matches the service name in the EmaConfig.xml file mentioned in the previous step.

 

  1. Add the custom fields, using only negative field ids, in the RDMFieldDictionary file used by TREP. In this article, the custom fields are BID_AVG_INTRADAY (field id -4001) and ASK_AVG_INTRADAY (field id -4002) which are of REAL (REAL64) type. Hence, these fields added in the RDMFieldDictionary file are like below:
    BID_AVG_INTRADAY "BID AVERAGE INTRADAY" -4001  NULL  PRICE            17  REAL64           7
    !
    ! This is the average BID during a day. If there is a new BID, the new BID_AVG_INTRADAY 
    ! is generated e.g.(the first BID+ new BID)/2,(the first BID+ the second BID + new BID)/3 
    ! and so on.
    !
    ASK_AVG_INTRADAY "ASK AVERAGE INTRADAY" -4002  NULL  PRICE            17  REAL64           7
    !
    ! This is the average ASK during a day. If there is a new ASK, the new ASK_AVG_INTRADAY 
    ! is generated e.g.(the first Ask + new ASK)/2,(the first ASK+ the second ASK + new ASK)/3 
    ! and so on.
    !
    

    For the meaning of each column above, please refer to the  Field Dictionary Columns section in the EMA Java RDM Usage Guide 

 

  1. Make sure that TREP configuration files use the RDMFieldDictionary file containing the custom fields by verifying the value of the *fieldDictionary configuration in the TREP configuration file, as shown below:
*fieldDictionary : /local/rep01/customdict/RDMFieldDictionary

 

 Building an Interactive Provider to publish custom fields

The process of building the Interactive Provider (IP) to publish custom fields can be separated into 2 parts:

         1. ADH and Interactive Provider Initial Interaction

Fortunately, an Interactive Provider example application, 350__Dictionary__Streaming, under the iprovider folder in the Elektron SDK Java Package already performs all the above steps. Hence, the application for this article will be developed on top of this example.

        2. Sending Data

The flow starts after a consumer application connects to TREP and sends an item request. The 350__Dictionary__Streaming example application performs the 1st, 3rd, 5th and 6th steps (the green arrows) already. Hence, code is added to the example application to perform the 2nd and 4th steps (the pink arrows) which are explained in the next section. 

 

Source Code

This section explains how to develop an Interactive Provider using EMA Java according to the previous section. To focus on custom fields (which are the purpose of this article) and make a simple Interactive Provider, I will use dummy data for Refinitiv fields i.e. BID and ASK fields, instead of consuming real data of these fields. The example application contains the following classes:

  • ItemInfo class. This is the source of canned data for the provider. It generates all fields which are:
    • Refinitiv field named BID (field id 22)
    • Refinitiv field named ASK (field id 25)
    • The custom field named BID_AVG_INTRADAY (field id -4001). It is the average BID during a day and is calculated from the sum of BID values divided by the number of BIDs.
    • The custom field named ASK_AVG_INTRADAY (field id -4002). It is the average ASK during a day and is calculated from the sum of ASK values divided by the number of ASKs.th

           Note: all custom fields, BID_AVG_INTRADAY and ASK_AVG_INTRADAY, must be defined in the field dictionary on TREP already.

  •  IProvider class. It is the main class of this application. It downloads the dictionary from TREP, handles item requests, and publishes refresh and update messages containing Refinitiv fields and custom fields. It uses the ItemInfo class to help generate all fields.  

The overview steps to develop the application are listed below:

  1. Create the ItemInfo class in ItemInfo.java file to:
  • Generate all fields. The GenerateAllFields() method  generates dummy values for Refinitiv fields, and calculates values of custom fields based on Refinitiv fields. In the real world, you can get Refinitiv fields by subscribing an item using the OmmConsumer class.
  • Provide the methods to allow any classes to get the value of each field i.e. getBID(), getASK(),getBidAvgIntraDay() and getAskAvgIntraDay().

        A snippet of source code is shown below:

...
public class ItemInfo {
    ...
    //The method generates new data of all fields:
    //Refinitiv fields - BID, ASK. In the real world, you can get them by subscribing an item from a feed.
    //The custom fields - BID_AVG_INTRADAY, ASK_AVG_INTRADAY. In the real world, the custom fields may be calculated from Refinitiv fields.  
    //This method should be called when the provider wants to sends new data to the consumer. 
    //In the real world, when the application receives new data (Refinitiv fields). Then,
    //the custom fields based on these Refinitiv fields should be calculated and sent to the consumer e.g.in an Update message
    public void GenerateAllFields() {
    	//Choose the increase value at random
    	//nextDouble() return double value between 0.0 and 1.0 e.g. 0.7853612220729844
    	double increase = rand.nextDouble();
    	//Increase the number of BID/ASK data to include new data
    	++numData;
    	
    	//Call the newData(..) method which generates new dummy value of BID from last BID + increase value
    	lastBid = newData(lastBid,increase);
    	//Calls newAverage(..) method which calculates new BID_AVG_INTRADAY value
    	//from(the sum of BID values + new BID value)/the number of BIDs 
    	AverageInfo bidAveInfo = newAverage(sumBid,lastBid,numData);
    	bidAvgIntraDay = bidAveInfo.average;
    	sumBid = bidAveInfo.sum;
    	
    	//Call newData(..) method which generates new dummy value of ASK from last ASK + increase value
    	//In the real world, ASK is higher than BID so increase value is increase+0.01
    	lastAsk = newData(lastAsk,increase+0.01);
    	//Calls newAverage(..) method which calculates new ASK_AVG_INTRADAY value
    	//from(the sum of ASK values + new ASK value)/the number of ASKs 
    	AverageInfo askAveInfo = newAverage(sumAsk,lastAsk,numData);
    	askAvgIntraDay = askAveInfo.average;
    	sumAsk = askAveInfo.sum;
    }
    //The method which allows other classes to get BID value 
    public double getBID() {
    	return lastBid;
    }
    //The method which allows other classes to get ASK value
    public double getASK() {
    	return lastAsk;
    }
    //The method which allows other classes to get BID_AVG_INTRADAY value
    public double getBidAvgIntraDay() {
    	return bidAvgIntraDay;
    }
   //The method which allows other classes to get ASK_AVG_INTRADAY value
    public double getAskAvgIntraDay() {
    	return askAvgIntraDay;
    }
    ...
}

 

  1. Copy IProvider.java (from the example application 350__Dictionary__Streaming, under the iprovider folder) to the working directory. The application can use the functionalities implemented in the example application such as downloading the dictionary from TREP, handling the client's item request, and sending a refresh message and update message. The example application uses the default service named DIRECT_FEED. Therefore, I will replace all DIRECT_FEED in the application source code to be INTERNAL_FEED as shown below:
long rwfFld = provider.registerClient(EmaFactory.createReqMsg().name("RWFFld").filter(EmaRdm.DICTIONARY_NORMAL)
					.serviceName("INTERNAL_FEED").domainType(EmaRdm.MMT_DICTIONARY), appClient);
			
long rwfEnum = provider.registerClient(EmaFactory.createReqMsg().name("RWFEnum").filter(EmaRdm.DICTIONARY_NORMAL)
					.serviceName("INTERNAL_FEED").domainType(EmaRdm.MMT_DICTIONARY), appClient);

 

  1. In AppClient class of IProvider.java, declare and initialize theItemInfo object which generates data for the provider. 
class AppClient implements OmmProviderClient
{
    ...
	//the source of canned data for the provider
	public ItemInfo data;
	AppClient(String[] args)
	{
	     ...
		 //Initialize the ItemInfo object to create all fields with initial values
		 data = new ItemInfo();
	}
	...
}

 

  1. Under the AppClient class, the processMarketPriceRequest(ReqMsg reqMsg, OmmProviderEvent event) method generates fields and sets them to a Refresh message before sending the message to the consumer application via TREP, In there, modify all fieldList.add(…)  lines to use the FieldEntry.realFromDouble(int fieldId, double value, int magnitudeType) method to create a REAL field from values  generated from the ItemInfo object. This step matches the 2nd step of the 2.Sending Data part in the Building an Interactive Provider to publish custom fields section.
    void processMarketPriceRequest(ReqMsg reqMsg, OmmProviderEvent event)
    {
        ...
        //Add the Refinitiv REAL fields and custom REAL fields(negative field id) to the fieldList of the Refresh Message
	//Create a REAL field by using FieldEntry.realFromDouble(int fieldId, double value, int magnitudeType) method
	fieldList.add(EmaFactory.createFieldEntry().realFromDouble(22, data.getBID(), OmmReal.MagnitudeType.EXPONENT_NEG_2));
	fieldList.add(EmaFactory.createFieldEntry().realFromDouble(25, data.getASK(), OmmReal.MagnitudeType.EXPONENT_NEG_2));
	fieldList.add(EmaFactory.createFieldEntry().realFromDouble(-4001, data.getBidAvgIntraDay(), OmmReal.MagnitudeType.EXPONENT_NEG_2));
	fieldList.add(EmaFactory.createFieldEntry().realFromDouble(-4002, data.getAskAvgIntraDay(), OmmReal.MagnitudeType.EXPONENT_NEG_2));
        ...
    }

 

  1. Under the IProvider class,  in the main(String[] args) method has a for loop which generates fields and sets them to an Update message before sending the message to the consumer application via TREP. In there, call the GenerateAllFields() method of an ItemInfo object to generate new values of all fields. Then, modify all fieldList.add(…) lines to add all fields with the new values by using source code similar to the previous steps. This step matches the 4nd step of the 2.Sending Data part in the Building an Interactive Provider to publish custom fields section.
public class IProvider
{
	public static void main(String[] args)
	{
        ...
            for(int i = 0; i < 60; i++)
            {
			  ...
                        //Generate new data of all fields for an Update Message
			appClient.data.GenerateAllFields();
			//Add the Refinitiv REAL fields and custom REAL fields(negative field id) to the fieldList of the Update Message
			//Create a REAL field by using FieldEntry.realFromDouble(int fieldId, double value, int magnitudeType) method
			fieldList.add(EmaFactory.createFieldEntry().realFromDouble(22, appClient.data.getBID(), OmmReal.MagnitudeType.EXPONENT_NEG_2));
			fieldList.add(EmaFactory.createFieldEntry().realFromDouble(25, appClient.data.getASK(), OmmReal.MagnitudeType.EXPONENT_NEG_2));
			fieldList.add(EmaFactory.createFieldEntry().realFromDouble(-4001, appClient.data.getBidAvgIntraDay(), OmmReal.MagnitudeType.EXPONENT_NEG_2));
			fieldList.add(EmaFactory.createFieldEntry().realFromDouble(-4002, appClient.data.getAskAvgIntraDay(), OmmReal.MagnitudeType.EXPONENT_NEG_2));
                        ...
			} 
            ... 
     }
}

 

    You can download the complete application source code from Article.EMA.Java.CustomFieldsIP Repository on GitHub.

     

     Build and Run the Interactive Provider

    Before building and runing the Interactive Provider, please make sure that:

    •  The EmaConfig.xml shipped with the Elektron SDK Java Package is put in the Interactive Provider run directory. EmaConfig.xml contains the information which TREP requires, i.e. the source directory of the Interactive Provider. Otherwise, the Interactive Provider's service on TREP will not go up and the consumer application cannot request items from the Interactive Provider.
    • Put the dictionary files named RDMFieldDictionary and enumtype.def in the Interactive Provider run directory, because the Interactive provider loads the dictionary from local files first. You may use dictionary files shipped with the Elektron SDK Java Package. Otherwise, the Interactive provider cannot start successfully.

     

    To build and run the Interactive Provider, the library files i.e. EMA, ETA, and EMA's dependency are required. All files are shipped with the Elektron SDK Java Package. Thus, you just set the classpath to all of them before building and running the application. 

    The following example command lines show how to set the classpath, build and run the application on Windows: 

    1. Set the classpath to EMA, ETA, and EMA's dependency library files. For example:
    set CLASSPATH=C:\Elektron-SDK\Java\Ema\Libs\ema-3.2.0.1.jar;C:\Elektron-SDK\Java\Eta\Libs\upa-3.2.0.1.jar;C:\Elektron-SDK\Java\Eta\Libs\upaValueAdd-3.2.0.1.jar;C:\Elektron-SDK\Elektron-SDK-BinaryPack\Java\Ema\Libs\apache\commons-collections-3.2.2.jar;C:\Elektron-SDK\Elektron-SDK-BinaryPack\Java\Ema\Libs\apache\commons-configuration-1.10.jar;C:\Elektron-SDK\Elektron-SDK-BinaryPack\Java\Ema\Libs\apache\commons-lang-2.6.jar;C:\Elektron-SDK\Elektron-SDK-BinaryPack\Java\Ema\Libs\apache\commons-logging-1.2.jar;C:\Elektron-SDK\Elektron-SDK-BinaryPack\Java\Ema\Libs\SLF4J\slf4j-1.7.12\slf4j-api-1.7.12.jar;C:\Elektron-SDK\Elektron-SDK-BinaryPack\Java\Ema\Libs\SLF4J\slf4j-1.7.12\slf4j-jdk14-1.7.12.jar;C:\Elektron-SDK\Elektron-SDK-BinaryPack\Java\Ema\Libs\xpp3-1.1.4c.jar

     

    1. Compile the application:
    javac com\thomsonreuters\ema\examples\training\iprovider\example__custom__fields\*.java

     

    1. Run the application:
    •   Include the path containing the Interactive Provider class files generated from step 2 to the classpath 
    set CLASSPATH=.;%CLASSPATH%
    •  Run the application:
    java com.thomsonreuters.ema.examples.training.iprovider.example__custom__fields.IProvider

     

     The Example Result

    • After the Interactive Provider is connected to the ADH and successfully downloads the dictionary from ADH, it should show a message like below:
    Jul 25, 2018 2:48:39 PM com.thomsonreuters.ema.access.ServerChannelHandler reactorChannelEventCallback
    INFO: loggerMsg
        ClientName: ServerChannelHandler
        Severity: Info
        Text:    Received ChannelUp event on ClientHandle 1
    	Instance Name Provider_1_1
    	Component Version adh3.0.6.L1.solaris.tis.rrg 64-bit
    loggerMsgEnd
    
    
    Received Refresh. Item Handle: 2147483647 Closure: null
    Item Name: RWFFld
    Service Name: INTERNAL_FEED
    Item State: Open / Ok / None / ''
    
    Received Refresh. Item Handle: 2147483648 Closure: null
    Item Name: RWFEnum
    Service Name: INTERNAL_FEED
    Item State: Open / Ok / None / ''
    
    
    Dictionary download complete
    Dictionary Id : 1
    Dictionary field version : 4.20.29
    Number of dictionary entries : 15047
    

     

    • Then, you can use a consumer application, example100__MarketPrice__Streaming, under the consumer folder to test if the Interactive Provider can successfully publish custom fields to the consumer application via TREP.  Before running the consumer application, please make sure that you modify host and port to be the TREP connecting to the Interactive Provider and the service to be the correct service e.g. INTERNAL_FEED  used in this article. After that the consumer application logs in and sends an item request to the Interactive Provider via TREP. The consumer application should receive a Refresh message and multiple Update messages containing Refinitiv and custom fields e.g. field id 22, 25,-4001 and -4002, as in the example below:
    Jul 25, 2018 2:48:55 PM com.thomsonreuters.ema.access.ChannelCallbackClient reactorChannelEventCallback
    INFO: loggerMsg
        ClientName: ChannelCallbackClient
        Severity: Info
        Text:    Received ChannelUp event on channel Channel_1
    	Instance Name Consumer_1_1
    	Component Version ads3.0.6.L1.solaris.tis.rrg 64-bit
    loggerMsgEnd
    
    
    RefreshMsg
        streamId="5"
        domain="MarketPrice Domain"
        solicited
        RefreshComplete
        state="Open / Ok / None / 'Refresh Completed'"
        itemGroup="00 01"
        name="IBM.N"
        serviceId="4511"
        serviceName="INTERNAL_FEED"
        Payload dataType="FieldList"
            FieldList
                FieldEntry fid="22" name="BID" dataType="Real" value="20.06"
                FieldEntry fid="25" name="ASK" dataType="Real" value="20.09"
                FieldEntry fid="-4001" name="BID_AVG_INTRADAY" dataType="Real" value="20.06"
                FieldEntry fid="-4002" name="ASK_AVG_INTRADAY" dataType="Real" value="20.09"
            FieldListEnd
        PayloadEnd
    RefreshMsgEnd
    
    UpdateMsg
        streamId="5"
        domain="MarketPrice Domain"
        updateTypeNum="0"
        name="IBM.N"
        serviceId="4511"
        serviceName="INTERNAL_FEED"
        Payload dataType="FieldList"
            FieldList
                FieldEntry fid="22" name="BID" dataType="Real" value="20.71"
                FieldEntry fid="25" name="ASK" dataType="Real" value="20.75"
                FieldEntry fid="-4001" name="BID_AVG_INTRADAY" dataType="Real" value="20.39"
                FieldEntry fid="-4002" name="ASK_AVG_INTRADAY" dataType="Real" value="20.42"
            FieldListEnd
        PayloadEnd
    UpdateMsgEnd
    
    UpdateMsg
        streamId="5"
        domain="MarketPrice Domain"
        updateTypeNum="0"
        name="IBM.N"
        serviceId="4511"
        serviceName="INTERNAL_FEED"
        Payload dataType="FieldList"
            FieldList
                FieldEntry fid="22" name="BID" dataType="Real" value="21.48"
                FieldEntry fid="25" name="ASK" dataType="Real" value="21.53"
                FieldEntry fid="-4001" name="BID_AVG_INTRADAY" dataType="Real" value="20.75"
                FieldEntry fid="-4002" name="ASK_AVG_INTRADAY" dataType="Real" value="20.79"
            FieldListEnd
        PayloadEnd
    UpdateMsgEnd
    

    Note: if you use another consumer application, please make sure that the application makes one item request because the 350__Dictionary__Streaming example application supports only one item request. Otherwise, the consumer application will get state="Closed / Suspect / Not found / 'Item not found' for other item requests.

    Troubleshooting

    Q: When compiling the IP EMA Java application, it shows "error: package [package name] does not exist"

    com\thomsonreuters\ema\examples\training\iprovider\example__custom__fields\IProvider.java:142: error: package OmmReal does not exist

    A: The classpath is not set or set to the wrong path. See the 1st step in the Build and Run Interactive Provider section.

     

    Q: When running the IP EMA Java application, it shows "Error: Could not find or load main class [class]"

    Error: Could not find or load main class com.thomsonreuters.ema.examples.training.iprovider.example__custom__fields.IProvider

    A: The path containing the IP EMA Java application class files is not included in the classpath, it is set to the wrong path, or the run [class] may be wrong. See the 3rd  step in the Build and Run Interactive Provider section.

     

    Q: Interactive Provider shows a message like below “Item State: Closed, Recoverable / Suspect / None / 'request is timeout'” for Item Name: RWFFld or RWFEnum

        Received Status. Item Handle: 2147483648 Closure: null
        Item Name: RWFEnum
        Service Name: INTERNAL_FEED
        Item State: Closed, Recoverable / Suspect / None / 'request is timeout'

    A: The provider application cannot receive the dictionary from the ADH in time, so the application receives a'request is timeout' status message. This can happen if the configuration value for numIpcOutputBuffers and tcpSendBufSize in the ADH is not enough to encode and publish the dictionary. Therefore, you should contact your TREP administration team who can set numIpcOutputBuffers and tcpSendBufSize to higher values for your Interactive Provider. 

     

    Q: Interactive Provider does not show anything. 

    A: The ADH goes down or connects to the wrong host/port running the Interactive Provider. Please contact your TREP administration team who can help you verify this and bring the ADH up or correct the TREP configuration to connect to your Interactive Provider. When the ADH connects to the provider application successfully, the application should show a message like below. 

        Jul 16, 2018 10:14:20 AM com.thomsonreuters.ema.access.ServerChannelHandler reactorChannelEventCallback
        INFO: loggerMsg
            ClientName: ServerChannelHandler
            Severity: Info
            Text:    Received ChannelUp event on ClientHandle 1
            	Instance Name Provider_1_1
    	        Component Version adh3.0.6.L1.solaris.tis.rrg 64-bit
        loggerMsgEnd

     

    Q: The Interactive Provider can run successfully as shown in the first bullet of The Example Result section. However, the consumer application does not receive data and shows "Service name of [service_name] is not found."

        StatusMsg
            streamId="0"
            domain="MarketPrice Domain"
            state="Closed / Suspect / None / 'Service name of 'INTERNAL_FEED' is not found.'"
            name="IBM.N"
            serviceName="INTERNAL_FEED"
        StatusMsgEnd

    A: It means the service provided by the Interactive Provider (in the example application it is INTERNAL_FEED ) does not match the service defined in the TREP configuration. Please contact your TREP administrator who can help you to verify this and configure TREP for your Interactive Provider service.

     

    Q: The Interactive Provider can run successfully as shown in the first bullet of The Example Result section. However, the consumer application receives a “FieldIdNotFound” error for negative fields, like below

        UpdateMsg
            streamId="5"
            domain="MarketPrice Domain"
            updateTypeNum="0"
            name="IBM.N"
            serviceId="4511"
            serviceName="INTERNAL_FEED"
            Payload dataType="FieldList"
                FieldList
                    FieldEntry fid="22" name="BID" dataType="Real" value="20.24"
                    FieldEntry fid="25" name="ASK" dataType="Real" value="20.28"
                    FieldEntry fid="-4001" name="" dataType="Error"
                        OmmError
                            ErrorCode="FieldIdNotFound"
                        OmmErrorEnd
                    FieldEntryEnd
                    FieldEntry fid="-4002" name="" dataType="Error"
                        OmmError
                            ErrorCode="FieldIdNotFound"
                        OmmErrorEnd
                    FieldEntryEnd
                FieldListEnd
            PayloadEnd
        UpdateMsgEnd

    A: The consumer application uses a field dictionary which does not contain the custom fields. It is possible that the consumer application uses:

    • The field dictionary on the local machine. Please modify EmaConfig.xml to download the dictionary from TREP. The DictionaryType need to be ChannelDictionary. For example:
        <Consumer>
            …
            <Dictionary value="Dictionary_1"/>
    	    …
        </Consumer>
        …
        <Dictionary>
    	    <Name value="Dictionary_1"/>
    	    <DictionaryType value="DictionaryType::ChannelDictionary"/>
        </Dictionary>
    • The field dictionary downloaded from TREP. Please contact your TREP administrator who can help you configure TREP to use the field dictionary defining the custom fields.

    Summary

    After finishing this article, you will understand more about custom fields (negative fields), Interactive Provider and how to apply them with TREP to serve your business requirements easier and faster including solving the common problems. If you do not have a TREP (ADH and ADS), please contact your Refinitiv Account team for the process and details. If you or your TREP administrator require any TREP assistance, you can contact the TREP support team directly by submitting your query to Get Support.

    References

    For further details, please check out the following resources: