Imported from previous forum
We are using FIX with a client and have agreed to add particular fields as "required" in our FIX applicaton messages (incremental to those required by FIX) fo ruse by our application.
We are trying to determine if we should go for the administrative reject message if any of the required fields are missing VS using the application level rejection.
Benefits of keeping it ad the administrative level would mean we wouldn’t propagate “bad” messages further into our application. But, they are not required on a FIX protocol level, so is it “best” to pass it up for an app level rejection?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> We are trying to determine if we should go for the administrative reject message if any of the required fields are missing VS using the application level rejection.
>
> Benefits of keeping it ad the administrative level would mean we wouldn’t propagate “bad” messages further into our application. But, they are not required on a FIX protocol level, so is it “best” to pass it up for an app level rejection?
In general, application-level rejects are preferred. While it means you have to carry "bad" data farther into your application, it also makes it easier for your clients to carry your rejects farther into their applications.
Not everyone processes session-level rejects well. At a minimum, it is clear that a compliant FIX engine cannot resend a message the other party rejected at the session level. But making the connection between the session-level sequence number of the message rejected and the business action that produced it can be somewhat difficult, depending on one’s internal architecture.
It generally is a safer assumption that everyone can process application-level rejects; the extra time to implement them as opposed to session-level rejects can often pay for itself by eliminating a whole class of failure scenarios.