Event design and testing

[jrobertshawe]

Hi there -
First thanks for a great project that has helped me tremendously and provided me with a great template for my project.

I have a question around events testing with a event driven micro service that does complex calculations
In the customer domain all the processing around capturing and storing the customers details. Once completed and with every update, a payload is sent via an event to the calc service that has it's own database to calculate a premium and this is returned to the customer service via an event payload.
Is this a correct design to use events for a round trip process?
What is the recommendation to test the round trip is successful via function testing using a development service bus

thanks in advance :)
Julian

[mvelosop]

Hi @jrobertshawe,

Even though this is not related to eShopOnContainers, it's a pretty interesting question 👍

I'll just throw in my two cents, just in case it helps somehow.

If I understood it correctly, you are essentially implementing an asynchronous command based on events.

That adds complexity because the essence of events is they are "fire-and-forget" and, since these are commands and you have to know the result, it's not fire-and-forget, and hence the additional complexity.

Perhaps (but as usual, it depends on the context) a better pattern could be creating a queue of documents to be calculated and then synchronously access the other microservice to get the result.

This way, as a whole, they would be processed asynchronously because they are in a queue, but each command is executed synchronously, so it's pretty easy to get the result.

This might not be so easy in your context, so take this with a grain of salt.

You might want to take a look at this section of the Microservices Guide that goes along with this repo, for it's related to your issue.

Hope this helps.

[mvelosop]

I forgot to include a link regarding the testing part of your question, you might also want to take a look at this page: https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/test

[jrobertshawe]

Thanks Miguel for your response :) I agree that it will add complexity to the design implementing a async command and process the result by consuming a returned event on the service bus. I looked at the example in eShop and can not see how the basket service gets the result from the create order command. If the UI calls the other service API to get the result and then calls a local API to save the result to the domain it is impossible to ensure the process completes and the data is saved (user closes browser) If the record owner service calls the other service's API then this will affect scaling and creates a bottleneck Is there a recommendation I could implement/research that would allow a command handler to return the result between services without tight coupling or locking Thanking you Julian

…

On 30/01/2019, at 1:17 AM, Miguel Veloso ***@***.***> wrote: I forgot to include a link regarding the testing part of your question, you might also want to take a look at this page: https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/test <https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/test> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#924 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACIxrl9lAXVIBZM2HlzqCxNaqrbd0ICpks5vIDvxgaJpZM4aT-2k>.

[mvelosop]

Hi @jrobertshawe,

The UI doesn't work as an intermediator between any two microservices, it just pushes it's updates to one of them (Ordering, for example) and then waits for the events/messages in the server to notify it back (using SignalR)

The general process flow is like this:

• A post from the user gets to and API controller that creates a command or publishes and integration event
• If it's a command it gets handled by a command handler
• The command handler might publish an integration event
• When the integration event is handled in another microservice it usually creates a command
• The command handler in the receiving microservices does the update or whatever it might again publish another integration event and so on.

I suggest you to follow the "trip" that originates from the Checkout action in https://github.com/dotnet-architecture/eShopOnContainers/blob/dev/src/Web/WebMVC/Controllers/OrderController.cs

Hope this helps.

[jrobertshawe]

Thanks Miguel, I am following the example and embracing the command handler. I am extending the process by raising an event from the service to return the result to the microservice that will store the value in the domain. I like this model as it will visualise integrations as messages in both directions on the event bus. I would like to update you when I have completed the async event command that expects a result event raised either successful or failed. I am very interest on scale and ability to auto recover using this model on k8s regards Julian

…

On 31/01/2019, at 9:25 AM, Miguel Veloso ***@***.***> wrote: Hi @jrobertshawe <https://github.com/jrobertshawe>, The UI doesn't work as an intermediator between any two microservices, it just pushes it's updates to one of them (Ordering, for example) and then waits for the events/messages in the server to notify it back (using SignalR) The general process flow is like this: A post from the user gets to and API controller that creates a command or publishes and integration event If it's a command it gets handled by a command handler The command handler might publish an integration event When the integration event is handled in another microservice it usually creates a command The command handler in the receiving microservices does the update or whatever it might again publish another integration event and so on. I suggest you to follow the "trip" that originates from the Checkout action in https://github.com/dotnet-architecture/eShopOnContainers/blob/dev/src/Web/WebMVC/Controllers/OrderController.cs <https://github.com/dotnet-architecture/eShopOnContainers/blob/dev/src/Web/WebMVC/Controllers/OrderController.cs> Hope this helps. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#924 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACIxrgVJQbt7ziSvcDzOTCX4BpsD2Wztks5vIf-wgaJpZM4aT-2k>.

[mvelosop]

Hi Julian, I'm glad this could help!

I'm marking this as a Question for future reference.

Do you think this issue can be considered answered?

[jrobertshawe]

Yes thanks

…

On 5/02/2019, at 10:40 AM, Miguel Veloso ***@***.***> wrote: Hi Julian, I'm glad this could help! I'm marking this as a Question for future reference. Do you think this issue can be considered answered? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#924 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACIxrn-zoBbW4VeIWA_7Y0weoHxqAXRnks5vKKjEgaJpZM4aT-2k>.