Now that we have created our expiration complete event we can create a publisher to publish this event
inside of our expiration service.
It has been just a little bit since we have created a publisher.
So let's just get a quick reminder on how we do it by taking a look back at our order service.
Back inside the order service we can find our SLC events publishers directory and inside there maybe
just look at our order created publisher.
So this is how we create a publisher.
Just make a new class.
We extend our publisher base class and we put in the type of event that we want to publish and then
for the subject.
We just defined that using these subjects in them and that's it.
Nothing else very special about it.
So let's create one of these or our expiration complete event back inside of the expiration service
inside of expiration.
I'll find the events directory and inside there I'll make a new folder called publisher's and in there
we'll create a new file of expiration complete publisher dot T.S.
then up at the very top we'll import subjects publisher and the expiration complete event from our common
module
will then export a new class of expiration complete publisher Come on.
There we go.
That's going to be extending publisher and as the generic type will stick in the expiration.
You bet.
These are some really long variable names.
That's why I'm pausing every school time because I want to make sure that I get the name exactly correct.
All right as usual typescript says well if you want to extend this you've got a defined subject I'll
set up these subject property.
It will be up type subjects dot expiration complete and we will sign that a value of subjects dot expiration
complete
now looks like touch script is still unhappy here.
Oh I put in subjects should be just subject singular.
There we go.
Now it's happy.
All right publisher created.
So now we can go back over to our Qs exploration queue and we'll find our process statement inside their
sorry member.
We go back and reference this diagram whenever we process this job whenever we receive it back from
readies.
That is when we are going to want to emit that new event or publishing event of expiration complete
and we just need to make sure that we take the order I.D. out of the job itself so the code for this
should be pretty easy and straightforward at the very top of our exploration queue file.
We are going to import our publisher
from up one directory events publishers expiration complete publisher and then remember any time that
we tried to publish an event.
We also have to provide the Nats client as well.
So we're going to also import our Nats rapper from up to directories or send me just one directory in
this case.
Nats rapper.
So now down inside of our process statement we can remove that console log and replace it with publisher
is where actually we don't even really need to assign it to a variable we can write it all out inside
just one statement so we'll just do that.
We'll say new expiration complete publisher will pass in our Nats client and we will publish
and as usual if we forget what we have to provide for publish we can just mouse over and touch crypto
tell us we have to give in order ideas so put in an order I.D. and that order idea is gonna come out
of our job number.
Our job has a data property the data property is going to contain all the information we are storing
inside the job which in this case is this payload interface or it is a object matching the payload interface.
Just to be really correct here so for order I.D. We'll put in job dot data dot order I.D. and that is
pretty much it.
So now naturally we should try to test this out so we can once again use postmen to manually create
a ticket manually create an order and then we could wait for that full 1 minute to eventually see a
expiration complete event get published but instead it just make everything go really quickly.
Let's go back over to our order created listener so inside of our listeners directory and we're going
to do a test of all this stuff.
But I'm going to come in out the delay right here that's going to cause the job to be processed instantly
and so we should see the event of expiration complete processed instantly as well.
Yeah.
Gonna say this we'll go to postman and test this all out inside a postman gonna once again create a
new ticket there is my ticket I.D. then use that to create a new order I'll put in the ticket idea right
there send it off and we'll go back over to my terminal and take a look at the different events it's
been published OK so let's kick off at order created right here from the expiration service we then
get the console log that we're gonna wait some number of milliseconds to process the job but of course
we just commented out that delay so it's gonna be kind of processed immediately so then see some other
stuff about a ticket being updated another ticket updated during CFD and then that's what we're looking
for right there.
Event published to expiration complete from the expiration service.
Awesome.
That means that it's all working as expected.
This looks pretty good and that is pretty much it for our expiration service.
Pretty simple straightforward.
All it really did was take an event wait some time and then publish another one in the future so last
thing I'm going to do for the listener I'm going to comment that delay and make sure I get a call about
right above
and close all this stuff out.
We'll take a pause right here and when we come back the next video we're going to move back over to
our order service and make sure that we receive that new ticket or expiration complete event as soon
as we get that event.
We'll make sure that we mark the accompanying order as expired well so quick pause right here and we'll
go back over to the order service in just a moment.