REDI Monitoring In C#
Introduction
REDI is an execution management system (EMS) allowing to trade equities, futures and options with major brokers, globally.
REDIPlus is a graphical user interface client that interfaces with REDI.
The REDI API is a local, COM-based API, leveraged from VBA/Excel, C#, and partially, from Python.
REDIPlus desktop has to be running and the local user logged in, in order to interface to REDI via REDI API.
REDI via API
At a high level, there are two main types of interaction with REDI via API:
- Request submission, such as order or ticket entry, order update or order cancellation
- Monitoring or subscription, that entails subscribing to the notification of the changes to the entities within REDI, such as changes to orders, positions, market data
This article will focus on and describe the monitoring of REDI objects in C#.
When Do We Use Monitoring in REDI?
Monitoring is a key functionality within REDI if we are planning to integrate via API.
Some common use cases that require REDI monitoring integration are:
- Submission of an order, if it requires to consequently confirm its state
- Keeping track of a portfolio in terms of positions, values, other characteristics
- Accessing REDI Market data
What Is In Common
Monitoring code interacts with REDI CacheControl.
The following steps are necessary to affect monitoring of REDI via CacheControl class:
We create a CacheControl, specify an event handler callback code that will be triggered on CacheEvents, and start our REDI event subscription.
In myCacheHandler we receive and process the CacheEvents based on the action:
How To Monitor Orders
Definition:
Submit(string table,string where, string err)
Usage example:
Notice, that we use MsgType = 10, which stands for Order,
One can use MsgType = 14, to monitor Trade, to receive more specifics on Trade,
otherwise, Trades will still be received, as Update to Order.
What Notifications To Expect From Order Monitoring
Our included example REDIConsoleOrders implements REDI monitoring of orders for a small set of fields.
We see notifications such as:
This is a typical output that shows a new order created, and then, its fields updated within REDI, without any action from the user. The order has been executed, first, partially and next, fully.
Let us review more notifications:
This is a typical output of an order updated by an action affected by a user, a cancellation request is being received, and then the order status becomes canceled.
How To Monitor REDI Market Data
Definition:
AddWatch(int Type, string Symbol, string Account, string err)
Example of usage:
Notice that the type of instrument has to be supplied into the call
When we are not interested in market data on the instrument anymore, there comes the opposite call
Definition:
DeleteWatch(int Type, string Symbol, string Account, string err)
Usage example:
In either case, an action has to be submitted:
Definition:
Submit(string table,string where, string err)
Usage example:
What Notifications To Expect From Market Data Monitoring
Our included example REDIConsoleL1 implements REDI monitoring of market data for equities and options.
We see notifications such as:
Notice that:
- Notifications are of type Snapshot, Update and Add.
- For equities, we expect a Snapshot followed by Updates.
- For options, we expect Add followed by Updates.
- Often, when the fields that we are watching did not change, however, there was an update, another field was updated, we would still get a notification for the update.
How To Monitor Positions
Definition:
AddWatch(int Type, string Symbol, string Account, string err)
Example of usage:
An action has to be submitted:
Definition:
Submit(string table, string where, string err)
Usage example:
Notice, we did not pass symbol into AddWatch, the parameter is passed empty.
What Notifications To Expect From Monitoring Positions
Our included example REDIConsolePositions1 implements REDI monitoring of positions.
We see notifications such as:
We are looking for the complete view, of all positions the account holds.
A small set of positions is usually communicated within Snapshot.
A large set of current positions can be communicated on startup as Snapshot followed by 0 or more Adds.
Once all the current positions are communicated, we expect to see Updates.
An Update on a position can be triggered by a field change and also by change to the position being held.
A new position will result in an Add.
Also, when a new position is first created, we should see Updates from 0 to N to Position:
Next Steps
Review, build and run the code examples bundled with this article.
In REDI API Specification, review sections CacheControl and Order Activity Data Subscription for more details.
References
- REDI API SPECIFICATION
https://developers.refinitiv.com/transactions/redi-api/docs?content=25822&type=documentation_item
- REDI Execution Management System
https://my.refinitiv.com/content/mytr/en/product/thomson-reuters-redi.html
- Code examples
https://github.com/Refinitiv-API-Samples/Example.REDI.CSharp.Examples/tree/master/REDIConsoleOrders
https://github.com/Refinitiv-API-Samples/Example.REDI.CSharp.Examples/tree/master/REDIConsoleL1
