3 of 3 people found this helpful
I'm not aware of any 'best practices' that we have for creating a windows service that will listen to Events on PI Points using PIDataPipe in AF SDK, may be others can chime in on this.
From the PIDataPipe documentation: There are two ways to get the data change events: a) direct GetUpdateEvents method to get events; b) through IObserver of AFDataPipeEvent. The IObserver pattern provides significant performance improvement over direct GetUpdateEvents method for high throughput scenario. Application will have to implement the IObserver and register the IObserver with the data pipe via the Subscribe(IObserver< AFDataPipeEvent> ) method.
I don't think it is necessary to have separate worker thread for handling events unless you are doing any large amount of processing on the subscribed data.
For error management of PI System connections:
Create your own custom event log within your services code, and register your service as a valid source of entries for that log. You must then write code to record entries to the log whenever an action you're interested in occurs, in this case errors or exceptions to the connection.
1 of 1 people found this helpful
I agree with Thyag, I don't know of any published best practices though I am sure that some customers have some valuable real life experiences that could help you out.
Regarding error management for PI Connections, I would assume you have a try-catch block where you are trapping the exception so that your Windows Service may log it. That's one of the big things about Windows Services or unattended tasks: you really should put in as much logging into your application as you need to help you troubleshoot later.
If your concern is losing connection later after a successful connection has been made, then you should subscribe to the PIServer.ConnectChanged Event. Your service would be notified that a connection has been lost, which gives you an opportunity to log it and handle it appropriately.
As for the need of a worker thread, a Windows Service is already multiple threaded. If I have a timer trigger that fires off requiring me to perform some action, I usually do this in its own thread. However, inside that one thread launched by the trigger, I see no reason to spin up additional threads. I do want my Windows Service to be fast, but it usually is running in the background and doesn't have the same burden of code for threading or parallelism that I would put in a UI app. So my answer is you don't have to, and you should really convince yourself that you need a reason to otherwise.