At the end of last video I mentioned whether or not it made sense to empty out or essentially reset
the ticket property of this order that has now been cancelled.
The reason that this is a relevant question is remember that we are tracking essentially whether or
not a ticket is reserved by taking a look and see if there are any orders that refer to it.
Let's go take a look at the code that actually decides inside of our order service whether or not a
ticket is currently reserved.
You might recall that we had written that inside of our models directory in the ticket TSA file on the
ticket document we added on a very special little method that we called is reserved.
Here it is right here.
So it is reserved.
We are going to invoke that and try to find in order that reference this ticket.
But then here's the critical part.
We made sure that we were only looking for orders that had a status of redid awaiting payment or complete.
So as soon as the order goes to the cancelled states the ticket that is associate with it is going to
be considered to be no longer reserved.
That's going to essentially unlock the ticket inside of the or as far as the order service is concerned.
That means that we do not need to reset or clear out this ticket property and that's actually a good
thing because now once an order is cancelled a user can still see what ticket it had been associated
with.
Just imagine if we had set ticket to null like so user would then try to look at all their different
orders and we would not have any idea what any given cancelled order was for what they were trying to
buy.
So if we reset that ticket property there would be no tie between this order and a given ticket anymore.
So a user might just see hey you've got like 5 cancelled orders but they'd be sitting there wondering
what were these orders for I don't have any information and so it's pretty convenient that we decide
our is reserve function to allow us to have a cancelled status.
Okay.
So in closing we are not going to include ticket of no now after setting that status on the order.
We then need to save the order.
So we'll do it in a wait order.
Save and then naturally we need to infer inform the rest of the world.
All of our different services that this order has now been cancelled.
Well you might recall that a while ago inside of our order service we had already put together a publisher
for the Order cancelled event.
Who put that together a long time ago.
It's all we have to do is import that Order cancelled publisher into this listener and right after we
save that order right after we make that update and cancel thing we should definitely publish an event
right away saying that this order has been cancelled and let's just go take a look at a quick diagram
of that so we're going to make sure we emit that event.
And right now really just going to worry about making sure that we eventually listen for that over on
the ticket service.
But as soon as we put together the payment service payment service is going to care about that event
as well all right.
So to emit an event or publishing event from inside of a listener we've done this once before remember
all we do is import the publisher read an instance of it right here pass in the Nats wrapper client
or really just the Nats client that is already a instance property of our class and that's it.
We can then call the published function so at the very top I will import the ticket cancelled or any
order canceled
publisher from up on directory publishers order canceled.
Publisher
then back down here we can do a New Order cancelled publisher.
We're gonna pass in our listeners now client that's a desktop client will then publish some information
and I definitely forget what properties this event is supposed to have.
Let's definitely do a mouse over and be told what we have to do here.
OK.
So we have to provide the idea of the order that's been canceled its version again for concurrency issues
and then a reference to the ticket or essentially the idea the ticket that this order was associated
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
version and then ticket
and ticket is going to be the idea and we have to get the idea of that ticket.
Well remember a backup here when we initially fetched our order we did not try to populate that ref.
Remember we are relating an order in a ticket together to that rep system.
So if you want to make sure that we get our order or fetch this order and also load up the associated
ticket we do have to chain on that dot populate statement and put in ticket like so.
So now we should be all to reference order that ticket dot i.e..
Looks good.
Now let's throw in a wait in front that public statement just to make sure we wait for this thing to
be published before finally asking or acknowledging the overall message and and speaking of which let's
put that in at the very bottom as well.
So message dot AK Like so case so that should be.
That is our listener for the exploration the complete event.
Naturally it would be nice to write out a quick test or two around this because this is a pretty critical
flow inside of our app and we really want to make sure that this event gets processed correct quickly.
I know that we've been through testing so many times now and it really might be a little bit tedious
at this point.
Nonetheless we really really should test this thing.
We'll go through the tests rather quickly though.
So let's take a pause right here and just nail these tests in the next video.