Imported from previous forum
[ original email was from Oren Miller - omiller@thoughtworks.com ]
In the Test Cases and Expected Behaviors document, tests 19a and 19b talk about testing the application level behavior of handling a PossResend message. I am working on the develepment of an open source fix engine that comes with a generic testing suite and would like to know if there is a way to handle this test in a generic way or should it be simply left to the developer.
Keep in mind that this is not testing PossDup which handles a duplicate message sent. PossResend tests identical application level data sent in a completely different FIX message. For instance it could be something like I sent a NewOrderSingle for the same order ID. Any thoughts on this?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> In the Test Cases and Expected Behaviors document, tests 19a and 19b talk about testing the application level behavior of handling a PossResend message. I am working on the develepment of an open source fix engine that comes with a generic testing suite and would like to know if there is a way to handle this test in a generic way or should it be simply left to the developer.
>
> Keep in mind that this is not testing PossDup which handles a duplicate message sent. PossResend tests identical application level data sent in a completely different FIX message. For instance it could be something like I sent a NewOrderSingle for the same order ID. Any thoughts on this?
PossResend is entirely an application-level concept. A FIX engine should just pass it up to the application layer to handle, clearly indicating that the message is a PossResend.
Unfortunately, not all application layers handle this gracefully. While we don’t send PossResend in production at this time, we are considering doing so in the future. I’ve been wondering how widely supported it is in the industry, so I had ARCA add two Poss Resend test cases into their automated certification environment to see who could and could not handle it. Preliminary results aren’t encouraging. We found two kinds of failure modes:
-
Some systems will double-book trades. I.e. client sends order for 1000, we send a partial fill for 100 and then Poss Resend the same partial fill for 100. The client erroneously books 200 shares as having traded.
-
Some systems will ignore Poss Resend entirely. I.e. client sends order for 1000, and we send a Poss Resend partial fill for 100 (simulating the original being lost.) The client erroneously ignores the partial fill.
fyi. Our system (a buyside perspective) can handle PossResend and perform a dupe check, however, we encountered some sellsides who did/could not always specify PossResend=Y. Therefore, we actually perform a dupe check (OrderID and ExecID combination for an open order with that sellside firm, security, and side combination) for every ExecRpt fill we receive.
> > In the Test Cases and Expected Behaviors document, tests 19a and 19b talk about testing the application level behavior of handling a PossResend message. I am working on the develepment of an open source fix engine that comes with a generic testing suite and would like to know if there is a way to handle this test in a generic way or should it be simply left to the developer.
> >
> > Keep in mind that this is not testing PossDup which handles a duplicate message sent. PossResend tests identical application level data sent in a completely different FIX message. For instance it could be something like I sent a NewOrderSingle for the same order ID. Any thoughts on this?
>
> PossResend is entirely an application-level concept. A FIX engine should just pass it up to the application layer to handle, clearly indicating that the message is a PossResend.
>
> Unfortunately, not all application layers handle this gracefully. While we don’t send PossResend in production at this time, we are considering doing so in the future. I’ve been wondering how widely supported it is in the industry, so I had ARCA add two Poss Resend test cases into their automated certification environment to see who could and could not handle it. Preliminary results aren’t encouraging. We found two kinds of failure modes:
>
> 1. Some systems will double-book trades. I.e. client sends order for 1000, we send a partial fill for 100 and then Poss Resend the same partial fill for 100. The client erroneously books 200 shares as having traded.
>
> 2. Some systems will ignore Poss Resend entirely. I.e. client sends order for 1000, and we send a Poss Resend partial fill for 100 (simulating the original being lost.) The client erroneously ignores the partial fill.
>
>