The diagram shows a configuration in which FIXEdge is a router between Client and Exchange.
FIXEdge works with two sessions:
- Client <-> FIXEdge (FIX session 1)
- FIXEdge <-> Exchange (FIX session 2).
Expected message flow: messages from the Client are routed to the Exchange and messages from the Exchange are routed back to the Client.
Sequences in such sessions FIX session 1 and FIX session 2 don't match. If the Exchange rejects a message from the client with session Reject (35=3), the Client often wants to get information about the rejected message. However, the value from RefSeqNum (45) tag doesn't refer to the original message from FIX Session 1.
As session-level messages aren't routed by BL rules, additional processing of session level Reject (35=3) is required to pass information about a rejected message back to the sender.
BL Rules configuration
Session level Rejects (35=3) trigger OnSessionLevelRejectEvent action on BL.
1. Stores all data from the original reject to some variables
2. Gets rejected message from the session logs with getMsgBySeqNum(<SenderCompId>, <TargetCompId> , <SeqNum>) function.
3. Serializes to the text serializeMessage(<tagDelimiter>)
4. Creates new reject message again with transform(<target protocol>, <target message type> )
5. Fills stored data from #1
6. Adds information about the rejected message. In this example Text (58) tag is used for it.
The message is ready. It will be sent to the session later.
SENDER session can get information about the rejected message from the Text (58) field:
Received SessionLevelReject message:
8=FIX.4.4|9=245|35=3|49=FIXCLIENT|56=FIXEdge|34=4|52=20180412-09:49:37.738|45=4|371=452|372=D|373=6|58=Field value '122' does not meet ValBlock dictionary conditions in tag 452[Group tag=453, Entry #=1] in message New Order - Single (D) with sequence number 4.|10=210|