I am getting 35=d message from ICE in my logs with all the details while requesting it via java application which is using quickfixj.
In onMessage implementation I am trying to get group data and values of individual field but my code fails at getGroup() and gives the error that field not found.
quickfix.fix44.SecurityDefinition.NoUnderlyings group = new quickfix.fix44.SecurityDefinition.NoUnderlyings();
message.getGroup(count, group);
This getGroup method internally calls getGroups function of quickfixJ which is failing becasuse at below line in -
this.getGroups(group.getFieldTag()); //group.getFieldTag() is 711 or NoUnderlyings
Is there anything that I am missing here? I have tried different ways to get the fields but no luck, help would be much appreciated.
Just an observation - In fromapp /on message method, I am not seeing the full message when I do message.toString(); . I Only see the first part, Second part which has actual security(many groups) is not being displayed. Not sure if there is any other way(other than toString()) to see full message in methods.
Message that I am getting in fromApp/OnMessage on message.toString();
<20190828-12:14:47, FIX.4.4:XXXX/1/0->ICE, incoming> (8=FIX.4.4 9=XXXXX 35=d 49=ICE 34=5 52=20190828-12:14:47.695 56=XXXX 57=1 322=10342 323=4 320=1566994457340_0 393=91 82=1 67=1 9064=0 711=91
Message that I am getting in logs :
<20190828-12:14:47, FIX.4.4:XXXX/1/0->ICE, incoming> (8=FIX.4.4 9=XXXXX 35=d 49=ICE 34=5 52=20190828-12:14:47.695 56=XXXX 57=1 322=10342 323=4 320=1566994457340_0 393=91 82=1 67=1 9064=0 711=91
311=5094981 309=UPL FQF0021.H0021 305=8 463=FXXXXX 307=UK Peak Electricity Futures (Gregorian) - UK Grid - Q1 21 308=IFEU 542=20201230 436=1.0 9013=0.01 9014=1.0 9040=0.01 9041=1.0 9017=1.0 9022=768 9024=1.0 9025=Y 916=20210101 917=20210331 9201=1900 9200=15 9202=Q1 21 9300=8148 9301=IPE UK Grid, UK (Peak) 9302=UK Grid 9303=UPL 998=MWh 9100=GBP 9101=GBP / MWh 9085=hourly 9083=2 9084=0 9061=4639 9062=UK Peak Electricity Futures (Gregorian) 9063=UK Power Peakload Futures (Gregorian) 9032=0.01 9215=1 9216=0 763=800
311=5094980 309=UPL FMH0021! 305=8 463=FXXXXX 307=UK Peak Electricity Futures (Gregorian) - UK Grid - Mar21 308=IFEU 542=20210225 436=1.0 9013=0.01 9014=1.0 9040=0.01 9041=1.0 9017=1.0 9022=276 9024=1.0 9025=Y 916=20210301 917=20210331 9201=1875 9200=12 9202=Mar21 9300=8148 9301=IPE UK Grid, UK (Peak) 9302=UK Grid 9303=UPL 998=MWh 9100=GBP 9101=GBP / MWh 9085=hourly 9083=2 9084=0 9061=4639 9062=UK Peak Electricity Futures (Gregorian) 9063=UK Power Peakload Futures (Gregorian) 9032=0.01 9215=1 9216=0 457=1 458=GB00H1RK4P63 459=U4 763=0
Which version of QuickFIX/J are you using? In some older versions the message got truncated when there were unknown fields.
That brings me to the question whether your used data dictionary is really containing all the fields that ICE is sending. Do you have all that 9000+ tags in your dictionary? Please double-check that.
Related
I'd like to know the position in which the driver would need to rest with given waypoints.
I am calling GET https://fleet.ls.hereapi.com/2/calculateroute.json with the following params:
{
mode: "fastest;car;traffic:enabled",
waypoint0: "19.286769, -99.652773",
waypoint1: "19.419185, -99.17755430000001",
waypoint2: "19.41530,-99.17844",
waypoint3: "31.29778, -110.93690",
restTimes: "MEX",
maxSpeed: 110,
departure: "2021-07-20T15:00:00.000Z"
}
This returns warnings with the info of rest times like this:
{
"message": "Taking the short driver rest time after 18036 sec for 1800 sec at routeLinkSeqNum 1485",
"code": 14,
"routeLinkSeqNum": 1485
}
I would like to know how to use/read this info. I don't know what routeLinkSeqNum is and how to utilize it.
Governments impose rules on how long a truck driver can drive before he needs to rest. Routing can consider these regulations w.r.t. short rests during a day and long (overnight) rests.
For example, in EU countries drivers have to rest after 4.5 hours of driving for at least 45 minutes, and must not exceed a total of 9 working hours per day before they have to rest for 11 hours.
Activate this feature in the router using the "&restTimes=local", in this case, it is the "MEX" in the request parameter. Routing will then consider each country's local regulations.
In the same parameter, you can specify whether the driver starts the route freshly or how long he is already driving / on duty since his last short or long rest period
routeLinkSeqNum is an index of the link array within a Leg. If you check the response, there will be response>route>[0]>leg[0]>[2]>link[1485].
So one route can have n-legs, 1 leg can have m-links
This will help you to plot the rest times.
Here is an example shown in the tool:
https://tcs.ext.here.com/examples/v3/fleet_telematics_api
I am trying to get the latest Intraday prices from Alpha Vantage API. Currently it is Friday, 9:16PM Eastern European Time. I am trying to get Tesla stock. Markets are still open. However, The API call returns me yesterday's data only. What could be the problem?
ts = TimeSeries(key='API_KEY', output_format='pandas')
data, meta_data = ts.get_intraday(symbol='TSLA',interval='1min', outputsize='full')
print(data.head(5))
print(meta_data)
1. open 2. high 3. low 4. close 5. volume
date
2020-04-16 16:00:00 746.06 746.830 745.530 745.6800 83342.0
2020-04-16 15:59:00 746.57 746.715 745.090 746.1958 53268.0
2020-04-16 15:58:00 746.90 747.465 746.490 746.6250 36746.0
2020-04-16 15:57:00 747.52 747.760 746.827 747.2147 25910.0
2020-04-16 15:56:00 747.95 747.990 746.800 747.2800 33869.0
{'1. Information': 'Intraday (1min) open, high, low, close prices and volume', '2. Symbol': 'TSLA', '3. Last Refreshed': '2020-04-16 16:00:00', '4. Interval': '1min', '5. Output Size': 'Full size', '6. Time Zone': 'US/Eastern'}
1. open 2. high 3. low 4. close 5. volume EMA
I had the same problem and wasn't able to solve it yet. But in my case only some stocks are not up to date. For example 'IBM' is up to date but 'TSLA' and 'AAPL' not. I also have written an email to the technical support 2 days ago. If I ever get a response with the explanation I will write you. I have checked this not only with the python module also with the direct API call.
My code:
https://github.com/SebNik/TradingBot
I also noticed this and contacted Alpha Vantage. I got this response:
Thank you for reaching out! For Nasdaq-listed securities such as MSFT, the data is refreshed daily at 4:30pm ET on our API platform.
So looks like real-time data is not provided for Nasdaq-listed items. This could be the issue here.
I'm looking to fetch recorded data using LogBook in a custom Movesense firmware. How do I get the correct byte stream offset for the next GET call when receiving HTTP_CONTINUE?
I'm trying to implement these steps as described in DataStorage.md:
### /Logbook usage ###
To get recording from the Movesense sensors EEPROM storage, you need to:
1. Do **GET** on */Logbook/Entries*. This returns a list of LogEntry objects. If the status was HTTP_OK, the list is complete. If the result code is HTTP_CONTINUE, you must GET again with the parameter StartAfterId set to the Id of the last entry you received and you'll get the next entries.
2. Choose the Log that you are interested in and notice the Id of it.
3. Fetch the descriptors with **GET** to */Logbook/byId/<Id>/Descriptors*. This returns a bytestream with the similar HTTP_CONTINUE handling as above. However you **must** keep re-requesting the **GET** until you get error or HTTP_OK, or the Logbook service will stay "in the middle of the stream" (we hope to remove this limitation in the future).
4. Fetch the data with **GET** to */Logbook/byId/<Id>/Data*. This returns also a bytestream (just like the */Logbook/Descriptors* above).
5. Convert the data using the converter tools or classes. (To Be Continued...)
The problem is basically the same for step 3 and 4. I receive a whiteboard::ByteStream object in the onGetResult callback function but I don't know how to get the correct offset information from it.
I've found a number of different methods seemingly concerning different aspects of number of bytes in ByteStream.h (length, fullSize, transmitted, payloadSize and serializationLength) but I just can't get it working properly.
Basically I would like to do something like this in onGetResult:
if (resultCode == whiteboard::HTTP_CODE_CONTINUE) {
const whiteboard::ByteStream &byteStream = rResultData.convertTo<const whiteboard::ByteStream &>();
currentEntryOffset += byteStream.length();
asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(), AsyncRequestOptions::Empty, currentEntryIdToFetch, currentEntryOffset);
return;
}
The basic idea is to do the same call again.
So if you do:
asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(),AsyncRequestOptions::Empty, currentEntryIdToFetch);
and get the response HTTP_CONTINUE, do:
asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(),AsyncRequestOptions::Empty, currentEntryIdToFetch);
Until you get HTTP_CONTINUE or an error.
If the result code is HTTP_CONTINUE, you must GET again with the parameter StartAfterId set to the Id of the last entry you received and you'll get the next entries.
Might be a bit cryptic but do another asyncGet to the exact same resource until you get HTTP_OK or an http error code.
Also, note that you need to decode the data, a python script can be found here in this answer
I am using the getdata function of the trading toolbox in Matlab (http://de.mathworks.com/help/trading/ibtws.getdata.html) to get real time price data of forex pairs (e.g. EURUSD) through the most up to date TraderWorkStation (TWS) with an Interactive Brokers (IB) demo account using the most recent API offered by IB (v9.71).
The TWS is running while executing my code (see below)
Here is the code I am using. It follows all the basic steps explained in the follwing tutorial by Mathworks (http://de.mathworks.com/videos/get-started-with-trading-toolbox-connect-to-interactive-brokers-1-of-3-91839.html).
% establish connection to TWS
ib = ibtws('',7497);
%% create currency handles
ibEURUSD = ib.Handle.createContract;
% set forex credentials
ibEURUSD.symbol = 'EUR';
ibEURUSD.secType = 'CASH';
ibEURUSD.exchange = 'IDEALPRO';
ibEURUSD.currency = 'USD';
cur = getdata(ib,ibEURUSD);
% close IB connection
close(ib);
In most of the cases (roughly 75%) this code deliveres the expected results and returns the requested financial data. However, in the remaining cases the variable "cur" does not contain the requested price data but the following error message: "HMDS data farm connection is OK:ushmds"
Which fist does not look like a problem. However this error message replaces the requested data so that during 25% of the runs no data will be received.
I apprechiate any hints to solve this.
It's bug in the MATLAB Trading Toolbox. There are a few messages that the IB API documentation describes as being safe to ignore, but the MATLAB errMsg event handler does not ignore them and instead terminates the ongoing getdata request while the price data is being received. The "HMDS data farm connection is OK:ushmds" is message number 2106 which is one of the ignorable messages.
Consider using the IB-Matlab connector, which does not have this problem.
I have a strange issue (hope you can help): I am working on a GWT Web Application that has times when more than 4 - 5 GWT RPC calls are made in the same time - as far as time is concerned.
Every once in a while - once every 15 calls maybe? The return Object from one call, gets 'assigned' to another. I have proof of this by using the gwt-log library on the client side.
Here the return object of the HistoryChangesCount call, got assigned to the modelingGetTemplates call also.
Thus resulting in a ClassCastException in the client file that made the call, on the same line as the onSuccess method.
Do you have any tips on how I can avoid this?
PS - I log every response object.toString() on error level. I know it's not best practice. It's just for troubleshooting.
[14:38:01.026] "(-:-) 2014-04-03 14:38:01,025 [ERROR] getHistoryChangesCount - HistoryPreviewFacet - SUCCESS RETURNED: HistoryChangesCount{dateToNumberOfChangesMap={Mon Mar 31 03:00:00 GMT+300 2014=3}, lastUpdatedOn=Mon Mar 31 11:11:02 GMT+300 2014}
"
[14:38:01.163] "(-:-) 2014-04-03 14:38:01,162 [ERROR] modelingGetTemplates - ModelingTemplatesDropdown - SUCCESS RETURNED: HistoryChangesCount{dateToNumberOfChangesMap={Mon Mar 31 03:00:00 GMT+300 2014=3}, lastUpdatedOn=Mon Mar 31 11:11:02 GMT+300 2014}
"
[14:38:01.175] "(-:-) 2014-04-03 14:38:01,174 [ERROR] Browser: null
java.lang.ClassCastException
at Unknown.iCb(StackTraceCreator.java:174)
at Unknown.sd(StackTraceCreator.java:508)
at Unknown.Txn(Throwable.java:46)
at Unknown.kIc(Cast.java:46)
at Unknown.rff(ModelingTemplatesDropdown.java:79)
at Unknown.bXi(AsyncWrapperForRPCManager.java:38)
at Unknown.Loe(RequestCallbackAdapter.java:232)
at Unknown.MWb(Request.java:258)
at Unknown.qXb(RequestBuilder.java:412)
at Unknown.anonymous(XMLHttpRequest.java:351)
at Unknown.eBb(Impl.java:189)
at Unknown.hBb(Impl.java:242)
at Unknown.anonymous(Impl.java:70)
"
Here is how a successful call to modelingGetTemplates looks like:
[14:37:24.933] "(-:-) 2014-04-03 14:37:24,932 [ERROR] modelingGetTemplates - ModelingTemplatesDropdown - SUCCESS RETURNED: [Advanced Business Application, Advanced Business Transaction, TestTemplate]
"
I am using vanilla GWT-RPC. I only have a class that extends AsyncWrapper for logging. I also created myself a client side queue that limits the number of parallel calls to 4, but even so it still happens.
Versions:
GWT: 2.5.1
and I also use Sencha GXT, not sure if relevant.
Here is a video of the issue reproducing - at 0:30 - this time another call get's the object from modelingGetTemplates.
The end result is that my widget is stuck on loading waiting for data forever. And of course angry users :)
Documenting the way I got around this, rather than fixing it :) (because I couldn't find a fix)
I created a client side GWT RPC call queue.
Any RPC call made by the UI was registring the call to the queue, and the queue would manage (during high load, read delay), the actual execution of the calls.
It acted similar to a thread pool. I had a constant of how many parallel calls I can have at one time, and also a minimum time interval between two calls. I believe it was eventually set to 200 milliseconds.
So by doing the above I (almost) never got that issue. The frequency was so low, nobody noticed it anymore.
My guess of the cause below:
I believe the GWT framework has some maps that use a key that depends on the timestamp of the calls, and if two calls happen at the same time, the map could switch the calls, messing up the results to calls mapping.