When I send the order request on the FIX server as :
8=FIXT.1.1|9=179|35=D|34=34|49=135|52=20200206-04:52:04.406|56=PSE|1=11101401117577|11=1580964724079|38=1000|40=2|44=10.5|54=1|55=AGI|59=0|60=20200206-12:52:04.406|453=1|448=13501100|447=C|452=12|10=009|)
The response that I receive is:
8=FIXT.1.1|9=000362|35=8|49=PSE|56=135|34=34|57=13501100|52=20200206-04:52:04.533|37=NONE|11=1580964724079|453=4|448=13501999|447=C|452=11|448=13501999|447=C|452=36|448=13501100|447=C|452=12|448=135|447=C|452=1|17=1904|150=8|39=8|103=99|1=11101401117577|55=AGI|54=1|38=1000|44=10.5|59=0|528=F|151=0|14=0|60=20200206-04:52:04.356|58=(293): **Orders are not being accepted at this time|10=020|)**
With the PSE error as:
<20200206-04:52:04, FIXT.1.1:135->PSE, error> (Rejecting invalid message: quickfix.IncorrectTagValue: Value is incorrect (out of range) for this tag, field=528 field=528: 8=FIXT.1.1|9=362|35=8|34=34|49=PSE|52=20200206-04:52:04.533|56=135|57=13501100|1=11101401117577|11=1580964724079|14=0|17=1904|37=NONE|38=1000|39=8|44=10.5|54=1|55=AGI|58=(293): Orders are not being accepted at this time|59=0|60=20200206-04:52:04.356|103=99|150=8|151=0|528=F|453=4|448=13501999|447=C|452=11|448=13501999|447=C|452=36|448=13501100|447=C|452=12|448=135|447=C|452=1|10=132|)
<20200206-04:52:04, FIXT.1.1:135->PSE, error> **(Reject sent for Message 34: Value is incorrect (out of range) for this tag**, field=528:528)
According to the documentary the value for 1 should be 14 digit trading account(1=xxxxxxxxxxxxxx) but when I give that, then I had receive the above error.So what value should be given for 1 so the response should be receive.
So what is the solution for this error?
The flow is as follows:
you send a NewOrderSingle
they reply with an ExecutionReport that they don't accept orders at that time
you (and not PSE) reject that ExecutionReport because tag 528 on the ExecutionReport that PSE sent contains a value that is not contained in your data dictionary.
What you need to do is either of
Read PSE's rules of engagement (i.e. their FIX spec) and add all needed tags and values to your data dictionary.
Configure your session to not validate incoming messages (setting ValidateIncomingMessage=N) but this means you would need to do validation by yourself if required. E.g. if you wanted to retrieve values from tag 150/ExecType then you can be sure that only values which are allowed in the data dictionary reach your application. With disabled validation you would need to do these checks by yourself.
Alternatively you could set RejectInvalidMessage=N which also will not reject the message but only log the warning with the validation error.
Related
According to the docs on case class validation for parameter extraction ( the last section of the docs found here: https://doc.akka.io/docs/akka-http/current/routing-dsl/case-class-extraction.html), if the validation fails, a ValidationRejection is returned and the request is sent further down to the next route.
What I would like it to do is instead immediately return a 400 Bad Request telling the user that they've sent invalid query parameter values. If the request goes on to the next route, this information will all be lost. Is there any way around this?
The data could not have been inputted by a typical user due to client-side validation. Is "400 Bad Request" the appropriate status code?
If you are certain the form is invalid 400 Bad Request is acceptable. However depending on why you believe a form is invalid you may also choose to use
status code 422 Unprocessable Entity.
This status code is designed to handle the use case where an submitted request is understood by the server and the request is syntactically correct, but the server was unable to process the instructions contained within the request.
Another possibly appropriate error code would be 415 Unsupported Media Type. This error code should be used when the server fails to understand the request due to an invalid type of form. For example, if a server expected a JSON value but was given XML it should in theory return a 415 Unsupported Media Type code.
I have a QuickFIX initiator getting 1.23E-6 in tag 270 from market data. Then I saw QuickFIX/J throw the following error:
Rejecting invalid message: quickfix.IncorrectDataFormat: Incorrect data format for value, field=270
Any idea how to avoid the rejection and parse the correct value?
I also receive the scientific format of number from my 35=8 message in tag 44 (price), but I could just getString then convert them into BigDecimal with no issue.
The real problem here is that your counterparty should not be sending a scientific-notation value in that field. The field has type "Price", and per spec, that should be a whole or decimal number, thus that's what the QF engine is validating.
So, I don't know who your counterparty is, but maybe you want to check with their support and see if this might be a legit bug on their end.
(I can't explain why your 35=8/tag-44 message is being accepted. There must be a detail to your situation that I'm not aware of.)
If you need to work around this anyway: An easy cheat way to make the engine accept this message is to simply change the field's type to "string" in your Data Dictionary xml file. Of course, that will require you to always explicitly convert the string to BigDecimal, but it sounds like you will not have a problem with that.
So we send a FIX deal message without a side, and the bank rejects with a 35=8 execution report with 150=8 reject, and text FIX Tag 54 (Side) has invalid value (0). Reason (should be either 1 or 2) and then a 35=3 reject message with Value is incorrect (out of range) for this tag. The 35=3 message is cracked but the 35=8 message never gets to fromapp.
Am I missing a setting?
35=3 indicates a transport-level (aka admin-level) reject. The message was rejected at a lower parsing layer, which means that it's so malformed that it wasn't even passed up to your application.
Usually this kind of reject means that the message was messed up in a way such that the engine can't even parse it correctly, or that the header fields can't resolve to a known session. I'm a little surprised that your particular situation triggered a 35=3 instead of a 35=j.
I suppose you could check the FIX spec to see what it mandates when an enum-type tag has an unknown value. Maybe the engine is following spec in this case?
I guess the reason why the 35=8 message with the incorrect 54=0 tag doesn't get to FromApp or FromAdmin is because of a data dictionary constraint, but this gave me a chance to implement the public void FromEarlyIntercept(Message msg, SessionID s) interface, and that has solved the problem that a bad 35=8 report is now reported back to the user... but introduced a new problem that a good report is now reported twice.
So I added <value enum="0" description="ERROR"/> to the enumeration for <field number="54" name="Side" type="CHAR"> and now the 35=8 message is not rejected by a 35=3 message.
I was hoping someone can shed some light on how the Quickfixn engine handles outgoing FIX messages... I have an outgoing connection set up, and I'm getting heartbeats. When I generate an outgoing message however, it gets rejected because it says that tag 58 is invalid for this message type... (35=AE) ... Normally, if this was an inbound connection, I could just modify the Data Dictionary and everything would be fine... but seeing as how this is an outgoing connection, plus I have my
UseDataDictionary property set to 'N' ... what does the quickfix engine use to validate the outgoing message? Can something be changed to allow the engine to pass the message ? Or is the only resolution not to include this tag in my outgoing message?
Any help on this matter would be greatly appreciated.
Edit-
The message is getting rejected by the quickfix engine. The message that I'm constructing and the respective reject message are:
8=FIX.4.4 9=400 35=AE 34=38 49=XXX 52=20130528-23:11:04.040 56=YYY 31=1.3022 32=1000000.00 39=0 55=EUR/USD 58=ABCD 60=20130528-22:34:52.000 64=20130531 75=20130529 570=N 571=ABCD 5495=0 5971=1302200.00 552=1 54=2 37=ABCD 453=3 448=LP1-DBAB 447=D 452=17 448=XXX 447=D 452=1 448=XXX 447=D 452=19 15=EUR 120=USD 10=082
8=FIX.4.4 9=130 35=3 34=38 49=YYY 52=20130528-23:11:04.283 56=XXX 45=38 58=Tag not defined for this message type 371=58 372=AE 373=2 10=033
I've seen incoming messages get rejected by the quickfix engine because the data dictionary didn't have the correct specs for the message... I thought this might be the same thing but the outgoing connection doesn't seem to use the data dictionary.
Your FIX library does not reject a message. The message is sent to the counter-party instead, which then rejects your message as invalid upon receiving and validating it. And the reason for that is because tag 58, if present, must be a part of “NoSides repeating group (tag 552), which in your case it is not, making the message ill-formed. What you have to do is send a "logically" correct message. I recommend you refer to the appropriate FIX protocol specification for a reference on how to construct a correct message.
Vlad's answer is correct, but I want to alert you to one other danger in your question.
I have my UseDataDictionary property set to 'N'
I am 90% sure you don't want to do this. Whatever you think you're gaining by using =N is probably based on a misunderstanding of something.
Without a DD, you can't read messages with repeating groups, because the engine won't know what fields go in what group.
In practice, every venue uses repeating groups. Therefore, you'll need to set UseDataDictionary=Y and you need to specify an xml file with DataDictionary=<file>.
The only reason we allow =N in QF/n is to be consistent with QF/C++ and QF/j.