MassTransit 3.2.1 — Проверка

Я хочу проверить входящее сообщение, используя FluentValidation в моем случае, и в случае сбоя оно должно немедленно вернуться. Я просмотрел http://docs.masstransit-project.com/en/latest/usage/observers.html, и в моем случае мне нравится идея

public class ConsumeObserver : IConsumeObserver
    {
    Task IConsumeObserver.PreConsume<T>(ConsumeContext<T> context)
    {
        //1.Validate here
        //2. If success go on to consumer
        //3. If fails exit with the result of validation and don't go through consumer.
    }

    Task IConsumeObserver.PostConsume<T>(ConsumeContext<T> context)
    {

    }

    Task IConsumeObserver.ConsumeFault<T>(ConsumeContext<T> context, Exception exception)
    {

    }
}

because I get the message already deserialized and so is easy to use the validator. The problem is that I don't know how to return without going through consumer and a the same time keep the validation errors.

Спасибо.


person Gradinariu Cezar    schedule 08.03.2016    source источник


Ответы (1)


Наблюдатели обычно наблюдают, а не действуют, и это подход к наблюдателям в MassTransit. Хотя вы можете сгенерировать исключение из метода PreConsume, что приведет к повторной попытке сообщения или его отправке в очередь ошибок, это не самое очевидное поведение для разработчиков в будущем, которые могут не понимать, почему сообщение не работает.

Другой подход заключается в создании компонента промежуточного программного обеспечения, который может проверять сообщение и, если оно недействительно, выполнять определенное действие над сообщением (например, перемещать его в недействительную очередь, выгружать его в журнал и т. д.), чтобы сообщение удаляется из очереди. Важно понимать, как это может повлиять на производителя сообщения.

Например, если это было сообщение с запросом, и отправитель ожидает ответа, отбрасывание сообщения означает, что ответ не будет получен. По умолчанию потребитель, выбрасывающий исключение, передает ошибку обратно запрашивающей стороне, завершая цикл, так что имейте это в виду.

Другой вариант — просто добавить поведение проверки к потребителю, используя либо внедренный интерфейс проверки, либо внутри самого потребителя. Таким образом, обработка сообщения становится ближе к потребителю, что улучшает связность кода и позволяет легко увидеть, что происходит.

В идеале проверка у производителя сообщений является лучшим вариантом, чтобы избежать переполнения очереди недействительными сообщениями. Так что это еще один вариант.

Итак, несколько вариантов, ваши требования будут диктовать, какой из них имеет наибольший смысл.

person Chris Patterson    schedule 08.03.2016