Azure Service Bus Topics and Queues

hello world and welcome to this edition of tech on fire with blaze and blaze stewart architect at winelike today we'll be looking at topics and cues for azure service bus [Music] [Music] hi guys today we'll be looking at azure service bus and looking at topics and cues specifically we'll be looking at it from the application perspective but this thing will integrate with a number of other things on azure we're primarily going to be looking at creating topics and cues today and then creating publishers and subscribers so we can get a handle on what it does and kind of how it works and we'll look at some more advanced use cases in future videos so when we talk about azure surface bus there's really two ways to send messages and that's with cues and topics and the most fundamental one is cues it's pretty straightforward we have a queue and if we want to send a message between a publisher and subscriber we use the queue so a publisher sometimes called a sender is going to have one message that's going to create and on the other end of that queue is going to be a subscriber the publisher will originate the message and then we'll put it onto the queue now the subscriber may or may not be there at the time that message is being sent so this allows the publisher to send up as many messages as the queue can hold until the subscriber connects to that queue and then starts moving those messages off the queue and processing them this is an asynchronous message pattern meaning that it allows the publisher to send something to the subscriber without the subscriber actually being there to receive it with http we do that in a more synchronous mode where we expect a response back from a client that's requesting something across the wire with the queue we don't necessarily expect something right away at the time of sending you can send messages back to another queue and then have the publisher also be a subscriber and the subscriber be a publisher and you can get two-way communication that way you can use correlation ids to correlate messages but fundamentally this is how it works where a publisher sends something to a queue it waits on the queue until the subscriber connects and then processes that message so service bus topics are a lot like hues the basically the major difference is it's one to many so we're going to have a topic and a publisher and the topic works a lot like the queue does where the publisher can publish to the topic but instead of having essentially just one listener or one-to-one correspondence between a message that's sent to the queue and then read from the queue we can have multiple subscriptions to a topic so that basically means that every subscription will get their own copy of the message from the publisher and then each subscription can have their own subscriber so what happens then in this case is the publisher will create a message put it onto the topic and then the topic will create a copy for each subscription and then once the subscription has the message each subscriber can then receive the message independent of other subscribers against their own subscription so it's very straightforward it's just basically multiplying the message against multiple receivers with a single sender so i'm here in the azure portal this is my service bus that i've set up it's service bus namespace and i have attached to it a queue and a topic and my queue is the one i want to look at first and this is a very straightforward example here so i just created a cue by clicking create a queue and you can do this programmatically too you don't have to do it in the portal but you give it a name and it's got a lot of different options here like it enabled duplication detection which is nice and you can enable sessions enable partition you do a lot of different things which we'll get to in more in-depth videos at a future date but for simplicity we're just going to set a name and call it myq and i basically just took the defaults in this and for many cases that's probably good enough for some things but for my case i'm just going to leave it like that currently i have five messages on this queue because when i was writing the apps i was writing some messages to this just to make sure that everything was working and to test this i'm basically just going to create a publisher and subscriber and this is going to be the cue that the publisher and subscriber are going to be publishing and subscribing to now to connect to a service bus i'm going to need connection stream to get that i'm just going to come over here to the policy and then click on root management shared access key and then click on primary connection string and i'm going to grab that and then i'm going to use that inside of my application now to do this i'm going to be using a publisher and a subscriber application so my publisher is this one right here and i'm going to open this up i wrote this in node.js which i tend to use for a lot of things but in any case this is pretty straightforward this particular app uses the connection string right here and then it's using a connection queue right there and then it configures that just using the sdk from azure and i create a service bus client and i create a sender and then this just creates a for loop that will go 10 000 times where it'll start sending a message on basically one every half a second so it'll send a message and then wait half seconds and the next one is basically just populating the body with the message id which is the integer of the for loop so very straightforward here but nothing fancy going on the receiver for this is pretty straightforward as well but let's go ahead and start this up so i'm going to go to node and i'm going to start sending messages to the queue so that's sending the messages to the queue now it's basically just writing one every half a second so let's come back over here to our code and let's look at the subscriber for this or the receiver and this is pretty much the same setup where i have a connection string i have a cue name and this one is setting up a receiver using the cue name and it has a handler for whenever it gets a new message and then it reads the message and basically just writes it back to the console so nothing fancy going on there but because that's already queued up a bunch of messages and there's a bunch of messages in the queue already it's just going to read everything in the queue at first until it catches up and then it's just going to basically be reading messages as they're sent so i should have a queue full of messages because the actual publisher has been running for a few seconds now so let's go ahead and run this and it's just going to receive a bunch of messages and let's wait till more to catch up and that should happen pretty quickly let's see right here on the publisher it's uh that's catching up to this batch and we are almost there and there it is now we're caught up so basically it caught up to the the publisher and as this one sends this one receives this one sends customer sees just because they're both connected simultaneously to the queue so if i was to kill this one right here this one should stop receiving messages and the next second i start sending messages again it's going to start receiving messages again so that's how cues works very straightforward not much to it now let's take a look at our topics and this one has a single topic with it and i have three subscriptions on this one so if you come over here and look at subscriptions you'll see i have three subscriptions right here and i can simply add another subscription and it's got some of the same kind of options that we would expect from a queue but this one allows me to have the auto delete after so many days etc just to keep the cue or the subscription cleaned up and so on this one is pretty straightforward this is where i'm going to be publishing to so i'm going to publish once and publish to then three different subscriptions that are going to consume that so it's one to three in this relationship that we have set up here so let's take a look at my demo for topics here now i have a publisher and subscriber for each one of the sides that i'll be working with on the topic the publisher is pretty much the same code that i saw with q i just changed the variable name and instead of calling it a q name i called it topic name but otherwise this code is identical and this is done this way because microsoft allows me to use the same client library whether i'm using cues or topics it will work with either one now the subscriber code is a little bit different but let's go and start this up so that we can get it running and i'm just going to run node nodeindex.js and that's just going to start publishing some messages up to that topic now the code for the subscriber is a little bit different in that i need to have both a topic and a subs a subscription named for this particular application to run so i get the the topic name is just a variable that's part coded in the code as well as a connection string but rather than have three instances of this running i'm basically just going to prompt myself to enter the name of the subscription and then it's going to connect using the name i entered and then the topic name right here and then that's going to connect the client to the particular topic and subscription to that topic so let's go ahead and start this one i'm going to create three instances of it since i had three subscriptions on my topic and i named them sub one sub two and sub three so let's call this one node index and just type in sub 1 and i could have made that a command line parameter or something like that i just decided to prompt for it in this case any case that's just running down and catching up to wherever my publisher was let's go ahead and start the other two instances of this basically doing the same thing this is going to be node index.js and sub 2 and it's catching up and let's go and start this one right here and node if i can type in no that'd be helpful and and i'm gonna call it sub three and that's gonna start catching up now now let's see if we can get these kind of all in the same screen here here's all of my uh subscribers there's one there's two and this should be my third one right here that is pumping out that's reading a bunch of messages off of that particular subscription and they're all kind of caught up in the same area so 209 210 to 11 they're all right there now let's get my publisher up which should be this window right here so you can kind of see that they're all getting the messages that my publisher is sending so this is sending it up to the topic it's getting multiplied among these various receivers over here that i have running so if i was to stop sending messages we would expect this one to stop receiving messages over here all three subscriptions so let's start them start sending messages again and we should start seeing messages come back through so again very much like we saw with cues the main difference is i have a one-to-many relationship rather than a one-to-one relationship so that's the main difference between the two if you like this content please consider visiting us online at www.wintelegg.com and there you can find about services that wintelec offers including training and consulting services also please consider subscribing this channel by clicking on the subscribe button and clicking the bell icon to get notifications when new content becomes available and also comment down below you can also follow me on twitter at the one mule and also follow intellect on twitter at winnelec now or at whenelect we are constantly posting things about azure related technologies and things related to software development you can also reach us by email at consulting whenelect.com until next time thank you [Music]

Channel: WintellectNOW

Views: 382

Keywords:

Id: vcWpmv8tJBQ

Length: 11min 55sec (715 seconds)

Published: Fri Oct 29 2021