Move Message from Error Queue to source queue

[Gaurav Yadav]

Helpful information to include

Product name: NServiceBus

Version:5.2.8, 

Stacktrace:

Description: How to move a message which has landed in the error queue back to the source queue [SQL Server Transport], Is there a Service Control API which allows that  (doing it through Service Pulse is not a valid business scenario).

[Daniel Marbach]

Hi Gaurav

Can you explain why this is not a valid business scenario? Does it need to be fully automated? Other reasons?

Thanks 

Daniel

[Gaurav Yadav]

Hi Daniel,

Yes, It has to be fully automated. To explain the complete scenario:

1. 100 Messages were sent by a business user from our web app to automation queue which initiates a multi step SAGA for each message
2. Out of 100 SAGA's 3 failed at diff steps even after retries and landed in the error queue 
3. For all 3 failed messages the user gets an alert about message being moved to error Queue
4. Now the message is available in the Failed messages tab of Service Pulse for retry but business users do not want to get involved with another tool [we also think Service Pulse is meant for IT-OPS and not end user]
5. Now business user wants to change the state of the system for these 3 messages and expects that a re-try should be triggered automatically without having to ask someone to do this from Service Pulse

In doing so we are facing two problems:

1. How to move the message from error queue to source queue, I was guessing since Service Pulse is already doing this via Service Control there might be some API call which we can use ?
2. We are subscribing to MessageSentToErrorQueue notification (code attached) but this does not give us access to Message data so we are unable to map it to the Case/Order to which this message belongs  

[Daniel Marbach]

Hi,

I suggest you use the service control events instead of the bus notifications.

http://docs.particular.net/servicecontrol/contracts

With ServiceControl events it is possible to acquire more information about the failed messages like shown in the following example

class MessageFailedHandler : IHandleMessages<MessageFailed> { public void Handle(MessageFailed message) { string failedMessageId = message.FailedMessageId; string exceptionMessage = message.FailureDetails.Exception.Message; using (var client = new HttpClient()) { client.Post("serviceControlURI/errors/retry", payload); } }

you can see what is available on the message here

https://github.com/Particular/ServiceControl.Contracts/blob/master/src/ServiceControl.Contracts/MessageFailed.cs

When you have the message id you can then issue a POST request against the following ServiceControl API

/errors/retry

the payload needs to contain a JSON list of message ids.

Attention: The ServiceControl APIs are still considered internal and are suspected to change. That's why there is no documentation available.

Regards

Daniel

[Ramon Smits]

Guarev,

You can also prevent messages from going to the error queue by tweaking the retry settings. For example, increasing the amount of retries or adding a custom retry policy. This can help if you want to increase the number of attempts over a longer period of time if that would resolve the tehnical issue.

http://docs.particular.net/nservicebus/errors/

Usually, messages that end up in the error queue end up there because of technical reasons. This is the reason that an IT-OPS role would be responsible for resolving such a technical issue and then has the ability to retry the messages that failed due to that reason.

It might be that in your case you want end users to 'retry' messages. Might this be because of a specific business condition like an incorrect status or other type of business rule? in that case, I would say that these are functional errors. Functional errors should not end up in the error queue but acted on in the system or user itself. This could mean that a user needs to perform a task that results in changing a status in order for the previous functionally failed message to now trigger the correct task. Using regular error logic means that all of such business rule violations would end up in a single error queue which seems incorrect thus of an incorrect usage of ServiceControl API to retry such operations by the end user.

Regards,

Ramon

[Gaurav Yadav]

Hi Daniel,

I have made significant progress with MessageFailedHandler and the Service Control retry API but got stuck with a small issue. I have access to the message body in MessageFailed.MessageDetails.Body but this is a JSON string, since all my commands inherit from a base command class I am trying to de-serialize this JSON string but can't figure out how.

Have tried Newtonsoft.Json.JsonConvert and System.Web.Script.Serialization.JavaScriptSerializer but both of them are throwing exceptions.

I tried going through the JsonMessageSerializer class on Github but can't figure how to use that.

Can you help me figure how to get the message body desirialized [probably using the JSON Serializer used by NSB ]

Regards,

Gaurav