In this post, I will talk about the various states of a device added in BizTalk RFID. Before I jump into that, want to quickly mention that you can use the "Contoso Provider" and the "Contoso Device Simulator" that come with BizTalk RFID (as part of the SDK component) to simulate a device. You can run the device simulator by changing directory to %RFIDINSTALLDIR%\Samples\Device Service Provider\Contoso\ContosoEndToEnd\ContosoDeviceSimulator and then launching runContosoSimulator.cmd. This will launch a device at 127.0.0.1 at port 6666 and you can add this device to BizTalk RFID.
Now, back to device states - the following is the overview of the various states (you can observe these using RFID Manager):
1) Open: BizTalk RFID Service (hereafter referred to as "the service") is connected to this device. This can happen in the following scenarios: a) You have one or more running "RFID processes" that are "bound" to this device. (and/or) b) You have a client application running that has opened a connection to this device.
2) Closed: The service is not currently connected to this device. Obviously, this means that there are no running processes or applications that are interested in this device.
3) Retrying: The service will retry connection to this device periodically as it couldn't connect successfully in an earlier attempt. This can happen in the following scenario: a) There are one or more running "RFID processes" that are "bound" to this device, (AND) b) The service couldn't connect to this device successfully in an earlier attempt.
How frequently does the service re-attempt a connection to such a device? In RFID Manager, if you right click on the Devices node on the left, and select "Connection Parameters", you can see a "Connection Retry Interval" parameter. This defaults to one minute, and can be tweaked appropriately to suit your needs.
How many times does the service re-attempt a connection to such a device before giving up? In the same "Connection Parameters" dialog, you can see a "Maximum retry attempts" parameter. This defaults to 10 attempts. Again, you can configure this parameter based on your environment.
You would also notice a parameter called "Connection Check Time" in the same dialog. For connected devices that are associated with a RFID process, the service has a mechanism to automatically verify periodically if the connection is still alive. The "Connection Check Time" parameter dictates how frequently the service should verify the validity of such connections. If the device is not found to be alive, the service automatically re-attempts a connection to this device. Note: I say "for a device associated with a RFID process" specifically because this automatic connection checking is not supported for a device connected through only a client application.
4) Disabled - Failed: We talked about the maximum number of retry attempts above. What happens when the service gives up? It takes the device to the "Failed" state. In this case, it might require the manual intervention of an administrator to fix the connectivity issue (for e.g. fix the IP address or fix a network problem). In most cases, the device has to be enabled manually before it can be used again. I say most cases because there is also a way in which BizTalk RFID can automatically bring back to life such a device: if it receives a discovery event for the same device from the provider, it will automatically enable the device. For e.g. there could be a mobile device which has gone out of scope and when it re-enters the system, the discovery event acts as a nice mechanism for automatically re-enabling such a device.
There is another scenario (probably less common compared to the above) where a device can get into the "Failed" state and that's when the provider corresponding to a device is "stopped" while a connection to the device is open. In such a case, the device is taken to the "failed" state. When the provider is started again, the service will automatically re-attempt a connection to the device if there is atleast one RFID process that is bound to this device. If there is no RFID process interested in the device, the device will transition to the "Closed" state. Note that in this case the manual action to transition the device out of the failed state is to just start the provider.
5) Disabled - UnConfigured: This is the default state of a newly discovered device. Enabling such a device typically involves providing the authentication information required to connect to this device (if any). An administrator has to manually enable such a device before it can be used.
6) Disabled - Name Conflict: This indicates that the "physical name" of a device is different from its "logical name" (the name with which it was added to BizTalk RFID). This can happen in the following scenario: a) The physical device supports the NAME property and it is a writable property (AND) b) When starting a RFID Process, the service finds that the physical name is not the same as the logical name.
An administrator has to manually enable such a device before it can be used. An easy way to fix this would be to rename the device and provide a new name so that the service can apply the same name to the physical name as well.
7) Disabled - Manually Disabled: You can also manually disable a device to temporarily put it out of use; this can be useful for any troubleshooting/maintenance activities on the device. An administrator has to manually enable such a device before it can be used
To manually enable a device from any of the above four disabled states, you can right-click on a device in the Devices node of RFID Manager, and click "Enable".
So, how do you track such state changes? For e.g. how can you detect quickly when you lose connection to a device and it goes to Retrying state? BizTalk RFID raises various management events, for e.g. DeviceConnectionAttemptFailedEvent when the service is not able to connect to a device. These are WMI based events and you can have your own WMI consumer client to listen to this events or use the "RFID Tray" application to view these events, or better still use MOM to manage such events. I will detail out the various device related management events in a future post...