Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

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:

  • Containers of Business Rules instructions: 
    • Routing rules – used to transform and route FIX messages to sessions, adaptors etc
    • Session events – used to handle events that are launched during execution: create session, destroy session etc.

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

...

Code Block
languagehtml/xml
<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:

Attribute 'Path'Mandatory. Defines path and name of plugin DLL
Set of plugin parametersOptional. Plugin parameters are defined via <Param> xml-element

 

...

Param element

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

Attributes:

NameMandatory. Defines name of parameter
ValueOptional. Defines parameter value by default

DllHandlers element

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

FIXEdge offers a flexible solution for FIX message processing - Handlers.

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

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

 

Optional <DllHandlers> section may contain one or more <handler> definitions.

Handler element

Mandatory attributes:

NameUnique handler name that will be used in HandlerAction
DescriptionHandler description
DllNameContains the path and file name of the Handler’s DLL
VerifyHandlersVersion

Specifies whether FIXEdge must verify the version of Handler interface when loading this handler. It prevents the “dll hell” problem

Valid values: "true"|"false"

  

Usage: HandlerAction action refers to the defined Handler and initiates message handling by a specified Handler.

See part FIXEdge API for BL Handlers for details.

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:

NameMandatory. Name of history, used to refer to history from XML actions or JavaScript functions.
StorageType

Mandatory. Defines type of history.

Valid values:  “ODBC” | “File” | “Memory”.

ClearTimeOptional. Defines when every-day clear procedure is started. The format is HH:MM:SS. Clear procedure erases obsolete records.

and the additional attributes in depend on the history type.

ODBC History

Example:

Code Block
languagehtml/xml
//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>

Each ODBC Histoty defines regulations of storage FIX message tags within the particular table of database.

Additional attributes:

TableNameMandatory. Name of table in database. History will be reflected in this table
ColumnSize

Optional. Default size of history string fields.

If size of string exceeds ColumnSize string will be truncated.

If size of string exceeds size of column in DB insert/update will be failed.

ConnectionStringMandatory. ODBC connection string. 

 

Xml-elements <KeyField> and <Field> are used to define the field in the table that will store the particular tag of the FIX message

ODBCHistory supports the following types of fields:

  •  Int
  •  Float
  •  Numeric.
  •  Date
  •  DateTime
  •  String

File History

Code Block
languagehtml/xml
//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>

Each File History defines regulations of storage FIX message tags within the particular file.

Additional attributes:

WorkingDirectory

Mandatory. Path to stored history files

StorageFileName

Mandatory. Name of history storage file

Both of xml-elements <KeyFields> and <Fields> define set of the tags.

Tags within <KeyFields> used as a record composite key

Memory History

Code Block
languagehtml/xml
//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> 

Memory History defines regulations of storage FIX message tags within the FIXEdge server memory.

MemoryHistory does not require additional attributes

Both of xml-elements <KeyFields> and <Fields> define set of the tags.

Tags within <KeyFields> used as a record composite key

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:

ColumnNameMandatory. Name of table field 
DataType

Mandatory. Type of table field

Valid values: "Int" | "Float" | "Numeric" | "Date" | "DateTime" | "String" – default value

ColumnSizeOptional
DecimalDigitsOptional, required if DataType = "Float"
PrecisionOptional, required if DataType = "Numeric". Max number of decimal digits, must have value from 1 to 38 
ScaleOptional, required if DataType = "Numeric". max number of decimal digits that can be stored to the right of decimal point, should be not less than 0 and not greater that Precision.

For example:

Code Block
languagehtml/xml
<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:

ColumnNameMandatory. Name of table field 
DataType

Mandatory. Type of table field

Valid values: "Int" | "Float" | "Numeric" | "Date" | "DateTime" | "String" – default value

ColumnSizeOptional
DecimalDigitsOptional, required if DataType = "Float"
PrecisionOptional, required if DataType = "Numeric". Max number of decimal digits, must have value from 1 to 38 
ScaleOptional, required if DataType = "Numeric". max number of decimal digits that can be stored to the right of decimal point, should be not less than 0 and not greater that Precision.

For example:

Code Block
languagehtml/xml
<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

Code Block
languagehtml/xml
<FIXEdge>
  <BusinessLayer>
     <!-- ... -->
     <DefaultRule>
       <Action>
         <DoNothing/>
       </Action>
     </DefaultRule>
  </BusinessLayer>
</FIXEdge>

Defines special type of rules, which contains section <Action> only.

Executed if no other rule is applied.

Located at the enf of Business Layer Configuration file.

Usually contains command <DoNothing/>

Routing strategies

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

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:

NameMandatory. Contains the name of element to identify in factory rules.  
History

Mandatory. Contains the name of <History> element, where the order flow strategy will refer to specify the routing destination

DestinationFieldMandatory. Contains a tag number with destination ExDestination (Tag = 100, Type: Exchange)
CreateBusinessRejectIfFailed

Optional.

Valid values: "true" | "false"

 

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:

 

Code Block
languagehtml/xml
<FIXEdge>
 <BusinessLayer>
 <!-- the rules set ... -->
 </BusinessLayer>
</FIXEdge>

 

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

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

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

Code Block
languagehtml/xml
</BusinessLayer>
</FIXEdge>

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

 

 

 

Children Display