For BizTalk folks, the release today of the EAI and EDI capabilities built on the Azure Service Bus represents one of the first major steps toward integration in the cloud. You can check out the blog post on the Windows Azure blog detailing the features, but essentially you have routing, mapping with lookup capabilities and EDI support in the cloud (that’s minimizing what you get here, but a general summary). There is also an SDK to enable you to create the required artifacts on your development machine and deploy them up to the Azure environment.

I’m excited to see new capabilities released on Service Bus, which is, in my mind, a major differentiator in the PASS space. Nobody has anything that comes close to the type of stuff Microsoft is doing here and plans to do on the Service Bus in the future. This, coupled with the announcement around BizTalk Server 2010 R2 and its support for the cloud means that the BizTalk space continues to be interesting and ever expanding. As anyone who does integration work knows, it’s not going away anytime soon, and it’s great to see Microsoft investing in both on-premise and cloud solutions to help customers integrate their disparate systems.

I’m looking forward to seeing this project grow and add new features over time, and even more to seeing how customers take advantage of these capabilities in the cloud.

Well, as you might have noticed if you got redirected here, by blog has moved to this new location after being hosted over at Pluralsight for the past few years. This change happened rather quickly, so I’m in the process of moving all of the existing posts over into this new blog. Hopefully, your redirected requests will bring you directly to the post you are looking for, but if not, please search for them. 

I apologize for the inconvenience. I knew this change was coming at some point, which is why I had this blog setup, but the switch came rather unexpectedly and I’m scrambling to get the data migrated.

Thanks to all who attended my talks on LightSwitch and jQuery templates / data linking at last week’s Minnesota Developers Conference. I’ve received several requests for the demo code and slides which I have included here as links.

Of note for those looking at the jQuery demonstration code, I updated the movie review linking sample to show how to update the rendered template content with the new values from the input form. True to form, this was only a matter of a few lines of code. 

Demo code:

LightSwitch asset manager

jQuery templates and data-link

Slides:

LightSwitch

jQuery

I’ve been working with AppFabric lately and one of the things I like to do is use PowerShell to get a sense of the current state of my workflows. Unfortunately, I don’t like the format of the output as I find it hard to read.  You can see an example of the default output here.

What I want is a nice succinct table.  So, I fiddled around a bit with PowerShell’s format-table command and was able to get my data looking like this:

The command is pretty simple. I use the Property parameter to the format-table command to identify three properties that I want, using expressions to go after the specific values in which I’m interested.

get-asappserviceinstance -groupby status | format-table -property @{n='Count';e={$_.Count}}, @{n='Status';e={$_.Groups[0].GroupValue}}, @{n='Status';e={$_.Groups[1].GroupValue}}

The expressions go into the objects returned by AppFabrics get-asappserviceinstance command when grouping by status.

Hopefully this will prove useful to those of you working with Windows Server AppFabric and PowerShell.

Last week I had the pleasure of presenting two sessions at the Heartland Developer’s Conference (HDC). I love this show and meeting people from the central region, as well as catching up with colleagues. It’s always a great time and this year was no different.

For those who attended, you can find the samples I used at the links below. Thanks for coming, I hope you enjoyed the show as much as I did.

WF 4 from hello world to real world

Choosing service technology

From Damir Dobric (http://developers.de/blogs/damir_dobric):

Patch to fix an issue where autostart services start in the wrong application pool:

http://support.microsoft.com/kb/983484

This only applies to Windows 7 and Server 2008 R2 as IIS 7.5 is the only supported platform for autostart in a service. 

Patch to fix issues where the IIS Manager or PowerShell cmdlets fail due to schema issues in IIS configuration files. 

http://support.microsoft.com/kb/980423

There are a number of different error messages that result from this core issue.  In addition to this patch, you should already have installed the hotfix described in the following article:

http://support.microsoft.com/kb/970773

Then go take this survey and let Microsoft feel your pain!  Not sure anyone will get zapped by their chair when you send feedback, but the team is actively looking into how to make the interop story better, so be sure to get your voice heard.  Oh, and it’s a short survey so not a huge time commitment.

http://mymfe.microsoft.com/Feedback.aspx?formID=283

A former student approached me with a problem related to the Web programming model using WCF in .NET 3.5.  In short, he was using a custom IErrorHandler to create a custom fault message, but the client was always receiving a generic error.  Even more of a problem was that the custom error was an HTML formatted message, despite having set the response format on the service to JSON.  This caused big problems for the AJAX client trying to reason over that response.  I knew that WCF REST Starter Kit and WCF 4 both allowed for custom error messages, so I did some digging to see what might be at the root of the problem.  It turns out that the WebHttpBehavior inserts its own IErrorHandler and it was getting in the way of the custom handler he was adding.  After pointing this out to Dave, he quickly realized he could create a class that derived from the WebHttpBehavior and override the AddServerErrorHandlers to insert his own error handler.  He also created the requisite BehaviorExtensionElement so the new endpoint behavior could be added in the configuration file. 

public class JsonWebHttpBehavior : WebHttpBehavior
    {
        protected override void AddServerErrorHandlers(ServiceEndpoint endpoint,
        System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
        {
            endpointDispatcher.DispatchRuntime.ChannelDispatcher.ErrorHandlers.Add(
               new JsonErrorHandler(endpointDispatcher.DispatchRuntime.ChannelDispatcher.IncludeExceptionDetailInFaults));
        }
    }

    public class JsonWebHttpElement : BehaviorExtensionElement
    {
        protected override object CreateBehavior()
        {
            return new JsonWebHttpBehavior();
        }

        public override Type BehaviorType
        {
            get { return typeof(JsonWebHttpBehavior); }
        }
    }

The job of the custom error handler is to create a custom fault class that provides data back to the calling application.  This solution nicely takes into consideration the IncludeExceptionDetailsInFaults property to correctly send the details only when configured to do so.  In this case, the status code is always set to 500 to trigger the correct error handling in the client library, but you could also modify this to send more specific HTTP status codes depending on the error message caught on the server. 

[DataContract]
    public class JsonFault
    {
        [DataMember]
        public string ExceptionType;

        [DataMember]
        public string Message;

        [DataMember]
        public string StackTrace;
    }

    public class JsonErrorHandler : IErrorHandler
    {
        public JsonErrorHandler(bool includeExceptionDetailInFaults)
        {
            this.includeExceptionDetailInFaults = includeExceptionDetailInFaults;
        }

        public bool HandleError(Exception error)
        {
            return false;
        }

        public void ProvideFault(Exception error,
            System.ServiceModel.Channels.MessageVersion version,
            ref System.ServiceModel.Channels.Message fault)
        {
            JsonFault jsonFault;
            if (includeExceptionDetailInFaults)
            {
                jsonFault = new JsonFault
                {
                    ExceptionType = error.GetType().FullName,
                    Message = error.Message,
                    StackTrace = error.StackTrace
                };
            }
            else
            {
                jsonFault = new JsonFault
                {
                    ExceptionType = typeof(System.Exception).FullName,
                    Message =
                        "An error occurred on the server. See server logs for details.",
                    StackTrace = null
                };
            }

            DataContractJsonSerializer serializer =
                new DataContractJsonSerializer(typeof(JsonFault));

            fault = Message.CreateMessage(version, null, jsonFault, serializer);
            fault.Properties.Add(WebBodyFormatMessageProperty.Name,
                new WebBodyFormatMessageProperty(WebContentFormat.Json));
            WebOperationContext.Current.OutgoingResponse.ContentType = "application/json";
            WebOperationContext.Current.OutgoingResponse.StatusCode =
                System.Net.HttpStatusCode.InternalServerError;
        }

        private bool includeExceptionDetailInFaults;
    }

You could certainly make modifications to only provide faults for certain types of exceptions (which is what .NET 4 does) log information in the HandleError method, etc.  Many thanks to Dave Grundgeiger for the inspiration to look into this and the final solution which he designed and allowed me to share here. 

In addition to now having WF 4 offered as a private on-site course, we have several upcoming public offerings of our Double Feature course which has been updated to .NET 4.  I’m excited to be teaching the course at the end of July in Boston and to cover the new features in WCF including configuration enhancements and REST improvements.  The bigger change, of course, is the entirely new WF 4 programming model.  In these open enrollment classes, we will be covering the new programming model, activity development and the runtime services such as persistence and tracking.  We’ll also cover the convergence of these two technologies in Workflow Service and the new message correlation capabilities introduced in .NET 4. 

So, if you are interested in an intense week of training in the Boston (July 26) or SoCal (Oct 11) area on these two great frameworks, register or save a seat before the classes fill up!

As promised to those who attended the user group last night, here is a link to the demonstration code I used in my talk on WF 4.  There was a great crowd at the event and I appreciate all the great questions during and after the presentation.  If anyone would like a copy of the slides, use the Contact link to the right to send me email and I’ll send them along.  Thanks for attending and congratulations to the first winner in the drawing who took home a 1 year subscription to Pluralsight On Demand!