Migrating application from SSL to ETA; need data from FIELD_LIST_NO in IDN/MarketFeed
We're rewriting an application in ETA since SSL is end of life.
Part of the application logic examines the FIELD_LIST_NO field in the MarketFeed Header.
For example in Record_Response and Snap_Response (340), the record is defined as:
<FS>340<US>TAG<GS>RIC[<RS>R_STATUS]<US>FIELD_LIST_NO<US>RTL{<RS>FID<US>VALUE}<FS>
Some examples of data (using SSL) up to the beginning of the FID/VALUE section are:
<FS>340<US>XX<GS>AAPL.O<US>78<US>15728
340 XX BB.TO 74 1296
<FS>340<US>XX<GS>CGBU6m<US>38<US>24080
<FS>340<US>XX<GS>.DJI<US>77<US>3488
<FS>340<US>XX<GS>GOOG.O<US>78<US>20160
<FS>340<US>XX<GS>IBM.N<US>79<US>63344
<FS>340<US>XX<GS>.SPX<US>77<US>46080
<FS>340<US>XX<GS>TRI.N<US>79<US>21376
In these messages, the FIELD_LIST_NO has values of: 38, 74, 77, 78, and 79
The (apparently partial) list of meanings for these fields is:
static const int FieldList_ALL_FUTURES_B = 20;
static const int FieldList_NMTS_NBIDASK = 21;
static const int FieldList_MARKET_INDEX_A = 77;
static const int FieldList_LINK_A = 80;
static const int FieldList_PAGE_25X80 = 82;
static const int FieldList_SPREAD = 83;
static const int FieldList_LONGLINK = 85;
static const int FieldList_CM2000 = 89;
(Of the values seen in the data, the only one that we appear to have a definition or is 77)
In any case, our existing code appears to have particular affinity for types 80 and 85.
Is it possible to recreate this field by extracting one or more values from the various data structures and messages available using the ETA API?
Or did the original author write something using undocumented features of MarketFeed (resulting either some very magic or a bit of cruft -- or both)
The equivalent is the FIELD_LIST_NO which is a attribute of a FIELD_LIST.
In terms of ETA Java it would be something like:
fieldList.fieldListNum()
which returns an int, but is really - as far as I understand - a short. The equivalent method in RFA Java indeed returns a short. Well, well.
You can view the field list number by using TRexplorer.
In the screenshot below you can see an example:
The data item I'm displaying in the screenshot is an IDN Chain. Unsurprisingly it has a field list number of 85 (LONGLINK style chains).
Relying on field list numbers for anything but allocating memory seems to me to be a dangerous strategy so you may want to review why they are used by your application. However if you want to do a 1:1 migration then the above would be what you are looking for.
Thanks!!
It looks like its a field, not a method: (fieldList.fieldListNum), at least in the C API.
It also looks like it's only present when msgCLass is RSSL_MC_REFRESH or
RSSL_MC_UPDATE and updateType is RDM_UPD_EVENT_TYPE_VERIFY.
Just as it was in MarketFeed MsgTypes: 340 and 318
Now, I just have to figure out why they are using that data downstream.
Thanks!!
It looks like its a field, not a method: (fieldList.fieldListNum), at least in the C API.
It also looks like it's only present when msgClass is RSSL_MC_REFRESH or RSSL_MC_UPDATE and updateType is RDM_UPD_EVENT_TYPE_VERIFY.
Just as it was in MarketFeed MsgTypes: 340 and 318
Now, I just have to figure out why they are using that data downstream.
Yes, it would only be present (only make sense) in those cases. However I'm under the impression that the API will always populate the field, so if it doesn't arrive on the wire it simply becomes 0. In other words : zero means "not defined".
Also: You would probably have to wait 10 years before you see an example where an open stream changes its fieldListNum in an UPDATE message of type VERIFY but I suppose it can theoretically happen. I would say it is a (almost) static value for the life time of the subscription.