Database Reference
In-Depth Information
In order to provide such reports, there needs to be an end-to-end tracking of messages. A
message is nothing more than a piece of data that travels through a system as the system
completes a transaction.
A transaction is a completed unit of work, such as completing a payment. A message can
be saved after a transaction is completed in order to keep a record and be able to provide
feedback on what happened through the workflow.
A workflow is the end-to-end processing of transactions as the message moves through
the system to complete its life cycle. During a message's life cycle, some data may be
mutated. An example is payment in part or additional fees. The system uses the message's
metadata to determine how the message moves through the workflow.
Metadata is information about the message itself, such as a message ID or header informa-
tion. Header information is used to keep information that may show, for instance, the ori-
ginating system and destination.
A saga uses a message ID to save and lookup the state of the message at a given point us-
ing the originator of the message to respond, with the status of the message, to the origin-
ator.
All of the previous work is performed in order to do reporting; also, instead of creating a
solution from the ground up, NServiceBus is built explicitly to simplify and assist with the
amount of work within a system. NServiceBus uses queuing to pass messages to other ser-
vices, such as MSMQ, which includes error queues and audit queues.
For example, a simple report may be there to send a daily message of how many messages
were sent to the error queue. Since messages can be created in XML, there could be an er-
ror field to be easily parsed out for error details. However, in no way does this replace
logging.
Products such as ServicePulse and other reporting mechanisms are used to assist in giving
reports of the company's messages and data. This simple example could be expanded to
send messages that contain payments above a threshold ($100 for instance) to one queue
and under the threshold to a different queue. A report could be made daily based on
timestamps. Since sagas are saved in databases before a message is completed, another re-
port could be generated to report on all the payments over $100 that are not processed.
