Imported from previous forum
In FIX4.4, allocation messages support fragmentation in which the sender can send subsequent fragmented messages referencing the same AllocID. This is against the general rule that AllocID should be unique with which we check the duplicate messages.
If we need to support the fragmentation of allocation messages but in the same time we also want to eliminate the duplicate messages, how can we solve this problem?
Thanks in advance,
Jue Wang
[ original email was from Gerardo Savoretti - gerardo.savoretti@ezxinc.com ]
> In FIX4.4, allocation messages support fragmentation in which the sender
can send subsequent fragmented messages referencing the same AllocID.
This is against the general rule that AllocID should be unique with
which we check the duplicate messages. If we need to support the
fragmentation of allocation messages but in the same time we also want
to eliminate the duplicate messages, how can we solve this problem?Thanks in advance,
Jue Wang
Hi Ms. Wang,
In FIX 4.4 even though you will repeat the AllocID the fields to pay attention to are TotNoAllocs field, NoAllocs field, and LastFragment these fields will help the reciever reconstitute the message.
Assuming AllocID = 12345, TotNoAllocs = 10 these fields basically tell the reciever that they have recieved AllocID=12345 portion 1 of 10, 2 of 10, 3 of 10, … 10 of 10 and in this message also LastFragment will be set denoting the last fragment has been recieved
Below is an exerpt from the FIX 4.4 spec in volume 5 entitled Fragmentation of Allocation Messages
. If there are too many entries within a repeating group to fit into one physical message, the entries can be continued in subsequent messages by repeating the principal message reference and other required fields, then continuing with the repeating group. This is achieved by using an optional TotNoAllocs field (giving the total number of AllocAccount details across the entire allocation) that supplements the NoAllocs field (giving the number of AllocAccount details in a particular message fragment). The TotNoAllocs field is repeated with the same value in all fragments of the batch. For example, an Allocation Instruction with 200 allocation account instances could be fragmented across three messages - the first two containing TotNoAllocs=200, NoAllocs=80 and the third TotNoAllocs=200, NoAllocs=40. To help the receiver reconstitute the batch the Boolean field LastFragment is sent with a “Y” value in the last fragment.
So is the consensus that regardless of fragmentation method, AllocID<70> should be unique (as required per protocol) or is it that for fragmenting, AllocID<70> can be duplicated as long as LastFragment<893> is sent to help the receiver reassemble the batch?
Fragmentation is a technical feature to split a single logical message across multiple physical messages. The application on the other end should reassemble the logical message as if it had been sent as a single physical message.
AllocID(70) value of a single logical message should be unique compared to other logical messages. If LastFragment(893) is present and set to “N” then the receiver should expect more messages with the same AllocID(70) until he gets one with LastFragment(893)=“Y”. Technical duplicates of messages can be identified via MsgSeqNum(34) on the session level. Otherwise, one or more fields in the body of the message identify functional duplicates. In case of messages supporting fragmentation this includes LastFragment(893) to be checked.
Isn’t there (or shouldn’t there be) a unique identifier for each of the fragment?
The documentation states that:
“The receiver must acknowledge every fragment received (AllocationInstructionAck with AllocStatus=“received”)”
When sender of AllocationInstruction fragments, receives AllocationInstructionAcks with AllocStatus=“received”, how is sender supposed to relate a particular AllocationInstructionAck is in response to specific AllocationInstruction?
Would it be more transparent if each fragment has a unique AllocFragmentID in AllocationInstruction that should be echoed in AllocationInstructionAck?
@cakeray, good question. I see that you refer to FIX 5.0 SP2 Volume 5, page 22 “Fragmentation of allocation messages”. One of the key rules is also:
The sender must supply a consistent value for TotNoAllocs in all related fragments and must use the same primary message reference in all fragments of the batch, e.g. AllocID in AllocationInstruction.
That does not answer your question yet. The recipient is able to do gap detection and will reject the allocation if he misses one of the fragments. The sender can count the number of Acks he receives but would not be able to identify the missing one without out-of-band communication. However, I would strongly advise to use a synchronous workflow with your counterparty to avoid physical messages overtaking each other. Otherwise the last fragment may arrive earlier than the one before and cause a rejection. Hence the sender needs to order the instructions and associate a response to the earliest instruction that has not been Ack’ed yet. A sanity check on TotNoAllocs(892) is also advisable.
Is your question of theoretical nature or are you having an issue with a counterparty about rejected instructions?