Fragmentation of Allocation messages and AllocID

imported
allocations
xid_160843

#1

Imported from previous forum


#2

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


#3

[ 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.


#4

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?


#5

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.