I have a questions about FIX protocol.
I plan to send a PositionReport message without a PositionReportRequest message received. But i must fill a field, ClearingBusinessDate, in the PositionReport message that i do not know what is the purpose of that field. Altough the PositionReportRequest has that field, i will not get a request message before sending a report message. So, i have no idea what it should be. And the worst thing is it is a required field..
What should be the value of ClearingBusinessDate field?
Thanks
This is more a question for your counterparty than a question about general FIX protocol.
If you're connecting to an outside FIX counterparty (e.g. exchange, clearing firm, etc), they should have documentation on their interface that should describe what the expected fields and field values should be. If they don't have docs, then you'll have to ask them.
FIX is a very loose protocol. All of the messages and fields in the default message/field definitions are really just suggestions. In practice, most counterparties alter and mutilate these message/field definitions in numerous ways. They may add custom fields, change field types, make optional fields required and vice versa, remove fields, etc etc. I've never seen a counterparty not mess with the definitions.
(P.S. You have a very low answer-acceptance rate. Please consider going back over your past questions and accepting the best answers. You'll get rep points, and you'll make StackOverflow better.)
Related
I have been struggling to find information on how a resource that contains generated values is modified. Below is a real world example:
Let's say we have 2 endpoints:
/categories and /products.
A category is used to contain various parameters that define any product belonging to it. For example, based on a category a product expiration date might be calculated, or some other properties might or might not be attached to a product.
Let's say we create a new product by sending a POST request to /products and among other fields we include the category ID property. Based on the category set a server creates and stores a new product along with various properties generated (expiration date, delivery policies) etc.
Now the problem arises when needing to modify (PATCH/ PUT) the mentioned product.
How are generated values edited? We can for example change a delivery policy, but then the product will contain a field that doesn't match what its attached category describes. Likewise, it might be very handy to modify its generated expiration date, however yet again that can create confusion about why a category says it should expire in 3 days but the product is set to expire in 20 days.
Another solution would be to make all these properties read-only and only allow regenerating them by changing the category, just like at creation.
However that poses 2 problems:
The biggest one being that a different category might not contain the same policy layout. For example, one category might enable generating GPS coordinates to ease the delivery, the other category does not. If we change the category, what do we do with these valuable properties already present? Do we drop them for the sake of clarity?
Another issue is limited flexibility. There might be cases when a property needs to be changed but the category needs to remain the same.
I think these questions are met and answered in probably every single REST API development and probably I am just missing something very simple and obvious. Could you help me understand the right way of going about this?
Thank you very much.
I think these questions are met and answered in probably every single REST API development and probably I am just missing something very simple and obvious. Could you help me understand the right way of going about this?
You write code to ensure that all of the invariants hold for the server's copy of the resource.
That can mean either (a) inspecting the body of the request, and returning a client error if the body doesn't satisfy the constraints you need to maintain, or (b) changing your resource in a way that doesn't exactly match the request you've received.
In the second case, you need to have a little bit of care with the response metadata, so that you don't imply that the representation of the request has been adopted "as is".
The code you are writing here is part of the origin server's implementation, deliberately hidden by the HTTP facade you present. The general purpose components in the middle don't care about those details; they just want you to use messaging semantics consistent with the HTTP (and related) specifications.
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.
I'm trying to understand the variety of message types and data fields in FIX protocol.
I did understand most of the things but I'm still not sure about Quotes and HandlInst.
When a dealer or a broker wants to trade in the market he have a list of all available products (e.g USD/EUR, USD/JPN, ...). each product has sell-price and buy-price which being update in high rate. Which message type generates this values? A Quote message type(quote request and quote response)?
A broker have the option to decide for each one of his dealers whether he automatically response as the counter-party for the dealer orders or the orders go out to the market for a trade. Which filed in the order message types indicates that mark? I was thinking about HandlInst <21> but i'm not quite sure...
Thanks for your help
These are vendor-specific questions. FIX just gives you a pile of messages and fields you can use, and some recommendations for how to use them. Some counterparties even follow those recommendations, but nearly all of them add their own weird customizations or use certain fields in weird ways.
If you are connecting to an external counterparty, you need to read their docs for their specific FIX interface. That will tell you which fields they use, how they use them, and what they expect from you.
So, get your counterparty's docs and read them.
Ok Kitsune, here are my answers for you (you should pay me for this !)
yes, Quote, and QuoteCancel (usually)
I think you are talking about an internal broker decision that's not to do with FIX. HandlInst can be used by a client sending their order to the broker to specify manual or automatic execution, but I think that is in specific limit order cases only, not the usual fill or kill stuff. If the order was $100mio then maybe a client would specify manual execution. Again, as in your other post, the ExecutionReport can specify manual or auto execution as well. Need to look at that...
I need to capture user input using a form. Each field within the form will undergo validation. The field will be either valid or invalid. Depending on the user input, certain parts of the form may be enabled, disabled, filtered or otherwise modified.
I am considering the state pattern to model the state transitions through the form. Each state will affect how the form is displayed, filtered etc. However, my understanding of the state pattern is that it would require a very large number of states to represent my form.
For example; if I have 10 fields that can be valid or invalid that is:
10P2 = 90 permutations.
That is an enormous number of states to represent in code, and I have grossly simplified the problem.
Questions:
Am I misunderstanding how to implement the state pattern for my problem?
If not, is the state pattern the wrong solution to my problem?
If yes to the last question, what is a good general solution?
Am I misunderstanding how to implement the state pattern for my
problem?
I think you've understood it correctly.
If not, is the state pattern the wrong solution to my problem?
Yes. The State pattern is a good solution when there are a limited number of states (conditions). This is not true in your case.
If yes to the last question, what is a good general solution?
I would recommend using the Specification pattern. You can have any number of rules attached to your input fields. The rules can determine if the field should be enabled or disabled, visible or hidden. Also worth noting is that the rules can be easily unit tested separately.
I'm creating v2 of an existing RESTful web api.
The responses are JSON lists of objects, roughly in the form:
[
{
name1=value1,
name2=value2,
},
{
name1=value3,
name2=value4,
}
]
One problem we've observed with v1 is that some clients will access fields by integer position, instead of by name. This means that if we decide to add fields to the response (which we had originally considered a compatibility-preserving change), then some of our client's code breaks, unless we add the fields at the end. Even then, other clients code breaks anyway, because they will fail in some way when they encounter an unexpected attribute name.
To counter this in v2, we are considering randomly reordering the fields in every response. This will force clients to index fields by name instead of by position.
Additionally, we are considering adding a randomly-named field to every response. This will force clients to ignore fields they don't recognize.
While this sounds somewhat barmy, it does have the advantage that we will be able to add new fields, safe in the knowledge that this isn't breaking any clients. This means we can issue compatible updates to v2.1, v2.3, etc at the same URL, and that means we will only have to maintain & support a smaller number of API versions.
The alternative is to issue compatibility-breaking v3, v4, at new URLs, which means that we will have to maintain & support many incompatible API versions, which will stretch us that little bit thinner.
Is this a bad idea, and if so, why? Are there any other similar ideas I should think about?
Update: The first couple of responses are pointing out that if I document the issue (i.e. indicate in the docs that fields may be added or reordered) then I am no longer to blame if client code breaks when I subsequently add or reorder fields. Sadly I don't think this is an appropriate option for us: Many dozens of organisations rely on the functionality of our APIs for real-world transactions with substantial financial impact. These organisations are not technically oriented - and the resulting implementations at the client end cover the whole spectrum of technical proficiency. We already did document that fields may get added or reordered in the docs for v1, and that clearly didn't work, because now we're having to issue v2 because many clients, due to lack of time or experience or ability, still wrote code that breaks when we add new fields. If I were now to add fields to the interface, it breaks a dozen different company's interfaces to us, which means they (and us) are bleeding money every minute. If I were to refuse to revert the change or fix it, saying "They should have read the docs!", then I will soon be out of the job, and rightly so. We may attempt to educate the 'failing' partners, but this is doomed to fail as the problem gets larger every month as we continue to grow. My question is, can I systemically head the whole issue off at the pass, preventing this situation from ever arising, no matter what clients try to do? If the techniques I suggest would work, why shouldn't I use them? Why isn't everyone else using them?
If you want your media types to be "evolvable", make that point very clear in the documentation. Similarly, if the placement order of fields is not guaranteed, make that explicitly clear too. If you supply sample code for your API, make sure it does not rely on field ordering.
However, even assuming that you have to maintain different versions of your media types, you don't have to version the URI. REST gives you the ability to maintain the same version-agnostic URI but use HTTP content negotiation (via the Accept and Content-Type headers) to offer different payloads at the same URI.
Therefore any client that doesn't explicitly wish to accept your new v2/v3/etc encoding won't get it. By default, you can return the old v1 encoding with the original field ordering and all of those brittle client apps will work fine. However, new client developers will know (thanks to your documentation) to indicate via Accept that they are willing and able to see the new fields and they don't care about their order. Best of all, you can (and should) use the same URI throughout. Remember - different payloads like this are just different representations of the same underlying resource, so the URI should be the same.
I've decided to run with the described techniques, to the max. I haven't heard any objections to them that hold any water for me. Brian's answer, about re-using the same URI for different API versions, is a solid and much-appreciated complementary idea (with upvote), but I can't award it 'best answer' because it doesn't get to the core of my original question.