What do the OmmState values mean?
We are looking for a description of what information is provided by the C++ Reuters Elektron ema Omm::StatusMsg class so that we can use them correctly. In particular we are looking for
- the exact meaning and significance of each of the values in the OmmState enum that are returned StatusMsg::getStatusCode() – that is, when would we see them, what do they indicate has happened, and what should we do if we do see them;
- the meaning and significance of each of these values that are returned by StatusMsg::getStreamState();
- clarification as to whether the status applies only to the OmmConsumerClient for whose onStatusMsg was called (and hence that subscription) or to the whole of the OmmConsumer (and its session)
- whether there is anything else we should be using to determine the status of our subscription.
Thus far we have only found the comments on the OmmState declaration, but the names and comments are not as precise as we would like.
Best Answer
-
I found some description of the state code in ETA Reference Manual (html). You may find the description from ETA document instead as the EMA build on top of ETA. The enum value should be the same. It may not cover all codes in EMA but I think it provides more details comparing with EMA document. Attached file is the information from the document I have exported to PDF file.
ultraperformanceapi-ceditionreferencemanual-rsslst.pdf
I have copied it from ETA document (html) which locates at <Elektron SDK Install Path>/Eta/Docs/doxygen/ETA/group__RsslStateType.html#ga43d7477e19a12dbb6857245f1ff3b208
For example,
file:///C:/EMA/Elektron-SDK1.1.1.win.rrg/Eta/Docs/doxygen/ETA/group__RsslStateType.html#ga43d7477e19a12dbb6857245f1ff3b208
0
Answers
-
Thanks. That those descriptions are helpful.
EMA provides this on a callback to an OmmConsumerClient object, which corresponds to a subscription for an instrument. Do you know if the stream states should be interpreted as applying only to that subscription, or to all subscriptions?
0 -
It should be interpreted as applying only to that subscription.
Basically the EMA assigns all opened items or instruments a unique numeric identifier (e.g. UInt64), called a handle, which is returned by the OmmConsumer::registerClient() call. A handle is valid as long as its associated item stays open. In case that your application send multiple requests for multiple items, to identify event stream in the EMA client callback e.g. OnRefreshMsg,onStatusMsg, you can get handle from OmmConsumerEvent object using getHandle() and then compare it with the handle returned by registerClient.
0 -
Are you saying that the 'stream' is the set of messages coming in response to a request (which relates to only one client), not the communication channel (which would affect more than one client)?
0 -
Stream in this case is not network communication channel. It's data stream for each domain model (Login , Item, Directory according to RDM Usage guide). EMA internal has to maintain the stream so that it can generate events for particular request.
Each time you call registerClient to open a new item subscription, EMA returns handle which you can used to identify each subscription. If application send item request for RIC A,B,C and D , it will have four item stream. Then it appears that your DACS user does not have permission to request item B and C, application should get onStatus callback with stream state is closed for item B and C but A and D still remains open and get Refresh and Update as usual. That is the concepts I want to explain.
0
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛