I have a partner which on the same fixt1.1 fix 5.0 session has defined two different message layout for the same message type. In the message header they then have a field which indicates which of the two layouts the
message adheres to.
In order to process these messages in Quickfix I would have to define a FIX XML specification with a message layout covering both formats. Which means that messages classes generated in each context will contain more
fields that may be supported by the actual layout (protocol). And fields in this superset message can only be defined as required when they are required in both layouts, which kind of moves parts of the message validation from Quickfix to the application layer.
This approach adds complexity and complicate maintenance going forward. So how or what is the best way to handle this?
I would really like to define two FIX XML specification, but this contradict quickfix configuration. Is there a way in quickfix configuration to only enable transportdatadictionary validation and parse the application
data of the message as is to my application?
Or have quickfix call custom code, ex. though callback, to decode the string message to a fix::message ?
Either way I would then implement decoding and validation based on the correct dictionary according to the header field value.