question

Upvotes
Accepted
48 8 16 19

How do I receive a new code msgs from EMA if the code add to the chain temporary in midday trading?

we can't receive the msgs of a new code 8599.HK because your colleague of data didn't add the code to the correct chain, after I noticed them ,they added the code 8599.HK to the chain of 0#RIGHTS.HK. However, we should request the chain of 0#RIGHTS.HK again, in fact our system request the chain before the opening once a day. so we have to restart the system and to request the chain again to resolve the problem. Is the any way to solve the problem and we need not to restart. Thank you!

elektronrefinitiv-realtimeelektron-sdkema-apirrtelektron-message-apichain-ric
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
16.9k 80 39 63

Hi @wangfugen,

If you haven't done so already, you can refer to this article and the comments around chain updates.

You will have to process the updatemsg if you want to detect changes in the chain. That being said, you can alternatively choose to have your chain refresh every day for example. Many chains don't change that often and to manage update msgs may be overkill if you simply want to refresh the chain periodically. This is quite common. So, instead of restarting your system, you can put a timer in your application to refresh your chain every morning for example.

The type of message that comes through in an update is one that provides which links have changed. For example, the Nasdaq Top 25 chain (.AV.O) changes often throughout a typical trading day. Below is an example of a change.

{
   "TIMACT": "14:33:54",
   "NUM_MOVES": 1576,
   "LONGLINK6": "TQQQ.O",
   "LONGLINK7": "ZNGA.O",
   "TIMACT1": "14:33:54"
}

I don't know of any documentation that describes the details of chain updates but using the .AV.O as a test instrument is a good reference as I have shown above.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Thanks for your reply. I read the article you mention. Let me explain more about my current usage. I will request all rics of the chain via chain subscription request and subsequently request all rics for realtime quote via timer at 4:00 American East time. And during the trading session no more action to update the rics of the chain. That's why I may miss some ric if certain ric is added into certain chain record during trading session. I know such chain update message change very little, but if it does happen, our customers will feedback why missing quote.

Due to chain update message sent very little, I haven't seen the actual message format and have no idea how to decode. I want to check if the chain update message has the same message format or fields like refresh message, using the same chain record templates ? If so, I just need to care about the rics added, ignoring removal of ric in a chain record, or changes across multiple chain records as I will stop subscribing rics removed. Expecting your reply, many thanks.

Upvotes
16.9k 80 39 63

Hi @wangfugen,

If you want to detect changes in your chain, you have to open a streaming chain within EMA. It's unclear from your question whether you are requesting a snapshot (non-streaming) chain but it appears you are. This way, you will be notified via update msgs when items are added or removed from the chain.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Currently I just process the refreshmsg from chain subscription which will get all possible trading symbols the day and ignore the updatemsg from the chain. So you mean I should also process the updatemsg of the chain ? Generally, due to very few such message received, I could not decide how to process this message. Is there any document that will describe how chain update msg sent ?


For example, using 0#RIGHTS.HK as starting chain, I got A1 - A14 totaly 14 symbols together with 1#RIGHTS.HK as next requesting chain from RefreshMsg. If A1 is deleted from chain or a new A15 is added into chain, How will those two message be sent ?

Upvotes
48 8 16 19
06/09/20  16:06:55:992 [server/emaparser/chain_handler_base.cpp:557] [9476:139740547532544] - processing chain updateMsg:UpdateMsg
    streamId="58"
    domain="MarketPrice Domain"
    updateTypeNum="7"
    DoNotRipple
    seqNum="2288"
    name="35#UNIVERSE.NB"
    serviceId="356"
    serviceName="ELEKTRON_DD"
    Payload dataType="FieldList"
        FieldList
            FieldEntry fid="1" name="PROD_PERM" dataType="UInt" value="8036"
            FieldEntry fid="2" name="RDNDISPLAY" dataType="UInt" value="173"
            FieldEntry fid="3" name="DSPLY_NAME" dataType="Rmtes" value="NASDAQ BASIC"
            FieldEntry fid="4" name="RDN_EXCHID" dataType="Enum" value="0"
            FieldEntry fid="15" name="CURRENCY" dataType="Enum" value="840"
            FieldEntry fid="239" name="REF_COUNT" dataType="UInt" value="14"
            FieldEntry fid="800" name="LONGLINK1" dataType="Ascii" value="BBBY.NB"
            FieldEntry fid="801" name="LONGLINK2" dataType="Ascii" value="BBC.NB"
            FieldEntry fid="802" name="LONGLINK3" dataType="Ascii" value="BBCA.NB"
            FieldEntry fid="803" name="LONGLINK4" dataType="Ascii" value="BBCP.NB"
            FieldEntry fid="804" name="LONGLINK5" dataType="Ascii" value="BBD.NB"
            FieldEntry fid="805" name="LONGLINK6" dataType="Ascii" value="BBDC.NB"
            FieldEntry fid="806" name="LONGLINK7" dataType="Ascii" value="BBDO.NB"
            FieldEntry fid="807" name="LONGLINK8" dataType="Ascii" value="BBEU.NB"
            FieldEntry fid="808" name="LONGLINK9" dataType="Ascii" value="BBF.NB"
            FieldEntry fid="809" name="LONGLINK10" dataType="Ascii" value="BBGI.NB"
            FieldEntry fid="810" name="LONGLINK11" dataType="Ascii" value="BBH.NB"
            FieldEntry fid="811" name="LONGLINK12" dataType="Ascii" value="BBI.NB"
            FieldEntry fid="812" name="LONGLINK13" dataType="Ascii" value="BBIN.NB"
            FieldEntry fid="813" name="LONGLINK14" dataType="Ascii" value="BBIO.NB"
            FieldEntry fid="814" name="LONGPREVLR" dataType="Ascii" value="34#UNIVERSE.NB"
            FieldEntry fid="815" name="LONGNEXTLR" dataType="Ascii" value="36#UNIVERSE.NB"
            FieldEntry fid="1709" name="RDN_EXCHD2" dataType="Enum" value="1042"
            FieldEntry fid="3841" name="MKT_SECTOR" dataType="Rmtes" value="0"
            FieldEntry fid="5357" name="CONTEXT_ID" dataType="Real" value="2755"
        FieldListEnd

    PayloadEnd
UpdateMsgEnd


Luckily I get the chain update message from today's quote and can make sure it uses the same message format as refresh message. So for update message, the action I should do is to detect added rics ? Another possiblility is that one more chain record is added if the updated chain record is the last one of the chain and that chain record is already filled with 14 rics. Then I manually subscribe for the new ric or chain record, Right ?

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Hi @wangfugen,

The best way to test chain activity is to use an active chain, such as .AV.O (I mentioned this above). You will see many updates during the day. One way to manage new constituents added is to keep a collection. Depending on the chain, things can switch around/re-position themselves. In the above case, the chain could have a logical sorted organization and that if a new record was added in the middle, everything will be shifted. For example, the value at "LONGLINK1", changed to "BBBY.N", and the value of LONGLINK2, changed to "BBC.N" and so on. The constituents "BBBY.N", "BBC.N" are not necessarily added to the chain but rather moved positions within the chain. Using another example I showed above, the constituent "TQQQ.O" is now occupying the position "LONGLINK6" and "ZNGA.O" is occupying the position "LONGLINK7". Neither one of these constituents were added, they simply swapped positions. Depending on the nature of the chain and how it is organized, you could possibly assume the updated chain record will show only those records that have been added. But there is the consideration that things can be removed from a chain thus shifting everything down. I would keep track of the contents of the chain within a dictionary and when an update occurs, search against your local dictionary to determine what has been added or not. I hope this makes sense.

Thanks for your reply. My current solution is requesting the whole chain and keeping all rics in my local cache. If any chain record update message receives, I first check if new ric is added by checking my local cache. If so, manually register it for subscription and put it into local cache. Another possibility is that the updated chain record is the last one of the chain, if one more ric added, then one more chain record will be marked by LONGNEXTLR field. In that case, I will continue request the new chain record until the end of the chain for newly added rics and batch register to subscribe them. Is that OK ?

By the way, I have no permission to request .AV.O, so I can just watch the update message log from my application.

@wangfugen,

Can you clarify what you mean by: ".. if one more ric added, then one more chain record will be marked by LONGNEXTLR field.."?

When you receive an update, it simply tells you which LONGLINK element has changed. You will need to determine if the changed value is new by checking your local cache. It's quite possible the LONGNEXTLR will not be provided which tells you that there are no additional changes. If the LONGNEXTLR field is present, then I believe that is an instruction for you to fetch the next chain record and then go through the process to determine which, if any, new rics have been added by checking against your local cache. I believe you may have implied that, but you can clarify. Thanks.

Show more comments

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.