Определить и повторно запустить определенные события в Axon

Question

Мы изучали повторный запуск выбранных вручную событий из аксона. Пример использования будет примерно таким:

Если событие регистрации пользователя завершилось неудачно, даже если команда была успешной, мы хотим повторно запустить это конкретное событие для указанного c обработчика событий.

Мы рассмотрели возможность использования обработчика событий отслеживания, но, похоже, это воспроизведение набора событий ИЗ определенного c момента времени. Однако в нашем случае, если бы вчера было 100 событий, мы бы хотели перезапустить только конкретное событие в середине.

В настоящий момент мы находимся в процессе миграции на Axon и поэтому решили go преимущественно с SubscriptionEventProcessors, поскольку он более синхронный (т. Е. Ошибки распространяются вверх по обработчику команд). И мы понимаем, что процессоры подписки не имеют состояния, поскольку они обрабатывают только то, что они получили через шину событий.

Итак, я предполагаю, что мы не можем использовать процессор отслеживания? а вместо этого нам нужно загрузить конкретное событие и повторно sh его в шину событий?

Как мы могли бы этого добиться? (С указанным выше предложением или без него)

Также, что касается идентификации исключений, мы думаем об использовании аспектов, регистрации и чтения конкретной строки журнала для исключений. Однако мы заметили модуль отслеживания аксона и пружинного ботинка. https://github.com/AxonFramework/extension-tracing Однако упоминается, что он находится в стадии бета-тестирования, и мы также не смогли найти много справочных документов. Есть ли лучшее решение, основанное на аксонах?

Answer 1

Чтобы быть быстрым, я бы использовал ответ, аналогичный тому, который я опубликовал на этот вопрос.

Reha sh мой ответ там быстро, его можно резюмировать by: Создайте модель запроса, содержащую необходимые аннотированные методы @EventHandler для «повторной обработки», которые вы должны предоставить в качестве входных данных конструктору Axon AnnotationEventHandlerAdapter. Вы должны вызвать следующий AnnotationEventHandlerAdapter с отфильтрованным потоком событий на основе ваших требований. В результате модель запроса будет обновлена ​​до нужного вам формата.

Таким образом, вместо того, чтобы выполнять ее как форму запроса, потому что пользователям требуется эта информация, вы должны выполнить операцию в исключительном случае. Тем не менее, вы все равно будете формировать модель запроса заново, но только на основе определенного c набора событий.

Кстати, когда дело доходит до выбора обработчика событий, я бы все равно go для TrackingEventProcessor. Да, это означает, что сбой события не приведет к откату, но, по сути, событие указывает, что оно произошло. Таким образом, откат, потому что что-то еще не может обработать это событие, неверен; команда все еще выполнена успешно, поэтому она тоже должна оставаться такой.

Наконец, вы ищете logi c. Расширение трассировки, которым вы поделились, совсем недавно было выведено из бета-статуса и, следовательно, может безопасно использоваться. Далее, ведение журнала basi c уже может быть достигнуто путем настройки LoggingInterceptor как MessageHandlerInterceptor и MessageDispatchInterceptor (документацию по этому поводу можно найти здесь ). И если вы хотите представить Aspect logi c: Axon имеет механизм, аналогичный t ie, в каждом обработчике сообщений. Взгляните на HandlerEnhancer / HandlerEnhancerDefintion на эту страницу.

Надеюсь, все это поможет вам @MilindaD!