BLLanguageExtension Handler

Owned by Former user (Deleted)
Last updated: Jan 15, 2014 by Former user (Deleted)Version comment
7 min read

 

BLLanguageExtension Handler

Message transformation configuration is an XML file with rules for FIX tag/value manipulations. The root element is <Mapping> element. It encloses all other elements in configuration file.

<Rule> elements


Every rule contains conditions and actions. Conditions are used for rule triggering and actions describe the rule behavior. There is only one attribute (mandatory) - the "Name" attribute. It is unique within current XML configuration file.

Example: 

<Rule Name="SimpleRule">
  <Condition>
    <Inclusion>
      <FieldEqualsTo Field = "35">
        <Val>D</Val>
        <Val>G</Val>
        <Val>F</Val>
      </FieldEqualsTo>
    </Inclusion>
    <Exclusion/>
  </Condition>
  <ActionIfTrue>
    <TryCopyField SourceField ="11" TargetField ="95011" />
  </ActionIfTrue>
  <ActionIfFalse>
    <StopProcessing/>
  </ActionIfFalse>
</Rule>

 

Conditions are within <Condition> element and Actions are within <ActionIf> tags in the example. Rules with no Actions (<ActionIfTrue>, <ActionIfFalse>) elements are ignored during rules execution. Rules with no <Condition> element are applied for all FIX messages unconditionally.

<ActionIfTrue>, <ActionIfFalse> elements

There are two optional action blocks – ActionIfTrue and ActionIfFalse. Success actions will be executed one-by-one once rule’s conditions evaluated as true. Otherwise, ActionIfFalse actions sequence will be executed.


<Condition> elements

Conditions are used for rule triggering. <Condition> element can consist of two elements - <Inclusions> and <Exclusions> (both are mandatory). Check's value for <Inclusions> tag is calculated as is. Check's value for <Exclusions> tag is inverted (logical NOT) after calculation. There is only one attribute ("Name", optional) in this element. It is unique within current XML configuration file.

Here are two examples:

 

<Condition Name="IsOrderFlow">
    <Inclusion>
        <FieldEqualsTo Field="35">
            <Val>D</Val>
            <Val>G</Val>
            <Val>F</Val>
            <Val>8</Val>
            <Val>9</Val>
        </FieldEqualsTo>
    </Inclusion>
    <Exclusion/>
</Condition>

There is only one concrete check in the example - the FieldEqualsTo check. The condition is evaluated as true in case of 35th tag in a message is equal to one of D, G, F, 8, 9 value only.

 

<Condition Name="NotIsOrderFlow">
  <Inclusion/>
  <Exclusion>
    <FieldEqualsTo Field="35">
      <Val>D</Val>
      <Val>G</Val>
      <Val>F</Val>
      <Val>8</Val>
      <Val>9</Val>
      </ FieldEqualsTo>
    </Exclusion>
</Condition>

 

 

In the example the condition is evaluated as true in case of 35th tag in a message is not equal to one of D, G, F, 8, 9 value only.

 

<FieldEqualsTo> check

 

<FieldEqualsTo Field="35">
  <Val>D</Val>
  <Val>G</Val>
  <Val>F</Val>
</FieldEqualsTo>

There is an attribute (mandatory) in the check - "Field". <FieldEqualsTo> element checks if tag is equal to the value from given <Val> list.

<MsgType> check

 

<MsgType>
  <Val>D</Val>
  <Val>G</Val>
  <Val>F</Val>
</MsgType>

<MsgType> element checks if MsgType (35) of current FIX message is equal to one of the value from given <Val> list. Actually it does the same as FieldEqualsTo check but a bit faster.

 

<FieldExists> check

 

 <FieldExists>
  <Val>20109</Val>
  <Val>20049</Val>
</FieldExists>

<FieldExists> element checks given fields presence in message and results in true if at least one field is present.

 <FieldExists Field="20109" />

Slightly different syntax with the Field attribute.

 

<FieldContains> check

 

<FieldContains Field="18">
  <Val>R</Val>
  <Val>T</Val>
</FieldContains>

<FieldContains> element checks if multi string value in the given field contains one of the value from given <Val> list.

<FieldContains Field="18" Delimiter="|">
  <Val>R</Val>
  <Val>T</Val>
</FieldContains>

The “Delimiter” attribute contains the delimiter used in multi value string. It is optional; default value is space.

 

 

<FieldIsGreaterThan> check

 

 <FieldIsGreaterThan Field="44" Value="100"/>

<FieldIsGreaterThan> checks if given field greater than “Value”. Absence of the tag defined by “Field” cause fail.

 

<FieldIsLessThan> check

 

<FieldIsLessThan Field="44" Value="100"/>

<FieldIsLessThan> checks if given field less than “Value”. Absence of the tag defined by “Field” cause fail.

 

<FieldBeginsWith> check

 

<FieldBeginsWith Field="6780" StartPos="6" CaseSensitive= "true">
  <Val>L</Val>
  <Val>N</Val>
  <Val>BC</Val>
</FieldBeginsWith>

<FieldBeginsWith> checks if “Field” begins with one of the substring from given list.

“Field” and “StartPos” attributes are mandatory.

The “StartPos” attribute refers to symbols within a string from 0.

Default value for “CaseSensetive” attribute is “true”. The attribute is optional.

<FieldLengthGreaterOrEqual> check

 

<FieldLengthGreaterOrEqual Field="6780" Length="7"/>

<FieldLengthGreaterOrEqual> checks if the length of the “Field” tag is greater or equal to the “Length” attribute. Both attributes are mandatory.

<FieldIsToday> check

 

<FieldIsToday Field="42" />

<FieldIsToday> checks if “Field” contains date/time value in UTC and equals to Today.

 

<FieldCheckBits> check

 

<FieldCheckBits Field="5047" Value="0x02000000" />

<FieldCheckBits> treats the Field as integer and checks if it contains the HEX value defined by the “Value” attribute. Bitwise AND operation is used within the check.

<Actions> elements

<RemoveField Field="19" Order="10"/>

Every action element can contain the “Order” attribute. Order is an integer value that defines a sequence of actions within a current rule.
The “Order” attribute is optional.


<TryCopyField> action

 <TryCopyField SourceField = "85005" TargetField = "95005" />

There are two (mandatory) attributes: “SourceField” and “TargetField”. The action tries to copy tags within current FIX message.

 Absence of the tag defined by “SourceField” does not cause fail, the action is just ignored.

 <TryCopyField SourceField ="85005" TargetField  ="95005" DefaultValue = "NONE"/>
 

It is possible to use default value for missed tags. Use optional attribute “DefaultValue” for this case.  

 <TryCopyField SourceField="126" TargetField="432" Method="UTCToLocalDate"/>

The “Method” attribute contains the method name that uses for conversion during copying. The “UTCToLocalTime” means that the conversation from UTC time to LocalDate will be performed.

 <TryCopyField SourceField="18" TargetField="18" Method="Trim"/>
The “Trim” method trims spaces and tabs from SourceField and copies the resulted value into TargetField.

 

<CopyField> action

 <CopyField SourceField = "11" TargetField = "95005" />

There are two (mandatory) attributes: “SourceField” and “TargetField”. The action tries to copy tags within current FIX message. Absence of the source leads to whole rule failure.

 <CopyField SourceField="126" TargetField="432" Method="UTCToLocalDate"/>

The “Method” attribute contains the method name that uses for conversion during copying. The “UTCToLocalTime” means that the conversation from UTC time to LocalDate will be performed.

 

 <CopyField SourceField="18" TargetField="18" Method="Trim"/>

The “Trim” method trims spaces and tabs from SourceField and copies the resulted value into TargetField.

 

<RemoveField>  action

 

 <RemoveField>
	<Val>7729</Val>
	<Val>7730</Val>
	<Val>7731</Val>
</RemoveField>

 

The action tries to remove given list of tags from the processed FIX message. Absence of the tag does not cause fail.

 


<MoveField> action

 

 <MoveField SourceField ="11" TargetField ="95005" />

The action is short form for the following sequence of actions: <CopyField>, <RemoveField>.

 

 

 

<AddOrUpdateField> action

 

 <AddOrUpdateField Field="56" Value="NONE"/>

There are two attributes: “Field” and “Value”. The action tries to insert tag into current FIX message. If tag exists, old value is overwritten. 

 

<AddField> action

 

<AddField Field="56" Value="NONE"/>

There are two (mandatory) attributes: “Field” and “Value”. The action inserts tag into current FIX message. In case of presence of tag action fails.

 

<ConditionalFieldAction> action

 

<ConditionalFieldAction> action evaluates Case’s SourceValues against “Field” tag. Based on result of the evaluation it copies “Value” to “Field”. “Field” attribute is optional; “SourceField” will be used if it is omitted.

 

<ConditionalFieldAction SourceField="167">
  <Case SourceValue="OPT">
    <AddOrUpdateField Field="461" Value="OXXXX" />
  </Case>
  <Case SourceValue="FUT">
    <AddOrUpdateField Field="461" Value="FXXXX" />
  </Case>
  <Case SourceValue="USTB">
    <AddOrUpdateField Value="TBILL" />
  </Case>
  <Case SourceValue="RP">
    <AddOrUpdateField Value="REPO" />
  </Case>
</ConditionalFieldAction>

If (SecType (167) = 'OPT') CFICode (461) = 'OXXXX'.

If (SecType (167) = 'FUT') CFICode (461) = 'FXXXX'.

If (SecType (167) = 'USTB') SecType (167) = 'TBILL'.

If (SecType (167) = 'RP') SecType (167) = 'REPO'.

 

 

 

<RemoveFromField> action

 

<RemoveFromField Field="55">
  <Val>.TO</Val>
  <Val>.V</Val>
</RemoveFromField>

This action removes values from a multi value string. Absence of the values does not cause fail.

 


<KeepFields> action

 

<KeepFields Tags="151, 14, 30" />

The “Tags” attribute is a list of tags, which are to be copied as is. This action is a short form for the sequence of TryCopyField actions with the SourceField attribute equals the TargetField one:

<TryCopyField SourceField=”151” TargetField=”151” />
<TryCopyField SourceField=”14” TargetField=”14” />
<TryCopyField SourceField=”30” TargetField=”30” />.

 

 

 

<WeedField> action

 

<WeedField Field="18" />

This action replaces special characters in the given tag on the space character. The special characters are \t, \n, \r, \v, \f, \’ ,”. Absence of the tag does not cause fail.

 

<StopProcessing> action

 

<StopProcessing/>

The action just stops processing of current FIX message. The rest of the rules will be skip.

 

<StopProcessing ResultCode="94" Description=""Required tag missing: Price" />

More advanced version of the “StopProcessing” action; ResultCode and Description are used at BL layer (see <CreateReject /> action in BL configuration) to generate a reject message.

 


Multiple message transformation configurations

It is possible to define more than one file with rules. The exact list of file names is set up via BL XML configuration file. Rules are applied for processed message in the order they are appeared in the files.

 

Groups of rules and rule routing

Group of rules is a set of rules and / or other groups. It is possible to route FIX messages from concrete FIX session to given group of rules. Routing is set up via BL XML configuration.

 

 

<DllHandlers>
 <Handler Name="FixConvert" Description="FixConvert" DllName="BLLanguageExtension.dll" RulesDir="D:/Products/FIXEdge/FixConvert/conf" />
</DllHandlers>

Here is fragment of BL config. There is “FixConvert” handler declaration with additional parameter – path to the folder where all FixConvert configs are.

 

 

<RuleGroup Name="CommonRules">
  <UseRule>Add1000</UseRule>
  <UseRule>Add1001</UseRule>
  <UseRule>Add1002</UseRule>
</RuleGroup>

Here is a group named “CommonRules”.  <UseRule> element is referenced to concrete rules.

There is an optional integer attribute (“Order”) that defines the sequence of applied rules.

<RuleGroup Name="TNXRules">
  <UseGroup>CommonRules</UseGroup>
  <UseRule Order = "0">TNXSpecific001</UseRule>
  <UseRule Order = "1">TNXSpecific002</UseRule>
  <UseRule Order = "2">TNXSpecific003</UseRule>
</RuleGroup>

Here is a group named “TNXRules”.  It contains the “CommonRules” group defined previously and 3 additional TNX specific rules. 

<UseGroup> element is referenced to concrete group of rules.

<RuleGroup Name="BMXRules">
  <UseGroup>CommonRules</UseGroup>
  <UseRule Order = "0">BMXSpecific001</UseRule>
  <UseRule Order = "1">BMXSpecific002</UseRule>
</RuleGroup>

 

 

Here is a group named “BMXRules”.  It contains the “CommonRules” group defined previously and 2 additional BMX specific rules. 

 

 

BL configuration fragment:

<DllHandlers>
  <Handler Name="FixConvert" Description="FixConvert" DllName="fixconvert.dll" />
</DllHandlers>
<Rule>
  <Source>
    <FixSession SenderCompID="TNX" TargetCompID=".*" />
  </Source>
  <Action>
    <HandlerAction Name="FixConvert" RuleGroup ="TNXRules" />
  </Action>
</Rule>

This BL-config rule runs all TNX rules agains all messages from TNX.