.Net Foundation On .NET, 7 Jan 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Azure Service Bus Core Features

Description

Azure Service Bus Messaging
https://docs.microsoft.com/azure/service-bus-messaging/service-bus-messaging-overview?WT.mc_id=ondotnet-c9-cephilli

Compare Azure Messaging Services https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services?WT.mc_id=ondotnet-c9-cephilli

Azure Service Bus Samples
https://github.com/Azure/azure-service-bus

Cloud messaging patterns
https://docs.microsoft.com/en-us/azure/architecture/patterns/category/messaging?WT.mc_id=ondotnet-c9-cephilli

AMQP https://www.amqp.org/

In this episode, Ashish Chhabria return to talk to us about some of the core features and capabilities of Azure Service Bus.

[00:32] - Core features of Azure Service Bus
[01:21] - Peek Lock
[05:49] - Receive and Delete
[08:37] - Rules, Filters and Actions
[12:58] - Service Bus Transactions

#dotnet #microservices #azureservicebus

A

The.Net Compton is bringing to you a dotnet, calm, focus event on January 14 to 2020. That's all about building web apps with blazer. This will be a free one day. Livestream event that features speakers from the community and also the dotnet product teams, make sure to tune in to focus dot, dot, net comp net and come see what all the excitement is about. Ask questions live and get some deep training on how to build beautiful, interactive and powerful web UI with blazer, hey everyone.

A

Welcome to another episode of the are.net show, and today we're going to be diving a little bit deeper into as your service boss and taking a look at some of the core features that are really important for our developers to know about.

A

Hey everyone, my name is also philip and welcome to another episode of the our net show and in today's episode we're gonna continue our conversation about as your service boss, I really dive into some of the basic features that I think it's really important for a lot of developers. So why don't you tell us? You know what are some of the features about service poster? We should, you know, really know about and care about sure.

B

Absolutely so we touched upon some of the introduction what service boss earlier, but now we can talk about all the features that we have available. So, as I mentioned, you know in the some of the previous sessions. We have the point-to-point semantics with with cue the cues yeah, where the sender sends a message. The cue will essentially act it and make sure it's never lost and the receiver can essentially receive the message as well and.

A

That doesn't acknowledge as well yeah.

B

So so we can do that. We have the next one with topics and subscriptions, which is more of a pub sub semantics yeah, wherein the sender only knows about the topic and the receive only knows about the subscriptions yeah.

C

B

Then the messages are routed based on filter conditions, sure right so we spoke about. You know how we can send you these cues and topics as well, but now, let's, let's look at how we can receive from each of these okay sure so you know receiving. We essentially have two or two options: we have the P clock, which is the at least once and then the receive and delete, which is the at most once. Okay. Now we're looking at the Q example over here, but it works the same way for subscriptions as well.

B

The way it works is that the sender will send the message. The receiver will then lock the mess when it calls receive right. So it says: hey this is my message: I'm going to lock, it don't expose it to any other receiver. No, the next receiver the gods receive, which will then lock the next message right, assuming both of them have got. The peak lock received mode set.

C

B

Once the receiver says: okay, you know the first one says: I'm completing this processing I want to complete it, it'll, take it off the queue and obviously released a lot. Meaner deletes it from the queue and then let's say the second receiver hits hits an issue and wants to abandon the lock it'll. Simply call abandon and that'll essentially keep the message on the cube but release the lock. Okay.

A

Yeah so now I can imagine. This is first scenario where I don't actually want to remove the item off the queue right, but I want to just I want to take a peep at it right like.

D

B

To look at it first that'll trigger well.

A

Can I actually do the processing that needs to happen with this particular type of message? That's.

B

Great, so so so it's a two-phase thing right. Firstly, you want to make sure you lock it, but you don't remove it from the queue just in case. Something goes wrong on the receiver side yeah. It could be that the receiver doesn't know how to process this message. It.

D

C

B

Routed or versioning error, yeah.

C

B

Could be that she was not ready to process a message because some configuration said you know, values another.

A

B

Thirdly, what is the receiver kind of restarts yeah? So you know you want to make sure that the message is not lost, because if it's lost then you know the queue can't do anything about it because.

D

B

You deleted it from the queue now.

D

B

Is more like saying, hey I want to peek it I'm going to lock it I'm gonna. Take you know a little time to process it and you can. You can extend the lock for as long as you need and then you can go ahead and complete the message. Okay,.

A

So how is that different from I guess if I don't have that setting and I'm in.

C

A

Scenario where I'm a receiver, mm-hmm I pull a message off right, but I don't send an acknowledgement right right, I'm guessing if I don't send an acknowledgment. That means that the message is still on the queue right. That's great! So.

B

So the wave works is I mean if you don't send an acknowledgement right. The lock is there for a limited time. Only okay, so you either you either complete, abandon or dead. Let the message within the within the block.

D

B

You extend the lock to say, hey, I'm, still working on this message. It's.

D

B

A little bit longer for whatever reason but I'm still interested in holding on to this or you know if, for whatever reason, the receiver, you know just crashes and it's restarting in it, you know comes back on us, no idea. What would the message mmm the lock will expire within that timeframe? Get it so it goes back into the queue got it when I say back into the queue it never really left the queue, but.

A

It's not available for other people to start working on. That's exactly.

B

Right and that's.

A

B

Exactly what we mean by competing consumer, mmm we're in a you know, multiple consumers are locking or trying to lock messages.

C

On the queue, if.

B

Someone breaks or someone crashes, the next one can pick it up got.

C

A

B

Really have an issue per se losing.

C

B

Cool, so very quick look into what the code looks like right. So again we have the queue, client and the subscription client now again we're calling both of these receive clients, since they have different API contracts, they're different classes, so to speak. Yeah.

C

B

The way it works is that we register a message handler mm-hmm right, so this is one way of you know registering a receiver on it. This is sudo push semantics, wherein you're not explicitly calling receive, but the SDK is doing it behind the scenes.

B

For you and and what's happening over here is you're saying this is my message handler when a message comes in, do this and then complete the message as appropriate, and this is because, in the message handler we have said autocomplete equal faults- you can set out completely equal to true, which means, as soon as your handler completes it'll, to go and complete. The message got it. One thing you notice over here is that there is no explicit abandon call, because if this, it is good block, fails, it'll automatically go and abandon the message and I.

D

B

Build into the SDK okay code keeps your programming model fairly straightforward, and you need only worry about your business logic. All.

A

Right so this is almost like an out of the box pattern for me, creating like a message: processing pump. That's.

B

Right, yeah right, yeah.

C

B

That's exactly where the class is calling the SDK message.

A

B

Yeah, that was good, yeah yeah.

D

B

So the next one which which you kind of touched upon, wherein you don't want to send the acknowledgment, but you know it's it's out of the hand of the service bus in a broker and- and this is a contract that we can set, so you can either either use the P clock mode or you can use the receive and delete mode. Okay and the way it works is that again, the sender sends the messages. As expected, the receiver will simply say and receive right.

D

B

What that does is it'll, take the message off the queue and.

D

B

Give to the receiver yeah and then you know the message: responsibilities now lies of the receiver got.

C

B

The receiver crashes, or has some any kind of issues- that's it. The message is gone. The message is gone, got it yeah. So so big clock is the default that we like that is built into the SDK. That's.

D

B

We recommend for most folks as well, so the next receiver will again pull the message off the queue and delete it from the queue and then have a have its own.

A

Copy is: is this a recommended approach because it offers the most throughput in terms of like processing messages? No.

B

B clock is the recommended clock.

A

Is record right, okay, tragic, not receiving the leap but preferably to use P clock yeah.

B

I mean so you know you can do something that matches your use case. If, if you know high throughput is one of the things that you were at a bar but you're not too much, you know if you're not sensitive to message, loss may be receiving the need works for you. Just fine, okay, but you know it's a service bus message. Reliability and persistence is far more important goal. Yeah.

C

B

Is why P clock is the default on the SDK yeah and.

A

That's that's one of the things that I find life is different about this types of.

B

A

You know to me it's not about processing millions of Records per second right, it's more about like the reliability. Did your ability or the message.

D

A

Know making sure that we go through the workflow, whatever the work that happens to be in a reliable way, yeah.

B

So the reliability is key. It doesn't mean that it's at the cost of throughput. So it's a it's balance, but reliability is key, so the idea is yeah. We want to make sure your message. Data is stored securely and for sure yeah and not have you worried about you know, losing messages or losing data right. Gotcha cool, so yeah, like I mention, abandon and delete methods are no longer required because there's nothing to abandon or delete, because.

A

It's off there's just a part of the SDK right, so.

B

Yeah, so in this case we have the receiving the code samples as well. Here we have the message receiver class and that allows you to receive async yeah again. This will not block your turn as corrected right, but the way it works is that you can call receive, and you can have it wait as long as a message comes in okay or you can have a receive with a timeout receive acing works with peacock as well. But the message handler is something that we recommend, because it's a lot more straightforward, yeah.

C

B

Terms of programming got it: okay,.

B

So next feature we have is is rules, you know- and we touched upon this with our topic in subscription, where you see the filter, which matches the condition and the message and then routes it yeah.

C

B

We also extend that concept to have rules right. Our rule is basically a filter, plus an action right and the filter defines which messages I want to act on, and the action defines what I want to do on those messages. Okay, now what what I mean with that is the filter would say: hey, send me messages that are that have the type order right and I'm gonna do some processing on it. Maybe change a couple of these use of properties which are which are mutable and then send it across to a subscription right.

A

Okay, so we do you define those actions exactly so.

B

You can define it using. You know on the broker itself, you could put it through. So it's a basically a control plane operation, which I mean, which means it's got the same. You know functionality as a crowd operation on a queue or topic. So essentially we have a management client, that's built into our SDK yeah.

C

B

You can use the create rules, async method, to essentially create these okay.

A

Yeah, so I can actually.

B

Show you, the code sample birth quickly, the kind of filters we support are the boolean filters. So true.

C

B

Is everything false, which is nothing yeah.

C

B

Send me everything's I mean nothing. We can also have sequel Lake conditional expressions. They match exactly sequel, 99. So.

C

B

Leverage, what do you know about sequel or kind of plug it into your your filter,.

C

B

Then we have correlation filters which are matched against the properties, the header properties of a message body, all right, so that's both for user and system got it.

A

Well, so for the sequel filter, specifically I'm, guessing you're querying the actual message itself. That's what you're saying like if I don't know some field contains.

C

B

Thing or something.

A

Is like this thing right, like those types of queries, that's.

B

Greater than this.

A

Or less than this, like those types of things, yeah yeah.

B

So so you predefined the condition and you essentially make a management call to say service. First, do this and it's part of the service, bus, topology, okay and then the you know: the broker, the service broker. Cord itself will look at each message. It comes in on topic and then say: okay, this is matching this filter condition. You.

C

B

Is the action associated with it so I'm going to make this edit to this property and then push it to a subscription? Got it okay, yeah and- and you know that were that that effect actions are essentially also a sequel like expression. So you can declare it to using the sequel, update, syntax, you could say: set a equal to B, okay, exactly how you do in sequel, okay, great and this is and so the action.

B

So when a message comes in the first thing is that the filter condition is matched, then the action is acted on it and then it appears in the subscription got.

C

B

So so that's essentially like one atomic operation. So it's not like something lines up in the subscription and then it needs to be acted on sure. It's just one single thing: okay,.

A

Cool so like so when you first set action, mm-hmm I thought you were talking about what happened on the receiver side and like the receiver work. Oh this.

D

A

Is pre receiver? This is pre subscription. This is there's just happening like within the boundary Oh like that filter. That's.

B

A

Filter and that filter action, that's.

B

Right, yeah I think the words a little bit overloaded, but yeah. That's basically it you essentially set set what you want to do on that message and only then it will be visible to the receiver kind of so very good code sample. We, like I, mentioned we have a management client. So that's exactly where Stan she ating over there yep. Then we create the sequel, filter and say: look if the source is from the orders. You.

C

B

Orders application you.

C

B

I'm gonna put in I'm gonna, put in an action that will change my source to route. It orders it's just the way of saying: hey, I, you know service bus. Looked at this and now it's been routed in the right direction. Sure so just want the use cases, and once you define these filter action rules, then you can go ahead and create the rule with that last line of code, and that is what your your client application can go and register with with service bus. Okay,.

C

B

Once you get an act back on that, the rule is established and your senders can start sending great.

A

So then, this might be something that I want to set up whenever I first create my my service, bus, namespace and I create my cube or my topic. When I create my topic: I'm, sorry, yeah and then now you know part of my deployment script or part of my you know. Infrastructure set up, I could go ahead and define these rules right. The actions and these filters that's right and then now, like my client, is just concerned about like sending messages.

B

That's correct, yes, okay,.

A

B

A

About transactions, a little bit like.

B

Because I know.

A

That's a big feature, a lot of folks right, I always ask about, and for me that's one of like the differentiating features for service bus versus, like some of these other messaging things that we have that's.

B

Correct and that's exactly why we call ourselves the enterprise messaging as a service, because a lot of enterprises need to have transit block of code that they need to execute totally.

C

B

It's all or nothing and that's exactly where transactions come to play. Okay, so.

C

B

Way it works is that you can group two or more operations within a single transaction scope, yeah.

C

B

They all have to be on the same messaging entity. So the same cue, the same topic same subscription or same yeah same subscription, basically yeah, and then they will succeed or fail jointly and.

D

B

If any one of those operations fail, the whole thing will be rolled back okay, and so you can essentially well it's a limited feature. So we have send a sinks and bats and bash a sink, which means you can essentially send a message or send a batch of messengers in a single call. Yeah.

C

B

On message, you can either complete abandoned a letter and those those can be plugged into one single transaction got.

A

It and then, when you say, rollback right, I'm assuming you mean, like all of those measures, are going to come back on the queue. That's great.

D

A

That was previously marked as.

D

A

Know taking care of yeah like there's are just gonna come back and in some other receiver, okay go through the process of trying to work with them or or if I don't know. If or maybe we just can't complete it, we could dead later those things and.

B

That send them somewhere else. That's great! That's.

A

B

So so that's exactly what we're showing we as well, that it wants all the operations complete. That's when you consider the entire block to be complete yeah, but if any operation fails, then we can roll back everything and then the whole block is considered fail, Geron.

B

So let's look at some of the code samples over there so again here we need to make sure the sender and receiver are on the same queue. We can start the transaction transaction scope and then do all the processing that's appropriate and then go ahead and complete the transaction scope as well, which is right over here.

B

So pretty straightforward, there's also an exception block that you can use to roll everything once you know if it fails right. Okay,.

A

Also, this is really interesting. Maryland. Definitely thank you for showing us this I know the service bus, github, repo has a lot of samples, and you know you know different ways of using the SDK. That's.

D

A

We'll make sure we do is like we'll add that to the show notes, sure everybody could kind of try out this. You know all these different features and include it you're, showing us today right also well. Thank you. So much man like I'm, really loving the service conversation.

C

A

We're having and thank you all for watching this has been another episode of the on dotnet sure we just been learning about some of the core features that are inside of Azure service bus.

A