Sagas play a critical role in workflow management. Without the ability to map data to persistent data, workflow among messages cannot be achieved. Saga's purpose is to persist saga data objects, which are files with data from selected content, directed from messages in the message handler. The following are some of the things that sagas are good for:
Saving message state/session information: When a message is started, the message handler will create the saga data instance that will be saved at the end of the message handler. It is up to the message handler data to set data into an instance of the object. NSB handles the mapping. The following screenshot displays the code for handling messages:
Changing message state/session information: During a message handler, the
ConfigureHowToFindSaga()function has mapped a way for NSB to retrieve the correct saga data object, based on the message's unique ID. In the initial message that started the saga, the initial data and ID is set to the saga data row. Subsequent messages will either update this row of data, retrieve it, or delete it. This data is the workflow used to store the state between messages.
Responding to originator/original client of changes: The saga can respond to the original client with the
ReplyToOriginator()function. This can complete the path of the original message with a success or error message to complete the end-to-end trip of the message. TheMarkAsComplete()function states that the data object is no longer needed and can be deleted.Providing timeouts: Sagas have the ability to provide timeouts. There could be many reasons for timeouts, but the most obvious one is not having a message running that has associated saga data to run forever. The
RequestTimeout()function can be a daily timeout, a one-time timeout, a timeout based on seconds, minutes, or hours, and other variations involving time. Other uses of timeouts could be an execution of jobs to run, more messages to send based on time, performing a timeout to update the originator of a status, and many more uses.In this scenario, we give the message three hours to perform its operations before timing it out. The following screenshot displays the code for providing timeouts:
Because the saga pattern has the ability to persist the message's state data, the messages become connectionless pieces of separate messages and provide a means to connect multiple messages to each other to perform end-to-end flow. Thus, the saga becomes the focal point of the interaction. The messages now have a behavioral pattern as they have more meaning than a single instance. They now have a long time to live, as when the individual message is no longer available, the saga data representing data for the message will still live on, until it is marked to be destroyed.