Book Image

Learning NServiceBus - Second Edition

By : David Boike
Book Image

Learning NServiceBus - Second Edition

By: David Boike

Overview of this book

Table of Contents (18 chapters)
Learning NServiceBus Second Edition
Credits
Foreword
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Running the solution


One thing that will be useful when developing NServiceBus solutions is being able to specify multiple startup projects for a solution:

  1. In Solution Explorer, right-click on the solution file and click on Properties.

  2. From the left side, navigate to Common Properties | Startup Project.

  3. Select the Multiple startup projects radio button.

  4. Set the Action for the service project and the MVC project to Start and order them such that the MVC project starts last.

  5. Click on OK.

Now build the solution if you haven't already, and assuming there are no compilation errors, click on the Start Debugging button or press F5.

So what happens now? You get a result that looks like what is shown in the following screenshot:

When you run the solution, both the MVC website and a console window should appear as shown in the preceding screenshot. As we can see, the browser window isn't terribly exciting right now. It's just showing the JSON results of the /Home/Index action. The console window is far more interesting.

If you remember, we never created a console application; our service endpoint was a class project. When we included the NServiceBus.Host NuGet package, a reference to NServiceBus.Host.exe was added to the class project (remember that a .NET executable is also an assembly and it can be referenced by another project) and the project was set to run that executable when you debug it.

NServiceBus uses different colors to log messages of different levels of severity. INFO messages are logged in white, and WARN messages are displayed in yellow. In addition, there can be DEBUG messages, also displayed in white, or ERROR and FATAL messages which are both logged in red. By default, the INFO log level is used for display, which filters out all the DEBUG messages here, and luckily we don't have any ERROR or FATAL messages.

The entire output is too much to show in a single screenshot. It's worth reading through, even though you may not understand everything that's going on quite yet. Here are some of the important points:

  • NServiceBus reports how many total message types it has found. In my example, two messages were found. Only one of them is ours; the other is an administrative message, which is used internally by NServiceBus. If it had said that no messages were found, that would have been distressing! We will revisit this message in Chapter 5, Advanced Messaging.

  • The License Manager checks for a valid license. You can get a free trial license that allows unrestricted non-production use for a limited time. After that, you need to purchase a commercial license, although Particular may be willing to extend your trial if your situation merits it. For all questions about licensing, go to http://particular.net/licensing. Every situation is different, so don't hesitate to contact Particular to find out which licensing structure will work best for you.

  • The status of many features is listed for debugging purposes.

  • NServiceBus checks for the existence of several queues and creates them if they do not exist. In fact, if we go to the Message Queuing Manager, we will see that the following private queues have now been created:

    • audit

    • error

    • exampleweb

    • exampleweb.retries

    • exampleweb.timeouts

    • exampleweb.timeoutdispatcher

    • userservice

    • userservice.retries

    • userservice.timeouts

    • userservice.timeoutsdispatcher

Note

If you installed the Service Platform, there could be queues for error.log and several queues starting with particular.servicecontrol as well. We'll discuss these in depth in Chapter 8, The Service Platform.

That's a lot of plumbing that NServiceBus takes care of for us! But this just gets the endpoint ready to go. We still need to send a message.

Visual Studio will likely give you a different port number for your MVC project than the number in the preceding example, so change the URL in your browser to the following, keeping the host and port the same. Feel free to use your own name and email address:

/Home/CreateUser?name=David&[email protected]

Look at what happens in your service window:

INFO  UserService.UserCreator Creating user 'David' with email '[email protected]'

This might seem simple, but consider what had to happen for us to see this message. First, in the MVC website, an instance of our message class was serialized to XML. Then that payload was added to an MSMQ message with enough metadata to describe where it came from and where it needs to go. The message was sent to an input queue for our background service, where it waited to be processed until the service was ready for it. The service pulled the message from the queue, deserialized the XML payload, and was able to determine a handler that could process the message. Finally, our message handler was invoked, which resulted in the message being output to the log.

This is a great start, but there is a great deal more to discover.