One of the problems I have encountered with NServiceBus is the issue of the UI reacting instantly to a user's request. The asynchronous nature of NServiceBus is somewhat in conflict with it.
Take the following example: A grid shows a list of records, each with a delete 'X' on them. The user clicks the X, which sets a 'Deleted' flag and publishes an NServiceBus event, so other systems are informed about the deleted record. (The will possibly be other actions, like adding to an audit trail, updating other entities that were dependant on that record etc).
Conventional architecture in NServiceBus dictates that when the 'X' is clicked, a command is sent from the controller, and the handler for this command performs all the actions, including publishing the event.
But how do we update the grid? We can't just requery the data as we can't be certain the command has been processed. Common practice in NServiceBus is to do one of the following:
- We forward the user to a new view which says something like 'You request is being processed, it make take a moment for the grid to be updated' and a link back to the list of records.
- We manually remove the record from the existing grid using javascript.
Option 1 - The 'In Progress' Flag
This involves immediately setting a 'deleting in progress' flag, and then sending the command to carry out the rest of the work:
public ActionResult DeleteRecord(Guid recordId)
{
using(var transactionScope = new TransactionScope())
{
var record = _recordRepository.GetById(recordId);
record.MarkAsDeletingInProgress();
_recordRepository.Save(record);
_bus.Send(new DeleteRecord { RecordId = recordId });
transactionScope.Complete();
}
return RedirectToAction("Index");
}
And the message handler would look like this:
public void Handle(DeleteRecord message)
{
var record = _recordRepository.GetById(recordId);
record.Delete();
_recordRepository.Save(record);
_bus.Publish(new RecordDeleted{ RecordId = recordId });
}
This way, we can return the grid and the record will either not be present or will be displayed as 'deleting in progress', so the user will have some definite feedback.It is important that the flag is set and the command is sent within the same transaction to avoid inconsistencies creeping in. The 'using' statement above may not be needed if the request is within a transaction.
Option 2 - Request/Response
Generally frowned upon by the NServiceBus community, synchronous communication is an included feature and can be a useful option. If the command is sent, the message handler can update the database and publish the event. If the command is handled synchronously, by the time it has returned, we can be sure the data has been updated and we can therefore query it.
public void DeleteRecordAsync(Guid recordId)
{
_bus.Send(new DeleteRecord { RecordId = recordId })
.Register<ReturnCode>(returnCode => AsyncManager.Parameters["returnCode"] = returnCode);
}
public ActionResult DeleteRecordCompleted(ReturnCode returnCode)
{
return RedirectToAction("Index");
}
And the message handler would look like this:
public void Handle(DeleteRecord message)
{
var record = _recordRepository.GetById(recordId);
record.Delete();
_recordRepository.Save(record);
_bus.Publish(new RecordDeleted{ RecordId = recordId });
_bus.Return(ReturnCode.OK);
}
This way, everything in our local domain is handled synchronously, while everything in other services/domains is handled asynchronously. There is even the option that the event can be handled in the local domain, and work can be done asynchronously there.This may lead to some inconsistencies if the UI is gathering some of that asynchronously handled data, so this technique should be used with caution. However, in the right circumstances, this can be a good way of separating things that NEED to be synchronous from those that CAN be asynchronous.
There is no need for the using transaction statement in this case as NServiceBus message handlers are always run within a transaction by default.
Option 3 - Continuous Polling
Poll for completion and update the UI when the command has been completed. Don't do it.
Option 4 - SignalR
A technology I have not yet investigated. This could be interesting but without knowing more about it I can't comment further.
Option 5 - Publish Events from the Web Application
Another suggestion that raises eyebrows. The main reason for sending the command in the first place was so we can raise the event, so why not just do all the database work in the web application (or other assembly directly referenced) and raise the event from there? I won't cover this here because I intend to cover this and its problems in a future post. However, for now I will just list it as an option.
Thank you to Udi Dahan, Andreas Öhlund and Jimmy Bogard for posting on the thread, as well as the many other contributors. My particular favourite is the interaction Jerdrosenberg described here. I think there are a lot of us who have been through this scenario and it is the kind of thing that prompted me to start the thread and write this post.
