we're evaluating nservicebus at my company for a rewrite of our sales process. we'll be using sagas and web api. we ran into a block handling responses on the client side. we're using Handling Responses on the Client Side for guidance.
from our client controller we have this code:
[Route("CreateProduct")]
public ActionResult CreateProduct()
{
ProductCreatedResponse message = null;
var product = new TestProduct { Id = ObjectId.GenerateNewId().ToString() };
var command = new StartProductCommand { ProductId = product.Id, ProductName = "Product1" };
var sync = ServiceBus.Bus.Send("Io.Server." + command.ProductName, command)
.Register(ar =>
{
var localResult = (CompletionResult)ar.AsyncState;
message = (ProductCreatedResponse)localResult.Messages[0];
ViewBag.ResponseText = message.Status;
}, null);
sync.AsyncWaitHandle.WaitOne();
return View("Index");
}
from our saga's handler we have this code:
public void Handle(StartProductCommand message)
{
Data.ProductId = message.ProductId;
Data.Status = "Product Created";
var productCreatedResponse = new ProductCreatedResponse { Status = Data.Status };
_bus.Reply(productCreatedResponse );
}
localResult.Messages is null. what am i doing wrong?
Callbacks can only handle int or enums: http://docs.particular.net/nservicebus/messaging/handling-responses-on-the-client-side
Take also a look at the warning on the above page:
"If the server process returns multiple responses, NServiceBus cannot know which response message will be the last. To prevent memory leaks, the callback is invoked only for the first response. Callbacks won't survive a process restart (common scenarios are a crash or an IIS recycle) as they are held in memory, so they are less suitable for server-side development where fault-tolerance is required. In those cases, sagas are preferred."