Database Reference
In-Depth Information
Using the saga pattern provides many of the features that are currently missing in the solu-
tion presented thus far. The saga is the end-to-end message workflow that can be used to
save the state in an intermediate process. This can be accomplished by saving an interme-
diate saga data object. This persistence typically is done to a database and looked up when
the same message is passed back through. Sagas can get complicated but, because very
little code is required—since the ServiceBus handles most of the work—sagas can be
simple to use.
As hinted previously, a saga can be created as an intermediate between the services to
keep the client, in our example Service1, informed about the progress of the message.
The saga can update other endpoints of the message status and change the message if it
needs updating as it moves through the workflow. The important piece of a saga is the
one-to-one lookup of the data related to the message and the message itself. This allows
the workflow to follow a message's progress and know where it is at a given moment
along multiple services. We could define a timer to fail the message if it continually errors
out, since we don't want messages to live forever.
Returning back to the pizza-ordering example, instead of waiting and not refreshing the
page, we can create a page where the user can go to and check the status as the order pro-
gresses through the ServiceBus workflow. Notice that this allows many nonfunctional re-
quirements to be addressed.
Nonfunctional requirements (such as monitoring, logging, manual retries, timeouts,
checking encryption, and the message) can be addressed by monitoring the services and
messages.
To recap, we can address the payment engine errors by adding logic to the saga to notify
the user, operations, and the organization of specific errors. For instance, we could add lo-
gic to the saga to send an e-mail to the user saying that the order was denied due to insuf-
