Wednesday, 30 June 2010

Hi all

I just had the funniest (NOT) experience (AGAIN) with the new BizTalk 2009 project system.

Somehow I had gotten into a situation, where I could add all the usual artifacts to a BizTalk project except schemas. I could add orchestrations, send pipelines, receive pipelines, maps, flat file schemas, property schemas, and flat file wizard schemas. So the only thing I couldn’t add was “normal” schemas.

I thought: Who cares? I can just add either a property schema or a flat file schema instead and then change the necessary properties on it to make it a normal schema, and that worked for me for some time.

Then, I was contacted by Microsoft to test out a new QFE package that they have created to fix an issue I have reported. The QFE package wouldn’t install, so i thought it might have something to do with my project system being broken, so I chose to repair my BizTalk installation.

The result was, that now I can add “normal” schemas, but I can’t add orchestrations and property schemas. Also, naturally, the QFE package still doesn’t install :-( So I ended up unconfiguring, uninstalling, reinstalling and reconfiguring. Everything seems normal now. But for how long?

I really hope they have improved the project system for BizTalk 2010.

--
eliasen

Wednesday, 30 June 2010 22:11:27 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Sunday, 30 May 2010

Hi all

Frequently I get emails from people looking for my help with some BizTalk challenge they are facing. Some times I just get a zipped version of a project containing schemas and other artifacts that don’t even have anything to do with the issue – it was just easier to send the entire thing and hope that I can figure it all out.

So here comes a plea from me to all you people looking for help: Please, when you send someone an email asking for help, prepare an SSCCE (See more here: http://sscce.org/).

I have plenty of things to look at, so if you take the time to prepare an SSCCE the chances of me helping you increases by a multitude of 10 :-)

Thanks!

--
eliasen

Sunday, 30 May 2010 21:21:14 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Monday, 24 May 2010

Hi all

I am just playing around with the new mapper in BizTalk 2010 beta (get it here).

I am happy to announce that the restrictions form the old versions of BizTalk regarding placement of functoids that have the output from other functoids as input has been removed.

In the “old” days (pre-BizTalk 2010 beta), you would have some of the mapper grid marked as inaccessible when you dragged a functoid that has the output form another functoid as input like this:

image

With BizTalk 2010 Beta you can place the functoids were you like. All links have a small arrow on them indicating the flow of information and you can therefore have a setup like this:

image

Very nice and more flexible, I think.

--
eliasen

Monday, 24 May 2010 15:10:16 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Saturday, 24 April 2010

Hi all

As many of you know, I am writing this book on BizTalk along side some great names of the community.

Anyway, I was just writing about the Scope shape for orchestrations and decided to go through the documentation of this to see if I missed something. And indeed there was a small detail I missed, which you can find at http://msdn.microsoft.com/en-us/library/aa560150(BTS.10).aspx – it states that “You can nest scopes up to 44 levels deep.”

I thought that was a funny number and decided to test it.

So I started adding Scope shapes and at 19 nested Scope shapes I had this:

Scopes_19_levels

which looks just fine. BUT, after adding an expression shape to the content of the 19’th Scope shape and adding the 20’th Scope shape I get this:

Scopes_20_levels

which is not fine.

So basically, the orchestration designer will not show you the Scopes at level 20 or deeper. You can still add them, though – and it compiles just fine even at 47 levels of Scope shapes, actually – haven’t bothered trying more levels than that.

Now, some of you (all of you?) may sit and wonder: Come on, how probable is it that anyone will do that? An I completely agree – if you get above 10 levels of nested Scope shapes you are most definitely going in the wrong direction :) I just wanted to see if the documentation was correct on this.

I hope this will help someone, but it probably won’t :)

--
eliasen

Saturday, 24 April 2010 11:48:05 (Romance Daylight Time, UTC+02:00)  #    Comments [4]  | 
Monday, 05 April 2010

Hi all

At times you may run into this error at compile time: “an atomic scope may not contain a receive with a correlation filtration initialized in the same scope”. Not very many posts exist on this topic so I thought I’d just share some thoughts on it.

First of all, the error occurs because you have a Receive shape inside an atomic scope and this Receive shape follows a correlation set that is initialized within the same scope. This is not allowed, as explained here: http://msdn.microsoft.com/en-us/library/aa560115(BTS.10).aspx.

The reason for this limitation is, that everything that happens inside the Atomic scope is not committed until the Scope shape finishes processing. If you at some point initialize a correlation set inside the Atomic scope, then the subscriptions for any Receive shapes that follow this correlation set cannot match the properties from the correlation type because the routing engine cannot know about the values until the Atomic transaction is committed.

If you actually could follow a correlation set that is initialized within the same Atomic scope you would end up in a deadlock because:

  1. The instance subscription is not created until the transaction commits
  2. The transaction does not commit until the Receive shape has its message

So as you can see, the Receive shape would never get a message and therefore the transaction would never commit.

Hope this helps someone out there.

--
eliasen

Monday, 05 April 2010 16:04:06 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 

Hi all

When I run into some issues on web pages and report them, one of the things that almost always happens is that they won’t deal with your request until you have deleted all cookies and tried again. The support guys have some steps to guide the user through before they can send anything on to the second level support. And this usually includes getting the users to delete all cookies.

Now, this is bad! IF there is an issue with the cookie for a particular web site, then

  1. Deal with it in your server side code
  2. Don’t ask me to delete ALL cookies, but instruct me to delete the one that is the right one for your web site.

Deleting all cookies will make me start over entering usernames and passwords for lots of web sites that are really not in any way impacted by the ongoing issue the support guys are trying to solve. It may solve the problem, sure… but it sure isn’t the RIGHT way to solve the issue. The right way would be to

  1. Make sure the cookie doesn’t get corrupted
  2. Handle the corrupt cookie in the server side code
  3. Only delete the necessary cookies and not all cookies.

Asking customers to delete all cookies is just plain lazy.

I have seen this from several web sites, and lately I actually got it from the mcp support team. I emailed them that I get this screen frequently:

ErrorOnMCPSite

As you can see, the web page instructs me to click an icon to sign in, but the icon is for signing out (Clicking it actually signs me out). Now, to me, this means that the server side code is faulty. The code generates a page that at the same time instructs me to sign in and to sign out. But, the reply from the mcp support team was that I was told to delete all cookies and try again. I have emailed them that I don’t think that is the right way to go about it and they have replied that deleting all cookies won’t do my system any harm and I should do it and get back to them. Sure it won’t harm my system, but it will for sure harm my user experience on all the web sites, whose cookies have now disappeared.

This is the way it always goes – not just with the mcp support team… I tell them it is the wrong solution and they instruct me to do it anyway.

Sigh…

--
eliasen

Monday, 05 April 2010 11:33:09 (Romance Daylight Time, UTC+02:00)  #    Comments [3]  | 

Hi all

I am trying out BizTalk 2010 beta, and just discovered a small glitch, will I will describe here and then email a link to the blog post to Microsoft to let them know about it.

I have a very simple solution:

I have a C# project which is a helper class, which I will be using from my orchestration in another project.

The project structure is as you can see here:

image

The helper class only has one class with one method which looks like this:

   1: private const string XPATH = "Some XPath expression";
   2: public static void ChangeXmlDocument(XmlDocument xmldoc)
   3: {
   4:     xmldoc.SelectSingleNode(XPATH).InnerText = "New value!";
   5: }

So it just changes the value of an element in the XML that is given to it as a parameter.

The second project only contains a schema:

image

and an orchestration:

image

The orchestration just picks up a message and then calls the helper class with the message as a parameter.

So, the deployment properties are set on the BizTalk project, so I right click it and choose to deploy it. It deploys fine.

I then entered BizTalk Server Administration, and created a new receive port and a receive location for it. I enabled the receive location and I bind the receive port to the Orchestrations receive port.

When enlisting the orchestration, I get this error:

image

Error message (For the benefit of search engines):

Could not enlist orchestration ‘strong name of orchestration’. Could not load file or assembly ‘Strong name of helper class’  or one of its dependencies. The system cannot find the file specified. (Microsoft.BizTalk.ExplorerOM)

So I am thinking that the error is because I forgot to GAC the helper class and the administration console wants to alert me to this. Not sure I like that, but ok – I’ll GAC it. That didn’t help, though.

So I thought: Maybe a refresh of the administration console, so I right clicked on the application with the orchestration and chose “Refresh”. That didn’t help.

Then I thought: I’ll right click the “Applications” node in Administration console and chose “Refresh”. That didn’t help either.

Then I tried to chose “Refresh” on the BizTalk Group node in Administration Console. That didn’t help either.

So, as it turns out, there are two options to fix this error.

  1. Restart BizTalk Server Administration Console
  2. Add the helper class as a resource in Administration Console

Neither should be necessary, I think…

Hope this helps someone.

You can find my solution here:

--
eliasen

Monday, 05 April 2010 11:05:34 (Romance Daylight Time, UTC+02:00)  #    Comments [2]  | 
Sunday, 07 March 2010

Hi all

Today I discovered something, that AGAIN confirms, that BizTalk 2009 was simply shipped without any form of proper testing of the new Visual Studio .NET project system that they chose to switch to. I have already described lots of issues here: http://blog.eliasen.dk/2009/07/21/IssuesWithBizTalk2009OnVSNET2008.aspx and a hotfix has been releases which I have shortly described here: http://blog.eliasen.dk/2010/01/27/HotfixForIssuesWithDevelopingBizTalk2009SolutionsInVisualStudio.aspx.

Anyways, the issue is, that I created a property schema in my project, and in this property schema I created four properties. I then opened up the orchestration I had in the same project and created a Correlation Type, that used these four properties. That gave me this error:

identifier 'PropertyName' does not exist in 'ProjectName'; are you missing an assembly reference?

So basically, when compiling, the new property cannot be found. Turns out, though, that if I compile the project and THEN use the properties in a Correlation Type, then everything works just fine. What a lousy deal…

The hotfix mentioned above does not seem to rectify this issue, so this remains an issue, I think.

--
eliasen

Sunday, 07 March 2010 20:35:43 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 

Hi all

I have just installed VMware WorkStation 7.0.1 in order to start building 64bit guest OS’es in order to try out Windows Server 2008 R2 and SharePoint 2010. Microsoft Virtual PC does not support 64bit guest operating systems, and since I really appreciate being able to run guest operating systems in a window on my host PC I saw no other way out than getting and installing VMware WorkStation.

Now, after installing it, I tried to create my first Windows 2008 R2 virtual machine, but that failed because I hadn’t enabled Virtualization Technology (VT) in my BIOS. So I rebooted, entered BIOS and enabled it. That worked fine, and I now have a virtual machine running Windows 2008 R2 64bit.

BUT, when I then wanted to fire up one of my old Microsoft Virtual PC virtual machines that I had earlier saved, I got an error saying that the saved file was corrupt. I had the choice of deleting the saved file or doing nothing. Since I needed the VPC, I chose to delete the saved file information and hope that I could recreate what was then lost.

Then, when starting up my next saved virtual machine from Microsoft Virtual PC, I got the same error. I have now played around with it, and it simply seems that if I save the state of a VPC and then turn on VT, the file gets corrupted and cannot be used :-( I even tried saving state when VT was enabled, and then I disabled it and reenabled it. Saved file was again corrupt :-(

This REALLY sucks! This means that you need to be really careful with when you save the state and when you do not…

--
eliasen

Sunday, 07 March 2010 11:03:41 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 
Tuesday, 02 March 2010

Hi all

Just to let you all know, that David GROSPELIER has written a BizTalk 2009 book in French that is about to be published.

You can find the book at Amazon and at Editions-ENI.

David has been so kind as to mention my collection of functoids from http://eebiztalkfunctoids.codeplex.com several times in the book, and since it is in French, I have not bothered to check what has been written, but trust that David knows what he is talking about :-)

So… go check it out! :-)

--
Eliasen

Tuesday, 02 March 2010 21:16:14 (Romance Standard Time, UTC+01:00)  #    Comments [0]  | 

Theme design by Jelle Druyts