Summary

Team Fly

Page 388

To test the application, you must first create the OrderTrigger trigger. This trigger is attached to the NWOrders queue and its ''Message processing type" setting should be Peeking. Its rule is the NWOrderRule, which has no conditions (it's fired every time a new message arrives at the NWOrders queue) and its action is the ProcessOrders.exe application. Check the box "Interact with the desktop" on the Rule Action tab of the NWOrderRule rule's property pages, so that the console window will appear on your desktop and you'll be able to interact with it. Figure 14.12 shows the Rule Action tab for the NWOrderRule, as well as the Parameters window.

FIGURE 14.12 Setting up the NWOrderRule rule for the OrderTrigger trigger

Assuming that you've set up the OrderTrigger trigger in the MSMQ snap-in, switch to the ProcessOrders project and build it. This project isn't meant to run on its own, because it should be called by a trigger, which is also responsible for passing the appropriate arguments to the application as command-line arguments. Switch to the DisconnectedOrders project and create a new order. As soon as the new order message is written to the NWOrders queue, the OrderTrigger will be fired, which in turn will invoke the ProcessOrders console application. You will see a console window that looks like the window of Figure 14.13. The data shown in this window correspond to those in the order shown on the form of the DisconnectedOrders project of Figure 14.14.

Summary

In this chapter you learned how to build applications running on loosely coupled systems. Large systems may involve computers that are not part of the same local area network, and we can't assume that all the computers we need to access are always online. To pass information from one system to another in a reliable, fail-safe way, we use messages.

Team Fly