Knowing Your IBus - Mastering NServiceBus and Persistence - page 127

definition, UseTransport<SqlServer> . The https://github.com/Particular/NSer-
viceBus.SqlServer link will demonstrate queuing across SQL Server.
As always, it is important to check out what the saga is doing. The saga will be located in
the VideoStore.Sales project. This code may start to look very similar to the previ-
ous BasicSaga code, but as with most of ESB, it works in the same pattern and only
adds minor differences. Here, we will be mapping SubmitOrder and CancelOrder
to the saga through OrderNumber . This is to look up the saga at a later time by its
unique OrderNumber that will keep the messages' mapping to the correct saga instance.
Notice that when the saga is started by the IAmStartedByMessages<Sub-
mitOrder> message handler, we start the timer; 20 seconds will be persisted to SQL
Server after the end of this function call. We save the message information—specifically
the uniqueness of the saga—and call OrderNumber and any information that we wish to
save additionally, then off it goes to SQL Server to be grabbed later from the
CancelOrder or SubmitOrder messages. This saga will be mostly used for a buyer's
remorse period of 20 seconds to return to the order information and then publish it to pro-
cess it if the user doesn't cancel it within 20 seconds.
After the timeout period has elapsed, a BuyersRemorseIsOver object will be sent to
the message handler of the timeout through the IHandleTimeouts<Pro-
cessOrderSaga.BuyersRemorseIsOver> interface. Because this is part of the
original saga, the saga will be pulled in as the data object.
The public void Timeout(BuyersRemorseIsOver state) function will be
called to handle the message and a new OrderAccepted message will be created and