About this article
This article is intended for anyone who is interested in using Refinitiv Real-Time Distribution System(formerly known as TREP) as a messaging medium for internal business workflows i.e. publishing his own data services using custom fields to ADH server. 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 the system. This article explains how to leverage EMA Java API to write an Interactive Provider application that publishes custom fields to Refinitiv Real-Time Distribution System.
EMA API is a data-neutral, multi-threaded, ease-of-use API providing access to OMM and RWF data. As part of the Refinitiv Real-time SDK, the EMA 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 ETA (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 the ADH or ADS server to avoid situations where the same field numbers are used by different products for different purposes. The server can manage all fields by specifying the field dictionary in the configuration file. The field dictionary file contains the definition e.g. field numbers, field names of all fields. 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 the server. 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 by the server side to avoid situations where the same FID numbers are used by different products for different purposes.
The FID range reserved for the Refinitiv Real-Time Distribution Systeme use is -1 to -32K. The FID range reserved for Real-Time feed 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 Refinitiv Real-Time Distribution System and subscriber applications. The same FID definition files may then be used throughout a site by all applications
- 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 Refinitiv Real-Time Distribution System 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 Refinitiv Real-Time Distribution System 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 the Refinitiv Real-Time Distribution System and sends an item request, the provider responds interactively to the request received from Refinitiv Real-Time Distribution System 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. Refinitiv Real-Time Distribution System 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 Refinitiv Real-Time Distribution System.
Prerequisites
1. Download the Refinitiv Real-time SDK which provides EMA, its dependency libraries, documents and the example applications.
2. 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 Refinitiv Real-time 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 infra administration team to prepare Refinitiv Real-Time Distribution System for the Interactive Provider that you are going to develop. If your infra administration team requires any additional information about the server side, they can contact the Refinitiv support team directly by submitting a query via Get Support.
3. Configure Refinitiv Real-Time Distribution System 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 the infra configuration is INTERNAL_FEED which matches the service name in the EmaConfig.xml file mentioned in the previous step.
4. Add the custom fields, using only negative field ids, in the RDMFieldDictionary file used by the server. 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
5. Make sure that the ADH/ADS configuration files use the RDMFieldDictionary file containing the custom fields by verifying the value of the *fieldDictionary configuration in the configuration file, as shown below:
*fieldDictionary : /local/rep01/customdict/RDMFieldDictionary
Fortunately, an Interactive Provider example application, 350__Dictionary__Streaming, under the iprovider folder in the Refinitiv Real-time 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 Refinitiv Real-Time Distribution System 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 the infra already.
- IProvider class. It is the main class of this application. It downloads the dictionary from server, 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:
- 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;
}
...
}
2. 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 the server, 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);
3. 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();
}
...
}
4. 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 Refinitiv Real-Time Distribution System, 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));
...
}
5. 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 infra. 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 Refinitiv Real-time SDK Java Package is put in the Interactive Provider run directory. EmaConfig.xml contains the information which the server requires, i.e. the source directory of the Interactive Provider. Otherwise, the Interactive Provider's service on the server 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 Refinitiv Real-time 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 Refinitiv Real-time 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:
- Set the classpath to EMA, ETA, and EMA's dependency library files. For example:
set CLASSPATH=C:\RTSDK\Java\Ema\Libs\ema-3.6.0.0.jar;C:\RTSDK\Java\Eta\Libs\eta-3.6.0.0.jar;C:\RTSDK\Java\Eta\Libs\etaValueAdd-3.6.0.0.jar;C:\RTSDK\RTSDK-BinaryPack\Java\Ema\Libs\apache\commons-collections-3.2.2.jar;C:\RTSDK\RTSDK-BinaryPack\Java\Ema\Libs\apache\commons-configuration-1.10.jar;C:\RTSDK\RTSDK-BinaryPack\Java\Ema\Libs\apache\commons-lang-2.6.jar;C:\RTSDK\RTSDK-BinaryPack\Java\Ema\Libs\apache\commons-logging-1.2.jar;C:\RTSDK\RTSDK-BinaryPack\Java\Eta\Libs\SLF4J\slf4j-1.7.12\slf4j-api-1.7.12.jar;C:\RTSDK\RTSDK-BinaryPack\Java\Eta\Libs\SLF4J\slf4j-1.7.12\slf4j-jdk14-1.7.12.jar;C:\RTSDK\RTSDK-BinaryPack\Java\Eta\Libs\ApacheClient\httpcore-4.4.12.jar
2. Compile the application:
javac com\refinitiv\ema\examples\training\iprovider\example__custom__fields\*.java
3. 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.refinitiv.ema.examples.training.iprovider.example__custom__fields.IProvider
Jul 25, 2018 2:48:39 PM com.refinitiv.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 Refinitiv Real-Time Distribution System. Before running the consumer application, please make sure that you modify host and port to be the server 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 server. 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.refinitiv.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\refinitiv\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.refinitiv.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 infra 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 infra administration team who can help you verify this and bring the ADH up or correct the 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.refinitiv.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 infra configuration. Please contact your infra administrator who can help you to verify this and configure the server 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 the Refinitiv Real-Time Distribution System. 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 the server. Please contact your infra administrator who can help you configure Refinitiv Real-Time Distribution System 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 Refinitiv Real-Time Distribution System to serve your business requirements easier and faster including solving the common problems. If you do not have a infra components (ADH and ADS), please contact your Refinitiv Account team for the process and details. If you or your infra administrator require any infra assistance, you can contact the Refinitiv technical support team directly by submitting your query to Get Support.
References
For further details, please check out the following resources:
- API Concepts Guide
- EMA Java Developers Guide
- EMA Java Reference Manuals
- EMA Java Configuration Guide
