Sunday, 25 July 2010

Hi all

I have decided to start up a personal blog as well. I get a few complaints from people who don’t care about my personal life, and therefore, I will be moving personal blog entries to my new blog at http://jan.eliasen.dk – with an RSS feed at http://jan.eliasen.dk/syndication.axd

This blog will NOT change! Well… personal blog entries will not appear anymore, but other than that, I will still be blogging about technological abnormalities, funny things, strange things, errors, and what not…

So, for Jan, the person, go see http://jan.eliasen.dk

Thanks

--
eliasen

Sunday, 25 July 2010 20:08:24 (Romance Daylight Time, UTC+02:00)  #    Comments [2]  | 
Wednesday, 07 July 2010

Hi all

The other day a developer who needs to call a BizTalk exposed web service approached me and told me that there was an error in the wsdl – something about the Response having the wrong fields.

So, I fixed it – I changed the XSD and ran the WCF Service Publishing Wizard again.

I called the developer and told him that everything was fine now. He refreshed his service reference and told me that everything was just as it was before. So I thought; Restart IIS.. and I did. Developer goes: Jan, what is wrong with you? Everything is still the same!

So now I actually need to start thinking…

Turns out, that silly I just did this:

  1. Made my changes to the XSD
  2. Recompiled
  3. Run the Wizard
    1. Point to the newly compiled assembly
    2. Finish the wizard

BUT, what I forgot was to deploy the newly created assembly… or at least GAC it. Because the wizard, even though you point to a .DLL in the file system, will look for the assembly in the GAC with the same strong name and used that instead of the .DLL you chose. To me this is really silly… It could at least provide a warning that it will ignore the assembly I chose before ignoring it.

Anyway, after deploying the new assembly, everything worked just fine.

--
eliasen

Wednesday, 07 July 2010 22:39:35 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Sunday, 04 July 2010

Hi all

If you read the documentation for Correlation Sets (here), you will see that it clearly states that:

“Each correlation set supports a maximum of three parameters.”

Now, the documentation for BizTalk 2010 is still subject to change, but you will find the same text in the documentation for previous versions.

The funny part is, that inside the Orchestration View, you are allowed to add as many properties to your Correlation Type as you please:

image

You will get no compiler error, as I would have expected, and no compiler warning, either.

I implemented a small orchestration that uses the Correlation Type seen above and it looks like this:

image

Basically, a message in, a transformation, an output and then a response back in. The “msg_FirstOut” initializes the correlation set and the “msg_SecondIn” follows it.

As mentioned, the compiler will not complain at all and I can deploy the solution. Once I send a message through, an instance subscription is created once the send shape has finished, and this surprisingly looks like this:

image

As you can see, ALL five properties are used in the instance subscription, which in effect means that the documentation is wrong.

So this brings me to the point; The documentation states, that you can only have three parameters (not sure why they call them parameters) in a Correlation Set, but this actually ONLY applies to Correlation Sets used in Convoys.

If I change my solution to utilize a parallel convoy like this:

image

or to be a sequential convoy like this:

image

then I still get no compiler warning or error no matter how many properties I have in my Correlation Type, but if I deploy the solution and try to start the orchestration, I get this error message:

image

“The maximum number of convoy set properties has been exceeded. A convoy set can only contain up to 3 properties.”

Now, you may very well ask, what is a convoy set? And yes, it is a bit confusing that the error message uses a term that is actually internal to BizTalk and not something your average BizTalk developer cares about. But a convoy set is simply a correlation set that is used in a convoy.

So this means, that for correlation sets that are used for convoys you can only have three properties, which actually comes from the fact that the table “ConvoySets” in the MessageBox database has three columns called “uidPropertyID1”, “uidPropertyID2”, and “uidPropertyID3” which contain GUIDs that are the GUIDs of the properties in the correlation set. So since only three fields exist in the database, only three properties can be in a convoy set.

So to me, it would nice if:

  1. The documentation was clear about the fact that the limitation only applies to correlation sets used in convoys
  2. The compiler would provide an error if you use more than three properties in a correlation set used in a convoy so you don’t ahve to wait until starting the orchestration to find that out.

Happy correlating and convoying out there!

You can find my sample code here: ThreePropertiesInCorrelationSet.zip

--
eliasen

Sunday, 04 July 2010 15:29:02 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Saturday, 03 July 2010

Hi all

This is probably most useful to Danish BizTalk people… We are four guys trying to start up a Danish BizTalk User Group.

The first meeting is set to be on August 12’th with the following agenda:

  1. Introduction to the User Group
  2. Basic topic: The new mapper in BizTalk 2010 by Jan Eliasen
  3. Advanced topic: Introduction to WF4 by Christian Stærk
  4. Tools of the Trade: Pipeline Component Wizard by Jan Eliasen

So as you can see, I’ll be speaking twice :) And unless someone else has a great topic, I have an advanced topic lined up for the next meeting as well.

You can find the official invitation here:

  – Danish only.

Everyone is invited, so please spread the word and the invitation.

Thanks

--
eliasen

Saturday, 03 July 2010 22:18:57 (Romance Daylight Time, UTC+02:00)  #    Comments [0]  | 
Thursday, 01 July 2010

Hi all

I am extremely happy to announce, that today I was re-awarded the MVP title for BizTalk Server for another year.

This is my fourth MVP title and the third in a row.

--
eliasen

Thursday, 01 July 2010 21:26:46 (Romance Daylight Time, UTC+02:00)  #    Comments [4]  | 
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]  | 

Theme design by Jelle Druyts