1
00:00:00,860 --> 00:00:05,870
We are all done with our expiration service and it is now emitting the expiration complete event so

2
00:00:05,870 --> 00:00:07,650
we're not going to travel back in time.

3
00:00:07,670 --> 00:00:12,980
Go back to the oil service and make sure that we build a listener to listen for this event as soon as

4
00:00:12,980 --> 00:00:15,470
the order service sees expiration completes.

5
00:00:15,530 --> 00:00:20,860
We're going to find the relevant order inside the orders collection and market as canceled.

6
00:00:20,900 --> 00:00:25,580
We might have to do one or two other things related to canceling an order but we'll discuss that in

7
00:00:25,580 --> 00:00:28,010
due time when we cancel the order.

8
00:00:28,010 --> 00:00:34,080
We are probably also going to want to emit an order canceled event from the order service as well but

9
00:00:34,140 --> 00:00:39,960
right now let's just focus on the order service and the listener for expiration comp. Now to build out

10
00:00:39,960 --> 00:00:44,400
this listener we first need to update our common module inside of the order service.

11
00:00:44,460 --> 00:00:49,650
Remember we update our come module just a moment ago and added in the expiration complete event but

12
00:00:49,650 --> 00:00:57,470
we never update the version of that module inside of our order service back at my terminal I'm gonna

13
00:00:57,490 --> 00:01:02,510
change into orders and then update my comfort module

14
00:01:08,130 --> 00:01:08,470
all right.

15
00:01:08,470 --> 00:01:09,710
Very good.

16
00:01:09,800 --> 00:01:16,570
Now go backwards my editor I'm going to find my orders directory I'll find listeners inside there and

17
00:01:16,580 --> 00:01:25,450
we'll add in a brand new listener with the name of you guessed it expiration complete listener got to

18
00:01:25,460 --> 00:01:31,160
yes now we put together several listeners over time but I don't know about you.

19
00:01:31,180 --> 00:01:34,470
I just have a hard time of remembering how to put these things together.

20
00:01:34,560 --> 00:01:36,990
Just remember you can always rely on typescript.

21
00:01:37,050 --> 00:01:44,080
The one thing at a minimum we have to remember we have to import listener from our common module we

22
00:01:44,080 --> 00:01:48,310
can then make our a class of expiration complete listener

23
00:01:51,380 --> 00:01:54,870
that will extend listener and then typescript is gonna take it from there.

24
00:01:54,920 --> 00:01:58,620
We've been over this many times so let's just be through the rest of this implementation.

25
00:01:58,700 --> 00:02:04,790
We need to import our event to provide to the generic type we need to import our Q Group Name subjects.

26
00:02:04,780 --> 00:02:06,510
We've got to get our message type.

27
00:02:06,590 --> 00:02:07,800
We've got to get.

28
00:02:07,910 --> 00:02:08,930
I think that's it.

29
00:02:08,950 --> 00:02:17,030
Actually from listener let's get the subject Seena and the exploration complete event.

30
00:02:17,180 --> 00:02:22,320
We'll get our message type from node Nats streaming

31
00:02:25,300 --> 00:02:26,920
and then what else.

32
00:02:26,980 --> 00:02:27,970
I think that's is that it.

33
00:02:27,970 --> 00:02:30,590
I think I feel like I mentioned one other but whatever will.

34
00:02:30,670 --> 00:02:37,130
The Q Group Name naturally Arrigo from same directory cougar name.

35
00:02:37,140 --> 00:02:37,620
There we go.

36
00:02:38,110 --> 00:02:38,360
OK.

37
00:02:38,400 --> 00:02:44,650
Now on our listener we'll stick in that type expiration complete event throw in the Q Group Name

38
00:02:47,990 --> 00:02:56,120
throw in a subject of subject start expiration complete subject start expiration complete and then finally

39
00:02:56,270 --> 00:03:05,970
on message mark that as a sync receive some data which will be of type expiration complete event at

40
00:03:05,970 --> 00:03:13,410
data and then get our message which is up type message we go there's our listener again it's all the

41
00:03:13,410 --> 00:03:18,660
same stuff between all these different listeners I tried to factor all this code down to be the absolute

42
00:03:18,660 --> 00:03:23,040
minimum and this is pretty much what I came up with we could probably figure out a way to more easily

43
00:03:23,040 --> 00:03:27,680
generalised Q Group name but in general this is pretty darn compact.

44
00:03:27,700 --> 00:03:34,050
Anyways back on topic so we've got this incoming data that describes some order or the attempt to save

45
00:03:34,050 --> 00:03:38,760
it in order should be cancelled the first thing you do is take a look inside of our orders collection

46
00:03:39,030 --> 00:03:49,340
and find the relevant order at the very top let's import our order from up to directories models order

47
00:03:53,540 --> 00:03:54,050
then inside of.

48
00:03:54,060 --> 00:04:02,570
On message we can find our order so we'll do it and await Order Act find by I.D. And remember this event

49
00:04:02,570 --> 00:04:08,450
right here has one single property it has the order ideas property if we ever forget that naturally

50
00:04:08,510 --> 00:04:13,280
we can do a command click on expiration complete even at the top and will tell us OK here's the data

51
00:04:13,280 --> 00:04:18,890
property it has an order I.D. so that is the idea the order that we want to find the inside of find

52
00:04:18,890 --> 00:04:26,560
by I.D. we will reference data what order I.D. then as usual typescript is not sure if this thing is

53
00:04:26,560 --> 00:04:32,350
actually defined or not so we just have to do a quick check make sure that order is defined that there's

54
00:04:32,410 --> 00:04:38,770
not an order let's throw a new error and say order not found

55
00:04:44,430 --> 00:04:49,110
then after that we need to update this thing status well do update the status we're going to need that

56
00:04:49,170 --> 00:04:54,450
order status enum remember we had previously defined that inside of our common module and I was going

57
00:04:54,450 --> 00:04:57,050
to describe all the puzzle statuses is that an order can have.

58
00:04:57,780 --> 00:05:01,170
So we will import order status from our common module

59
00:05:07,030 --> 00:05:14,750
then right after the if statement we'll do an order dot set up not that order dot set there we go.

60
00:05:14,990 --> 00:05:19,420
And I want to change the status to order status that cancelled

61
00:05:22,130 --> 00:05:24,790
now there might be one other thing we should do here as well.

62
00:05:24,790 --> 00:05:30,310
Remember the order is going to contain a reference directly to the ticket that it is reserving.

63
00:05:30,460 --> 00:05:35,170
And so we need to kind of make a decision here and decide whether or not we want to clear out that reference.

64
00:05:35,290 --> 00:05:38,590
So in other words whether we want to say ticket is something like.

65
00:05:38,590 --> 00:05:39,900
No.

66
00:05:39,910 --> 00:05:42,060
Does that make sense or does it not.

67
00:05:42,070 --> 00:05:44,130
Should we keep a reference to the order.

68
00:05:44,180 --> 00:05:46,380
That's something we should probably discuss a little bit.

69
00:05:46,390 --> 00:05:49,690
So let's take a quick pause right here and save this file that's why you're seeing my code jump all

70
00:05:49,690 --> 00:05:50,540
over the place.

71
00:05:50,620 --> 00:05:51,370
We can save this file.

72
00:05:51,370 --> 00:05:55,510
We'll take a quick pause and we're going to decide whether or not it makes sense to reset the ticket

73
00:05:55,510 --> 00:06:00,370
property on this newly cancelled order the quick pause here and we'll continue in just a moment.