I need to map one message to multiple saga instances.
how can i do it?
i thought to an utility service that receives that message and sends copies of it to all saga instances. But this solution requires the knowledge from this service of all sagaIds.
This isn't currently supported on a single endpoint. If you want multiple sagas to handle the same message, that message needs to be processed by multiple endpoints.
Can you design your solution differently not to need multiple sagas to be invoked per message?
Related
I use Nservicebus 5 with RabbitMQ, and I want to send different messages to different queues under the same uow. Is it possible ?
using (_NsbunitOfWork)
{
_NsbunitOfWork.Begin();
_busSms.Send(smsmessage);
_busOffer.Send(offermessage);
_busTrnx.Send(Trnxmessage);
_NsbunitOfWork.Commit();
}
I'm not sure what you're trying to accomplish? I'm assuming you want to send messages to different queues, so that different applications can process these messages? In the documentation these are usually called endpoints.
If you read the routing documentation, you'll notice that the sender code should not be aware of where the message should be sent. This is what routing takes care of. So you could do multiple calls to context.Send() and NServiceBus would figure out where to send the message to.
Does that make sense? You could also try https://discuss.particular.net/ which is more suited for NServiceBus related discussions with multiple replies, or try support#particular.net
I have a complex business logic process that includes 4 different servers (each performs different part of the process).
I used WCF web service to every server.
Now I want to use NServiceBus in this process. The saga feature sounds exactly what I need how ever I don't quit understand how to implement this process - do I need to create handlers in the saga so that each of them will call a webService?
Or can I put the same saga host on every server so that each server will handle it's part of the process?
You could have the orchestration between the servers performed as an NServiceBus saga, where it sends messages (rather than calling webservices) to the other servers. You'd have message handlers on those servers which perform the logic, and return messages back (as needed).
All that being said, a more detailed explanation of your process and the logic itself may lead to an alternative design.
We have a bunch of requests that we plan to publish to the queue.
There will be several different subscriber types, each in their own round robin pool.
For example Request1 is pushed onto the queue
LoggingSubscriber1 and LoggingSubscriber2 both subscribe with the "LoggingSubscriber" subscriptionId so that only one of them gets the request.
There will be other groups like DoProcessSubscriber1, DoProcessSubscriber2, and DoProcessSubscriber3
And another DoOtherProcessSubscriber1, DoOtherProcessSubscriber2
We need some way to know that all three subscribers (Logging, DoProcess, and DoOtherProcess) have completed, so that we can perform some action...like sending a message to the client that all the entire request has completed.
How would we aggregate responses like this? We were thinking of having each subscriber put a response object on the queue, but we still aren't sure how to know that they are all done.
Ideally you'd use the Request/Response pattern built into EasyNetQ, but that's designed for a single (potentially farmed) consumer. It doesn't allow you to bind to multiple queues. In your case you should probably have your client set up a subscription for replies and have all three services publish a message when they are complete. The client can then wait until it has a response from all three before updating.
However, I'd encourage you to possibly re-think your design. By making the client responsible for acknowledging the completion of the subscribers, you're building a very tightly coupled system. Messaging System design works far better if you adopt the notion of eventual consistency. Allow your client to fire-and-forget and have some audit process ensure that all the expected processing did eventually occur.
I have a situation where the Maxtries in my MSMQ is 5. After 5 times nservicebus sends the message to the Error que that I have defined. Now I want to perfomr some further action when this happens (I have to update status of some processes to Error)
Is it possible to write a handler in my Saga class to read these error queues?
Thanks in Advance
Haris
If your are using 2.x you may want to consider writing a separate endpoint where the error queue is its input queue. The downside to this is that the messages will come off the queue. Assuming you still want to store them, you'll have to push them off to a database or some other type of storage.
You could also write a Saga that polls the error queue to check for messages and updates the appropriate status. After each time you check the queue, you would need to request another Timeout.
In 3.0, you have more control over the exceptions, and can implement your own way to handle the errors. If you implement the interface IManageMessageFailures, you can do your work there.
As an alternative to the solutions provided by Adam, you can subscribe to events raised by ServiceControl which are raisesd when a messages is sent to the errorqueue. See the official documentation about this here: http://docs.particular.net/servicecontrol/contracts
Another approach would be the notification API as described here: http://docs.particular.net/nservicebus/errors/subscribing-to-error-notifications. It allows you to subscribe to certain events (not event messages) like "MessageSentToErrorQueue" directly on the endpoint, so you wouldn't need to consume the error queue.
I am calling a WCF service which contains the business logic to process the message objects.
I need to pass the id of the message to WCF service. We are using MSMQ for queuing up the requests.
There could be multiple messages that WCF service need to process which can be handled as follows
Send the message id one by one
Send array of message ids and then WCF service will iterate through each id and process the message object.
Performance point of view I believe second option is better as multiple requests to WCF are not there.
Is my assumption correct?
-
Ram
Number 2 is more efficient in terms of latency but does not give you the chance to spread the processing load by having multiple queue readers
Also be aware that if you use a transactional queue and sessions then WCF may put more than one SOAP message in each MSMQ message