Argthtjtr

I am new to AXON framework and are using it for our development. We have a requirement where command (command side) is created for the persisting data, for the same event is triggered which is consumed at query side. Now we need to have a response back to command side from query side which says if the record is persisted into database successfully (custom successful message) or if failed then the reason of the failure (custom exception message as response). Kindly help if there is any way to achieve such scenario.

Here command side and query side are 2 different micro-services and we are using Rabbit Mq for event driven technique.

Thanks in advance

I think that what you are asking is if there is a way for the command and event to be processed in a single transaction?

If you use a subscribing event processor, running in the same JVM, the event is processed synchronously and the whole transaction is rolled back in case of an exception in an event handler. This is not the case here, because you have loosely coupled separate services, which is good.

It's best practice for the aggregate with the command handler to have all the information available to decide whether or not the command can successfully be processed, and when an event is applied, this is a signal that it has happened, and the other services (the query side in this case) have to be informed. It's not good practice for a query module to overrule this ("you say it happened, I say it didn't"). If there is an error in the query side, you fix it, and replay the event.

If it really is an error in the event handler that the whole system must know about, that is really a separate event. You can apply such an event directly on the event bus and notify the whole system. Something like this:

 @Autowired

 private EventBus eventBus;



 (...)



 CatastrophicFailureEvent failureEvent = new CatastrophicFailureEvent("OH NO!");

 eventBus.publish(GenericEventMessage.asEventMessage(failureEvent));

I think you might need to reconsider your architecture. Keep in mind that events should encapsulate the irreversible state changes of your system. These state changes should not be questioned after they have happened. Your query side should only need to care about projecting these valid state changes that your command side has decided on.

If you need to check whether a user already existed, you need to do this on the command side in your aggregate. The aggregate can keep a list of all the existing usernames and throw an exception if an invalid command is given. The command response (tip: using the sendAndWait() method on the CommandGateway returns a response) can then be used as the system to inform your user about the success/failure of its action.

The following flow might solve your problem, but keep in mind that the user will get a callback on the success of the action even though the query side might not have processed its result yet. This part is eventually consistent.

Command Side:

1. Request from frontend handled by a Controller class and creates an corresponding command


2. The above command is invoked and handled by a command handler which creates the corresponding event or throws an exception if the user already exists.


3. The invoker of the command is informed about the success of the command or the exception is handled and the error shown to the user.


4. The above event is published through rabbit mq event bus if the command was successful.

Query side:

5. The event that is published in the step 4 is consumed by the event handler in query side. No checks or validations should be necessary, since they were already handled on the command side.

@Mzzl
Series of activities

Command Side:

1. Request from frontend handled by a Controller class and creates an corresponding command

2. The above command is invoked and handled by a command handler which in return create corresponding event

3. The above event is then published through rabbit mq event bus.

Query Side:

4. The event that is published in the step 3 is consumed by the event handler in query side.

5. The event handler has the logic to perform db transaction (lets assume add a user). Once a user is added then a success message or failure message (lets assume user already available in the DB so could not create duplicate entry) should flow from query side to command side and eventually back to UI as a repsonse.

I'm not sure I've fully understand your issue (especially the microservice part :)),
but if your problem is related to having the query side up to date after the command execution, then you can have a look at this project.

In this example, you can see that he uses a SubscriptionQueryResult in conjunction with a QueryUpdateEmitter (see here)

Basically you will subscribe to query side changes before the command is issued, and you will block after the command execution until the query side send a notification when it is up to date.

This way you can avoid the eventual consistency.