Shut down the Shut Down Event Tracker

by community-syndication | Jan 15, 2011 | BizTalk Community Blogs via Syndication

• click start, select run
• type ’gpedit.msc’ and hit enter
• select ’local computer policy’
• select ’computer configuration’
• select ’administrative templates’
• select ’system’
• change the value of ’display shutdown even tracker’ to ’disabled’

WCF: 4 Tenets of Service Oriented Data Validation

by community-syndication | Jan 15, 2011 | BizTalk Community Blogs via Syndication

Remember the 4 tenets of SOA?  One of them is that Boundaries are explicit.  When somebody sends data to your service it is just like when you cross an international border into another country.  Just a couple of hours drive north of us in Redmond is the border crossing to Canada.  When you cross into Canada or back into the United States you have to stop your car and the border agents do their job.  Their job is to make sure that you have proper documentation and that you aren’t smuggling something (or someone) bad into the country.

Your service has to have a similar border checkpoint and it is at the trust boundary where data enters your “country”.  At the boundary you have to validate the data before it gets down deep into your business logic or database in some invalid form.  The question I want to focus on here is one of design.  Where should the validation be done?

Service Operation

Most of the time we tend to validate data on entry to the service method.  In small applications this approach is manageable but suppose you have a number (call it a Foo) that you use in 15 different services and you always pass it as an integer.  As you review the system you find that some services reject any negative Foo value while others reject any Foo value less than 1.  Your refactoring instinct tells you that it would be a good idea to centralize the Foo validation logic so you don’t end up with a variety of different validation rules.

Take a look at this code.  It works, but could it be better?

public bool SomeOperation(int foo)

{

    if (foo < 0)

    {

        throw new FaultException("Invalid Foo");

    }

    return ProcessTheFoo(foo);

}

The problem with this code is that

1. The validation rule (foo must be greater than zero) is contained within this service method.  If you use foo in another method or another service where it has the same semantic you have to be sure that your validation rule is followed there are well.  Once you code the rule in more than one place you have a system that is difficult to maintain and prone to inconsistent validation.
   
2. The response to failed validation is also contained within the service method.  In this case you throw a FaultException but there are many options for how to Fault the service (as I mentioned in my previous post) and once again the way in which you respond to the failure of validation now becomes spread across your codebase resulting in a fragile system.
   

Ron’s 4 Tenets of Service Oriented Data Validation

Services have to consume and receive data.  This data flows across the service boundary and therefore must be untrusted until validated.  I’m proposing some new tenets for service orientation.  These tenets describe validation rules.  Validation rules are an expression that tells you if the data is valid or not.

1. Validation Rules should be in one place
2. Validation Rules should apply to all layers of the app
3. Validation Rule violations should result in internal exceptions which may cause external faults
4. Validation Rules may be shared between sender and receiver

Validation Rules should be in one place

In your system you have to validate the state of an object.  The validation rules for object should be written once and only once.  This makes your system more maintainable..

Validation Rules should apply to all layers of the app

Service Oriented Applications consist of the service boundary and lower layers or business logic.  What makes an object valid at one layer should be the same as what makes it valid at another layer.  Lower layers of the system may use internal types which hold data in intermediate states that is not valid according to the rules.  When this is the case you should think of these types as being fundamentally different than the type that the validation rules apply to.

Validation Rule violations should result in internal exceptions which may cause external faults

If validation is called from internal service logic, validation rules should throw exceptions types appropriate for internal use such as ArgumentNullException or ArgumentOutOfRangeException.  At the service boundary if you want to propagate the error to the sender these exceptions must be converted to FaultException or FaultException<TDetail>

Validation Rules may be shared between sender and receiver

If the sender and receiver are able and willing to accept the tighter coupling that comes from sharing assemblies, you can share validation rules between sender and receiver.  If you share validation rules, the sharing should be limited to only the types exposed at the boundary

Scenario: Self-Validating Request Message

Given

• an entity named Foo which implements the IFoo interface

public interface IFoo
{
    int Data { get; set; }
    string Text { get; set; }
}

• a DataContract type named GetDataRequest with a property named Foo of type IFoo
• A class Foo that implements IFoo and does data validation in the property setter
• A class FooValidator that validates data on behalf of Foo
• An InternalFoo class that implements internal business logic

When

• The service is invoked with invalid data

Then

• WCF deserializes the message body and creates an instance of Foo
• The Foo property setters run validation code using the FooValidator
• the FooValidator methods throw ArgumentException
• and the Foo class converts the ArgumentException to a FaultException<TDetail> and throws
• The sender catches a FaultException<TDetail>

Conclusion

Sound complex?  Sure but it is one thing to build a simple example and quite another to show an architecture style that yields some significant benefits.  Of course there are many ways to accomplish these goals – you might have a better way – if so, please share it with me.

Happy Coding!

Ron

http://blogs.msdn.com/rjacobs

Twitter: @ronljacobs

WCF Spike FaultContract, FaultException<TDetail> and Validation

by community-syndication | Jan 14, 2011 | BizTalk Community Blogs via Syndication

Ready to have some fun? Today I spent the day investigating WCF FaulContracts and FaultException and some best practices for argument validation.  I’m going to do the same in a future post on Workflow Services but I felt it best to really understand the topic from a WCF point of view first.

Investigation Questions

1. What happens when a service throws an exception?
2. What happens if a service throws a FaultException?
3. What happens if the service operation includes a FaultContract and it throws a FaultException<TDetail>?
4. How can I centralize validation of DataContracts?

Scenario 1: WCF Service throws an exception

Given

• A service that throws an ArgumentOutOfRangeException
• There is no <serviceDebug> or <serviceDebug includeExceptionDetailInFaults="false" /> in web.config

When

• The service is invoked with a data that will cause the exception

Then

• The client proxy will catch a System.ServiceModel.FaultException
• The FaultCode name will be “InternalServiceFault”
• The Fault.Reason will be

"The server was unable to process the request due to an internal error.  For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs."

Conclusions

No surprises here, probably anyone who has done WCF for more than 5 minutes has run into this.  For more information see the WCF documentation Sending and Receiving Faults.  You might be tempted to just turn on IncludeExceptionDetailInFaults but don’t do it because it can lead to security vulnerabilities.  Instead you need a better strategy for dealing with exceptions and that means you need to understand FaultException

Scenario 2: WCF Service throws a FaultException

As we saw in the previous example, WCF already throws a FaultException for you when it encounters an unhandled exception.  The problem is in this case that we want to let the caller know they sent an invalid argument even when they are not debugging.

Given

• A service that throws a FaultException

public string GetDataFaultException(int data)

{

    if (data < 0)

    {

        // Let the sender know it is their problem

        var faultCode =

            FaultCodeFactory.CreateVersionAwareSenderFaultCode(

                ContractFaultCodes.InvalidArgument.ToString(), ContractConstants.Namespace);

        var faultReason = string.Format(Resources.ValueOutOfRange, "Data", Resources.ValueGreaterThanZero);

        throw new FaultException(faultReason, faultCode);

    }

    return "Data: " + data;

}

When

• The service is invoked with a data value that will cause an exception

Then

• The client proxy will catch a System.ServiceModel.FaultException
• The FaultCode.Name will be “Client” (for SOAP 1.1) or “Sender” (for SOAP 1.2)
• The Fault.Reason will be Argument Data is out of range value must be greater than zero

Conclusions

The main thing is that the client now gets a message saying that things didn’t work and its their fault.  They can tell by looking at the FaultException.Code.IsSenderFault property.  In my code you’ll notice a class I created called CreateVersionAwareSenderFaultCode to help deal with the differences between SOAP 1.1 and SOAP 1.2.  You will find it in the sample.

Some interesting things I learned while testing this

• You should specify a Sender fault if you determine that there is a problem with the message and it should not be resubmitted
• BasicHttpBinding does SOAP 1.1 while the other bindings do SOAP 1.2 so if you are working with both you need to do the version aware sender fault code.
• FaultException.Action never shows up on the client side so don’t bother with it.
• FaultException.HelpLink and FaultException.Data (and other properties inherited from Exception) do not get serialized and will show up empty on the client side so you can’t use them for anything.

While this is better than throwing unhandled exceptions, there is an even better way and that is FaultContracts

Scenario 3: WCF Service with a FaultContract

Given

• A service operation with a FaultContract
• and a service that throws a FaultException<TDetail>

var argValidationFault = new ArgumentValidationFault

{

    ArgumentName = "Data",

    Message = string.Format(Resources.ValueOutOfRange, "Data", Resources.ValueGreaterThanZero),

    HelpLink = GetAbsoluteUriHelpLink("DataHelp.aspx"),

};

throw new FaultException<ArgumentValidationFault>(argValidationFault, argValidationFault.Message, faultCode);

When

• The service is invoked with a data value that will cause an exception

Then

• The client proxy will catch a System.ServiceModel.FaultException
• The FaultCode.Name will be “Client” (for SOAP 1.1) or “Sender” (for SOAP 1.2)
• The Fault.Reason will be Argument Data is out of range value must be greater than zero
• The FaultDetail will be the type TDetail which will be included in the generated in the service reference

Conclusions

This is the best choice.  It allows you to pass all kinds of information to clients and it makes your error handling capability truly first class.  In the sample code one thing I wanted to do was to use the FaultException.HelpLink property to pass a Url to a help page.  Unfortunately I learned that none of System.Exception’s properties are propagated to the sender.  No problem, I just added a HelpLink property to my ArgumentValidationFault type and used it instead in FaultException.Details.HelpLink

Some interesting things I learned while testing this

• You can specify an interface in the [FaultContract] attribute but it didn’t seem to work on the caller side for catching a FaultException<T>

Recommendation

Use [FaultContract] on your service operations.  You should probably create a base type for your details and perhaps have a few subclasses for special categories of things.  Remember that whatever you expose in the FaultContract is part of your public API and that versioning considerations that apply to other DataContracts apply to your faults as well.

Happy Coding!

Ron

http://blogs.msdn.com/rjacobs

Twitter: @ronljacobs

All about the Testing Applications with Microsoft Test Manager Course

by community-syndication | Jan 14, 2011 | BizTalk Community Blogs via Syndication

The 2-day Testing Applications with Microsoft Test Manager course is currently our most popular Visual Studio 2010 training course. For every public delivery of the course we are usually running 4 or 5 private in-house courses for companies. So why the demand for this course?

Microsoft has invested a significant amount of time and effort focusing on improving the testing capabilities of Visual Studio 2010. Here are a few of the key things you will learn by attending the Testing Applications with Microsoft Test Manager course.

Test Case Management

Learn how to create a Test Plan and configure properties for the test plan including test settings and configurations.  You’ll create Test Suites and link them to your requirements for traceability and reporting. During the course you’ll see how to write effective test cases and organize them for convenience and reporting.

Executing manual tests

Microsoft’s new Manual Test Runner is a purpose built application to allow you to step through your test cases and see how you need to interact with your application under test. You can record an action recording for a test case which will then allow you to fast forward one or more steps on subsequent test executions. This can be a huge time saving feature.

What’s changed? What do I need to retest?

Using the Test Impact Data Collector, you can select two different builds (eg. 2.1.10.1 & 2.1.12.1) and with the click of a mouse button see exactly what changes (work items) have gone in the newer build. You can also find out which test cases should be executed based on what has changed between the builds. Why run 200 tests when you only need to run 20 of them?

Raising data-rich bugs

One of the challenges a tester has is knowing what information and how much information to include in a bug report. Often testers don’t have time to include as much detail as they would like and developers invest more time trying to reproduce a bug then they might otherwise need to. Using the Test Runner, you can raise data rich bug reports that can include a wealth of helpful information for the developer. Through the selection of data collectors, much of the relevant information is automatically added to the bug report when the testers raises the bug. This means less time writing the bug and for developers, possibly a significant reduction in the time it takes to reproduce the bug.

Automated UI testing

The Mastering Testing with Visual Studio 2010 course will cover creating automated user interface tests called Coded UI tests. Coded UI tests can be generated from manual test action recordings or they can be recorded using the Coded UI test recorder. These tests have the great benefit of being able to be automated completely and included as part of the build process.

Report on test progress

Another time consuming task for testers is often creating the testing reports needed for management or to record the daily progress of your testing. In the course we’ll look at how to use some of the out-of-the-box reports and how you can quickly and easily create your own reports.

While the courses covers more than I have listed above, these are some of the most important things you’ll learn how to use by attending the Mastering Testing with Visual Studio 2010 course.

Our the next Testing Applications with Microsoft Test Manager course is scheduled for February 16th. Hope to see you there! 

Some tips for a BizTalk catastrophic event

by community-syndication | Jan 13, 2011 | BizTalk Community Blogs via Syndication

Introduction Today I witnessed a BizTalk catastrophic event. One of the SQL drives for a company I work for failed. In scrambling to find some solutions and fixes for the errors we were seeing I realized I could not find a great case study in a catastrophic event for BizTalk. One thing that would be […]

WCF Routing Service Deep Dive: Part II-Using Filters

by community-syndication | Jan 13, 2011 | BizTalk Community Blogs via Syndication

In the first part of this series, I compared the WCF Routing Service with BizTalk Server for messaging routing scenarios. That post was a decent initial assessment of the Routing Service, but if I stopped there, I wouldn’t be giving the additional information needed for you to make a well-informed decision. In this post, we’ll […]

Calling EDI Pipelines from Orchestrations

by community-syndication | Jan 13, 2011 | BizTalk Community Blogs via Syndication

In a recent client project, I found a need to call an EDI pipeline from my orchestration.
Environment:
BizTalk Server 2009
Use Case:
Call external synchronous web service that expects a string type with contents of an EDI document. The orchestration receives response and takes action based on response code type. In my case, I passed a 270 and […]

QuickLearn’s New Year’s Sale: 15% off Public Classes

by community-syndication | Jan 13, 2011 | BizTalk Community Blogs via Syndication

Sign up for classroom training before January 31st and receive 15% off your registration.

Kick off the new year with training from QuickLearn. Update your skills, improve at your job, and make getting a raise your New Year’s resolution!

All classes taught at our training center in Redmond, WA (or through remote training from your home or office) are eligible. Register for classroom training using the promotion code: NY2011

Search the course calendar to find and register for your course.

*Sorry this offer cannot be applied to prior registrations or combined with any other offers. Discounts are not valid at partner locations.

Announcing release of ASP.NET MVC 3, IIS Express, SQL CE 4, Web Farm Framework, Orchard, WebMatrix

by community-syndication | Jan 13, 2011 | BizTalk Community Blogs via Syndication

WF4: How Tracking Helped Me Write a Better Unit Test

by community-syndication | Jan 13, 2011 | BizTalk Community Blogs via Syndication

This morning I’ve been working on how to support cancelling a workflow via a CancellationToken.  The details of that are not important right now but what is really cool is how I was able to test this.

Scenario: Caller requests Cancellation via a CancellationToken and the UnhandledExceptionAction is Cancel

Given

• An activity that contains a CancellationScope
• The CancellationScope body has an activity that will create a bookmark and go idle
• The CancellationScope has a CancelHandler with a WriteLine that has a DisplayName "CancelHandlerWriteLine"

When

• The caller invokes the workflow asynchronously as a task with a CancellationToken
• and in the idle callback calls CancellationTokenSource.Cancel

Then

• A TaskCanceledException is thrown
• The WorkflowApplication is canceled
• The CancelationScope CancelHandler is invoked

Test Challenges

• How can I wait until the cancel is completed after handling the exception before verifying?
• How will I verify that the CancelHandler is invoked?

Solution

To wait until the cancel is completed after handling the exception before verifying I simply create an AutoResetEvent (line 18) and signal it from the WorkflowApplication.Completed event callback (line 19).  Then before verifying the tracking data I wait for this event (line 41)

To verify that the cancel handler was invoked I use the Microsoft.Activities.UnitTesting.Tracking.MemoryTrackingParticipant. This allows me to capture the tracking information into a collection that I can search using AssertTracking.Exists to verify that the activity with the name ExpectedCancelWriteline entered the Closed state.

   1: [TestMethod]

   2: public void ActivityIsCanceledViaTokenShouldInvokeCancelHandler()

   3: {

   4:     const string ExpectedCancelWriteLine = "CancelHandlerWriteLine";

   5:     var workflowApplication =

   6:         new WorkflowApplication(

   7:             new CancellationScope

   8:                 {

   9:                     Body = new TestBookmark<int> { BookmarkName = "TestBookmark" }, 

  10:                     CancellationHandler = new WriteLine { DisplayName = ExpectedCancelWriteLine }

  11:                 });

  12:  

  13:     // Capture tracking events in memory

  14:     var trackingParticipant = new MemoryTrackingParticipant();

  15:     workflowApplication.Extensions.Add(trackingParticipant);

  16:  

  17:     // Use this event to wait until the cancel is completed

  18:     var completedEvent = new AutoResetEvent(false);

  19:     workflowApplication.Completed = args => completedEvent.Set();

  20:  

  21:     try

  22:     {

  23:         var tokenSource = new CancellationTokenSource();

  24:  

  25:         // Run the activity and cancel in the idle callback

  26:         var task = workflowApplication.RunEpisodeAsync(

  27:             (args, bn) =>

  28:                 {

  29:                     Debug.WriteLine("Idle callback - cancel");

  30:                     tokenSource.Cancel();

  31:                     return false;

  32:                 }, 

  33:             UnhandledExceptionAction.Cancel, 

  34:             TimeSpan.FromMilliseconds(1000), 

  35:             tokenSource.Token);

  36:  

  37:         // Exception is thrown when Wait() or Result is accessed

  38:         AssertHelper.Throws<TaskCanceledException>(task);

  39:  

  40:         // Wait for the workflow to complete the cancel

  41:         completedEvent.WaitOne(this.DefaultTimeout);

  42:  

  43:         // Verify the the cancel handler was invoked

  44:         AssertTracking.Exists(

  45:             trackingParticipant.Records, ExpectedCancelWriteLine, ActivityInstanceState.Closed);

  46:     }

  47:     finally

  48:     {

  49:         // Write the tracking records to the test output

  50:         trackingParticipant.Trace();

  51:     }

  52: }

  53:  

When I run this test I also get the Tracking info in the Test Results along with any Debug.WriteLine output to help me sort out what is happening.  The tracking data is nicely formatted thanks to extension methods in Microsoft.Activities.UnitTesting.Tracking that provide a Trace method for each type of tracking record which produces human readable formatting.

WaitForWorkflow waiting for workflowBusy - check for cancel

Checking cancel token

System.Activities.WorkflowApplicationIdleEventArgs

    Bookmarks count 1 (TestBookmark)

Idle callback - cancel

Checking cancel token from idle handler

Cancel requested canceling workflow 

WaitForWorkflow workflowBusy is signaled - check for cancel

Checking cancel token

Cancel requested canceling workflow 

WorkflowApplication.Cancel

this.CancellationToken.ThrowIfCancellationRequested()

*** Tracking data follows ***

WorkflowInstance for Activity <CancellationScope> state is <Started> at 04:13:53.7852

Activity <null> is scheduled child activity <CancellationScope> at 04:13:53.7852

Activity <CancellationScope> state is Executing at 04:13:53.7852

Activity <CancellationScope> is scheduled child activity <TestBookmark> at 04:13:53.7852

Activity <TestBookmark> state is Executing at 04:13:53.7852

{

    Arguments

        BookmarkName: TestBookmark

}

WorkflowInstance for Activity <CancellationScope> state is <Idle> at 04:13:53.7852

Activity <null> cancel is requested for child activity <CancellationScope> at 04:13:53.7852

Activity <CancellationScope> cancel is requested for child activity <TestBookmark> at 04:13:53.7852

Activity <TestBookmark> state is Canceled at 04:13:53.8008

{

    Arguments

        BookmarkName: TestBookmark

        Result: 0

}

Activity <CancellationScope> is scheduled child activity <CancelHandlerWriteLine> at 04:13:53.8008

Activity <CancelHandlerWriteLine> state is Executing at 04:13:53.8008

{

    Arguments

        Text: 

        TextWriter: 

}

Activity <CancelHandlerWriteLine> state is Closed at 04:13:53.8008

{

    Arguments

        Text: 

        TextWriter: 

}

Activity <CancellationScope> state is Canceled at 04:13:53.8008

WorkflowInstance for Activity <CancellationScope> state is <Canceled> at 04:13:53.8008