Please refer to Arpit’s post here, where he talks about writing a sample capture service.
Part 3 – a write up of BizTalk RFID EPCIS OM is coming up shortly.
Cheers
Krish
BizTalk RFID 2009 provides support for generating EPCIS events and converting the EPCIS events into EPCIS documents. We will start with a pictorial of the EPCIS support in this release.
As you see, there is good support to generate EPCIS compliant documents with the EPCIS Object Model and with the set of samples provided in the product.
Generating EPCIS Documents from a RFID Business Process
The RFID Business process is designed to receive Tag Read Events or Tag List Events asynchronously and components within the business may transform such events appropriate to their business logic. In BizTalk RFID 2009, we provide two sample event handlers to generate EPCIS events (not EPCIS documents) from within a process.
Transform EH
Using this EH, you may transform a raw tag read event into an EPCIS event. This sample generates only EPCIS Object events. You will need to extend this event handler to generate EPCIS Aggregation or EPCIS Quantity events. The configuration screen for the event handler is shown below.
If you have static data for the properties, you may enter it in the configuration dialog. The properties need to be entered in the URN format and some examples are shown below
BizLocation: urn:epc:id:sgln:0614141.12345.0
Business Step: urn:shipping
Disposition:urn: active
ReadLocation: urn:Contoso:ReceivePortal1
MSMQ EH
The MSMQ Sample EH that ships with BizTalk RFID 2009 enables you to store any object into a user specified queue. When you provide the Queue name, please make sure to provide the full path to the Q, such as .\PRIVATE$\<Queue Name>. If you omit the full path and just provide the Queue name, the sample will be unable to post to the Queue.
Using the above 2 event handlers, you now have EPCIS events in a queue. The next step is to take the events out of this queue and post it to a capture service, which we shall describe in the EPCIS Posting application.
Generating EPCIS Documents from a .NET Application
In this scenario, we look at a .net application receiving Tag Read Events from BizTalk RFID and needs to generate EPCIS Documents. The application would use the EPCIS Object Model (implemented in the namespace Microsoft.Rfid.Epcis) to first convert the raw events to EPCIS events. The application would then use the Capture client classes in the EPCIS OM to serialize the events into an EPCIS document and forward it to the capture service. We illustrate this via some sample code
Sample code
This sample code illustrates
- Creation of a custom EPCIS event "TemperatureEvent" using the BizTalk RFID EPCIS OM
- Forwarding the custom EPCIS event to a capture service
You could modify this code sample to send base EPCIS events to the capture service instead of the temperature event.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SensorServices.Rfid.Epcis;
using Microsoft.SensorServices.Rfid.Epcis.Serialization;
using System.ServiceModel;
using System.ServiceModel.Description;
using System.IO.SensorServices.Rfid.Client;
using System.Collections.ObjectModel;
using Microsoft.SensorServices.Rfid;
using Microsoft.SensorServices.Rfid.TagDataTranslation;
// Assumptions:
// You have a real/simulated device 'DockDoor1'
// You are running the sample Capture Service
namespace EPCISOMSamples
{
// We are creating a user defined event - TemperatureEvent” with an extra xml element
// - Temperature and an extra xml attribute SensordeviceID
[EpcisSerializable]
public class TemperatureEvent : ObjectEvent
{
[EpcisElement(Name = "Temperature")]
public double Temperature;
[EpcisAttribute(Name = "SensorDeviceID", Namespace = "Contoso")]
public string SensorDeviceID;
}
class Program
{
static void Main(string[] args)
{
// create the temperature event
// This client picks up the configuration from app.config
// The client gets the endpoint where the service resides as well as how (WCF binding) it has to
// use from the configuration file. It also gets the configuration of using "TemperatureEvent"
// in place of "ObjectEvent" from the config file. Thus, with this client you can send
// TemperatureEvent in place of ObjectEvent.
// You may use the capture client configuration defined in app.config or set it up programmatically.
// The line of code that gets configuration from the config file is below
CaptureClient client = new CaptureClient("EPCISRestClient");
// If you want to set the client configuration programmatically, uncomment the lines of code below
// and comment the above line
// NOTE : All 'TemperatureEvents' are serialized as 'ObjectEvents' , with the extra fields going
// into the 'ObjectEvent' extension fields. Once overridden,you will not be able to send an
// ObjectEvent or any sub class of the ObjectEvent other than the TemperatureEvent
// through this Capture Client instance
// Dictionary<string, Type> eventOverridesDictionary = new Dictionary<string, Type>();
// eventOverridesDictionary.Add(typeof(ObjectEvent).Name, typeof(TemperatureEvent));
// EpcisBehavior epcisBehavior = new EpcisBehavior(eventOverridesDictionary);
// CaptureClient client = new CaptureClient(new WebHttpBinding(), // new EndpointAddress("http://localhost:9998/Epcis/rest/"));
// client.Endpoint.Behaviors.Add(new WebHttpBehavior());
// client.Endpoint.Behaviors.Add(epcisBehavior);
client.Capture(GetTemperatureEventList());
}
private static IEnumerable<EpcisEvent> GetTemperatureEventList()
{
DeviceConnection dc = new DeviceConnection("DockDoor1");
dc.Open();
ICollection<TagReadEvent> treCollection = dc.GetTags(TagDataSelector.All);
List<EpcisEvent> temperatureEventList = new List<EpcisEvent>();
foreach (TagReadEvent tre in treCollection)
{
// Typically you will make a external call (Web Service/LOB) to get the business
// context such as location and the BusinessTransactionList
TemperatureEvent temperatureEvent = new TemperatureEvent();
temperatureEvent.Action = EpcisAction.Add;
temperatureEvent.BizLocation = new BusinessLocation() { Name = new Uri("Contoso:Shanghai") };
temperatureEvent.EventTime = DateTime.Now;
// Ideally one should use CommonUtilities defined in ObjectModelExtension
// to fill Uri from TRE/TLE
temperatureEvent.EpcList.Add(CommonUtilities.GetEpcForTagID(tre.GetId()));
temperatureEvent.ReadLocation = new ReadPoint() { Name = new Uri("Contoso:Dockdoor1") };
temperatureEvent.SensorDeviceID = "Sensordevice1";
temperatureEvent.Temperature = 99.98;
temperatureEventList.Add(temperatureEvent);
}
return temperatureEventList;
}
}
}
App.Config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding name="WebHttpBinding_IEpcisService">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
</binding>
</webHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:9998/Epcis/rest/" binding="webHttpBinding" bindingConfiguration="WebHttpBinding_IEpcisService" contract="EpcisCaptureClient" behaviorConfiguration="EpcisArrayItemBehavior" name="EPCISRestClient" />
</client>
<behaviors>
<endpointBehaviors>
<behavior name="EpcisArrayItemBehavior">
<webHttp />
<epcis>
<epcisArrayItems>
<add clrType="EPCISOMSamples.TemperatureEvent, EPCISOMSamples, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" tagName="ObjectEvent" />
</epcisArrayItems>
</epcis>
</behavior>
</endpointBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
vent : ObjectEvent
{
[EpcisElement(Name = "Temperature")]
public double Temperature;
[EpcisAttribute(Name = "SensorDeviceID", Namespace = "Contoso")]
public string SensorDeviceID;
}
class Program
{
static void Main(string[] args)
{
// create the temperature event
// This client picks up the configuration from app.config
// The client gets the endpoint where the service resides as well as how (WCF binding) it has to
// use from the configuration file. It also gets the configuration of using "TemperatureEvent"
// in place of "ObjectEvent" from the config file. Thus, with this client you can send
// TemperatureEvent in place of ObjectEvent.
// You may use the capture client configuration defined in app.config or set it up programmatically.
// The line of code that gets configuration from the config file is below
CaptureClient client = new CaptureClient("EPCISRestClient");
// If you want to set the client configuration programmatically, uncomment the lines of code below
// and comment the above line
// NOTE : All 'TemperatureEvents' are serialized as 'ObjectEvents' , with the extra fields going
// into the 'ObjectEvent' extension fields. Once overridden,you will not be able to send an
// ObjectEvent or any sub class of the ObjectEvent other than the TemperatureEvent
// through this Capture Client instance
// Dictionary<string, Type> eventOverridesDictionary = new Dictionary<string, Type>();
// eventOverridesDictionary.Add(typeof(ObjectEvent).Name, typeof(TemperatureEvent));
// EpcisBehavior epcisBehavior = new EpcisBehavior(eventOverridesDictionary);
// CaptureClient client = new CaptureClient(new WebHttpBinding(), // new EndpointAddress("http://localhost:9998/Epcis/rest/"));
// client.Endpoint.Behaviors.Add(new WebHttpBehavior());
// client.Endpoint.Behaviors.Add(epcisBehavior);
client.Capture(GetTemperatureEventList());
}
private static IEnumerable<EpcisEvent> GetTemperatureEventList()
{
DeviceConnection dc = new DeviceConnection("DockDoor1");
dc.Open();
ICollection<TagReadEvent> treCollection = dc.GetTags(TagDataSelector.All);
List<EpcisEvent> temperatureEventList = new List<EpcisEvent>();
foreach (TagReadEvent tre in treCollection)
{
// Typically you will make a external call (Web Service/LOB) to get the business
// context such as location and the BusinessTransactionList
TemperatureEvent temperatureEvent = new TemperatureEvent();
temperatureEvent.Action = EpcisAction.Add;
temperatureEvent.BizLocation = new BusinessLocation() { Name = new Uri("Contoso:Shanghai") };
temperatureEvent.EventTime = DateTime.Now;
// Ideally one should use CommonUtilities defined in ObjectModelExtension
// to fill Uri from TRE/TLE
temperatureEvent.EpcList.Add(CommonUtilities.GetEpcForTagID(tre.GetId()));
temperatureEvent.ReadLocation = new ReadPoint() { Name = new Uri("Contoso:Dockdoor1") };
temperatureEvent.SensorDeviceID = "Sensordevice1";
temperatureEvent.Temperature = 99.98;
temperatureEventList.Add(temperatureEvent);
}
return temperatureEventList;
}
}
}
App.Config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding name="WebHttpBinding_IEpcisService">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
</binding>
</webHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:9998/Epcis/rest/" binding="webHttpBinding" bindingConfiguration="WebHttpBinding_IEpcisService" contract="EpcisCaptureClient" behaviorConfiguration="EpcisArrayItemBehavior" name="EPCISRestClient" />
</client>
<behaviors>
<endpointBehaviors>
<behavior name="EpcisArrayItemBehavior">
<webHttp />
<epcis>
<epcisArrayItems>
<add clrType="EPCISOMSamples.TemperatureEvent, EPCISOMSamples, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" tagName="ObjectEvent" />
</epcisArrayItems>
</epcis>
</behavior>
</endpointBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
In the next post, we will cover the EPCIS Object Model and provide a sample capture service.
Amar Sagare contributed the sample code for this article. Thanks Amar.
With the imminent release of BizTalk Server 2009, the BizTalk RFID team is proud of the products' growing support for industry standards. In this emerging technology, standards are critical to mass adoption. Enterprises can confidently adopt the technology without fear of being locked into one vendor. One could envision multiple software and service layers being supplied by various vendors that inter-operate well due to support for existing standards. Customers have become very well informed of the existing standards in this space.
On that general note, BizTalk RFID is rapidly becoming best of breed for support for many industry standards.
Our LLRP implementation is shipped out of box in BTS 2009 as a LLRP Provider and is compatible with many industry heavyweight LLRP implementations such as Impinj, Motorola and Intermec. Not only do we use LLRP to communicate with fixed UHF readers, but we also use the protocol in our store and forward service on BizTalk RFID Mobile and for remote management of RF modules on mobile devices. Very innovative way of finding another use case for the LLRP protocol.
On the device management side, discovery of devices is a major pain for adoption. How many times have you had to manually enter IP addresses of devices to provision them to some middleware? Don't you wish that device discovery is truly plug and play. With the emerging WS-Discovery standard [OASIS will ratify this standard in June 2009], discovery of devices in the same subnet will be truly plug and play. With the Discovery proxy support in Windows 7, one could extend this to discover devices across the entire enterprise. What does BizTalk RFID do to enable discovery? We ship a discovery library in BizTalk RFID 2009 that enables any device provider to use it and discover WS-Discovery enabled devices. The device developer would have to implement WS-Discovery on the device. There are freely available DPWS (Device Profile for Web Services stacks) on the web today. DPWSCORE is a popular open source DPWS stack that works on Windows, Linux etc. In the future, we do plan to build discovery in the platform as we believe it is a core platform feature.
While discovery is a start, there are other aspects of device management such as initialization (firmware update), configuration and monitoring that scream for standardization. Why should customers pay the price for having to learn to multiple different ways of doing the same thing, especially if they have a multi vendor policy. We are hard at work in ISO/SC31/WG4/SG1 with our partners to define a web service standard for RFID device management. This is called RFID Device Management Profile (RDMP) and is layered on top of DPWS and WS-Discovery. More to come later, when I am allowed to share details...
Leaving the device world for a bit, EPCIS has been making waves in the industry. BizTalk RFID steps into EPCIS by providing solid support to build a capture client application. We ship a powerful Object Model for EPCIS that has support for base EPCIS events (object etc) and user extensions of base events. There are two samples that ship as well - the EPCIS transform event handler enables a developer to add business context to a Tag Read Event and generate an EPCIS event. The MSMQ event handler then enables EPCIS events to be persisted in a MSMQ to be then consumed by a capture client to forward to a capture service. The capture client would use the capture client SDK to post to a capture service. I will post a follow up with more details on EPCIS OM and our roadmap for rounding out our EPCIS support.
Thanks for reading and if you have any questions, leave a comment and I will be glad to reply
Cheers
Krish
A number of BizTalk RFID Mobile developers have asked us about support for .net CF 3.5 in BizTalk RFID Mobile. This post seeks to address this issue and provides information to enable .net 3.5 CF based applications to work with the BizTalk RFID Mobile platform.
The BizTalk RFID Mobile platform itself is a .net CF 2.0 based platform. Hence, the minimum requirement is a device that has .net CF 2.0 loaded. However, with .net CF 3.5 being the latest version of the compact framework, how do applications work with BizTalk Mobile platform and providers that could have been built with potentially different .net CF versions?
Permutations to consider:-
1) Provider built for .net CF 3.5
| Mobile Application Target | 2.0 |
| Provider Target | 3.5 |
| BizTalk Mobile Platform | 2.0 |
2) App and provider built for .net CF 3.5
| Mobile Application Target | 3.5 |
| Provider Target | 3.5 |
| BizTalk Mobile Platform | 2.0 |
3) Only app is built for .net CF 3.5
| Mobile Application Target | 3.5 |
| Provider Target | 2.0 |
| BizTalk Mobile Platform | 2.0 |
In scenario 1), let us say the application has been built for .net CF 2.0 and the provider is built for .net CF 3.5. Since the BizTalk RFID platform and provider are executing in the application context, the application developer is required to include a configuration file that sets the execution environment to 3.5. Please see http://msdn.microsoft.com/en-us/library/d5cd9b2c.aspx for how to do this. If you are running a provider that is built for .net 3.5 CF, you are required to provide this configuration file for the management app and the read tags app that ship with BizTalk RFID Mobile. For example, for the management app, you would include managementapp.exe.config that would look thus
<configuration>
<startup>
<supportedRuntime version="v3.5.7283"/>
</startup>
</configuration>
To get the supportedRuntime version, please follow the steps in the link above.
For scenario 2) there is no additional steps required, since the application and the provider are .net CF 3.5 based.
For scenario 3), if you are building an application that is .net CF 3.5 based, a configuration file is not required as the native target for the application is .net CF 3.5.
Cheers
Krish
I wondered how many BizTalk RFID users really know about RFID Tray. The RFID Manager gets used all the time, but the RFID Tray is a useful tool for monitoring.
The RFID Tray is not added to the tray by Setup. The administrator has to launch it from the BizTalk RFID Program Group.
Once launched, the RFID Tray adds itself to the desktop tray and starts monitoring events from the local server. You may add more BizTalk RFID Servers for the tray to monitor.
When you right click on the RFID Tray Icon, you have four items
1) Servers...
2) Alerts...
3) Show Popup
4) Exit
Servers
Clicking the servers item displays this servers window
You may add a new server, remove an existing server or refresh the status of a server. I stopped the BizTalk RFID Service on my machine. and hit refresh and RFID Tray changed status to Service Stopped.
Alerts
In normal operation, as soon as an alert is received, the RFID Tray displays a popup (like the Outlook message alert) and gradually fades away. You can disable pop-ups by toggling the Show Popup check mark. If you take a coffee break and missed the pop-ups, no worries. If there are alerts that you have not seen, RFID tray changes its icon state to this 
to show that there are new alerts to be seen.
The alerts window displays a history of alerts from one or more BizTalk RFID servers. Here is an example of a few alerts
I started a process named Inventory Management. It was bound to the RootDeviceGroup, but none of the devices were up. I started the Contoso device simulator to simulate the Inventory Reader and the Receiving Reader. You can see the change in status of process to started and of the devices from retrying to open.
The alerts window lets you see alerts from various servers in a single window, which is very convenient.
In the next example, I changed the binding for a process by removing its binding to a logical device. Here is what RFID Tray displayed
As a part of the process stopping, the connection to the device was closed. The process went into event collecting mode to ensure no tags were lost. The process restarted, but you don't see the device state changing from closed, because I had unbound the process from all devices.
RFID Tray is a WMI listener and listens to specific WMI events generated by the BizTalk RFID Service.
Hope you try out this tool and let us know if you find it useful.
Happy New Year!
Our documentation team has recently released online documentation for BizTalk RFID Standards Pack and BizTalk RFID Mobile. The documentation may be accessed at the links below.
BizTalk RFID Standards Pack:
Installation Guides and Readme
Downloadable Documentation
MSDN Documentation
Trial Software
Code Samples
BizTalk RFID Mobile:
Installation Guides and Readme
Downloadable Documentation
MSDN Documentation
Trial Software
Code Samples
Here is hoping that you will find the documentation invaluable. Keep sending us feedback on the content.
Cheers
Krish
Couple of days ago, I participated in the Hyderabad 10K run and for the 2nd year in a row, RFID tags were used to clock runners. My analog watch said 54 minutes, but the RFID measurement clocked me at 00:57:35. I guess technology deflated my short lived feeling of euphoria. I also expected to get segment times, to find out where I started slowing down or picking up speed, but alas, that was not to be. I guess there was not enough funding to place readers at intermediate points.
This time, the organizers used a RFID tagged bib. In last year's run, a plastic tag was used and one had to attach it to the sneaker. I wonder about the pros and cons of each approach. I also noticed that a cable was strung across the start and finish areas. It was placed about 10 feet high and sure enough all finishers jumped up to touch it as if to indicate that they finished. Organizers had a tough time stopping people from destroying the cable :-).
Another trivia - last year a company from Netherlands provided the RFID Solution. This year, it was a French Company. Whose turn will it be next? No points for guessing Senor!
Is there any other sport where RFID technology is used?
It was also a sad week for folks in Mumbai, who were crushed by terrorism. Is it possible to use RFID technology to counter terrorists while they are causing damage? With hotels becoming targets, how may they be able to use RFID to counter the threat? If you have any thoughts, please share.
Cheers
Krish
Over this year, we have been talking to a number of partners and customers on the usage of EPCIS. It appears that many companies are in the process of evaluating EPCIS in the form of pilots. Many customers have also insisted on the availability of EPCIS in the middleware platforms that they evaluate.
In the BizTalk RFID 2009 release, we will be releasing client components to enable building of EPCIS Services. What does this mean and why should you care?
EPCIS, in broad terms, consists of a capture service, a query service and a repository. An EPCIS event is posted to a capture service (typically from multiple RFID deployments) and these events are saved to a repository. A standard query interface enables applications to query and retrieve observation events from the repository.
In this release, we will provide the following functionality:-
EPCIS Object Model - This is the CLR object used to represent EPCIS events and EPCIS master data. This object model will be used by BizTalk RFID developers to add context to EPCIS events as well as post it to the Capture Services
The Capture client - The capture client serializes the EPCIS event and posts it to the capture service. It is the responsibility of the capture service to de serialize the EPCIS event
Out of the Box Event Handlers - We will provide two event handlers. The transformation event handler transforms Tag Read/Tag List Events into EPCIS events. An ISV may extend the transformation event handler to add business context (such as bizStep, bizLocation etc) to the EPCIS event. Once the EPCIS event is formed, the Post Event Handler uses the capture client to post the events to the capture service.
Support for .NET Applications - A .net Application may wish to generate EPCIS events. Using the EPCIS OM and the capture client, a .net Application can successfully generate an EPCIS event and post it to the capture service
Extending EPCIS Events - We will also provide the ability to extend pre-defined EPCIS events to enable custom attributes to be added as the ISV chooses.
This infrastructure enables ISVs to build EPCIS applications on top of the BizTalk Server RFID 2009 release.
To illustrate with a diagram:-
Over the next few weeks, we will provide more details of the EPCIS functionality. Let us know if you are working on EPCIS based applications and your thoughts or questions on our offering.
Regards
Krish
