I am receiving incomplete SecurityLists from a venue. Here is the message I am receiving:
8=FIXT.1.1|9=112|35=y|34=9|49=xxx|52=20130913-11:17:37.418|56=xxx|146=1|020001=20130913-11:17:37.402|10=108
(I have deleted the COMPID's)
I have tried reordering the repeating groups fields in our data dictionary to match the order of the repeating group fields in the venues data dictionary.
Still having no luck!
Advice would be appreciated.
You're using QuickFIX, right?
If yes, I'm guessing that you are missing UseDataDictionary=Y and/or DataDictionary=path/to/your/dd. It's a common newbie mistake.
This is just a guess, though. You really haven't given much to go on.
Related
Beginner question. I would like to have a value list display only the records in a found set.
For example, in a law firm database that has two tables, Clients and Cases, I can easily create value list that displays all cases for clients.
But that is a lot of cases to pick from, and invites user mistakes. I would like the selection from the value list to be restricted to cases matched to a particular client.
I have tried this method https://support.claris.com/s/article/Creating-conditional-Value-Lists-1503692929150?language=en_US and it works up to a point, but it requires too much entry of data and too many tables.
It seem like there ought to be a simpler method using the find function. Any help or ideas greatly appreciated.
I want to be able to get the total amount of reactions and then split by each type of reaction. This is what I am using so far for getting the total amount of reactions and the count of likes.
me?fields=posts{reactions.summary(true),likes.summary(true)}
However, I would like for the other kind of reactions to be included as well (love, sad, hahah etc.)
When I try to query the love field I get the following debug message:
The love field does not exist on the PagePost object.
I've gone through all the node options but I can't find them.
Any help will be greatly appreciated since I am quite stuck.
Specific types of reactions can be queried using the type parameter, see https://developers.facebook.com/docs/graph-api/reference/v6.0/object/reactions#parameters
If you want to query data for multiple reactions in one request, then you will have to use the Field Aliasing syntax, otherwise you will get an error saying that your field list contained the reactions field twice. https://developers.facebook.com/docs/graph-api/aliasing-fields
So this could look something like this,
me?fields=posts{reactions.type(LOVE).summary(1).as(reacts_love),
reactions.type(LIKE).summary(1).as(reacts_like)}
(Exemplary for the two reaction types LOVE and LIKE - add the rest, by following the same format.)
The resulting data will then contain sub-structures under the keys reacts_love and reacts_like.
This might still give you some data about individual reactions - if you don’t need those, but only the summaries, you can also add .limit(0) into the above “chains” of parameters - then the data portion of these responses will always be empty.
In the FIX.4.4 data dictionary XML bundled with the quickfix library, it appears that some fields are marked as required that possibly should not be according to protocol specs as described in FIXimate.
For example:
35/OrderId in message AE/TradeCaptureReport's component group TrdCapRptSideGrp 552/NoSides
Another example:
15/ExecType in message AR/TradeCaptureReportAck
I am thinking that these fields should not be required, and that I can simply mark them as required='N' in the FIX44.xml in my data dictionary.
Is it at all surprising that I am finding questionable required='Y' in the stock data dictionary? Should I be at all concerned about changing these?
It's best to consider the FIX's default data dictionaries as nothing more than a suggestion.
In practice, every counterparty does things a little differently and may
use certain fields in different ways. Additionally, most counterparties
like to add custom fields to messages (or even all new messages!), and you'll need to adjust your data dictionary XML to match, so that the engine knows what fields to expect.
In practice, I've never seen a counterparty that didn't screw with the data dictionary at least a little. You really have to check each firm's specs; assume nothing.
Venue 1 may use a a specific message to request say Market Data, whilst venue 2 may use another message for the same task. Now what is the best way of mapping this? Any suggestions would be appreciated
Plus is it sensible to append extra fields to a venues message, to make mapping easier?
Can anyone provide insight on how an exchange performs this task? As an exchange which is connected to multiple venues must surely have to parse and translate each venues spec.
Unfortunately, the flexible nature of FIX doesn't really make this an easy task. My other answer goes into more detail on why converting between FIX versions is not feasible and how two venues using the same FIX version can actually be radically incompatible.
In my experience, you really have to write a custom adapter for each venue. One way is to create a venue-independent set of data objects for your app to use, and then implement conversions between your objects and the FIX messages to/from the venue. The app would see the converter as only a generic interface; it doesn't need to know whether the target venue is 4.2 or 4.4 or whatnot.
For instance, you could create a GenericNewOrder class and an IConverter interface with a method SendNewOrder(GenericNewOrder). The IConverter has an implementation for each venue, e.g. VenueAConverter and VenueBConverter. VenueAConverter creates a new order message appropriate for VenueA, and VenueBConverter creates one for VenueB. If you ever have to add a new venue, just implement a new IConverter.
That's the best pattern I've been able to come up with.
(Questions like yours actually come up semi-frequently on the QuickFIX mailing lists.)
These day I work with a database that have this style of relationship then I've been very confused with it. This database is in a very large web app & have worked well for 10 years then I wonder whether this design is good in someway? or in which situations I should implement it?
Welcome any idea!
There is nothing wrong in my opinion. You can have, for example, in a personal_data table a place_of_birth field and a place_of_living field both referring to a cities table. By the way you should post a more meaningful example to have a more precise answer.