Imported from previous forum
What should be the ideal way from the following choices to express the error (from sell side or exchange side FIX 4.2 engine) in Execution Report (35=8) or Cancel Reject (35=9)?
- Error string like “Price value out of range”, be populated in 58 tag and transmitted to the receiving FIX engine.
- Error code value (possibly numeric) be sent as the value of tag 103 (in case of execution report) or tag 102 (in case of cancel reject). In this case the receiving FIX engine should be able to map predefined the error string from the error code and can use that string for further processing.
If the second option is expercised, how should this Error Code to Error String mapping be transferred to the receiving engine?
Please suggest any alternate solutions if any…
The ideal way is to use tag OrdRejReason (103) to communicate error. This is has the following benefits -
- Standard mechanism for communicating error.
- Receiving application can convert this to any language before displaying
- If the receiving application does not have a GUI it doesn’t have to do screen scraping to understand what your Text field means.
But having said that many implementations I have seen do not use OrdRejReason alone becuase its not always practical -
- Range of possible OrdRejReason values are more than whats defined in FIX 4.2
- If you change possible OrdRejReason values the client applications anyways will have to change if they want to benefit from it. Sometimes a sudden appearence of a new value can also cause receiving applications to fail. So its expensive to add new values.
- Many buy side client applications do not use OrdRejReason value at all and expect a meaningful message in Text.
So using OrdRejReason is good if your client connections are happy to use it properly. If not go for Text (or both).
What should be the ideal way from the following choices to express the error (from sell side or exchange side FIX 4.2 engine) in Execution Report (35=8) or Cancel Reject (35=9)?
- Error string like “Price value out of range”, be populated in 58 tag and transmitted to the receiving FIX engine.
- Error code value (possibly numeric) be sent as the value of tag 103 (in case of execution report) or tag 102 (in case of cancel reject). In this case the receiving FIX engine should be able to map predefined the error string from the error code and can use that string for further processing.
If the second option is expercised, how should this Error Code to Error String mapping be transferred to the receiving engine?
Please suggest any alternate solutions if any…
Tks Kingshuk for the reply.
I have one more thought in my mind, can an exchange side FIX engine develop customized Error Code to Error String mapping download?
This download may be based on request-response phenomenon and both request and response MsgTypes may be customized…
Do FIX 4.2 provides MsgType and tags for such downloads?
The ideal way is to use tag OrdRejReason (103) to communicate error. This is has the following benefits -
- Standard mechanism for communicating error.
- Receiving application can convert this to any language before displaying
- If the receiving application does not have a GUI it doesn’t have to do screen scraping to understand what your Text field means.
But having said that many implementations I have seen do not use OrdRejReason alone becuase its not always practical -
- Range of possible OrdRejReason values are more than whats defined in FIX 4.2
- If you change possible OrdRejReason values the client applications anyways will have to change if they want to benefit from it. Sometimes a sudden appearence of a new value can also cause receiving applications to fail. So its expensive to add new values.
- Many buy side client applications do not use OrdRejReason value at all and expect a meaningful message in Text.
So using OrdRejReason is good if your client connections are happy to use it properly. If not go for Text (or both).
What should be the ideal way from the following choices to express the error (from sell side or exchange side FIX 4.2 engine) in Execution Report (35=8) or Cancel Reject (35=9)?
- Error string like “Price value out of range”, be populated in 58 tag and transmitted to the receiving FIX engine.
- Error code value (possibly numeric) be sent as the value of tag 103 (in case of execution report) or tag 102 (in case of cancel reject). In this case the receiving FIX engine should be able to map predefined the error string from the error code and can use that string for further processing.
If the second option is expercised, how should this Error Code to Error String mapping be transferred to the receiving engine?
Please suggest any alternate solutions if any…
Tks Kingshuk for the reply.
I have one more thought in my mind, can an exchange side FIX engine develop customized Error Code to Error String mapping download?
This download may be based on request-response phenomenon and both request and response MsgTypes may be customized…
Do FIX 4.2 provides MsgType and tags for such downloads?
As far as I know there isn’t any such message type.
The ideal way is to use tag OrdRejReason (103) to communicate error. This is has the following benefits -
- Standard mechanism for communicating error.
- Receiving application can convert this to any language before displaying
- If the receiving application does not have a GUI it doesn’t have to do screen scraping to understand what your Text field means.
But having said that many implementations I have seen do not use OrdRejReason alone becuase its not always practical -
- Range of possible OrdRejReason values are more than whats defined in FIX 4.2
- If you change possible OrdRejReason values the client applications anyways will have to change if they want to benefit from it. Sometimes a sudden appearence of a new value can also cause receiving applications to fail. So its expensive to add new values.
- Many buy side client applications do not use OrdRejReason value at all and expect a meaningful message in Text.
So using OrdRejReason is good if your client connections are happy to use it properly. If not go for Text (or both).
What should be the ideal way from the following choices to express the error (from sell side or exchange side FIX 4.2 engine) in Execution Report (35=8) or Cancel Reject (35=9)?
- Error string like “Price value out of range”, be populated in 58 tag and transmitted to the receiving FIX engine.
- Error code value (possibly numeric) be sent as the value of tag 103 (in case of execution report) or tag 102 (in case of cancel reject). In this case the receiving FIX engine should be able to map predefined the error string from the error code and can use that string for further processing.
If the second option is expercised, how should this Error Code to Error String mapping be transferred to the receiving engine?
Please suggest any alternate solutions if any…