1 00:00:01,270 --> 00:00:04,450 We've got a rough start to our ticket created listener put together. 2 00:00:04,450 --> 00:00:08,800 We're not going to start to pivot and work on the ticket update a listener just you know we are not 3 00:00:08,800 --> 00:00:10,720 by any means done with this code right now. 4 00:00:10,840 --> 00:00:15,040 But as I mentioned at the start of this section I really want to focus on some of those different concurrency 5 00:00:15,040 --> 00:00:19,000 issues now that we have both publishers and listeners inside of rap. 6 00:00:19,040 --> 00:00:24,310 So we're gonna work on the listener for ticket updated we're gonna see that there's very quickly some 7 00:00:24,310 --> 00:00:27,970 really big concurrency issues and we're going to come back through both these listeners and make some 8 00:00:28,000 --> 00:00:29,750 adjustments to them. 9 00:00:29,890 --> 00:00:36,180 So inside my listeners directory inside my order service I'll make a new file of tickets updated. 10 00:00:36,250 --> 00:00:42,790 Listener Scott T S and then inside of here we're going to add some very similar imports to what we've 11 00:00:42,790 --> 00:00:49,780 got up here at the very top so inside of ticket updated we will add in and import for message from node 12 00:00:49,960 --> 00:00:58,480 that streaming will get subjects listener and ticket updated event from our common module 13 00:01:02,770 --> 00:01:06,780 I'm going to get tickets from up to directories models. 14 00:01:06,940 --> 00:01:09,110 Ticket. 15 00:01:09,170 --> 00:01:14,900 And then finally our Q Group name from you. 16 00:01:14,900 --> 00:01:19,950 Group Name Then comes our actual listener definition. 17 00:01:19,950 --> 00:01:22,190 So export class tickets. 18 00:01:22,320 --> 00:01:24,030 Updated listener. 19 00:01:24,030 --> 00:01:29,550 This is going to be extending our listener abstract class and the event that we are trying to listen 20 00:01:29,550 --> 00:01:37,210 for is ticket updated though ticket updated event then inside of here we'll go through all that hassle 21 00:01:37,210 --> 00:01:38,190 with subject again. 22 00:01:38,200 --> 00:01:44,640 So put in subject as subject stop ticket updated equal to subjects start ticket. 23 00:01:44,860 --> 00:01:48,790 Updated then our Q Group name 24 00:01:52,680 --> 00:02:00,460 and then finally async on message they're gonna receive some data that's gonna be a type ticket updated 25 00:02:00,760 --> 00:02:10,360 event at data and as the second argument we'll get our message of type message well now inside of here. 26 00:02:10,410 --> 00:02:12,240 Well pretty straightforward. 27 00:02:12,270 --> 00:02:16,950 In theory we need to find the ticket that is being updated the ticket that is mentioned inside of this 28 00:02:16,950 --> 00:02:20,010 data object and just update the data and save it. 29 00:02:20,010 --> 00:02:21,000 That's pretty much it. 30 00:02:21,030 --> 00:02:24,720 So at the end the day in theory it's gonna look kind of similar to what we just did inside of ticket 31 00:02:24,720 --> 00:02:25,190 created. 32 00:02:25,200 --> 00:02:31,950 The only differences this time around we are updating data instead so step one let's pull the ticket 33 00:02:32,040 --> 00:02:40,920 out of our ticket collection using that ticket model will say ticket is a weight ticket that find by 34 00:02:40,980 --> 00:02:42,950 Idi. 35 00:02:43,120 --> 00:02:50,870 The idea is going to be contained inside this data argument as I.D. so we'll say Ada dot I.D. There 36 00:02:50,870 --> 00:02:54,340 is a chance that we will not find a ticket we are looking for. 37 00:02:54,350 --> 00:02:57,600 So if we don't find the ticket we are looking for take a love a value of No. 38 00:02:57,640 --> 00:03:02,660 So very similar to what I've done on some of our root handlers in the past will say if there is no ticket 39 00:03:02,960 --> 00:03:05,240 right now we're just gonna throw a very simple error. 40 00:03:05,250 --> 00:03:10,370 So we'll say throw new error tickets not found. 41 00:03:10,400 --> 00:03:14,270 We will come back and address error handling in a way greater detail very shortly. 42 00:03:14,270 --> 00:03:20,520 But remember right now we're just trying to focus on some of this async issue stuff now that we found 43 00:03:20,520 --> 00:03:24,760 the ticket we can go through and update presumably the title and the price. 44 00:03:25,050 --> 00:03:27,100 Remember that's the only properties we really care about here. 45 00:03:28,980 --> 00:03:33,990 So on the ticket we are going to set the title and the price. 46 00:03:34,150 --> 00:03:38,180 Let's make sure we pull off those properties from ideas or from data as well. 47 00:03:38,250 --> 00:03:42,730 So let's say concert title and price is coming from data that's better. 48 00:03:43,740 --> 00:03:46,560 After setting those properties will then save the updated ticket. 49 00:03:46,590 --> 00:03:51,000 So a weight ticket dot save. 50 00:03:51,130 --> 00:03:53,480 Well that is pretty much it for our business logic. 51 00:03:53,480 --> 00:03:58,550 And so after we've executed all of our business logic again that we want to call our message dot ACH 52 00:03:58,580 --> 00:04:02,510 function that's going to acknowledge the message until that streaming server that we have successfully 53 00:04:02,510 --> 00:04:03,480 processed it. 54 00:04:03,600 --> 00:04:09,980 Little called message dot EQ at the bottom like so and well once again that's pretty much it kind of 55 00:04:09,980 --> 00:04:14,810 a simple on message implementation so let's save this right here. 56 00:04:14,810 --> 00:04:19,130 The last thing to do is make sure that these two listeners actually get used at some point time. 57 00:04:19,130 --> 00:04:23,390 Right now we have added in these two files these two listeners but we don't actually make use of these 58 00:04:23,390 --> 00:04:25,760 classes anywhere inside of our project. 59 00:04:25,760 --> 00:04:30,050 So we need to figure out a suitable location to create an instance of these listeners and have them 60 00:04:30,050 --> 00:04:31,580 start listening for events.