Edition 0 Updated to asp. Net core 0

Additional resources 
•
Honoring message idempotency
https://learn.microsoft.com/previous-versions/msp-n-p/jj591565(v=pandp.10)#honoring-
message-idempotency
 
Deduplicating integration event messages 
You can make sure that message events are sent and processed only once per subscriber at different 
levels. One way is to use a deduplication feature offered by the messaging infrastructure you are 
using. Another is to implement custom logic in your destination microservice. Having validations at 
both the transport level and the application level is your best bet. 
Deduplicating message events at the EventHandler level 
One way to make sure that an event is processed only once by any receiver is by implementing certain 
logic when processing the message events in event handlers. For example, that is the approach used 
in the eShopOnContainers application, as you can see in the 
source code of the 
UserCheckoutAcceptedIntegrationEventHandler class
 when it receives a 
UserCheckoutAcceptedIntegrationEvent
integration event. (In this case, the 
CreateOrderCommand
is 
wrapped with an 
IdentifiedCommand
, using the 
eventMsg.RequestId
as an identifier, before sending 
it to the command handler). 

---

151 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Deduplicating messages when using RabbitMQ 
When intermittent network failures happen, messages can be duplicated, and the message receiver 
must be ready to handle these duplicated messages. If possible, receivers should handle messages in 
an idempotent way, which is better than explicitly handling them with deduplication. 
According to the 
RabbitMQ documentation
, "If a message is delivered to a consumer and then 
requeued (because it was not acknowledged before the consumer connection dropped, for example) 
then RabbitMQ will set the redelivered flag on it when it is delivered again (whether to the same 
consumer or a different one). 
If the “redelivered” flag is set, the receiver mus
t take that into account, because the message might 
already have been processed. But that is not guaranteed; the message might never have reached the 
receiver after it left the message broker, perhaps because of network issues. On the other hand, if the 
“redelivered” flag is not set, it is guaranteed that the message has not been sent more than once. 
Therefore, the receiver needs to deduplicate messages or process messages in an idempotent way 
only if the “redelivered” flag is set in the message.