In one of the solutions I work on I consequently received the warning  ‘Cannot resolve the ‘schemaLocation’ attribute’. This solution contains a BizTalk project with a lot of schemas. For each schema multiple occurrences of this warning where reported. This lead to a long list of warnings.

Although this is a warning and it didn’t seem to bother anything at run-time I didn’t like the excessive list of warnings.

It turned out that the BizTalk compiler is quite strict in the way the imports are defined for schemas in other assemblies. We have schema types defined in schemas in other assemblies. We reference those assemblies and use the types in the schemas. Something like this:

<xs:import namespace="http://biztalk_server_project1.myschematypes" schemaLocation="BizTalk_Server_Project1.MySchemaTypes" />

As you can see we had the ‘namespace’ before the ‘schemaLocation’ attribute in the import statement. We manually added the import statements and didn’t bother about the sequence of those attributes. However it seems the BizTalk compiler wants the imports to be defined as:

<xs:import schemaLocation="BizTalk_Server_Project1.MySchemaTypes" namespace="http://biztalk_server_project1.myschematypes" />

This also the sequence used when you import a schema in the BizTalk schema editor.

After putting all the ‘schemaLocation’ attributes before the ‘namespace’ attributes the warnings were gone.

Not a showstopper but still worth mentioning in my view.

1. promoting properties (including the message type)
2. validating incoming documents (if turned on)
3. disassemble batches into body messages

Sometimes situations can occur where you want to process an envelope message but you don’t want to have it disassembled into separate body messages.

For example when receiving a message that contains a lot of data in the header of the envelope that is needed in the body of a message further on in the process. You then ideally want to use a map to copy over this header data into another message. If the port receiving this message uses the XmlDisassembler component the envelope will be processed and the header information is “gone”.

You can of course promote everything in the header to the context but that leads to a lot of data in the context. Besides that a considerable amount of code (distinguished fields and xpath statements in expression shapes) is needed to get the context properties into the message later on.

Another and, in my view, more elegant way to do this is by setting the value of a special property to true on the context of the envelope message before it is processed by the XmlDisassembler. The property is called ‘PromotePropertiesOnly’ and resides in the ‘http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties’ namespace.

A very simple pipeline component can be used to do this:

public IBaseMessage Execute(IPipelineContext pContext, IBaseMessage pInMsg)
{
pInMsg.Context.Promote("PromotePropertiesOnly",
"http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", true);

return pInMsg;
}

After setting this property will still have the functionality of the XmlDisassembler (like property promotion, setting the message type, etc.) but the debatching is skipped.

The property is available and can be used in all versions of BizTalk Server (2004, 2006 (R2), 2009 and 2010).

So what is the greatest new feature in BizTalk 2010? For me it is by far sizeable code window for expression shapes and message assignment shapes in the orchestration designer.

Although this seems like a small improvement it was many times requested and really makes the live of a BizTalk developer easier.

If you follow my blog you might know I wrote the expression maximizer utility a couple of months ago. This was actually a fun project for me to be able to join in the BizTalk tip contest on BizTalk gurus. I must admit though that I use it in my day to day development work.

I’m very excited that Microsoft has a similar feature out of the box. I gives me the same feeling when they added the browse button next for file ports in the admin console in BizTalk 2006 .

The expression window is now a standard visual studio window. This means you can for example dock it into the right pane:

But you can also use it in the normal way:

and resize it:

Zooming in the window is also possible. Handy if you need to do a demo:

Cool! Thank you Microsoft!

Every time Microsoft releases a new version of BizTalk we are all very disappointed that they did not make the expression window resizable or at least bigger.

There are rumors that this is done to discourage developers to write a lot of code in those windows and move to external assemblies with helper classes instead.

Although I agree with that I still think it would be very nice to have a bigger window occasionally.

Like the “Orchestration Variable Retriever Functoid” this was on my “experimental things to do list” for a long time. I never had or took the chance to try it until BizTalk king Stephen W. Thomas announced his competition for the best BizTalk tip or trick.

Of course I want to join this competition so I started coding. Now that it is finished I must admit it has become quite a hack but it seems to work .

Anyway the “ExpressionMaximizer” will be my entry for the competition.

A quick walkthrough:

I have an orchestration with an expression shape containing a lot of code:

I double click the expression shape to open it (in normal mode):

With expression window still open I press CTRL+SHIFT+ALT+M (nice key combination ) and ……:

I have a big expression window where I can type many long lines of code!!!!

Everything is back to normal when you close the window and open it again.

Note that you first have to open the expression shape before pressing the key combination.

Want to try it yourself?
(description below is based on Visual Studio 2008)

- Download this zip file and extract it somewhere.
- Click ‘Tools’ –> ‘External Tools…’
- Press the ‘Add’ button
- Type a title, e.g. ‘Expression Window Maximizer’
- Fill in the command text box by browsing to the extracted ‘ExpressionMaximizer.exe’

- Press the ‘OK’ button
- Select ‘Tools’ –> ‘Customize…’
- Press the ‘Keyboard…’ button
- In the ‘Show commands containing:’ text box type ‘Tools.External’
- Select the correct ‘Tools.ExternalCommandX’ from the list. (You need to find out the correct entry by counting the external tools in the Tools menu).
- Click in the text box ‘Press shortcut keys:’ to set the focus to it.
- Press CTRL+ALT+SHIFT+M
- Click the ‘Assign’ button.

- Press the ‘Ok’ button.
- Press the ‘Close’ button.

I tried this on ‘Windows Server 2008 R2/VS2008′ and ‘Windows Server 2003 R2/VS2005’ without problems but I still take no responsibility for malformed windows or other disasters After all it is a big hack!

If you’re interested you can find the (VS2008) source code here.

From a developer perspective however there is a nasty side effect that you should be aware of. This is caused by the fact that there is no MS virtualization tool running on a client OS that supports 64 bit guests.

Most developers follow the best practice to do development in a virtual environment and use their host for e-mail, word processing, etc.

In my case the host was Windows 7. I used my server running hyper-v to initially build the a new virtual BizTalk 2009 development box running on Windows Server 2008 R2. After that was done I wanted to transfer the .vhd to my laptop and run it from there.

As far as I know the MS options for running the VM are:

• Microsoft Virtual PC 2007
• Microsoft Virtual Server 2005 R2
• Microsoft Windows Virtual PC (currently RC)

As none of these options support 64 bit guest meaning I can’t use a Microsoft Virtualization tool to run my new Windows Server 2008 R2 development environment. Hyper-V supports 64 bit guest OS but doesn’t run on Windows 7.

The “not so nice” solutions left for me were:

• Use a non MS virtualization tool (like sun virtual box or VMware) that support 64 bit guests.
• Replace Windows 7 on my host with windows server 2008 hyper-V.
• Rebuild the virtual machine and use another 32 bit OS.