BizTalk Orchestration Error Message – Using Parallel Action – if shared data is updated in a parallel then all references in every task must be in a synchronized or atomic scope

BizTalk Orchestration Error Message – Using Parallel Action – if shared data is updated in a parallel then all references in every task must be in a synchronized or atomic scope

by | Jan 17, 2011 | BizTalk Community Blogs via Syndication

SCENARIO I have one scenario that at the end of the orchestration I will delivery notification to the client, one branch will send notification by SMS, another by email but both branches make user of one orchestration variable: UserProperties. When using parallel shape inside orchestration that makes uses of a given orchestration variable, you can […]

SharePoint 2010: Stranger than Strange error – “Key cannot be null.” when creating

by | Jan 16, 2011 | BizTalk Community Blogs via Syndication

I recently came across a SharePoint Portal that previously was working a treat up
until Christmas (just gone) and then the client got this on their Create Site
Page:

So the good old “Parameter name: key” errorthat old chestnut I thought (like I had
any idea at that stage).
Null – is always an interesting thing. So something is going through
a collection and not finding the value, not that they should have tested for the existence
of the value firstbut we’ll leave that for another story.

Why this was happening now? I haven’t got to the bottom of it, could be an update?
security patch? SQL update? code somewhere? I find these things happen on the night
before an important release date.

So after sheer luck of me just ’doodling’ on the Create Site Page, this appears to
have fixed it:

From the highlighted area – just simply fill in the empty(null) search box EVEN though
we are Creating a Site here.

Go figure

Do I add SharePoint to the Wonders of the World list?

WCF: 4 Tenets of Service Oriented Data Validation

by | 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 | 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 | 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!