Imported from previous forum
Hi guys,
I’m looking at the BM&FBOVESPA FAST examples that they have online and I had a question about the provided templates-UMDF.xml:
.There are times when they use the same field “id” and “name” but with different data types. In the below example, they have two versions of MsgType=X, one where SecurityID is a int64 and the other where it is string:
(MsgType="X") ... ...And then there is:
(MsgType="X") ...Is this allowed because “SecurityID,” in this case, is in two different dictionaries?
Is it common for exchanges (with FAST) to have different different types associated with the same field “id”?
This appear rather unusual even if it probably reflects their usage more accurately (synthetic number for derivatives and symbol for equities) and distinct dictionaries are used. It is not unusual to chose a different data type in FAST than you have in FIX for reasons of performance. If the output of the FAST decoder also needs to be translated into FIX, then all you need to do is to look up the FIX data type and convert data types if necessary (in this case only the int64 version of the field as SecurityID is a string in FIX).
Hi guys,
I’m looking at the BM&FBOVESPA FAST examples that they have online and I had a question about the provided templates-UMDF.xml:
.There are times when they use the same field “id” and “name” but with different data types. In the below example, they have two versions of MsgType=X, one where SecurityID is a int64 and the other where it is string:
(MsgType="X") ... ...And then there is:
(MsgType="X") ...Is this allowed because “SecurityID,” in this case, is in two different dictionaries?
Is it common for exchanges (with FAST) to have different different types associated with the same field “id”?
Hi Hanno,
Thanks for clearing that up for me.
In regards to dictionaries, if two Msgs share a dictionary and they both have a field in common, say a field with name=“ABC”, would it be considered unusual if the field is optional in one message (can have null values) and mandatory in the other msg (cannot have null values)? Or is this a common use case?
I’m new to FAST and trying to get a feel for how different exchanges use it.
Thanks in advance.
This appear rather unusual even if it probably reflects their usage more accurately (synthetic number for derivatives and symbol for equities) and distinct dictionaries are used. It is not unusual to chose a different data type in FAST than you have in FIX for reasons of performance. If the output of the FAST decoder also needs to be translated into FIX, then all you need to do is to look up the FIX data type and convert data types if necessary (in this case only the int64 version of the field as SecurityID is a string in FIX).
Hi guys,
No, it is rare but not unusual for a field to be optional in one message context (or template) and mandatory in another.
Hi Hanno,
Thanks for clearing that up for me.
In regards to dictionaries, if two Msgs share a dictionary and they both have a field in common, say a field with name=“ABC”, would it be considered unusual if the field is optional in one message (can have null values) and mandatory in the other msg (cannot have null values)? Or is this a common use case?
I’m new to FAST and trying to get a feel for how different exchanges use it.
Thanks in advance.
This appear rather unusual even if it probably reflects their usage more accurately (synthetic number for derivatives and symbol for equities) and distinct dictionaries are used. It is not unusual to chose a different data type in FAST than you have in FIX for reasons of performance. If the output of the FAST decoder also needs to be translated into FIX, then all you need to do is to look up the FIX data type and convert data types if necessary (in this case only the int64 version of the field as SecurityID is a string in FIX).
Hi guys,
Thanks Hanno for your replies. Sorry it has taken so long for a reply.
An important principle at work here is that FAST is a completely separate encoding from FIX and is independent of FIX. You can encode any type of data in FAST. FIX datatypes are not FAST datatypes. FAST was developed to be independent and uncoupled from any business level protocol, including FIX. With that said, seeing that FIX Protocol and the FIX Community funded the development of FAST, there is a preference that you would use FIX messages over FAST.
So, outside of a recommendation document describing FIX over FAST http://www.fixprotocol.org/documents/4652/FIX%20Messaging%20Over%20FAST%20V1.0.pdf that was developed by the Market Data Optimization Working Group, there is not a one-to-one mapping between FIX datatypes and FAST datatypes, nor should there be. There should be and is a general recommendation, but FAST exists to optimize the transmission of messages. Practically, a quality FIX over FAST implementation would have more than one template per FIX message based upon different scenarios.
In the case of differences between SecurityID encoding, BVMF currently has more than one trading engine. The newer trading engine uses an integer SecurityID. Using FAST Encoding we can take advantage of the independence of datatype and optimize and use in integer encoding instead of being restricted to using a string. I agree this is unusual from one exchange, but it shows the power and flexibility of FAST encoding. When BVMF finishes integrating their trading onto a single platform, this will likely change to a single encoding for SecurityID. The fact that the FAST datatypes for a particular FIX field can change over time should be taken into consideration in your implementation.
Regarding multiple FAST templates representing the same FIX message, this is the power of FAST. You can get quite clever in terms of optimizing what data needs to be transmitted by using multiple templates to represent different message scenarios. Multiple templates per FIX message allows you to specify fields as being optional or constant depending on scenario to minimize transmission requirements.
FIX tag=value has one predefined closed encoding of FIX messages and fields and datatypes to FIX tag=value messages. FIXML has one predefined closed encoding of FIX messages and fields and datatypes. FAST being an open and very powerful and flexible encoding mechanism does not limit or impose one encoding - the options available to implementers are quite varied and limited largely only be imagination. We do provide a basic set of recommendations for FIX to FAST as mentioned previously, but limiting this encoding would defeat the purpose of FAST, which is to minimize the amount of data that needs to be exchanged.
Thanks for the input, guys. The responses were very informative.
Thanks Hanno for your replies. Sorry it has taken so long for a reply.
An important principle at work here is that FAST is a completely separate encoding from FIX and is independent of FIX. You can encode any type of data in FAST. FIX datatypes are not FAST datatypes. FAST was developed to be independent and uncoupled from any business level protocol, including FIX. With that said, seeing that FIX Protocol and the FIX Community funded the development of FAST, there is a preference that you would use FIX messages over FAST.
So, outside of a recommendation document describing FIX over FAST http://www.fixprotocol.org/documents/4652/FIX%20Messaging%20Over%20FAST%20V1.0.pdf that was developed by the Market Data Optimization Working Group, there is not a one-to-one mapping between FIX datatypes and FAST datatypes, nor should there be. There should be and is a general recommendation, but FAST exists to optimize the transmission of messages. …
…