FIXTradingCommunity / fix-orchestra

Machine readable rules of engagement
Apache License 2.0
71 stars 34 forks source link

[repositorySchema] Correlating an incoming tag-value message to its scenario. #166

Closed donmendelson closed 3 months ago

donmendelson commented 2 years ago

From document Orchestra Enhancements for Scenario Identification

The class of a tag-value message is traditionally identified by MsgType(35). However, this encoding does not by itself support scenarios. In fact, scenarios in Orchestra were conceived to create useful subsets of overloaded FIX message types, each for a specific use case. Conversely, a message definition in the FIX standard is a union of all possible uses, across all markets, asset classes, and use cases.

Alternatives discussed by the Orchestra working group in March 2022:

A. ID on the wire: Add a scenario identifier on the wire to be equivalent to the SBE solution, say ScenarioID that would, in combination with MsgType, uniquely identify a message layout. Addition of a tag for ScenarioID would require a gap analysis.

B. Metadata only: Add sufficient metadata to an Orchestra file to infer the scenario using a rule based on message contents. For example, if ExecutionReport has a scenario for trade executions, then a rule could be expressed as (pseudocode, not actual syntax) "if MsgType(35)=8(ExecutionReport) and 150=F(Traded) then ScenarioID=6". If a message arrived with that combination of field values, the Orchestra scenario could be selected with confidence. For performance purposes, the decision tree could be generated as a table or generated code so there wouldn't be reckoning of XML at runtime.

donmendelson commented 2 years ago

A message definition currently contains a <structure> child element to define its layout, and optionally a <responses> child element to give workflow. Each response can have a <when> element that gives a rule for when that response applies.

Proposed XML schema change Add an optional <when> element to a message definition to differentiate scenarios of a message type. The new element would follow the exact same syntax as <when> elements in responses and rules that are used to explain conditionally required fields. The contents of <when> is a Score DSL expression. It is a predicate (Boolean expression) that tells if the scenario applies. That is, if the expression evaluates to true. The expression could distinguish scenarios by order state, asset class, party role, or the like.

The rules that distinguish scenarios of a message type could be used to generate a decision tree to correlate an incoming message to its scenario, or to decide which scenario of a request message to send.

kleihan commented 3 months ago

Implemented in RC1