FIXEdge offers a flexible solution for storing information that goes through the Business Layer of FIXEdge – Histories. ODBCHistory is one of the histories type which allows storing information into the database.
- Make a backup copy of your current configuration;
- Make sure you have sufficient administration permissions for further uninstall/install procedures;
- Install the required DataBase;
- Make sure that DB driver is installed on the machine, that you are going to connect to;
- Make sure that you have your database connection parameters (host, port (if it is different from default), server name, username, password);
Define the data which should be stored to the DataBase and create corresponding scheme;
Take into account that ODBCHistory supports the following types of fields:
- Create the history definition in the Business Layer Configuration file according to the steps below:
Specify <History> element. The following attributes should be defined for the <History> element:Name of the attributeRequiredDescription
Below is the example of ODBCHistory definition:
How to store data to DB
In order to store some data from FIX messages in DB there is a need to specify the rules in the Business Layer Configuration file.
Actions defined in the business rule are executed synchronously.
There are two ways to call the command that stores data from the handled message in the DB storage:
XML SaveToHistory action
Below is the example of invoke of the SaveToHistory XML action:
Below is the example of the saveMDReqIDToHistory.js:
How to read data from DB
In order to get the stored data from DB there is a need to specify the rules in the Business Layer Configuration file.
- getFromHistory – locates a record in the history by key and retrieves the value of the record field
- getRecordFromHistory – locates a record in the history by key and returns it
Below is the example of the getMDReqIDFromHistory.js:
How to manipulate data stored in DB
In order to manipulate stored data there is a need to specify the rules in the Business Layer Configuration file.
There are several ways to manipulate data from DB:
- XML Actions:
ClearHistory – erases obsolete records from the history.
- updateHistory - modifies fields in the history;
- removeRecordFromHistory - removes the entire record with the key <keyFields>, located in the history <historyName>;
- removeRecordFromHistoryByCompositeKey - removes the entire record by matching the composite key with <keyFields>, located in the history <historyName>.
What happens to FIX Messages if there is a failure writing to the database or a database outage? Would the writing fail at that point?
If there is a failure writing to the database, OnRuleFailEvent will be generated. The FixEdge behaviour on handling messages that failed to reach the database can be defined by specifying particular OnRuleFailEvent for them.
Would the message failed to reach the database be queued internally and written when the database would be available without affecting the message?
If the work with the database is kept within a separate rule, then the database failure shall have no impact onto the main rule for message processing, since rules are executed independently. However, there is no internal queue to postpone messages till the database is up.