WEBVTT 1 00:00:00.080 --> 00:00:02.480 Ever, just stop and think about how much stuff there 2 00:00:02.520 --> 00:00:04.400 is in the world, Yeah, and keeping track of it all, 3 00:00:04.599 --> 00:00:07.200 you know, from the apples and the supermarket to like 4 00:00:07.280 --> 00:00:10.480 parts for a satellite. It's a massive job. 5 00:00:10.480 --> 00:00:12.439 It really is. And that's where the tech we're digging 6 00:00:12.519 --> 00:00:17.480 into today comes in RFID radio frequency identification. 7 00:00:17.160 --> 00:00:19.960 Right, and you send us some really interesting material focused 8 00:00:20.000 --> 00:00:25.760 on pro RFID and BizTalk server two thousand and nine. Now, okay, 9 00:00:25.800 --> 00:00:27.239 biztalks evolves since O nine. 10 00:00:27.120 --> 00:00:31.000 Obviously, absolutely, but the core RFID concepts in there still 11 00:00:31.039 --> 00:00:33.600 incredibly relevant and gives a solid look at how you 12 00:00:33.640 --> 00:00:36.079 actually implement this stuff in a business. 13 00:00:36.280 --> 00:00:38.200 So at its heart, what is RFID? 14 00:00:38.560 --> 00:00:40.719 Just for a quick baseline, Okay, basically, it's a way 15 00:00:40.759 --> 00:00:44.359 to automatically ID objects using radio waves. You've got a 16 00:00:44.359 --> 00:00:46.640 reader right, sends out a signal, then there's a tag 17 00:00:46.640 --> 00:00:48.600 on the item. Here's the signal and talks. 18 00:00:48.399 --> 00:00:50.640 Back, and a computer sorts it all out exactly. 19 00:00:50.640 --> 00:00:53.320 It's like giving, I don't know every physical thing its 20 00:00:53.359 --> 00:00:54.920 own little digital voice. 21 00:00:54.920 --> 00:00:57.560 Got it. So our mission today really is to cut 22 00:00:57.560 --> 00:01:01.640 through the textbeak understand what RFID he actually does, why 23 00:01:01.679 --> 00:01:05.159 it matters, especially using this source material as our guide 24 00:01:05.480 --> 00:01:08.560 which seems to cover everything from the real basics up 25 00:01:08.599 --> 00:01:10.159 to the nuts and bolts of using it with biz 26 00:01:10.159 --> 00:01:11.079 talk two thousand and nine. 27 00:01:11.200 --> 00:01:13.599 Yep, let's maybe start with some context, like how did 28 00:01:13.640 --> 00:01:16.599 we even track things before all this fancy radio stuff. 29 00:01:16.640 --> 00:01:19.239 Well, for ages, it was just looking at stuff, right. 30 00:01:19.359 --> 00:01:21.840 The source calls it the mark one mod zero eyeball, 31 00:01:22.319 --> 00:01:23.640 you just saw it, you knew what it was. 32 00:01:23.760 --> 00:01:27.439 Ah, yeah, pretty much. Then paper a Ledgers obviously trying 33 00:01:27.439 --> 00:01:28.159 to scale that up. 34 00:01:28.239 --> 00:01:30.640 Yeah, imagine trying to run a supermarket just by memory, 35 00:01:31.000 --> 00:01:35.120 the cashier knowing every single price impossible, so much room 36 00:01:35.159 --> 00:01:36.480 for air, so slow. 37 00:01:36.319 --> 00:01:39.040 That human element, that manual data entry, that was always 38 00:01:39.079 --> 00:01:43.439 the bottleneck. Then late sixties bar codes came along, big step. 39 00:01:43.359 --> 00:01:46.760 Huge, using lasers, right, suddenly you could scan something. Boom, 40 00:01:46.799 --> 00:01:49.079 digital info pops up. We see them everywhere. 41 00:01:48.719 --> 00:01:51.719 Now, totally change the game. But bar codes, yeah, they 42 00:01:51.760 --> 00:01:53.480 have that one limitation line of sight. 43 00:01:54.280 --> 00:01:56.599 You have to physically point the scanner at the barcode, 44 00:01:56.719 --> 00:01:57.480 make sure it can. 45 00:01:57.400 --> 00:02:01.920 See it clearly, exactly, And that's where RFID really shines. 46 00:02:01.959 --> 00:02:04.319 As the source points out, no line of sight needed. 47 00:02:04.760 --> 00:02:07.799 You can read these tags right through cardboard boxes, plastic 48 00:02:07.799 --> 00:02:08.719 crates even. 49 00:02:08.520 --> 00:02:11.680 Some wood, so like stuff flying down a conveyor belt, 50 00:02:12.599 --> 00:02:15.280 doesn't matter. If the tag is facing the wrong way, pretty. 51 00:02:15.039 --> 00:02:17.520 Much, the reader can often still pick it up. It's 52 00:02:17.599 --> 00:02:19.080 using radio waves, not late. 53 00:02:19.199 --> 00:02:23.240 Okay, let's break that down. How does that radio conversation 54 00:02:23.400 --> 00:02:26.560 actually happen between the reader and the tag? 55 00:02:26.719 --> 00:02:29.280 Right, So the reader starts it. It sends out a 56 00:02:29.360 --> 00:02:32.719 radio wave using its antenna at a specific frequency, and. 57 00:02:32.680 --> 00:02:33.919 The tag has an antenna too. 58 00:02:34.080 --> 00:02:37.319 Yep, the tag's antenna picks up that energy from the 59 00:02:37.360 --> 00:02:40.280 reader's signal. Now, if it's a passive tag and most far, 60 00:02:40.639 --> 00:02:43.719 that radio wave actually powers up the little chip inside 61 00:02:43.840 --> 00:02:44.159 the tag. 62 00:02:44.240 --> 00:02:47.000 Whoa Okay, so the reader beam literally wakes. 63 00:02:46.680 --> 00:02:48.919 The tag up, kind of gives it just enough juice 64 00:02:48.919 --> 00:02:51.000 to operate for a moment. Then the reader might send 65 00:02:51.000 --> 00:02:53.599 a command on that wave, like hey, who are you? Huh? 66 00:02:53.840 --> 00:02:56.639 If the tag gets the command, it uses that energy 67 00:02:56.680 --> 00:02:59.439 it just collected to send back its stored info, usually 68 00:02:59.439 --> 00:03:02.840 it's unique ID number, modulating it onto its own radio 69 00:03:02.879 --> 00:03:03.840 wave signal. 70 00:03:03.639 --> 00:03:07.080 Which the reader then picks up. Got it now, the 71 00:03:07.159 --> 00:03:11.039 source mentioned different kinds of RFID, different frequencies. Why so many? 72 00:03:11.199 --> 00:03:14.719 Ah? Yeah, the frequency affects things like how far away 73 00:03:14.759 --> 00:03:17.800 you can read. The read range also affects how much 74 00:03:17.879 --> 00:03:19.520 data you can send back and forth, and how well 75 00:03:19.520 --> 00:03:21.680 it works around things like metal and liquids, which can 76 00:03:21.759 --> 00:03:25.599 sometimes interfere. Okay, and you mentioned passive tags. There are 77 00:03:25.599 --> 00:03:28.719 also active tags. These guys have their own little battery. 78 00:03:28.479 --> 00:03:31.199 Ah, so they don't rely on the reader's energy. Right. 79 00:03:31.639 --> 00:03:34.080 Means they can be read from much further away, sometimes 80 00:03:34.159 --> 00:03:37.479 hundreds of feet, and they can power other things like sensors, 81 00:03:37.479 --> 00:03:39.280 maybe temperature sensors or something. 82 00:03:39.319 --> 00:03:41.599 But I guess they're more expensive and the battery runs 83 00:03:41.599 --> 00:03:42.599 out eventually. 84 00:03:42.360 --> 00:03:46.960 Exactly trade offs. Passive tags are cheaper, last basically forever, 85 00:03:47.039 --> 00:03:51.000 but shorter range. Active tags longer range, more capabilities, but 86 00:03:51.080 --> 00:03:54.719 cost more and have a limited lifespan. You pick what 87 00:03:54.759 --> 00:03:55.879 fixed The job makes. 88 00:03:55.759 --> 00:03:58.599 Sense and it's not always just reading one tag, right, Yeah, 89 00:03:58.599 --> 00:04:01.360 I remember reading about scanning. Yeah, like a whole palette 90 00:04:01.360 --> 00:04:02.280 of boxes at once. 91 00:04:02.800 --> 00:04:07.360 Yes, that's a huge advantage anti collision. It's a key concept. 92 00:04:07.960 --> 00:04:10.840 Imagine that palette, maybe fifty boxes, each with a tag. 93 00:04:11.560 --> 00:04:14.800 A reader at a doorway can ideally read all fifty 94 00:04:14.879 --> 00:04:16.560 tags as the palette goes through. 95 00:04:17.240 --> 00:04:19.680 How does it avoid just getting a garbled mess of 96 00:04:19.680 --> 00:04:21.040 signals all talking at once. 97 00:04:21.399 --> 00:04:23.920 Clever algorithms. It's a bit like you know how you're 98 00:04:23.959 --> 00:04:27.000 a Wi Fi router manages lots of devices talking. The 99 00:04:27.040 --> 00:04:30.160 reader manages the conversation telling tags in effect to speak 100 00:04:30.160 --> 00:04:32.959 one at a time or in small groups very very quickly, 101 00:04:33.079 --> 00:04:35.600 so it can identify all of them without the signals 102 00:04:35.600 --> 00:04:36.680 crashing into each other. 103 00:04:36.839 --> 00:04:40.639 Wow. Okay, that sounds incredibly efficient for logistics. So what 104 00:04:40.720 --> 00:04:42.600 kind of info is actually on these tags? Is it 105 00:04:42.639 --> 00:04:43.480 just a serial number? 106 00:04:43.759 --> 00:04:46.600 It varies a lot. Some basic tags might just have 107 00:04:46.680 --> 00:04:49.399 a globally unique idea like an MT address for a 108 00:04:49.399 --> 00:04:52.519 physical object. That's often enough just to know which specific 109 00:04:52.600 --> 00:04:55.519 item it is, right. But other tags, especially where more 110 00:04:55.560 --> 00:04:58.199 expensive ones, can have user memory, You can write other 111 00:04:58.319 --> 00:05:02.079 data to them, maybe the product code, manufacturing date, batch number, 112 00:05:02.720 --> 00:05:04.720 even maintenance history potentially and. 113 00:05:04.680 --> 00:05:07.480 The source mentioned. Commissioning is a loading this data onto 114 00:05:07.480 --> 00:05:08.720 the tag pretty much. 115 00:05:08.920 --> 00:05:11.600 Commissioning is that initial step where you write this specific 116 00:05:11.680 --> 00:05:14.199 data onto a tag and associate it in your system. 117 00:05:14.480 --> 00:05:17.399 You're giving the tag its identity for your application, and 118 00:05:17.560 --> 00:05:20.839 groups like GS one and EPC Global are working hard 119 00:05:20.879 --> 00:05:24.199 on standards for this data like the EPC standards, so 120 00:05:24.199 --> 00:05:27.560 everyone speaking the same language, similar to how UPC barcodes work. 121 00:05:27.759 --> 00:05:30.079 So it's not just this is a box of widgets, 122 00:05:30.079 --> 00:05:33.439 it's this is this specific box of widgets made on Tuesday, 123 00:05:33.720 --> 00:05:34.759 expiring next year. 124 00:05:35.079 --> 00:05:39.600 Huge for traceability, absolutely, things like recalls, warranty tracking, authentication. 125 00:05:40.199 --> 00:05:43.399 It opens up a lot. And the source also quickly 126 00:05:43.439 --> 00:05:48.480 mentions antenna's linear versus circular polarization that affects read reliability too, 127 00:05:48.879 --> 00:05:52.199 especially the further away you get with UAGEF frequencies. But 128 00:05:52.279 --> 00:05:53.680 maybe that's getting a bit deep for now. 129 00:05:53.759 --> 00:05:56.079 Okay, Yeah, let's maybe stick to the core ideas. For now, 130 00:05:56.120 --> 00:05:59.399 we've talked anti collision tag types. Let's circle back to 131 00:05:59.480 --> 00:05:59.800 that tag. 132 00:06:00.560 --> 00:06:02.800 Sure. So, like we said, memory varies, and there's a 133 00:06:02.839 --> 00:06:05.560 direct link usually between how much memory tag has and 134 00:06:05.600 --> 00:06:06.519 how much it costs. 135 00:06:06.600 --> 00:06:07.959 Right, more memory, more money. 136 00:06:08.240 --> 00:06:11.879 Yeah, So if you're tracking, say a critical jet engine part, 137 00:06:12.160 --> 00:06:14.319 you might splurge on a high memory tag to store 138 00:06:14.360 --> 00:06:17.839 its entire maintenance log directly on the part. Super valuable data. 139 00:06:17.920 --> 00:06:20.519 Right there makes sense, expensive part critical data. 140 00:06:20.560 --> 00:06:23.120 But if you're tracking I don't know, millions of pairs 141 00:06:23.120 --> 00:06:26.800 of socks for a retailer, tag cost is king. You'll 142 00:06:26.879 --> 00:06:29.560 use the cheapest possible tag with maybe just that unique 143 00:06:29.600 --> 00:06:32.319 ID number. You store all the other details about the 144 00:06:32.360 --> 00:06:34.560 sock in a database link to that ID. 145 00:06:34.839 --> 00:06:37.680 Gotcha. You wouldn't put the socks washing instructions on the 146 00:06:37.800 --> 00:06:39.079 RFID tag itself. 147 00:06:39.279 --> 00:06:42.360 Probably not. And that commissioning step we mentioned, that's where 148 00:06:42.360 --> 00:06:44.439 you write that unique ID to the sock tag and 149 00:06:44.519 --> 00:06:47.040 link it in your database to pair of blue socks 150 00:06:47.079 --> 00:06:50.639 size tens KIU one two, three, four five. It activates 151 00:06:50.680 --> 00:06:51.879 the tag within your system. 152 00:06:52.120 --> 00:06:56.079 Okay, So with all this tech reading through boxes, unique IDs, 153 00:06:56.519 --> 00:06:59.920 anti collision, what's the real bottom line? The source scene 154 00:07:00.160 --> 00:07:02.000 keen to manage expectations a bit. 155 00:07:02.199 --> 00:07:04.600 Yeah, it makes a good point. RFID doesn't really let 156 00:07:04.600 --> 00:07:07.240 you do things that were fundamentally impossible before. I mean, 157 00:07:07.240 --> 00:07:10.279 you could theoretically have someone manually inspect and log every 158 00:07:10.319 --> 00:07:12.279 single item entering a warehouse. 159 00:07:12.160 --> 00:07:15.439 Theoretically, yeah, but it would be painfully slow and full 160 00:07:15.439 --> 00:07:16.720 of mistakes exactly. 161 00:07:16.759 --> 00:07:20.839 That's the key. RFID takes processes that were possible but 162 00:07:20.959 --> 00:07:24.879 maybe impractical, slow or error prone, and makes them feasible. 163 00:07:25.279 --> 00:07:28.720 It automates them, makes them faster, way more accurate, and scalable. 164 00:07:28.800 --> 00:07:31.519 So debut efficiency and accuracy gains through automation. 165 00:07:31.680 --> 00:07:36.839 Precisely. Take that warehouse receiving example, manual check slow mistakes happen. 166 00:07:37.000 --> 00:07:41.279 RFID a palette rolls through a portal reader, scans dozens 167 00:07:41.360 --> 00:07:44.360 or hundreds of items, and seconds instantly verifies against the 168 00:07:44.399 --> 00:07:48.120 shipping notice, updates, inventory boom. 169 00:07:47.399 --> 00:07:49.759 Minimal human intervention, real time data. Right. 170 00:07:50.000 --> 00:07:52.639 So, whether you're using eyeballs or a barcode scanner or 171 00:07:52.680 --> 00:07:55.680 an RFID reader, the goal is the same, connect the 172 00:07:55.680 --> 00:07:59.279 physical item to its digital record. RFID just provide a much, 173 00:07:59.360 --> 00:08:02.279 much faster, more automated, and often richer way to make 174 00:08:02.279 --> 00:08:02.759 that connection. 175 00:08:02.920 --> 00:08:04.959 Okay, so where's this paying off the most? Where's the 176 00:08:04.959 --> 00:08:06.040 adoption really happening? 177 00:08:06.360 --> 00:08:09.120 Well, according to the source, supply chain is huge, tracking 178 00:08:09.160 --> 00:08:12.000 goods from factory through distribution centers all the way to 179 00:08:12.040 --> 00:08:14.639 the store shelf at palette level, case level, sometimes even 180 00:08:14.680 --> 00:08:17.399 item level. Big visibility improvements. 181 00:08:16.879 --> 00:08:18.839 There, and retail seems to be catching. 182 00:08:18.560 --> 00:08:21.160 On too, definitely. Retailers are using it more and more 183 00:08:21.199 --> 00:08:24.079 for inventory accuracy. Knowing what you actually have on the 184 00:08:24.120 --> 00:08:27.519 shelves and in the back room helps prevent empty shelves. 185 00:08:27.560 --> 00:08:30.720 You know, out of stocks also helps reduce lost or 186 00:08:30.759 --> 00:08:33.399 stolen items. It can be more informative than just those 187 00:08:33.440 --> 00:08:34.679 basic anti theft. 188 00:08:34.440 --> 00:08:37.679 Tags, right because you know which specific item went missing, 189 00:08:37.759 --> 00:08:40.639 not just that something beat exactly. Okay, So let's pivot 190 00:08:40.639 --> 00:08:45.120 to the specific focus of the source. BizTalk RFID two 191 00:08:45.159 --> 00:08:48.559 thousand and nine now again acknowledging the date. What was 192 00:08:48.600 --> 00:08:51.000 the core idea behind this platform? 193 00:08:51.159 --> 00:08:54.919 BizTalk RFID back then was Microsoft's answer from managing these 194 00:08:55.039 --> 00:08:58.600 RFID systems in a business context. The source use is 195 00:08:58.600 --> 00:09:01.399 a pretty cool analogy. It's like trying to assign IP 196 00:09:01.519 --> 00:09:03.879 addresses to every object in the real world. But from 197 00:09:03.879 --> 00:09:07.480 the hardware view, bistok RFID was the software layer on 198 00:09:07.519 --> 00:09:07.960 top of that. 199 00:09:08.039 --> 00:09:09.960 So it connects to the readers, gets the data. 200 00:09:10.200 --> 00:09:12.919 Yeah, it connects to all sorts of different RFID readers, printers, 201 00:09:12.960 --> 00:09:16.519 other devices. It processes the raw tag data coming in 202 00:09:16.559 --> 00:09:18.759 and then helps you integrate that data with your other 203 00:09:18.799 --> 00:09:21.840 business systems, your inventory system, your ERP. 204 00:09:21.919 --> 00:09:24.840 Whatever, the software brain making sense of the radio signal. 205 00:09:25.000 --> 00:09:27.759 You got it. The source shows this architecture right with 206 00:09:27.960 --> 00:09:31.320 logical devices, ways to connect to bistalk server itself or 207 00:09:31.480 --> 00:09:35.960 SQL databases, and this event driven model for building specific 208 00:09:36.200 --> 00:09:40.080 RFID business processes. It aimed to provide a structured way 209 00:09:40.120 --> 00:09:43.080 to handle all that RFID data flowing in, and it had. 210 00:09:43.000 --> 00:09:44.919 A layered architecture. What did that look like? 211 00:09:45.039 --> 00:09:47.919 Broadly, think of it like stacks. Down at the bottom 212 00:09:48.039 --> 00:09:51.399 the actual physical readers and tags. Then a layer called 213 00:09:51.600 --> 00:09:56.159 device providers basically drivers software bits that let bistalk RFID 214 00:09:56.600 --> 00:10:00.519 talk to specific hardware models. Okay, above that the main 215 00:10:00.559 --> 00:10:04.960 bistok RFID engine managing the devices, processing the events. And 216 00:10:05.000 --> 00:10:07.159 then at the top the business logic you build your 217 00:10:07.240 --> 00:10:10.080 RFID processes that decide what to do with the tag reads. 218 00:10:10.480 --> 00:10:13.679 The source mentions these things called knobs exposed as properties 219 00:10:13.720 --> 00:10:15.320 for devices sounds intriguing. 220 00:10:15.480 --> 00:10:19.240 Yeah, that's about controlling the reader hardware. Bistok RFID assumed 221 00:10:19.279 --> 00:10:22.360 readers have settings you can tweak network settings, radio power, 222 00:10:22.480 --> 00:10:26.000 maybe antenna configurations. It tried to expose these settings as 223 00:10:26.039 --> 00:10:30.000 properties you could adjust right from the bistok RFID software, so. 224 00:10:30.000 --> 00:10:32.200 You could fine tune the reader's behavior remotely. 225 00:10:32.399 --> 00:10:35.399 That was the idea. The source notes though that how 226 00:10:35.440 --> 00:10:38.720 many knobs you actually got depended on how good the 227 00:10:38.840 --> 00:10:42.919 device provider software was for that specific reader, and some 228 00:10:43.039 --> 00:10:46.519 settings might reset if the reader rebooted while others would stick. 229 00:10:46.679 --> 00:10:50.240 Gotcha. And then there's this difference between physical device names 230 00:10:50.559 --> 00:10:53.120 and logical devices. Why separate them? 231 00:10:53.320 --> 00:10:57.360 Ah, that's actually a really useful abstraction. A logical device 232 00:10:57.480 --> 00:11:00.000 is like a placeholder name you use inside your business 233 00:11:00.120 --> 00:11:03.960 talk RFID process. Like warehouse door reader. It's not the 234 00:11:04.000 --> 00:11:06.960 actual IP aggress or serial number of the physical reader. 235 00:11:07.000 --> 00:11:08.559 Okay, so it's a nickname sort of. 236 00:11:09.080 --> 00:11:13.200 Then separately, you bind that logical name warehouse door Reader 237 00:11:13.440 --> 00:11:17.039 to the actual physical reader hardware installed at the warehouse door. 238 00:11:17.399 --> 00:11:20.000 Why bother with the extra step flexibility? 239 00:11:20.120 --> 00:11:22.720 Say that physical reader breaks, you replace it with a 240 00:11:22.720 --> 00:11:26.399 new one, maybe even a slightly different model. If it's compatible. 241 00:11:26.440 --> 00:11:28.840 You might just need to update the binding point the 242 00:11:28.879 --> 00:11:31.600 logical name warehouse door Reader to the new physical reader. 243 00:11:32.200 --> 00:11:37.480 Your actual RFID business process code doesn't necessarily need to change. 244 00:11:37.559 --> 00:11:40.320 It insulates your logic from the specific hardware. 245 00:11:40.600 --> 00:11:44.879 I see. That makes maintenance and upgrades much easier. Smart okay, sok. 246 00:11:45.039 --> 00:11:49.000 RFID provides this framework, what about actually managing it? The 247 00:11:49.039 --> 00:11:51.080 source mentions r FID manager. 248 00:11:51.399 --> 00:11:54.799 Right, RFID manager was the main graphical tool the GUI 249 00:11:55.039 --> 00:11:58.480 for administering bis talk RFID. It's where you'd register those 250 00:11:58.559 --> 00:12:02.240 device providers, add your physical readers, organize them, and configure 251 00:12:02.279 --> 00:12:06.320 the RFID business processes themselves the command center pretty much. 252 00:12:06.360 --> 00:12:08.240 The Source does mention a little quirk sometimes you had 253 00:12:08.240 --> 00:12:10.559 to manually hit refresh to see the latest status. Updates 254 00:12:10.559 --> 00:12:12.200 in the manager tool wasn't always real. 255 00:12:12.080 --> 00:12:15.480 Time h okay, goodl manual refresh. So what could you 256 00:12:15.519 --> 00:12:18.600 actually do an RFID manager besides adding devices? 257 00:12:18.960 --> 00:12:22.399 Well, you could connect to your local BizTalk RFID server 258 00:12:22.720 --> 00:12:27.039 or manage remote ones. You could group devices logically, maybe 259 00:12:27.120 --> 00:12:31.000 west wing readers shipping dock readers. You could also import 260 00:12:31.080 --> 00:12:33.840 and export device configurations. 261 00:12:33.080 --> 00:12:35.399 Oh like for backups or setting up another server the 262 00:12:35.399 --> 00:12:36.360 same way exactly. 263 00:12:36.399 --> 00:12:40.879 And one really neat feature highlighted was device property versioning. 264 00:12:40.600 --> 00:12:43.600 Version like Source control for reader settings. 265 00:12:43.360 --> 00:12:46.639 Kind of RFID manager kept a history of changes made 266 00:12:46.720 --> 00:12:49.519 to device properties. So if you tweaked, say the radio 267 00:12:49.600 --> 00:12:51.919 power on a reader, and things stopped working, well you 268 00:12:51.919 --> 00:12:54.840 could look back see exactly what changed and easily roll 269 00:12:54.919 --> 00:12:58.279 back to a previous configuration. The source had an example 270 00:12:58.320 --> 00:13:01.759 of changing a reader's location property and then undoing it. 271 00:13:01.879 --> 00:13:05.360 That sounds super useful for troubleshooting, like an undoe button 272 00:13:05.360 --> 00:13:07.840 for your hardware settings. Yeah. Can you also change how 273 00:13:07.919 --> 00:13:09.799 processes are connected the bindings in there? 274 00:13:09.919 --> 00:13:12.360 Yep. When a process was stopped, you could go into 275 00:13:12.480 --> 00:13:15.639 RFID manager and change which logical devices it listens to 276 00:13:16.080 --> 00:13:18.840 or which software components it uses. There was a wizard 277 00:13:18.840 --> 00:13:21.639 to help, or you could edit the raw binding files 278 00:13:21.639 --> 00:13:22.320 if you needed to. 279 00:13:22.720 --> 00:13:26.879 Okay. The source uses a warehouse exegate example to show 280 00:13:26.879 --> 00:13:28.840 how a process works. Can you walk through that? 281 00:13:29.039 --> 00:13:32.600 Sure? So picture an RFID reader over the exit door 282 00:13:32.600 --> 00:13:36.000 of a warehouse. The goal is when a palette with 283 00:13:36.120 --> 00:13:39.639 tag items goes out, automatically confirm it shipped. Right in 284 00:13:39.679 --> 00:13:43.159 bistok RFID, you'd build a process. This process would be 285 00:13:43.159 --> 00:13:46.000 configured to listen for tag reads coming only from the 286 00:13:46.039 --> 00:13:49.399 logical device bound to that exit gate reader. When a 287 00:13:49.519 --> 00:13:51.639 tag or a list of tags from the palette is 288 00:13:51.720 --> 00:13:55.960 read by that specific reader, an event handler component inside 289 00:13:55.960 --> 00:13:59.559 your process gets triggered. This component takes the tag data 290 00:13:59.559 --> 00:14:03.000 and does something maybe calls a web service, updates a database, 291 00:14:03.120 --> 00:14:05.919 sends a message to the shipping system saying this pallette 292 00:14:05.960 --> 00:14:06.399 just left. 293 00:14:06.559 --> 00:14:09.080 So the process is like the little automated agent watching 294 00:14:09.080 --> 00:14:11.639 that door. Yeah, and the binding tells it which physical 295 00:14:11.679 --> 00:14:12.039 door to. 296 00:14:12.000 --> 00:14:15.399 Watch exactly right. The binding connects the abstract idea in 297 00:14:15.440 --> 00:14:18.519 your process, the exit gate reader, to the actual piece 298 00:14:18.519 --> 00:14:21.200 of hardware bolted to the wall. Data flows from the 299 00:14:21.200 --> 00:14:24.279 physical reader through the binding to the correct logical device 300 00:14:24.320 --> 00:14:26.159 in your process, triggering your logic. 301 00:14:26.399 --> 00:14:30.200 You mentioned components and event handlers. What are those exactly 302 00:14:30.240 --> 00:14:31.159 within a process? 303 00:14:31.720 --> 00:14:34.440 Think of them as plug ins or building blocks for 304 00:14:34.519 --> 00:14:38.559 your process. They do specific jobs when an RFID event happens. 305 00:14:39.000 --> 00:14:42.080 The source gives a good example. A SQL server sink 306 00:14:42.320 --> 00:14:43.240 component that's. 307 00:14:43.080 --> 00:14:46.799 What it sounds like, writes data to SQL precisely. 308 00:14:47.120 --> 00:14:50.159 You drop this component into your process pipeline. When a 309 00:14:50.200 --> 00:14:53.320 tag read event comes through, this component automatically takes the 310 00:14:53.399 --> 00:14:57.360 data tag id, timestamp, reader name, et cetera, and inserts 311 00:14:57.399 --> 00:15:00.759 it into a specified table in your SEQL server day dtabase. 312 00:15:00.639 --> 00:15:02.679 Handy, and you could write your own custom ones. 313 00:15:02.840 --> 00:15:06.159 Yes, absolutely. Those are often called event handlers. They're basically 314 00:15:06.240 --> 00:15:09.399 snippets of dot Net code you write to perform any 315 00:15:09.399 --> 00:15:13.120 custom logic you need, maybe complex validation calling a specific 316 00:15:13.120 --> 00:15:17.080 internal system whatever. The component model makes processes modular u lets. 317 00:15:17.159 --> 00:15:18.519 You reuse common bits. 318 00:15:18.279 --> 00:15:21.000 Of logic, and you'd manage adding and configuring these components 319 00:15:21.039 --> 00:15:23.600 like the sql sinc using RFID manager too. 320 00:15:23.639 --> 00:15:27.279 Correct, you'd register any custom components, then drag and drop 321 00:15:27.320 --> 00:15:30.720 them into your process design and RFID manager and configure 322 00:15:30.759 --> 00:15:34.039 their settings like the database connection string for the SQL SINC. 323 00:15:34.399 --> 00:15:38.080 Okay, Now, what if you don't have physical RFID readers 324 00:15:38.159 --> 00:15:42.759 lying around, but you want to build and test these processes. 325 00:15:43.159 --> 00:15:44.639 The source mentions a simulator. 326 00:15:44.720 --> 00:15:48.200 Yeah, the device simulator in the SDK super valuable for 327 00:15:48.240 --> 00:15:50.919 development and testing. It lets you pretend to be one 328 00:15:51.120 --> 00:15:55.159 or more RFID readers, generating fake tag read events, all 329 00:15:55.200 --> 00:15:56.440 in software. 330 00:15:56.080 --> 00:15:57.840 So you don't need the hardware budget just to get 331 00:15:57.840 --> 00:15:58.879 started exactly. 332 00:15:58.960 --> 00:16:01.600 You can configure it through files, tell it how many 333 00:16:01.679 --> 00:16:04.720 fake readers to create, what IP addresses and ports they 334 00:16:04.720 --> 00:16:07.600 should pretend to use, how often they should see tags, 335 00:16:07.639 --> 00:16:09.720 what the tag data should look like, so. 336 00:16:09.639 --> 00:16:12.559 You can simulate different scenarios like lots of tags appearing 337 00:16:12.600 --> 00:16:14.720 at once or tags appearing intermittently. 338 00:16:14.879 --> 00:16:18.080 Yep, you can define the notification behavior, send tags one 339 00:16:18.120 --> 00:16:21.320 by one, send them in batches, tagless events, control the timing. 340 00:16:21.759 --> 00:16:25.000 The source even points to a ready made Contoso simulator 341 00:16:25.080 --> 00:16:28.200 example in the SDK to get you started quickly. You 342 00:16:28.240 --> 00:16:31.120 can fire that up and immediately have simulated tag data 343 00:16:31.120 --> 00:16:34.120 flowing into your BizTalk. RFID processes for testing. 344 00:16:34.279 --> 00:16:36.960 Very cool, like a virtual RFID lab. And the SO 345 00:16:37.039 --> 00:16:39.279 has tied this back to a simple retail case study. 346 00:16:39.559 --> 00:16:44.639 Right, just a basic example. Imagine high value electronics tagged 347 00:16:44.679 --> 00:16:47.639 in a store. Reader at the exit logs every time 348 00:16:47.639 --> 00:16:50.279 one of these tags passes through, that data goes to 349 00:16:50.320 --> 00:16:53.440 a central system, maybe using that SEQL sync. Okay, just 350 00:16:53.440 --> 00:16:57.000 by logging those exits, the retailer gets basic business intelligence. 351 00:16:57.360 --> 00:17:00.440 How many expensive TVs left the store today, any leave 352 00:17:00.480 --> 00:17:04.200 outside of transaction hours. It's simple tracking, but gives real 353 00:17:04.200 --> 00:17:07.279 time visibility that can help with inventory, maybe spot potential 354 00:17:07.359 --> 00:17:09.680 theft patterns, or even trigger real time alerts. 355 00:17:09.920 --> 00:17:12.400 Taking the raw reads and turning them into useful info 356 00:17:12.640 --> 00:17:14.960 makes sense. And there was also a command line tool 357 00:17:15.160 --> 00:17:16.920 RFID client Console. 358 00:17:16.640 --> 00:17:20.400 Yeah, URFID Clientconsole dot exe for folks who prefer command 359 00:17:20.400 --> 00:17:23.279 lines or need to script administrative tasks. It offered another 360 00:17:23.279 --> 00:17:26.480 way to manage providers, devices and processes, doing much of 361 00:17:26.519 --> 00:17:28.039 what RFID Manager could do. 362 00:17:28.720 --> 00:17:31.759 But text base okay, handy for automation. Yeah, Now for 363 00:17:31.799 --> 00:17:34.279 the developers listening, the source gets into coding aspects. It 364 00:17:34.319 --> 00:17:36.880 mentions a base class r FAD event handler base. 365 00:17:37.359 --> 00:17:40.680 Right, if you're writing those custom components, those event handlers 366 00:17:40.720 --> 00:17:43.880 we talked about, you'd typically create a dot net class 367 00:17:43.920 --> 00:17:47.240 that inherits from our fit event handerbase. This gives you 368 00:17:47.319 --> 00:17:51.240 the framework the necessary methods to plug into the BizTalk 369 00:17:51.400 --> 00:17:55.400 RFID run time, banken init methods exactly. The init method 370 00:17:55.400 --> 00:17:57.839 gets called when your handler starts up. It's where you'd 371 00:17:57.839 --> 00:18:01.000 grab any configuration settings you define for your component in 372 00:18:01.200 --> 00:18:04.799 RFID manager, like maybe a threshold value or web service 373 00:18:05.000 --> 00:18:06.240 URL needs to call. 374 00:18:06.119 --> 00:18:08.559 And the source stress keeping these handlers fast. 375 00:18:08.640 --> 00:18:11.759 Oh yeah, critical point. The methods in your event handler 376 00:18:11.759 --> 00:18:14.160 that actually process the tag reeds need to be quick, 377 00:18:14.640 --> 00:18:18.839 avoid long database calls, complex calculations, or anything that blocks 378 00:18:18.880 --> 00:18:20.960 the processing thread for a long time. Why is that 379 00:18:20.960 --> 00:18:25.039 so important Because bistok RFID is trying to process potentially 380 00:18:25.200 --> 00:18:28.200 hundreds or thousands of tag reads per second. If your 381 00:18:28.200 --> 00:18:31.039 custom code takes a half a second for every tag, 382 00:18:31.240 --> 00:18:34.559 you'll create a massive bottleneck. The whole system slows down. 383 00:18:34.920 --> 00:18:37.480 It's much better to do quick processing in the handler 384 00:18:37.480 --> 00:18:40.440 and maybe hand off longer tasks to a separate background 385 00:18:40.480 --> 00:18:41.240 service or que. 386 00:18:41.519 --> 00:18:44.079 Got it, keep it lean and mean in the main 387 00:18:44.079 --> 00:18:47.279 event pass. What about this deploy static method? When is 388 00:18:47.319 --> 00:18:47.920 that used? 389 00:18:48.319 --> 00:18:51.200 That's for setup tasks. If your event handler needs something 390 00:18:51.240 --> 00:18:54.960 done once when the RFID process is first deployed or updated, 391 00:18:54.960 --> 00:18:58.160 maybe creating a specific database table it needs to write to, 392 00:18:58.680 --> 00:19:01.839 or registering something with the operating system, you'd put that 393 00:19:01.960 --> 00:19:04.880 logic in the static deploy method. The runtime calls it 394 00:19:04.920 --> 00:19:06.359 automatically during deployment. 395 00:19:06.480 --> 00:19:10.279 Okay for one time initialization. And how does bistalk RFID 396 00:19:10.440 --> 00:19:13.640 handle the different kinds of data coming from readers, taglists, 397 00:19:13.799 --> 00:19:16.160 single reads source mentioned strong taping. 398 00:19:16.400 --> 00:19:18.920 Yeah, it uses a strongly typed event system. When you 399 00:19:18.960 --> 00:19:22.440 build your process, your event handlers declare what specific type 400 00:19:22.440 --> 00:19:25.000 of event they expect, like a tag rate event, a 401 00:19:25.039 --> 00:19:27.799