Pro RFID in BizTalk Server 2009 (Expert's Voice in BizTalk)

Ever, just stop and think about how much stuff there is in the world, Yeah, and keeping track of it all, you know, from the apples and the supermarket to like parts for a satellite. It's a massive job.

It really is. And that's where the tech we're digging into today comes in RFID radio frequency identification.

Right, and you send us some really interesting material focused on pro RFID and BizTalk server two thousand and nine. Now, okay, biztalks evolves since O nine.

Obviously, absolutely, but the core RFID concepts in there still incredibly relevant and gives a solid look at how you actually implement this stuff in a business.

So at its heart, what is RFID?

Just for a quick baseline, Okay, basically, it's a way to automatically ID objects using radio waves. You've got a reader right, sends out a signal, then there's a tag on the item. Here's the signal and talks.

Back, and a computer sorts it all out exactly.

It's like giving, I don't know every physical thing its own little digital voice.

Got it. So our mission today really is to cut through the textbeak understand what RFID he actually does, why it matters, especially using this source material as our guide which seems to cover everything from the real basics up to the nuts and bolts of using it with biz talk two thousand and nine.

Yep, let's maybe start with some context, like how did we even track things before all this fancy radio stuff.

Well, for ages, it was just looking at stuff, right. The source calls it the mark one mod zero eyeball, you just saw it, you knew what it was.

Ah, yeah, pretty much. Then paper a Ledgers obviously trying to scale that up.

Yeah, imagine trying to run a supermarket just by memory, the cashier knowing every single price impossible, so much room for air, so slow.

That human element, that manual data entry, that was always the bottleneck. Then late sixties bar codes came along, big step.

Huge, using lasers, right, suddenly you could scan something. Boom, digital info pops up. We see them everywhere.

Now, totally change the game. But bar codes, yeah, they have that one limitation line of sight.

You have to physically point the scanner at the barcode, make sure it can.

See it clearly, exactly, And that's where RFID really shines. As the source points out, no line of sight needed. You can read these tags right through cardboard boxes, plastic crates even.

Some wood, so like stuff flying down a conveyor belt, doesn't matter. If the tag is facing the wrong way, pretty.

Much, the reader can often still pick it up. It's using radio waves, not late.

Okay, let's break that down. How does that radio conversation actually happen between the reader and the tag?

Right, So the reader starts it. It sends out a radio wave using its antenna at a specific frequency, and.

The tag has an antenna too.

Yep, the tag's antenna picks up that energy from the reader's signal. Now, if it's a passive tag and most far, that radio wave actually powers up the little chip inside the tag.

Whoa Okay, so the reader beam literally wakes.

The tag up, kind of gives it just enough juice to operate for a moment. Then the reader might send a command on that wave, like hey, who are you? Huh? If the tag gets the command, it uses that energy it just collected to send back its stored info, usually it's unique ID number, modulating it onto its own radio wave signal.

Which the reader then picks up. Got it now, the source mentioned different kinds of RFID, different frequencies. Why so many?

Ah? Yeah, the frequency affects things like how far away you can read. The read range also affects how much data you can send back and forth, and how well it works around things like metal and liquids, which can sometimes interfere. Okay, and you mentioned passive tags. There are also active tags. These guys have their own little battery.

Ah, so they don't rely on the reader's energy. Right.

Means they can be read from much further away, sometimes hundreds of feet, and they can power other things like sensors, maybe temperature sensors or something.

But I guess they're more expensive and the battery runs out eventually.

Exactly trade offs. Passive tags are cheaper, last basically forever, but shorter range. Active tags longer range, more capabilities, but cost more and have a limited lifespan. You pick what fixed The job makes.

Sense and it's not always just reading one tag, right, Yeah, I remember reading about scanning. Yeah, like a whole palette of boxes at once.

Yes, that's a huge advantage anti collision. It's a key concept. Imagine that palette, maybe fifty boxes, each with a tag. A reader at a doorway can ideally read all fifty tags as the palette goes through.

How does it avoid just getting a garbled mess of signals all talking at once.

Clever algorithms. It's a bit like you know how you're a Wi Fi router manages lots of devices talking. The reader manages the conversation telling tags in effect to speak one at a time or in small groups very very quickly, so it can identify all of them without the signals crashing into each other.

Wow. Okay, that sounds incredibly efficient for logistics. So what kind of info is actually on these tags? Is it just a serial number?

It varies a lot. Some basic tags might just have a globally unique idea like an MT address for a physical object. That's often enough just to know which specific item it is, right. But other tags, especially where more expensive ones, can have user memory, You can write other data to them, maybe the product code, manufacturing date, batch number, even maintenance history potentially and.

The source mentioned. Commissioning is a loading this data onto the tag pretty much.

Commissioning is that initial step where you write this specific data onto a tag and associate it in your system. You're giving the tag its identity for your application, and groups like GS one and EPC Global are working hard on standards for this data like the EPC standards, so everyone speaking the same language, similar to how UPC barcodes work.

So it's not just this is a box of widgets, it's this is this specific box of widgets made on Tuesday, expiring next year.

Huge for traceability, absolutely, things like recalls, warranty tracking, authentication. It opens up a lot. And the source also quickly mentions antenna's linear versus circular polarization that affects read reliability too, especially the further away you get with UAGEF frequencies. But maybe that's getting a bit deep for now.

Okay, Yeah, let's maybe stick to the core ideas. For now, we've talked anti collision tag types. Let's circle back to that tag.

Sure. So, like we said, memory varies, and there's a direct link usually between how much memory tag has and how much it costs.

Right, more memory, more money.

Yeah, So if you're tracking, say a critical jet engine part, you might splurge on a high memory tag to store its entire maintenance log directly on the part. Super valuable data.

Right there makes sense, expensive part critical data.

But if you're tracking I don't know, millions of pairs of socks for a retailer, tag cost is king. You'll use the cheapest possible tag with maybe just that unique ID number. You store all the other details about the sock in a database link to that ID.

Gotcha. You wouldn't put the socks washing instructions on the RFID tag itself.

Probably not. And that commissioning step we mentioned, that's where you write that unique ID to the sock tag and link it in your database to pair of blue socks size tens KIU one two, three, four five. It activates the tag within your system.

Okay, So with all this tech reading through boxes, unique IDs, anti collision, what's the real bottom line? The source scene keen to manage expectations a bit.

Yeah, it makes a good point. RFID doesn't really let you do things that were fundamentally impossible before. I mean, you could theoretically have someone manually inspect and log every single item entering a warehouse.

Theoretically, yeah, but it would be painfully slow and full of mistakes exactly.

That's the key. RFID takes processes that were possible but maybe impractical, slow or error prone, and makes them feasible. It automates them, makes them faster, way more accurate, and scalable.

So debut efficiency and accuracy gains through automation.

Precisely. Take that warehouse receiving example, manual check slow mistakes happen. RFID a palette rolls through a portal reader, scans dozens or hundreds of items, and seconds instantly verifies against the shipping notice, updates, inventory boom.

Minimal human intervention, real time data. Right.

So, whether you're using eyeballs or a barcode scanner or an RFID reader, the goal is the same, connect the physical item to its digital record. RFID just provide a much, much faster, more automated, and often richer way to make that connection.

Okay, so where's this paying off the most? Where's the adoption really happening?

Well, according to the source, supply chain is huge, tracking goods from factory through distribution centers all the way to the store shelf at palette level, case level, sometimes even item level. Big visibility improvements.

There, and retail seems to be catching.

On too, definitely. Retailers are using it more and more for inventory accuracy. Knowing what you actually have on the shelves and in the back room helps prevent empty shelves. You know, out of stocks also helps reduce lost or stolen items. It can be more informative than just those basic anti theft.

Tags, right because you know which specific item went missing, not just that something beat exactly. Okay, So let's pivot to the specific focus of the source. BizTalk RFID two thousand and nine now again acknowledging the date. What was the core idea behind this platform?

BizTalk RFID back then was Microsoft's answer from managing these RFID systems in a business context. The source use is a pretty cool analogy. It's like trying to assign IP addresses to every object in the real world. But from the hardware view, bistok RFID was the software layer on top of that.

So it connects to the readers, gets the data.

Yeah, it connects to all sorts of different RFID readers, printers, other devices. It processes the raw tag data coming in and then helps you integrate that data with your other business systems, your inventory system, your ERP.

Whatever, the software brain making sense of the radio signal.

You got it. The source shows this architecture right with logical devices, ways to connect to bistalk server itself or SQL databases, and this event driven model for building specific RFID business processes. It aimed to provide a structured way to handle all that RFID data flowing in, and it had.

A layered architecture. What did that look like?

Broadly, think of it like stacks. Down at the bottom the actual physical readers and tags. Then a layer called device providers basically drivers software bits that let bistalk RFID talk to specific hardware models. Okay, above that the main bistok RFID engine managing the devices, processing the events. And then at the top the business logic you build your RFID processes that decide what to do with the tag reads.

The source mentions these things called knobs exposed as properties for devices sounds intriguing.

Yeah, that's about controlling the reader hardware. Bistok RFID assumed readers have settings you can tweak network settings, radio power, maybe antenna configurations. It tried to expose these settings as properties you could adjust right from the bistok RFID software, so.

You could fine tune the reader's behavior remotely.

That was the idea. The source notes though that how many knobs you actually got depended on how good the device provider software was for that specific reader, and some settings might reset if the reader rebooted while others would stick.

Gotcha. And then there's this difference between physical device names and logical devices. Why separate them?

Ah, that's actually a really useful abstraction. A logical device is like a placeholder name you use inside your business talk RFID process. Like warehouse door reader. It's not the actual IP aggress or serial number of the physical reader.

Okay, so it's a nickname sort of.

Then separately, you bind that logical name warehouse door Reader to the actual physical reader hardware installed at the warehouse door.

Why bother with the extra step flexibility?

Say that physical reader breaks, you replace it with a new one, maybe even a slightly different model. If it's compatible. You might just need to update the binding point the logical name warehouse door Reader to the new physical reader. Your actual RFID business process code doesn't necessarily need to change. It insulates your logic from the specific hardware.

I see. That makes maintenance and upgrades much easier. Smart okay, sok. RFID provides this framework, what about actually managing it? The source mentions r FID manager.

Right, RFID manager was the main graphical tool the GUI for administering bis talk RFID. It's where you'd register those device providers, add your physical readers, organize them, and configure the RFID business processes themselves the command center pretty much. The Source does mention a little quirk sometimes you had to manually hit refresh to see the latest status. Updates in the manager tool wasn't always real.

Time h okay, goodl manual refresh. So what could you actually do an RFID manager besides adding devices?

Well, you could connect to your local BizTalk RFID server or manage remote ones. You could group devices logically, maybe west wing readers shipping dock readers. You could also import and export device configurations.

Oh like for backups or setting up another server the same way exactly.

And one really neat feature highlighted was device property versioning.

Version like Source control for reader settings.

Kind of RFID manager kept a history of changes made to device properties. So if you tweaked, say the radio power on a reader, and things stopped working, well you could look back see exactly what changed and easily roll back to a previous configuration. The source had an example of changing a reader's location property and then undoing it.

That sounds super useful for troubleshooting, like an undoe button for your hardware settings. Yeah. Can you also change how processes are connected the bindings in there?

Yep. When a process was stopped, you could go into RFID manager and change which logical devices it listens to or which software components it uses. There was a wizard to help, or you could edit the raw binding files if you needed to.

Okay. The source uses a warehouse exegate example to show how a process works. Can you walk through that?

Sure? So picture an RFID reader over the exit door of a warehouse. The goal is when a palette with tag items goes out, automatically confirm it shipped. Right in bistok RFID, you'd build a process. This process would be configured to listen for tag reads coming only from the logical device bound to that exit gate reader. When a tag or a list of tags from the palette is read by that specific reader, an event handler component inside

So the process is like the little automated agent watching that door. Yeah, and the binding tells it which physical door to.

Watch exactly right. The binding connects the abstract idea in your process, the exit gate reader, to the actual piece of hardware bolted to the wall. Data flows from the physical reader through the binding to the correct logical device in your process, triggering your logic.

You mentioned components and event handlers. What are those exactly within a process?

Think of them as plug ins or building blocks for your process. They do specific jobs when an RFID event happens. The source gives a good example. A SQL server sink component that's.

What it sounds like, writes data to SQL precisely.

You drop this component into your process pipeline. When a tag read event comes through, this component automatically takes the data tag id, timestamp, reader name, et cetera, and inserts it into a specified table in your SEQL server day dtabase.

Handy, and you could write your own custom ones.

Yes, absolutely. Those are often called event handlers. They're basically snippets of dot Net code you write to perform any custom logic you need, maybe complex validation calling a specific internal system whatever. The component model makes processes modular u lets. You reuse common bits.

Of logic, and you'd manage adding and configuring these components like the sql sinc using RFID manager too.

Correct, you'd register any custom components, then drag and drop them into your process design and RFID manager and configure their settings like the database connection string for the SQL SINC.

Okay, Now, what if you don't have physical RFID readers lying around, but you want to build and test these processes. The source mentions a simulator.

Yeah, the device simulator in the SDK super valuable for development and testing. It lets you pretend to be one or more RFID readers, generating fake tag read events, all in software.

So you don't need the hardware budget just to get started exactly.

You can configure it through files, tell it how many fake readers to create, what IP addresses and ports they should pretend to use, how often they should see tags, what the tag data should look like, so.

You can simulate different scenarios like lots of tags appearing at once or tags appearing intermittently.

Yep, you can define the notification behavior, send tags one by one, send them in batches, tagless events, control the timing. The source even points to a ready made Contoso simulator example in the SDK to get you started quickly. You can fire that up and immediately have simulated tag data flowing into your BizTalk. RFID processes for testing.

Very cool, like a virtual RFID lab. And the SO has tied this back to a simple retail case study.

Right, just a basic example. Imagine high value electronics tagged in a store. Reader at the exit logs every time one of these tags passes through, that data goes to a central system, maybe using that SEQL sync. Okay, just by logging those exits, the retailer gets basic business intelligence. How many expensive TVs left the store today, any leave

Taking the raw reads and turning them into useful info makes sense. And there was also a command line tool RFID client Console.

Yeah, URFID Clientconsole dot exe for folks who prefer command lines or need to script administrative tasks. It offered another way to manage providers, devices and processes, doing much of what RFID Manager could do.

But text base okay, handy for automation. Yeah, Now for the developers listening, the source gets into coding aspects. It mentions a base class r FAD event handler base.

Right, if you're writing those custom components, those event handlers we talked about, you'd typically create a dot net class that inherits from our fit event handerbase. This gives you the framework the necessary methods to plug into the BizTalk RFID run time, banken init methods exactly. The init method

And the source stress keeping these handlers fast.

Oh yeah, critical point. The methods in your event handler that actually process the tag reeds need to be quick, avoid long database calls, complex calculations, or anything that blocks the processing thread for a long time. Why is that so important Because bistok RFID is trying to process potentially hundreds or thousands of tag reads per second. If your custom code takes a half a second for every tag, you'll create a massive bottleneck. The whole system slows down.

Got it, keep it lean and mean in the main event pass. What about this deploy static method? When is that used?

That's for setup tasks. If your event handler needs something done once when the RFID process is first deployed or updated, maybe creating a specific database table it needs to write to, or registering something with the operating system, you'd put that logic in the static deploy method. The runtime calls it automatically during deployment.

Okay for one time initialization. And how does bistalk RFID handle the different kinds of data coming from readers, taglists, single reads source mentioned strong taping.

Yeah, it uses a strongly typed event system. When you build your process, your event handlers declare what specific type of event they expect, like a tag rate event, a single tag or a tag list event the batch of tags. The runtime manages this. If a reader sends a tagless event, but your first handler wants individual tag rate events, the runtime can automatically shred the list and feed the tags to your handler one by one. This strong typing helps

In your code helps avoid errors from unexpected data formats. Speaking of errors, how does BizTalk RFID handle things going wrong in a process?

It has built in error handling in RFID manager. You could set thresholds like if you get more than ten errors in a minute, maybe automatically stop and restart the process. You could also see the details of the last error that occurred. But the advice in the source generally is to handle recoverable errors like a temporary network clitch, trying to call on external service within your own event handler code.

Try to fix what you can. Let the system handle the disasters. The source also mentioned programmatically setting up those bindings between logical and physical devices.

Yes, besides using the RFID manager GUI, there's an API using a class called binding manager Proxy. This lets you write code to create or modify those bindings. Useful for automated deployment scripts or maybe dynamic scenarios where the physical device might change based on some external factor. You could bind based on device names, group names, even specific antenaports give you more controls, and.

We saw a diagram of the runtime architecture. What were the key parts there?

Well, there's the routing engine that gets the raw events from the device providers. It figures out which running RFID process should receive that event based on the bindings. Each process has its own input q q Q. It decouples things. The reader can send events quickly and they pile up in the queue if the process takes a little time to handle them. It smooths out bursts of activity and makes the system more resilient. If the process is busy,

Server on Windows server? The source explains biztok. RFID typically hosted its processes and providers inside IC Internet information services.

Like web applications.

Essentially, yes, yeah, each process often ran in its own IC application pool. This offer better reliability, security, and isolation compared to running directly as a service, especially in a production server environment. The programming model was the same, but the hosting was more robust on server got it.

And finally, on the process side, these different event processing modes transactional, reliable, express, what's the difference.

It's all about trade offs between reliability and speed. Transactional is the safest, every event is processed within a database transaction. If anything fails mid processing, the whole thing rolls back guaranteed processing, but slower due to the overhead.

Okay, maximum safety. Reliable mode relaxes the strict transaction per event, but still guarantees that once an event makes it to the queue, the system will try its best to process it, even if there are restarts better throughput than transactional.

A middle ground kind.

Of Then there's Express mode fast as possible minimal overhead events fly through, but if the system crashes at the wrong moment, you might lose events that were in flight. It prioritizes speed over guaranteed delivery. Good for scenarios where occasional data loss is acceptable, like maybe just updating a real time dashboard where the next update will correct it anyway.

So you choose base on how critical each individual event is. That's a clear explanation. The source then uses a cruise ship example that seems different.

Yeah, quite different. Guests get RFID wristbands, they use them to open their cabin doors, pay for drinks, access lounges.

Oh, like a magic key and wallet exactly.

But behind the scenes, the cruise line is potentially tracking movement patterns, maybe seeing which restaurants are busy, ensuring safety protocols are followed. It's RFID enhancing the customer experience and providing operational data shows the versatility beyond just boxes in a warehouse definitely okay.

Then the source dives back into the API side, programmatically controlling things. Process manager proxy, device manager proxy. Right.

These are dot net classes that let external applications talk to BizTalk RFID. You could write a separate dashboard application, for instance, that uses process manager proxy to start or stop RFID processes or maybe even inject test events. Device manager proxy lets you control the actual connected readers, get their status, change their settings programmatically, so you.

Build custom management tools or integrate control into other systems.

YEP, and the device connection class lets you establish a direct line to a reader and send specific commands like what kind of commands. The source lists standard ones defined by the interface, like get property to read a setting set property to change one read tag to trigger read write tag data to write to a tag's user memory, assuming the tag has user memory, right, and assuming the reader supports that command. Not all readers implement all commands.

Okay, and there's another simulator, the tag read Simulator application.

Yeah, this one's a graphical tool, not just contributed by files. It gives you a UI to easily generate simulated tag reads. You can type in tag IDs, choose how many click a button, and it sends those events to to a specified logical device in your BizTalk RFID setup. Really handy for quick tests or demos.

Got it and a quick mention of BizTalk RFID mobile for handhelds.

Right, an extension for building apps on well back then Windows mobile devices that had built in RFID readers. Think of a worker scanning items on a shelf with a handheld scanner running a custom BizTalk RFID mobile app. It even mentioned integrating bar code scanning into those mobile apps too.

Makes sense for mobile workforces. Then this TDTAPI tag data translation what's that about.

TDT is about standards, specifically the EPC Global Tag Data Standard. It's a library that helps you encode and decode the data on RFID tags according to that standard. Why is that important?

Interoperability so different company systems can understand each other's.

Tags exactly if everyone follows the standard, A tag commission by manufacturer A can be read and understood by retailer b's system. TDT helps translate the compact binary data on the tag into meaningful information like a product code, serial number, and vice versa. It also supports the idea of tags being somewhat self describing, reducing the need to always look up every single tag ID in a central database.

Crucial for making supply chains actually work across companies. Okay, almost there. Publishing events from BizTalk RFID to bistok server. Why do that extra.

Hop Because bistalk server is the big enterprise integration engine. Once you get the RFID data into bistalk server, you can do much more complex things with its sophisticated process orchestration, mapping data to completely different formats, connecting to hundreds of different systems using bistoks adapters, applying complex business.

Rules so bistok RFID handles the edge the device interaction, and BizTalk server handles the heavy lifting in the enterprise back end.

That's a good way to put it. The source shows how you could use a custom event handler in BizTalk rfid to send the event data over MSMP Microsoft message queuing to bistok server. Bistok server then just picks it up from the queue. Or you could use use a SQL adapter in bistalk server to pull data directly from the database that bistalk rfid was writing to.

And you could use the bistalk Business rule engine too. Yep.

Bistalk rfid had a component specifically for that, the Rules Engine Policy Executor. You could configure it to send RFID event data to the BRE, let the BRE evaluate complex rules against it, and get the results back to guide the RFID process flow more dynamic logic without hard coding it.

Okay, and SharePoint integration displaying RFID data in a portal, Yeah.

The idea was to make RFID information accessible. You could build SharePoint web parts that maybe showed a list of recent tag reads at a certain location or the status of RFID readers pulling data from BizTalk rfid using its APIs or web services embed RFID visibility into existing dashboards.

Got it. And the final case study tracking storage components in finance using both BizTalk RFID and server right.

This tied it all together. Tag sensitive items like backup tapes or hard drives, readers track them moving around a data center. BizTalk RFID captures the reads. It sends events to bistalk server. Bisktop server runs orchestrations that apply rules. Is this tape allowed to be in this area? Has it been out of the secure vault for too long? If a rule is violated, bistalk server triggers an alert, notifies security, a full end to end automated tracking and alerting system.

Wow, that really shows the power when you combine the real time physical tracking with the enterprise process smarts. It's clear even looking back at this two thousand nine material, the core value proposition of RFID, bridging that physical digital gap with automation speed accuracy is incredibly powerful, maybe even more relevant now.

I think so too, that ability to get real time automated data about physical assets is fundamental. It drives efficiency, better decisions, new services across so many areas.

So thinking about all that potential for you, the listener, where do you see this fitting considering that real time visibility, that data driven approach, What could RFID unlock in your world, in your endoe or just areas you find interesting. The possibilities seem vast.

Definitely worth pondering, and if specific parts of this spark your interest, do dive back into that source material you shared. It goes into much more technical depth on BizTalk RFID features, the APIs, the configurations, lots to explore there.

Absolutely and as always, let us know what you think. Any questions about rfid's applications, maybe things we didn't touch on, We'd love to hear them. Thanks for joining us on this deep dive.