Imported from previous forum
What practices are in place when using session level and application elvel reject messages in a hub scenario? E.g. Session Level Reject and Business Message Reject messages.
A message received by a hub from Party A FIX session (and not rejected at the session level) is then delivered onto Party B. If the Party B session rejects the message back to the hub with a session level reject message, what should the hub send back to the Party A session? Similar question for a Business Message Reject scenario.
In order for this to work correctly the hub would need to map the routed message (message sent to Session B) back to the message reeceived by the hub from Session A, so that it could obtain the correct SeqNo to use in the session message reject (or business message reject) routed back down to Session A. There are complications here if the Party A - hub session has run its end of day processing in the meantime, so that the original sequnence number is no longer relevant for the current session.
Would another approach would be to add an Application level “unique-identifier” to each message (in an Application header), which did not make use of the session level message sequence numbers. And use a generic Application level reject message which referenced the message type and the “unique identifier”?
Could this approach also be used as a generic way to reject application messages, rather than having different message types for different scenarios… e.g. Execution Report to reject an Order and Business Message Reject to reject other message types.
The advantage for a hub is it would not need to do any cross-referencing to the original message.
Does anyone have any other way they have got around this scenario?
Thanks
Clive Browning
[ original email was from John Prewett - jprewett@lavatrading.com ]
Hi Clive,
I happen to know something about this subject.
When operating as a FIX hub, I have in the past re-mapped sequence numbers between the two sessions such that a Reject of BusinessReject, when forwarded, contains the appropriate sequence number.
I never hit the scenario surrounding re-mapping when an EOD has occurred. This sounds extremely ugly. I’m not strictly sure how this could occur. A request on Session A is forwarded on Session B. The hub runs EOD. A Reject or BusinessReject is received on session B and the sequence number remapping is no longer a viable option as the sequence numbers have been reset. Why did the Reject or BusinessReject response happen after EOD, rejecting something that happened before EOD? Can you not effectively “quiesce” both sessions for a while prior to running EOD, so that all “unfinished business” is wrapped up. Then run EOD. That way any dangling responses to things should all happen prior to running EOD.
Sorry for the rambling. I hope some of this helps.
Thanks
JohnP
What practices are in place when using session level and application elvel reject messages in a hub scenario? E.g. Session Level Reject and Business Message Reject messages.
A message received by a hub from Party A FIX session (and not rejected at the session level) is then delivered onto Party B. If the Party B session rejects the message back to the hub with a session level reject message, what should the hub send back to the Party A session? Similar question for a Business Message Reject scenario.
In order for this to work correctly the hub would need to map the routed message (message sent to Session B) back to the message reeceived by the hub from Session A, so that it could obtain the correct SeqNo to use in the session message reject (or business message reject) routed back down to Session A. There are complications here if the Party A - hub session has run its end of day processing in the meantime, so that the original sequnence number is no longer relevant for the current session.
Would another approach would be to add an Application level “unique-identifier” to each message (in an Application header), which did not make use of the session level message sequence numbers. And use a generic Application level reject message which referenced the message type and the “unique identifier”?
Could this approach also be used as a generic way to reject application messages, rather than having different message types for different scenarios… e.g. Execution Report to reject an Order and Business Message Reject to reject other message types.
The advantage for a hub is it would not need to do any cross-referencing to the original message.
Does anyone have any other way they have got around this scenario?
Thanks
Clive Browning
Hi John
Thanks for the ramblings, always appreciated.
One scenario occurs if we have the two sessions using completely different service windows (owing to them being in different time zones)… and running EOD at different times. And… using store and forward to send the messages between the sessions when either is off-line.
I’m sort of asking… it would be nice if the seqnos were not involved with rejects, in much the same way an Order can be rejected using an Execution Report. And it would be even nicer if this was via a generic application message reject.
Clive
Hi Clive,
I happen to know something about this subject.
When operating as a FIX hub, I have in the past re-mapped sequence numbers between the two sessions such that a Reject of BusinessReject, when forwarded, contains the appropriate sequence number.
I never hit the scenario surrounding re-mapping when an EOD has occurred. This sounds extremely ugly. I’m not strictly sure how this could occur. A request on Session A is forwarded on Session B. The hub runs EOD. A Reject or BusinessReject is received on session B and the sequence number remapping is no longer a viable option as the sequence numbers have been reset. Why did the Reject or BusinessReject response happen after EOD, rejecting something that happened before EOD? Can you not effectively “quiesce” both sessions for a while prior to running EOD, so that all “unfinished business” is wrapped up. Then run EOD. That way any dangling responses to things should all happen prior to running EOD.
Sorry for the rambling. I hope some of this helps.
Thanks
JohnP
What practices are in place when using session level and application elvel reject messages in a hub scenario? E.g. Session Level Reject and Business Message Reject messages.
A message received by a hub from Party A FIX session (and not rejected at the session level) is then delivered onto Party B. If the Party B session rejects the message back to the hub with a session level reject message, what should the hub send back to the Party A session? Similar question for a Business Message Reject scenario.
In order for this to work correctly the hub would need to map the routed message (message sent to Session B) back to the message reeceived by the hub from Session A, so that it could obtain the correct SeqNo to use in the session message reject (or business message reject) routed back down to Session A. There are complications here if the Party A - hub session has run its end of day processing in the meantime, so that the original sequnence number is no longer relevant for the current session.
Would another approach would be to add an Application level “unique-identifier” to each message (in an Application header), which did not make use of the session level message sequence numbers. And use a generic Application level reject message which referenced the message type and the “unique identifier”?
Could this approach also be used as a generic way to reject application messages, rather than having different message types for different scenarios… e.g. Execution Report to reject an Order and Business Message Reject to reject other message types.
The advantage for a hub is it would not need to do any cross-referencing to the original message.
Does anyone have any other way they have got around this scenario?
Thanks
Clive Browning