Get your blog to speak up!

by community-syndication | Feb 12, 2010 | BizTalk Community Blogs via Syndication

By clicking the    icon above you can have the content of the blog post to be read back to you. Not a very useful feature perhaps, but I thought it was pretty cool. The feature is provided by ReadSpeaker and is easy to implement.

First, register you on the ReadSpeaker site. The advertisement version is free but can only be used for personal websites and bloggers.

Secondly, add the script tag below in the head of your page. I’m using Community Server, so I added it to the theme masterpage.

<script 
    language="javascript" 
    type="text/javascript" 
    src="http://wr.readspeaker.com/webreader/webreader.js.php?cid=[PrivateKey]">
</script>

Then, on your page add the img tag below:

<img onclick="readpage(this.id+escape(document.location.href),1); return false;"
src="http://blogical.se/blogs/mikael/loudspeaker.png" 
id="http://wr.readspeaker.com/webreader/webreader.php?cid=[PrivateKey]&amp;t=blog_free&amp;title=readspeaker&amp;url="
title="Listen with webReader" 
alt="Listen with webReader"/>

If you want to limit the text to be read you can use the comments below:

<!-- RSPEAK_START -->
<p>
    Blog post....</p>
</p>
<!-- RSPEAK_STOP -->

btw, it’s not optimized for reading code, as you might have already found out 😉

Consolidating BizTalk blogs

by community-syndication | Feb 11, 2010 | BizTalk Community Blogs via Syndication

In the past, the product team has been blogging about BizTalk in multiple blogs:

Over time, some of these have become silent and others are updated from time to time. We’ve also heard that it is confusing to look for related information in multiple places. To solve this, we’re going to consolidate all BizTalk product team blogging into this blog: http://blogs.msdn.com/biztalk_server_team_blog/

We’ll try to make our blogging more interactive – we’ll respond to comments on articles and ask for your input on features you use and topics you want to hear. We’ll periodically post articles, so keep in touch.

Ciao

BizTalk Server Team

Intellisense Crashing fix for VS 2010

by community-syndication | Feb 11, 2010 | BizTalk Community Blogs via Syndication

BizTalk Virtual Training Material

by community-syndication | Feb 11, 2010 | BizTalk Community Blogs via Syndication

Hi folks,

Lately I’ve had several requests from folks whom want to have a play with BizTalk
but don’t want to setup the whole infrastructure etc.

Here’s a great page from MS Virtual Labs that will get you on your way
(some labs are for BTS2006, others for BTS2009, the same principles apply)

Check it out and if you’re ever away from a VM, might be handy a fallback plan.

BizTalk
Virtual Lab Material

There’s 4 pages and here’s a snippet from Page 1

————————————————————–

MSDN Virtual Lab: Microsoft BizTalk Server 2006 Working with Schemas

MSDN Virtual Lab: Microsoft BizTalk Server 2006 Working with Maps

MSDN Virtual Lab: Integrating Business Rules in Microsoft BizTalk Server 2006

MSDN Virtual Lab: New Features for Deploying and Managing a BizTalk Application in Microsoft BizTalk Server 2006

MSDN Virtual Lab: Connected Commerce with Commerce Server 2007

TechNet Virtual Lab: Integrating Business Rules in Microsoft BizTalk Server 2006

MSDN Virtual Lab: Creating Schemas using Microsoft BizTalk Server 2004

MSDN Virtual Lab: Publishing a Web Service in Microsoft BizTalk Server 2004

MSDN Virtual Lab: Microsoft BizTalk Server 2004 Consuming a Web Service

TechNet Virtual Lab: New Features for Deploying and Managing a BizTalk Application in BizTalk 2006

Two New Webcasts from Brian Loesgen

by community-syndication | Feb 11, 2010 | BizTalk Community Blogs via Syndication

LIDNUG Online Chat with Me on Thursday Feb 11th

by community-syndication | Feb 11, 2010 | BizTalk Community Blogs via Syndication

WF4 runtime performance

by community-syndication | Feb 10, 2010 | BizTalk Community Blogs via Syndication

Welcome to the first in a series of blog posts on WF4 performance. In this post, we will discuss the core workflow runtime. An important reason many of our customers are moving from WF3 to WF4 is the large performance improvements they realize with the WF4 runtime. This post describes a few of these improvements, provides some background on what we did to make it happen, and warns about some common pitfalls. Please note that the data contained in this post is based on prerelease software and is subject to change.

As an example, consider the following While activity built with WF4:

Variable<int> i = new Variable<int>();
new While(env => i.Get(env) < 100)
{
    Variables = { i },
    Body = new Increment
    {
        X = i,
    },
};


public class Increment : CodeActivity
{
    public Increment()
        : base()
    {
    }

    public InOutArgument<int> X
    {
        get;
        set;
    }

    protected override void Execute(CodeActivityContext context)
    {
        X.Set(context, X.Get(context) + 1);
    }
}

In the lab, we observe that the throughput of this WF4 workflow is 273 times the throughput of a comparative WF3 workflow. In other words, on this lab machine, we execute 273 times as many of WF4 workflows per second as the WF3 workflow.

Now, the performance improvements will vary greatly from one workflow definition to another. It will be far less dramatic for many other workflows, or even more dramatic for others, but overall, these improvements symbolize the work we’ve put into making WF4 far more performant.

There are multiple behind-the-scenes reasons for why you see these improvements:

– Introduction of a formal data flow model and scoping rules

There were no scoping rules for data in 3.0 or 3.5 – you could bind activity properties without clear boundaries. So, we had to keep significant state around for the lifetime of your workflow.

In WF4, we provide a consistent model for sharing state among activities (with variables, arguments, and expressions). More importantly, we also have rules for data scoping that enable us to do very efficient cleanup of state when it is no longer needed. In WF4, we consider only the variables of currently executing activities active state.

Earlier, it was impossible for the runtime to reason about what was in scope, and what state wasn’t needed any more, and this forced us to carry around a lot of unnecessary state.

– Separation of activity definition from activity instance

In WF3, activity types were configured at design time, and the same types were instantiated at runtime. This model had performance implications, because for each workflow instance, the entire activity tree was kept in memory (or persisted when it was unloaded). 

In .NET 4.0, we’ve separated the notion of program definition from activity instance. The type you use to author an activity is instantiated only as part of a workflow definition.  It is not maintained as part of instance state.

Instead, scheduling in WF4 creates lightweight ActivityInstances which represent the execution state for an activity. As I mention in the first bullet point, this execution state primarily includes the values of variables declared on this activity.

– Improved activity cleanup and activity creation

Beyond the separation of activity definition from activity instance, we also modified the activity lifecycle so that we proactively cleaned up activities that were no longer executing. Just as important, we’ve removed the initialized state from activities. Now, an activity instance is only created when it is scheduled.

– Elimination of bottlenecks that made looping constructs significantly less performant in WF3

For all the reasons described above, writing activities that performed any kind of looping in WF3 was challenging, because you had to maintain a template activity, spawn, and cleanup children. Also, in WF3, every time we tried to run the child of a While, we would use the binary formatter to replicate the entire tree every time. This was extremely expensive, and as a result, performance-sensitive workflow developers started eliminating loop constructs from workflows altogether!

Now, because activity types are instantiated only as part of the workflow definition, and because it is not maintained as part of instance state, not only is writing looping activities far easier, scheduling them is also significantly more performant.

This should begin to provide a view of how we’ve invested in performance on just the workflow runtime. Discussion of persistence has been intentionally left out of this discussion. There will be a different, future post on persistence performance.

Two gotchas to keep in mind: Before you leave, there are two performance warnings about a few common mistakes we’ve seen customers make.

– Not caching the workflow definition. The first common mistake we’ve seen customers make is not caching the workflow definition before execution. In other words, instead of creating the definition and using it during subsequent executions, some customers unintentionally re-create the definition from scratch during every invocation (in the example above, that would mean instantiating a new While activity before every execution). Recreation of the workflow definition is a bad idea not just because of the object creation, but also because preparing the definition involves calling CacheMetadata to build the runtime activity tree.                

– Blocking the thread. The second common mistake is blocking the thread, often unknowingly relying on expensive operations in activities. In the WF4 threading model, one thread at a time is used to process work items in a workflow instance. While this helps simplify the programming model for activities, it also means that activities should not block this thread. Note that expensive operations come in many forms, so keeping this warning in mind is not always obvious. Also, WF4’s new asynchronous activity capability allows you to perform work off of the workflow thread while keeping the instance in memory; for more information, please see the new async activity sample in the .NET 4 RC SDK.

If you’d like to see any other topics discussed in the future, please let us know!

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Visual Studio 2010 RC

by community-syndication | Feb 10, 2010 | BizTalk Community Blogs via Syndication

Following the release of Visual Studio 2010 Release Candidate, I installed it on one of my laptops. I ran into some minor issues with the Silverlight dev tools SDK, but I hear they’ve been resolved for RTM. Other than that, it seems to be working fine.
I’ve already updated my Current Line Highlighting and Keyword Classifier […]

Discover a New WCF with Discovery!

by community-syndication | Feb 10, 2010 | BizTalk Community Blogs via Syndication

Juval Lowy has a great article in the January 2010 issue of MSDN Magazine: Discover a New WCF with Discovery.  He goes into the basics of Discovery, how it works and why you would use it, and also provides his own set of helper classes that you can download to make using discovery in your application even easier.  Then he shows how to use these classes to build a publish-subscribe service using WCF.

4.0 Beta2->RC WCF/WF List of Breaking changes

by community-syndication | Feb 10, 2010 | BizTalk Community Blogs via Syndication

This list covers known breaking changes between 4.0 Beta2 and RC WCF & WF Framework.  

Summary of Breaking Changes

FlowChart Designer produces FlowSwitch<T> instead of FlowSwitch

Description: In Beta2 the FlowSwitch item in the activities toolbox produces a non-generic FlowSwitch. Post Beta2, it produces a FlowSwitch<T>. The reason for the change is that non-generic FlowSwitch (used in beta2 and earlier) only allowed to switch on strings (e.g. all keys in the cases needed to be strings) while FlowSwitch<T> allows to switch on any type of T.

Customer impact: Flowcharts that use a FlowSwitch and have been authored using the WF designer in Beta2 or earlier won’t load in the WF designer post beta2.

Mitigation: If you’re using FlowSwitch in a Flowchart workflow using Beta2 (or pre-Beta2 builds), you will need to hand edit the Flowchart XAML and add x:TypeArguments=”x:String” to the FlowSwitch node as shown in the snippet below (highlighted code):

Beta2

<FlowSwitch x:TypeArguments=“x:String“ Default=“{x:Reference __ReferenceID2}“ x:Name=“__ReferenceID3“ Expression=“[variable1]“>

  <x:Reference>__ReferenceID0<x:Key>Ray</x:Key></x:Reference>

  <x:Reference>__ReferenceID1<x:Key>Bill</x:Key></x:Reference>

</FlowSwitch>

RC

<FlowSwitch x:TypeArguments=“x:String“ Default=“{x:Reference __ReferenceID2}“ x:Name=“__ReferenceID3“ Expression=“[variable1]“>

  <x:Reference>__ReferenceID0<x:Key>Ray</x:Key></x:Reference>

  <x:Reference>__ReferenceID1<x:Key>Bill</x:Key></x:Reference>

</FlowSwitch>

Reference Types in Literal <T> Expressions

Description:  Literal expressions are represented in WF using the Literal<T> activity.  In Beta2 any type could be used with this expression.  In RC It is invalid to initialize Literal<T> with an instance of a reference type.  String is the only exception to this rule.  The motivation for the change was that users erroneously thought that creating a Literal<T> with a new reference type created the new reference type for each instance of the workflow.  Disallowing “Literal” reference types eliminates this confusion.  In Beta2 the following workflow definition would run without error.  In RC it will receive a validation error:

‘Literal<List<String>>’: Literal only supports value types and the immutable type System.String.  The type System.Collections.Generic.List`1[System.String] cannot be used as a literal.

List<string> names = new List<string> {“Frank”, “Joe”, “Bob” };

Variable<List<string>> nameVar = new Variable<List<string>> { Default = new Literal<List<string>>(names)};           

//Note: the following is the equivalent to the line above, the implicit cast creates a Literal<T> expression

//Variable<List<string>> nameVar = new Variable<List<string>> { Default = names };

DelegateInArgument<string> name = new DelegateInArgument<string>();

Activity program = new Sequence

{

    Variables = { nameVar },

    Activities =

    {

        new AddToCollection<string> {

            Collection = new InArgument<ICollection<string>>(nameVar),

            Item = new InArgument<string>(“Jim”)},

        new ForEach<string>{

            Values = new InArgument<IEnumerable<string>>(nameVar),

            Body = new ActivityAction<string>{

                Argument = name,

                Handler = new WriteLine { Text = new InArgument<string>(name)}}}

    }

};

Customer Impact:  Customers who have used reference types in Literal<T> expressions will need to use a different kind of expression to introduce the reference type into the workflow.  For example VisualBasicValue<T> or LambdaValue<T>.

Variable<List<string>> nameVar = new Variable<List<string>>{

    Default = new VisualBasicValue<List<string>>(“New List(Of String)(New String() {\”Frank\”, \”Joe\”, \”Bob\”})”)};

DelegateInArgument<string> name = new DelegateInArgument<string>();

Activity program =  new Sequence

{

    Variables = { nameVar },

    Activities =

    {

        new AddToCollection<string> {

            Collection = new InArgument<ICollection<string>>(nameVar),

            Item = new InArgument<string>(“Jim”)},

        new ForEach<string>{

            Values = new InArgument<IEnumerable<string>>(nameVar),

            Body = new ActivityAction<string>{

                Argument = name,

                Handler = new WriteLine { Text = new InArgument<string>(name)}}}

    }

};

Mitigation (if any):  n/a

IPC channel security descriptor change (Remoting)

Description:  In Beta2, if a user in UAC – User Access Control with administrator privileges creates a named pipe in the IPC (Inter-process Communication) channel then that user’s SID is ACL-ed (Access Control List). However, that enables the user in UAC to access the named pipe when that user loses the administrator privileges.

Post Beta2, we provide users with an API to be able to change the security descriptor in the named pipe so the previous values of security descriptor can be restored. This API helps users to make their apps more secure and consists of a new IPCChannel constructor that takes an extra fourth argument with a custom security descriptor to override the default one:

public IpcChannel(IDictionary properties, IClientChannelSinkProvider clientSinkProvider,
                                  IServerChannelSinkProvider serverSinkProvider, CommonSecurityDescriptor securityDescriptor)
{
}

Customer Impact:  Customers that create IPC channel in Beta2, will notice the change of the default security descriptor if their security descriptor must be different than the provided one in beta2. However, in post Beta2, you can now specify your own security descriptor using the new added constructor.

Mitigation (if any):  We have provided the API described above that will allow users to set their own security descriptor.

Type change for the EventTime property in the TrackingRecord API

Description:  In Beta2, the EventTime property within System.Activities.Tracking.TrackingRecord was of the type System.DateTimeOffset, post Beta2 the type was changed to System.DateTime. The EventTime property stores the time in UTC when the TrackingRecord was emitted.

public abstract class TrackingRecord {
             
             public System.DateTime EventTime { get; }
            
}

Customer Impact:  Customers who have created a custom tracking participant which consumes TrackingRecord objects and access the EventTime property will need to change the type. If the logic within the tracking participant implementation assigns the EventTime property from the TrackingRecord, the place where the property is assigned will receive a DateTime type instead of DateTimeOffset.

Mitigation (if any):  none.

New Persistence impacts

Description: Due to large changes in the instance schema and logic, it is not possible to migrated persisted data from Beta 2 to RC.

Customer Impact: To upgrade from Beta 2 to RC, discard any existing instances and resubmit data.  Alternatively, install RC on separate physical or virtual machines and target a different database than used for Beta 2.

Mitigation (if any):  none.

 — Khalid Mouss.