Management Events in BizTalk RFID
Sorry about the long hiatus - things have been pretty hectic in the last few months. Planning to catch up on all the missed blogging in the coming few weeks (things will always be hectic, so why wait any longer :)) !! If you have any specific topics in mind that you want the BizTalk RFID team to blog about, please send me a note.
Today, there was an interesting question from one of our IHV partners about the management events hierarchy, so that brings us to this post:
BizTalk RFID supports the concept of management events. A management event is an asynchronous event that can originate from a device or the device provider or even from the BizTalk RFID Service to notify the occurence of a specific condition.
Examples of management events:
1) An event "BizTalk RFID Service discovered a new device" (DeviceDiscoveryEvent) raised by BizTalk RFID Service. This is an example of an informational event.
2) An event "The source <foo> of Device <bar> is currently down" (SourceDownEvent) raised by the device provider. This is an example of a warning/error event.
For event handlers / apps / management consoles:
So, how can one subscribe to these events? BizTalk RFID Service exposes them to the outside world in two ways:
1) BizTalk RFID Service fires the management event as a WMI event. This applies to the events that originated from the device/provider and also the events that originated from the Service itself. The "RFID Tray" application that ships with BizTalk RFID (you can find it in the shortcuts in the programs menu) is an example of a "WMI consumer" application that subscribes to such events and displays them in its UI.
2) BizTalk RFID Service sends the management event to the RFID Process pipeline (i.e. notifies interested processes). This applies only to events that originated from the device/provider and not for events originating from the service. For e.g. if you have process P1 that was bound to device "D1" and if there is a BatteryLowEvent from this device, it will be sent to P1's process pipeline.
So, you can see that the above kind of events can be useful for a RFID administrator or an Event Handler writer to know about these conditions and take appropriate action when required. If you have MOM, you can use the
MOM Pack as well.
For Provider Writers:
If you look at the hierarchy of the management events defined in the DSPI, there is a class ManagementEvent from which there are three derived classes:
i) DeviceManagementEvent
ii) ProviderManagementEvent
iii) ServerManagementEvent
All the derived classes from DeviceManagementEvent (
http://msdn2.microsoft.com/en-us/library/bb656891.aspx) and all the derived classes from ProviderManagementEvent fall in the domain of the provider; for e.g. the SourceDownEvent derives from DeviceManagementEvent and you should strongly consider supporting this in your provider/device. Anything which derives from ServerManagementEvent falls in the domain of BizTalk RFID Service (i.e. service will raise such events).
Also, please make sure your device capabilities is in sync with the management events that you support in your provider. For e.g. if you support SourceDownEvent, include that in your
device capabilities.
