Profile Picture

A Question about ServiceEvent

Posted By ssdarvin 6 Years Ago
Message
Posted Tuesday October 25 2011
In build 36 or 37,  a ServiceEvent is required as a member of IService in each plugin.

I just added following code:

public event EventHandler<ServiceEventArgs> ServiceEvent;

But I don't know if I should do more implementations about it?

I found the API documents and samples are not updated about this.

Another question, how can I debug plugins?

Posted Tuesday October 25 2011
As far as debugging plugins goes, you can use the attach to process functionality of Visual Studio to attach to the RightEdge process to debug your plugin.

The ServiceEvent lets a service notify RightEdge when it has been disconnected or reconnected.  You may not need to do anything with it.  It was added for the TWS plugin where TWS can get disconnected from IB and when it reconnects, the plugin needs to re-sync to get any order fills or cancellations that happened while disconnected.

Here's some more detailed information about how it works that I wrote for someone else with the same question:

These changes were added in build 35.  The problem was before that there was no good way for a service to notify RightEdge that it had gotten disconnected.  We had some logic that would look for "disconnected" in error messages, but that wasn't reliable.  So I added an event to the IService interface for this:

 

/// <summary>

/// Notifies RightEdge about a service event (for example, if it has disconnected or reconnected).

/// </summary>

event EventHandler<ServiceEventArgs> ServiceEvent;

 

Here’s what ServiceEventArgs looks like, and the documentation:

 

/// <summary>
/// Indicates the type of a service event message.
/// </summary>
public enum ServiceEventType
{
         /// <summary>
         /// Indicates that the service has been disconnected.
         /// </summary>
         Disconnected,
         /// <summary>
         ///Indicates that the service has been reconnected.  Does not need to be raised if the reconnection is a result of calling the <see cref="IService.Connect"/> method explicitly.
         /// </summary>
         Reconnected,
}
 
/// <summary>
/// Provides information that notifies RightEdge about a service event (for example, if it has disconnected or reconnected).
/// </summary>
public class ServiceEventArgs : EventArgs
{
         /// <summary>
         /// The type of the message.
         /// </summary>
         public ServiceEventType EventType { getset; }
         /// <summary>
         /// A message describing the event or providing further information.
         /// </summary>
         public string Message { getset; }
         /// <summary>
         /// If true, indicates that RightEdge does not need to call <see cref="IService.Connect"/> periodically to try reconnecting
         /// in response to this message (which should be of type <see cref="ServiceEventType.Disconnected"/>).  The service will attempt
         /// to reconnect itself and send a service event with an event type <see cref="Reconnected"/> when it is successful.
         /// </summary>
         public bool SuppressAutoReconnect { getset; }
         /// <summary>
         /// If true, indicates that RightEdge should call <see cref="IBroker.SyncAccountState"/> in response to this message
         /// (which should be of type <see cref="ServiceEventType.Reconnected"/>).
         /// </summary>
         public bool ShouldSyncAccountState { getset; }
 
         /// <summary>
         /// <see cref="ServiceEventArgs"/> constructor.
         /// </summary>
         public ServiceEventArgs()
         {
                  Message = string.Empty;
         }
}
 
The SyncAccountState() method was also added to the IBroker interface:

/// <summary>
/// Called when the broker plugin should try to sync its orders with the orders at the broker.  Called by RightEdge after
/// <see cref="IService.Connect"/> or after a reconnection.
/// </summary>
void SyncAccountState();

 

This is where the broker should put its logic to match up the list of orders it knows about to the ones that are actually active at the broker.  Previously this was supposed to be done when Connect() was called, now it is a separate method so that the sync can happen without having to reconnect the plugin.  This is all because with TWS there are really two connections – one from the TWS plugin to TWS, and one from TWS to IB.  When TWS gets disconnected from IB and then reconnects, RightEdge doesn’t need to have the plugin reconnect to TWS, but it should resync the orders.

Thanks,
Daniel

Posted Thursday October 27 2011
Thanks for your example.Wink


Similar Topics


Reading This Topic


2005-2017 © RightEdge Systems