Overview

FIXEdge offers the set of Business Rules, which can be useful to determine message routing, session events, scripting, message modification, plug-in connection, histories management, automatic routing for some types of the messages. The Rules formation is defined by special syntax in the XML format that is described in this guide. The XML formatting of configurating file is described in ‘FixEdge/conf/BusinessLayer.dtd’.

Business Rules are stored in business layer configuration file in xml format. This file is loaded into th e memory during FixEdge starting. The installation package contains the business layer configuration file (‘FixEdge/conf/BL_Config.xml’) with rules that allow to test the FixEdge functionality. See test-case description in section BL_Config Test case. For the real work, the business rules have to be configured in accordance with the recommendations described in this section.

Rules can be changed from FIXICC or by editing the file directly.

Note: The name of configuration file can be changed in ‘FixEdge.properties’ file using ‘BusinessLayer.RoutingRules’ property

   There is a possibility to store Business Rules in separate files. See section 'Storing Business Rules in separate files' for details.

Business Layer Configuration file

It is assumed that the configuration file contains different xml-elements fully describing FIXEdge behaviour.

Elements could be classified on the following groups:

Routing rules are represented in the configuration file via <Rule> xml-elements.  

 Session events are represented in the configuration file via the following xml elements: <CreateSessionEvent>, <DestroySessionEvent>, <OnUndeliveredMessageEvent>, <OnSessionLevelRejectEvent>, <OnRuleFailEvent>, <OnNotificationEvent>.

The configuration file can contain zero or more of these xml-elements. See Routing Rules and Session Events for details. 

There is also special type of rule which executed if no other rule is applied. This rule is represented in the file via one mandatory <DefaultRule> xml-element.

• Auxiliary entities definitions that could be used in Business Rules:
• Plug-ins – objects that encapsulate field transformation algorithm. All Plug-ins are represented in the file in one optional <Plugins> xml-element.
• Handlers – objects that encapsulate message handling algorithm. All Handlers are represented in the file in one optional <DllHandlers> xml-element.
• Histories – objects that store data from the handled messages. Histories are represented in the file via <History> xml-elements. The configuration file can contain zero or more <History> elements.

• Routing strategies – objects that encapsulate algorithms of automatic message routing. Routing strategies are represented in the file via <OrderFlowStrategy>, <DeliverToStrategy> and <WheelOrderFlowStrategy> xml-elements. The configuration file can contain zero or more of these xml-elements.

All described above elements belong to the element <BusinessLayer>. 

This element has one optional attribute 'RejectUnrouteMsg' which determines rejecting mode: 

• AppReject - Application level Rejecting is allowed
• SsnReject - Session level Rejecting is allowed
• NotReject - the rejection is prohibited

Plugins element

...

<FIXEdge>
 <BusinessLayer>
   <Plugins>
     <Plugin Path="./Brass.dll">
       <Param Name="Param1"/>
     </Plugin>
   </Plugins>
 </BusinessLayer>
</FIXEdge>

FIXEdge offers a flexible solution for modification of FIX message partial fields - Plugins.

Plugins provide an open interface and can be written in any programming language that allows creating modules in Microsoft Windows DLL format.

The custom Plugins mechanism can be used in case Business Layer’s built-in mechanisms and engines cannot perform a specified task.
For example when conversion data must be stored from call to call or when its data must be persistent.

Optional <Plugins> section may contain one or more <plugin> definitions.

Plugin element

Each <Plugin> element has:

...

Param element

Param element is used in the configuration file within <Plagin> and <Script> elements to define their parameters.

Attributes:

DllHandlers element

<FIXEdge>
 <BusinessLayer>
   <DllHandlers>
      <Handler VerifyHandlersVersion="true"
               DllName="./PSHandlerPlugin.dll"
               Description="Test Handler description"
               Name="TestHandler"/>
   </DllHandlers>
 </BusinessLayer>
</FixEdge>

History element

FIXEdge offers a flexible solution for storing information that goes through the Business Layer of FIXEdge.

Business Layer supports the following types of information storage:

•  ODBC History – allows storing information in the database
•  File History - allows storing information in the persistent file-based storage
•  Memory History - allows storing information in the transient memory-based storage

Histories can be used in routing rules only when they are defined in the BL rules XML file.

Each <History> element has the common attributes:

and the additional attributes in depend on the history type.

ODBC History

//Defines history "SampleODBCHistory" that reflects on the Orders table in database SampleBase.
// Following FIX message tags mapped into the Orders table fields:
// ClOrdID(11) -> ClOrdID, type - string
// SenderCompId(49) -> SenderCompId, type - string[512]
// TargetCompId(56) -> TargetCompId, type - string
// SettlDate(64) -> SettlDate, type - date
// History maps the record's ExpireDateTime attribute to the database field TransactTime
<History Name="SampleODBCHistory"
StorageType="ODBC"
TableName="SampleBase.dbo.Orders"
ClearTime="22:00:00"
ColumnSize="256"
ConnectionString="DSN=SampleBase;UID=test;PWD=test123;">
<KeyField ColumnName="ClOrdID">11<KeyField>
<Field ColumnName="SenderCompID" ColumnSize="512">49</Field>
<Field ColumnName="TargetCompID">56</Field>
<Field ColumnName="Price" DataType="Numeric" Precision="20" Scale="6">44</Field>
<Field ColumnName="SettlDate" DataType="Date" ColumnSize="10">64</Field> <Field ColumnName="TransactTime">ExpireDateTime</Field>
</History>

File History

//Defines history SampleFileHistory" history saves data to the file .\logs\SmplFileHistory 
// The ClOrdID(11), SenderCompId(49) and TargetCompId(56) FIX tags used as a record composite key 

<History Name="SampleFileHistory" WorkingDirectory=".\logs" StorageType="File" 
  StorageFileName="SmplFileHistory" ClearTime="22:00:00"> 
  <KeyFields>11, 49, 56</KeyFields> 
  <Fields> 99,18,63,64,528,529,100</Fields> 
  <Field>ExpireDateTime</Field> 
</History>

Memory History

//Defines history "SampleMemHistory" 
// The ClOrdID(11), SenderCompId(49) and TargetCompId(56) FIX tags used as a record composite key 
<History Name="SampleMemHistory" StorageType="Memory" ClearTime="22:00:00"> 
  <KeyFields>11, 49, 56</KeyFields> 
  <Fields> 99,18,63,64,528,529,100</Fields> 
  <Field>ExpireDateTime</Field> 
</History> 

KeyField element

Element defines a key field in the database table and a tag of the FIX message that will be stored in it.

Attributes are used for database fields definition in ODBC History:

For example:

<KeyField ColumnSize="7" ColumnName="ClOrdID">11</KeyField>

Field element

Element defines the field and the tag of the FIX message that will be stored in it.

Attributes are used for database fields definition in ODBC History:

For example:

<Field ColumnSize="15" ColumnName="ExDestination">100</Field>
<Field ColumnSize="19" ColumnName="Quantity" DecimalDigits="10" DataType="Float">53</Field>
<Field ColumnSize="12" ColumnName="TransactTime" DataType="Datetime">60</Field>
<Field ColumnSize="19" ColumnName="OfferPx" DecimalDigits="7" DataType="Float">133</Field>
<Field ColumnSize="19" ColumnName="OfferSize" DecimalDigits="7" DataType="Float">135</Field>

KeyFields element

Contains a set of comma-separated FIX message tags. Tags are used for search the message data within the file.

Fields element

Contains a set of comma-separated FIX message tags.

DefaultRule element

<FIXEdge>
  <BusinessLayer>
     <!-- ... -->
     <DefaultRule>
       <Action>
         <DoNothing/>
       </Action>
     </DefaultRule>
  </BusinessLayer>
</FIXEdge>

Routing strategies

Routing strategies are used to specify the destinations for FIX messages. The strategies are used in the following cases: 

• Sending instruction StrategySend

In all cases the startegies are indentified by attrubute 'Name'.

OrderFlowStrategy element

<OrderFlowStrategy> element defines the orders flow to destination that can be found in the history of orders.

Attributes:

OrderFlow strategy defines the destination of FIX message routing by source identifier only. Session with source identifier (FIX session attribute "name"<Source Name="SourceID"/>) that in the destination field should be registered in FIXEdge, otherwise an order will be rejected.

DeliverToStrategy element

<!-- DeliverToStrategy description -->

<!ELEMENT DeliverToStrategy >

<!ATTLIST DeliverToStrategy

      Name CDATA #REQUIRED

      TargetField CDATA #REQUIRED

      SourceField CDATA #REQUIRED

>

WheelOrderFlowStrategy element

<!ELEMENT WheelOrderFlowStrategy (Destination+)>

<!ATTLIST WheelOrderFlowStrategy

      Name CDATA #REQUIRED

      DestinationHistory CDATA #REQUIRED

      RouteHistory CDATA #REQUIRED

      DestinationField CDATA #REQUIRED

      RouteCountField CDATA #REQUIRED

      IsDestDownField CDATA #REQUIRED

>

<!ELEMENT Destination>

<!ATTLIST Destination

      Name CDATA #REQUIRED

      Id CDATA #REQUIRED

      Counter CDATA #REQUIRED

Storing Business Rules in separate files

XML rules for Business Layer can be stored in separate files. List of these files and their loading sequence are defined in configuration property  (TBD Link) BusinessLayer.RoutingRules = file1.xml, file2.xml, file3.xml,…etc. This approach facilitates users to easily debug rules and configure them using pre-prepared parts of rules.

Note: In this case the FIXEdge will treat these files as a parts of a single XML document. I.e. the first file must contain the standard XML declaration line: <?xml version="1.0" encoding="UTF-8"?> (or UTF-16) and the rules must be wrapped into special tags:

<FIXEdge>
 <BusinessLayer>
 <!-- the rules set ... -->
 </BusinessLayer>
</FIXEdge>

The good practice is to start the list with BL_header.xml with the following content:

<?xml version="1.0" encoding="UTF-8" ?>  
<!-- (or UTF-16) -->
<FIXEdge>
 <BusinessLayer>

and end up with BL_tail.xml with the following content:

</BusinessLayer>
</FIXEdge>

In this case the configuration property will look like this: BusinessLayer.RoutingRules = BL_header.xml,…file1.xml, file2.xml,…,BL_tail.xml