Spy internal messages using MSMQ in a separated system.

As an introduction, MSMQ is a messaging protocol that allows applications running on separate servers/processes to communicate in a failsafe manner. This mechanism uses a queue where, when a new item enters, this is place to the bottom of the queue. Only when all items that were before on the top of the queue are read, this new item will be reached.
To read and shift the top item, the Receive method must be called. If only it is necessary to read it, the Peek method can be used. Also, a GetAllMessages is available to read all messages. Nevertheless, neither GetAllMessages nor Peek methods does shift the cursor.

To remark, all these messages corresponds to the entity System.Messaging.Message.

Issues

The main issue regarding this scenario is that when all internal messages are consumed for the destination, then all these consumed messages cannot be consumed again by our spy. Therefore, MSMQ cannot be used in scenarios where there are several listeners, without tricks.

Solution

This chapter suggests a possible solution to solve the scenario where messages can be read with several listeners using MSMQ. Nevertheless, this solution requires some minimal and non-critical changes in the server which send the messages.

This suggested solution uses the Journal queue feature of MSMQ. The only required changes in the sender side are:

- Set UseJournalQueue property in Message to true before to send.

- Set AppSpecific property in Message to a special identifier before to send.

UseJournalQueue enables to copy the message into a special queue in MSMQ named Journal when this message is consumed for the destination.

AppSpecific enables to filter the messages in the journal queue to retrieve only the necessaries ones to listen. To read this property in any listener, the method SetAll in MessageReadPropertyFilter within the MessageQueue instance must be called.

Therefore, the spy reads the Journal queue and does not disturb the communication between sender and the internal listener within external system.

- Advantages
        o Destination need to modify nothing.
        o Minimal changes in sender.
        o Efficient decoupled solution with security requirements (sender chooses whether want to do it)
        o Only includes messages that have arrived to the destination.
- Disadvantages
        o Journal queue can grow a lot. Purge action once per day must be required.

Other solution might be the replication of messages (through of Peek and Receive mechanism) that have been received by the internal listener of external system. Nevertheless, there would be a lot of changes in the internal listener to modify and, also, there would be necessary to add a special identifier to avoid read again. This solution would be very coupled with spy and this is not a good scenario since spy is an optional feature.

Another choice to achieve this feature, it would be using MSMQ triggers but this is a more complex solution and this would require extra configuration in MSMQ server.

Conclusion

The suggested solution applies all requirements using a very simple solution achieving security and decoupled mechanism.