Please review the following points when implementing with the SIXP APIs:
Minimize querys and use filtering
Do not create large queries if you do not need them. For example if you need market SSE do query /rt/stock/quote?Mkt="SSE". Do not make the query /rt/stock/quote and filter in the client as more data will be sent and the client must work more to process the data. For more information how to create filters please refer to the Prl query examples.
Number of logins
The account you have been given do only have a maximum number of logins. If you cannot login, please check if you already have connections to our servers. If you need more concurrent logins please Contact our support.
Column order and Row order
Do not assume the order on the columns or rows that are sent from the server to the client. The columns and rows may come in different order when reconnecting to the server. Here is a column order example:
value = u.Fields[3].Value; // Wrong: assume that Tm is always in fixed positions 3
foreach (Field f in u.Fields) {
if (f.FieldInfo.Name=="Tm") value=f.Value
}
// Correct: always check each element
Reconnect and persistence
When a client is reconnected to the server all data that has been saved in memory should be cleared. The server will resend all important data to the client on connect.
Get request usage
The SIXP server is optimized to deliver streaming data. The get request is a exception and should be used sparse. The main purpose for the Get request is to get news texts and it should be its main use. If you want to do a snapshot solution you should look at our product SIXIQ that is a snapshot request service much like the get request and better suited to handle this kind of solution.
Logged out without apparent reason
If you are getting logged out without apparent reason you should use the OnTimingInfo event and print out the turnaround time and queue size. If these numbers grow you probably have problems handling all data in a timely fashion or the bandwidth between the server and client is to small.
Threading and Events
Beware that in all of the APIs different threads may access the different events. Therfore any data shared between the events must be syncronized otherwise you may break the program or get unexpected results.
Should I handle reconnects myself?
No, this should be handled by the APIs themself. If you still have problems with the reconnect please contact our support and we will investigate the matter further.
Can I sleep or wait inside a Event?
No, all the code inside events should be run as fast as possible as sleeping inside a event will lock up the API. If you want to do prolonged work create a separate thread to handle this.
How do you handle news text revisions?
News text revisions is just a new updated news text. We have no technical way to connect a news text with a news text revision sent later. This may be implemented at a later time.
Can I use the ticker code in the API Key value for some purpose, for example NGM/CBK-TOXS4C1310SE?
No, the key is unique but the information in this key can be changed in the future. If you want to connect a specific data row with a ticker in this case, create a conversion table between recordid and the ticker. Please note that the recordid change between sessions so you have to clear this table on reconnects.