Scenario Classification

[francescoloconte]

Deciding the appropriate scenario for a received message is a critical task. We propose defining Scenario Classifiers as predicates that analyze incoming messages to determine if they belong to a specific scenario.

The predicates should support the following tests:

• Field value literal check: Ensures the field matches a specific value.
• Field value pattern check: Checks if the field matches a defined pattern.
• Field value range check: Validates if the field value falls within a specified range.
• Field value set check: Confirms if the field value is part of a predefined set.
• Element presence check: Verifies the presence of a specific element.

These predicates should be defined as Boolean expressions, supporting compound relational conditions joined by "and," "or," and negation of conditions using the "not" operator.

Orchestra 1.1 RC1 includes the when element in messageType, which is designed for this task. This element can contain an expression in Score DSL, which can be evaluated using the incoming message as context.

Multiple Matching
It is still unclear how the Standard suggests handling cases where multiple scenarios match the incoming message.

One option is to raise an error. The application would then handle it as it does with unrecognized messages. This approach requires careful design of scenario classifiers to ensure there are no ambiguous conditions. It ensures the completeness of Rules of Engagement (RoE) expressed in the Orchestra file.

A more flexible option is to allow multiple scenarios to match a given message and pass all matched messages to the application. The application could then set up a handler to either choose one message from the set or raise an error. This approach adds an extra layer of scenario classification. While it might be less performant and obscure part of the logic from the Orchestra file, it provides better flexibility. Although multiple matching scenarios could be allowed, it can still be avoided by using unambiguous classifiers.

Classification and Validation
Classification is an additional layer of message processing that occurs before validation. To validate a message, it must first be classified to determine which scenario and corresponding validation rules apply. If a message is classified into a scenario but then fails validation, an error must be raised.

Matching Rules
A common scenario arises when there are multiple classification predicates, with one being a specialized version of another (e.g., when one scenario inherits from another). In such cases, it makes sense to perform matching by checking the most specialized predicate first. This can be achieved by introducing a predicate complexity metric.

The complexity can be calculated based on the number of checked entities and the number of checks, with priority given to the variety of checked entities.

Example:
Scenario A applies if the following conditions are met:

• OrderType is not Stop
• QuoteType is Tradeable

The predicate has 2 fields examined with 2 checks.

Scenario B applies if the following conditions are met:

• ExecType is Trade
• OrderType is not Stop
• OrderType is not StopLimit

The predicate has 2 fields examined with a total of 3 checks.

When a message matches both scenarios' predicates, Scenario B takes priority.

Optional Matching
In some cases, it is desirable to avoid matching certain message scenarios.

One way to achieve this is by adding a new attribute, abstract, to the messageType. If the abstract attribute is set to true, the message should be skipped from the matching process.

<fixr:message name="QuoteRequest" id="26" msgType="R" abstract=”true”>

Another way is to use a special predicate in the when element that would never evaluate to true, ensuring the message will not match. Introducing a built-in constant equal to false would facilitate this approach.

<fixr:message name="QuoteRequest" id="26" msgType="R">
	<fixr:structure>
		<!-- The message structure -->
	</fixr:structure>
	<fixr:when>NEVER</fixr:when>
</fixr:message>

Predicate Expression Language
The current version of the Orchestra specification proposes using Score DSL to build predicates. This DSL is widely supported in Orchestra for various condition and assignment expressions. Being domain-specific, the language allows expressions to be concise yet readable.

Another option under consideration is to use a simpler syntax built on top of plain XML constructs, with several predefined “check” elements that cover the requirements stated above. This syntax is easy to parse and evaluate. An example is provided below.

<fixr:message name="QuoteRequest" id="26" msgType="R" scenario=”CDS” scenarioId=”2”>
	<fixr:structure>
		<!-- The message structure -->
		<fieldRef id="167" name=”Product” presence="constant" value="CDS"/>
		<fieldRef id="63" name=”Tenor” presence="required"/>
	</fixr:structure>
	<fixr:when>
		<fieldCheck path=”167” value="CDS"/>
	</fixr:when>
</fixr:message>
<fixr:message name="QuoteRequest" id="26" msgType="R" scenario=”CDS_MIFID” scenarioId=”3”>
	<fixr:structure>
		<!-- The message structure -->
		<fieldRef id="447" name=”PartyIDSource” presence="constant" value="N"/>
		<fieldRef id="448" name=”PartyID” presence="required"/>
	</fixr:structure>
	<fixr:when>
		<and>
			<fieldCheck path=”167” value="CDS" />
			<fieldCheck path=”447” value="N"/>
		</and>
	</fixr:when>
</fixr:message>

The fieldCheck element can support various usage schemas:

• <fieldCheck path=”167” value="CDS"/>
• <fieldCheck path="448" pattern="[0-9A-Z]{20}"/>
• <fieldCheck path=”123” minInclusive="0" maxInclusive=”100”/>

<fieldCheck path=”167”>
    <value>CDS</value>
    <value>CAP</value>
</fieldCheck>

There could be another check types defined, for example to check for element’s existence:
<exists path="447"/>

[JoanPuig]

Great proposal @francescoloconte

On the subject of multiple matching I would propose the following:
-All messages must have at least one scenario (explicit or defaulted base)
-Rules are evaluated in a deterministic order
-The first rule that matches, that is the one and only scenario of the message
-The last rule to be evaluated would be a catch all rule (predicate returning constant True)
-The catch all rule could either be explicit, or if not present, implicitly and it would point to the base scenario

On the subject of xml based predicates: Agreed, the majority of the rules will be very simple, so it is good to have a simple way to express them