Imported from previous forum
I would like to propose adding a non-required tag called “AppId” to the fix header that could be used by the application layer to uniquely identify a fix message that it has generated.
Usually the point where an application fix message is generated is not the same place where the sequence number is generated. This means there is no easy way for the application to identify or marry up events associated with that message.
For example if an OMS sends a message to a FIX engine asynchronously it must somehow include a unique identifier as out of band data or using a custom tag in the fix message so it can marry up events from the FIX engine.
With the inclusion of an App Id we would have a consistent way of allowing the business layer to identify their own messages and it would have a roll on effect of simplifying business level rejects.
[ original email was from John Prewett - jprewett@lavatrading.com ]
As I am currently living in a free(ish) country, I would politely like to register disagreement with this proposal. I think there are already enough fields that can be used for internal FIX_Engine --> application routing purposes. This proposal will add yet another one.
While most internal application routing can be done by looking at the ClOrdID (where applicable) on responses, it is still possible for a reasonable FIX engine to use the RefSeqNum on a BusinessReject (or Reject) to lookup into its "sent message store" and discover which application sent this message. In that manner it can then route the BusinessReject (or Reject if applicable) back to the appropriate application.
Each time a new field is added (especially a header field, but also body field), it delays the propagation of a new FIX version out into the real world because of the development effort required to change the multititude of applications. It is relatively easy to upgrade a FIX engine, but that is only a small part of the picture. Everyone please look at what versions of FIX your engine supports and then look at what versions of FIX your applications support. Typically, the applications lag way behind the FIX engine. Adding new, arguably unnecessary, fields increases this problem. Thus the adoption of more recent versions of FIX is slowed.
Sorry to disagree, thanks for listening.
JP
> I would like to propose adding a non-required tag called “AppId” to the fix header that could be used by the application layer to uniquely identify a fix message that it has generated.
>
> Usually the point where an application fix message is generated is not the same place where the sequence number is generated. This means there is no easy way for the application to identify or marry up events associated with that message.
>
> For example if an OMS sends a message to a FIX engine asynchronously it must somehow include a unique identifier as out of band data or using a custom tag in the fix message so it can marry up events from the FIX engine.
>
> With the inclusion of an App Id we would have a consistent way of allowing the business layer to identify their own messages and it would have a roll on effect of simplifying business level rejects.
>
>
I’m not sure I understand how this will be used… It seems like you want to associate a specific FIX MsgSeqNum with a specific “AppId” so that your engine and “link” the two. I do not, however, understand how adding an “AppId” field to the Standard Header helps you do this. It seems to me that all that would accomplish is letting your counterparty (vs. your fix engine) “know” about this cross-reference. Unless maybe you’re talking about using FIX to communicate “internally” to/from a FIX engine in which case you could easily add/use a custom field.
I would be very concerned that actually adding "AppId" to messages one sends would result in needing to have a "RefAppId" when (i.e. Execution Report responding to an Order). I am against that, though.
If what you want is a MsgSeqNum to AppId cross-reference, I would suggest that the FIX engine maintain this and the AppId specification be confined to that engine’s API or interfacing data.
> I would like to propose adding a non-required tag called “AppId” to the fix header that could be used by the application layer to uniquely identify a fix message that it has generated.
>
> Usually the point where an application fix message is generated is not the same place where the sequence number is generated. This means there is no easy way for the application to identify or marry up events associated with that message.
>
> For example if an OMS sends a message to a FIX engine asynchronously it must somehow include a unique identifier as out of band data or using a custom tag in the fix message so it can marry up events from the FIX engine.
>
> With the inclusion of an App Id we would have a consistent way of allowing the business layer to identify their own messages and it would have a roll on effect of simplifying business level rejects.
>
>
Firstly thank you for your constructive response.
My original motivation to suggest an AppId was driven by the following scenario.
An OMS wants to send messages to the FIX Engine when a session is down. It then wants to get an event when the message has been sent out. Obviously there needs to be a mechanism of marrying up that event with the message sent by the OMS.
We had thought of using a user defined tag, (as you suggested) but then it occurred to us that maybe we should raise the possibility of adding a standard field for this purpose since it may be a common problem.
> I’m not sure I understand how this will be used… It seems like you want to associate a specific FIX MsgSeqNum with a specific “AppId” so that your engine and “link” the two. I do not, however, understand how adding an “AppId” field to the Standard Header helps you do this. It seems to me that all that would accomplish is letting your counterparty (vs. your fix engine) “know” about this cross-reference. Unless maybe you’re talking about using FIX to communicate “internally” to/from a FIX engine in which case you could easily add/use a custom field.
>
> I would be very concerned that actually adding “AppId” to messages one sends would result in needing to have a “RefAppId” when (i.e. Execution Report responding to an Order). I am against that, though.
>
> If what you want is a MsgSeqNum to AppId cross-reference, I would suggest that the FIX engine maintain this and the AppId specification be confined to that engine’s API or interfacing data.
>
>
> > I would like to propose adding a non-required tag called “AppId” to the fix header that could be used by the application layer to uniquely identify a fix message that it has generated.
> >
> > Usually the point where an application fix message is generated is not the same place where the sequence number is generated. This means there is no easy way for the application to identify or marry up events associated with that message.
> >
> > For example if an OMS sends a message to a FIX engine asynchronously it must somehow include a unique identifier as out of band data or using a custom tag in the fix message so it can marry up events from the FIX engine.
> >
> > With the inclusion of an App Id we would have a consistent way of allowing the business layer to identify their own messages and it would have a roll on effect of simplifying business level rejects.
> >
> >
>