1 00:00:01,030 --> 00:00:06,100 At the end of last video I mentioned whether or not it made sense to empty out or essentially reset 2 00:00:06,100 --> 00:00:09,010 the ticket property of this order that has now been cancelled. 3 00:00:09,010 --> 00:00:13,600 The reason that this is a relevant question is remember that we are tracking essentially whether or 4 00:00:13,600 --> 00:00:18,910 not a ticket is reserved by taking a look and see if there are any orders that refer to it. 5 00:00:18,910 --> 00:00:23,020 Let's go take a look at the code that actually decides inside of our order service whether or not a 6 00:00:23,020 --> 00:00:25,050 ticket is currently reserved. 7 00:00:25,060 --> 00:00:30,820 You might recall that we had written that inside of our models directory in the ticket TSA file on the 8 00:00:30,820 --> 00:00:37,350 ticket document we added on a very special little method that we called is reserved. 9 00:00:37,360 --> 00:00:38,360 Here it is right here. 10 00:00:39,610 --> 00:00:41,160 So it is reserved. 11 00:00:41,260 --> 00:00:46,010 We are going to invoke that and try to find in order that reference this ticket. 12 00:00:46,020 --> 00:00:47,610 But then here's the critical part. 13 00:00:47,610 --> 00:00:54,500 We made sure that we were only looking for orders that had a status of redid awaiting payment or complete. 14 00:00:54,510 --> 00:01:00,080 So as soon as the order goes to the cancelled states the ticket that is associate with it is going to 15 00:01:00,080 --> 00:01:02,980 be considered to be no longer reserved. 16 00:01:03,020 --> 00:01:08,720 That's going to essentially unlock the ticket inside of the or as far as the order service is concerned. 17 00:01:10,140 --> 00:01:14,730 That means that we do not need to reset or clear out this ticket property and that's actually a good 18 00:01:14,730 --> 00:01:21,030 thing because now once an order is cancelled a user can still see what ticket it had been associated 19 00:01:21,030 --> 00:01:21,720 with. 20 00:01:21,720 --> 00:01:27,570 Just imagine if we had set ticket to null like so user would then try to look at all their different 21 00:01:27,570 --> 00:01:32,430 orders and we would not have any idea what any given cancelled order was for what they were trying to 22 00:01:32,430 --> 00:01:33,250 buy. 23 00:01:33,270 --> 00:01:38,220 So if we reset that ticket property there would be no tie between this order and a given ticket anymore. 24 00:01:38,220 --> 00:01:42,060 So a user might just see hey you've got like 5 cancelled orders but they'd be sitting there wondering 25 00:01:42,420 --> 00:01:47,220 what were these orders for I don't have any information and so it's pretty convenient that we decide 26 00:01:47,310 --> 00:01:51,390 our is reserve function to allow us to have a cancelled status. 27 00:01:51,390 --> 00:01:51,610 Okay. 28 00:01:51,630 --> 00:01:58,640 So in closing we are not going to include ticket of no now after setting that status on the order. 29 00:01:58,670 --> 00:01:59,980 We then need to save the order. 30 00:01:59,990 --> 00:02:02,320 So we'll do it in a wait order. 31 00:02:02,470 --> 00:02:07,970 Save and then naturally we need to infer inform the rest of the world. 32 00:02:07,990 --> 00:02:11,800 All of our different services that this order has now been cancelled. 33 00:02:11,800 --> 00:02:17,470 Well you might recall that a while ago inside of our order service we had already put together a publisher 34 00:02:17,500 --> 00:02:19,690 for the Order cancelled event. 35 00:02:19,780 --> 00:02:21,720 Who put that together a long time ago. 36 00:02:21,750 --> 00:02:26,620 It's all we have to do is import that Order cancelled publisher into this listener and right after we 37 00:02:26,620 --> 00:02:31,030 save that order right after we make that update and cancel thing we should definitely publish an event 38 00:02:31,030 --> 00:02:35,680 right away saying that this order has been cancelled and let's just go take a look at a quick diagram 39 00:02:35,680 --> 00:02:39,830 of that so we're going to make sure we emit that event. 40 00:02:39,830 --> 00:02:43,390 And right now really just going to worry about making sure that we eventually listen for that over on 41 00:02:43,390 --> 00:02:44,590 the ticket service. 42 00:02:44,590 --> 00:02:48,280 But as soon as we put together the payment service payment service is going to care about that event 43 00:02:48,310 --> 00:02:50,780 as well all right. 44 00:02:50,800 --> 00:02:55,720 So to emit an event or publishing event from inside of a listener we've done this once before remember 45 00:02:55,720 --> 00:03:01,900 all we do is import the publisher read an instance of it right here pass in the Nats wrapper client 46 00:03:01,900 --> 00:03:06,800 or really just the Nats client that is already a instance property of our class and that's it. 47 00:03:06,820 --> 00:03:13,610 We can then call the published function so at the very top I will import the ticket cancelled or any 48 00:03:13,630 --> 00:03:14,330 order canceled 49 00:03:17,420 --> 00:03:22,610 publisher from up on directory publishers order canceled. 50 00:03:22,620 --> 00:03:23,130 Publisher 51 00:03:27,620 --> 00:03:35,450 then back down here we can do a New Order cancelled publisher. 52 00:03:35,590 --> 00:03:43,950 We're gonna pass in our listeners now client that's a desktop client will then publish some information 53 00:03:44,310 --> 00:03:47,900 and I definitely forget what properties this event is supposed to have. 54 00:03:47,940 --> 00:03:50,590 Let's definitely do a mouse over and be told what we have to do here. 55 00:03:50,610 --> 00:03:50,870 OK. 56 00:03:50,880 --> 00:03:56,070 So we have to provide the idea of the order that's been canceled its version again for concurrency issues 57 00:03:56,610 --> 00:04:01,230 and then a reference to the ticket or essentially the idea the ticket that this order was associated 58 00:04:01,230 --> 00:04:10,070 with I'm going to put in my I.D. which will come from order I.D. I'll put in its version JS order dot 59 00:04:10,130 --> 00:04:12,530 version and then ticket 60 00:04:15,590 --> 00:04:21,630 and ticket is going to be the idea and we have to get the idea of that ticket. 61 00:04:21,680 --> 00:04:27,500 Well remember a backup here when we initially fetched our order we did not try to populate that ref. 62 00:04:27,500 --> 00:04:30,730 Remember we are relating an order in a ticket together to that rep system. 63 00:04:31,080 --> 00:04:36,220 So if you want to make sure that we get our order or fetch this order and also load up the associated 64 00:04:36,230 --> 00:04:45,570 ticket we do have to chain on that dot populate statement and put in ticket like so. 65 00:04:45,580 --> 00:04:52,200 So now we should be all to reference order that ticket dot i.e.. 66 00:04:52,420 --> 00:04:53,430 Looks good. 67 00:04:53,500 --> 00:04:58,280 Now let's throw in a wait in front that public statement just to make sure we wait for this thing to 68 00:04:58,280 --> 00:05:03,850 be published before finally asking or acknowledging the overall message and and speaking of which let's 69 00:05:03,850 --> 00:05:05,260 put that in at the very bottom as well. 70 00:05:05,290 --> 00:05:09,930 So message dot AK Like so case so that should be. 71 00:05:10,210 --> 00:05:13,890 That is our listener for the exploration the complete event. 72 00:05:13,960 --> 00:05:18,850 Naturally it would be nice to write out a quick test or two around this because this is a pretty critical 73 00:05:18,850 --> 00:05:23,860 flow inside of our app and we really want to make sure that this event gets processed correct quickly. 74 00:05:24,070 --> 00:05:28,180 I know that we've been through testing so many times now and it really might be a little bit tedious 75 00:05:28,180 --> 00:05:28,880 at this point. 76 00:05:28,960 --> 00:05:31,940 Nonetheless we really really should test this thing. 77 00:05:32,020 --> 00:05:33,380 We'll go through the tests rather quickly though. 78 00:05:33,430 --> 00:05:36,520 So let's take a pause right here and just nail these tests in the next video.