Hi all

Actually, I was warded the MDIP title quite some time ago – I just haven’t blogged about it.

The MDIP title is sort of a Danish mini-MVP award. It stands for Microsoft Designated Information Provider.

Yeah…

--
eliasen

Hi all

Last week I participated in a pretty insane and intensive 5-day course covering the TOGAF 9 Foundation and TOGAF 9 Certified curriculum.

We were 11 people form Logica Denmark doing the course, and on Friday we all took the Foundation exam just after lunch. Luckily we all passed and then at 2pm we all took the Certified exam. The colleagues I have heard from by now all passed, and I am happy to announce, that so did I.

So I can now call myself TOGAF 9 Certified!

You can read more about The Open Group, TOGAF and the certifications at http://www.opengroup.org/, http://www.opengroup.org/togaf/ and http://www.opengroup.org/togaf9/cert/.

--
eliasen

Hi all

If you go to http://msdn.microsoft.com/en-us/biztalk/default.aspx you can see that this month I am the featured BizTalk MVP – yeah…

--
eliasen

Hi all

A couple of days ago I held two presentations at the first meeting in the Danish BizTalk User Group (DBUG).

The first presentation was about the new mapper in BizTalk 2010.
Find my presentation here:

The second presentation was about the Pipeline Component Wizard.
Find my presentation here:

Find the code samples for both presentations here:

Note that my file names, source code, and so on has “DKBUG” instead of “DBUG” because the official acronym wasn’t chosen until the meeting, so I guessed… and guessed wrong

That’s all, folks!

--
eliasen

Hi all

For those interested in the Danish BizTalk User Group (DBUG), at LinkedIn group has been created, free for everyone to join.

Find it here: http://www.linkedin.com/groups?gid=3305228

--
eliasen

Hi all

So, today my boss confirmed that I can go to the event held by the Swedish BizTalk User Group. See the details of the event here: http://bugs20100908-widget.eventbrite.com/. The event says it’s a BizTalk 2010 launch party… but whether BizTalk 2010 will be out there… I don’t know.

I am really looking forward to hearing what Richard Seroter, Ewan Fairweather and Stephen W. Thomas have to say. I have preordered their book, both paper and ebook editions. Hopefully I will receive at least one of them before September 8’th where the event starts.

Also, this will actually be the first time I will meet Johan Hedberg and Mikael Håkansson, who are two of my Swedish colleagues who are both BizTalk MVPs.

Anyway, flight and hotel are booked. Look for me there!

--
eliasen

Hi all

Today I exported an MSI file from my development machine and wanted to import the MSI file on our test environment.

I got this error, though:

Change requests failed for some resources. (mscorlib)

Unable to process create change request for BizTalk binding "BindingInfo.xml". Import bindings (overwrite) failed. (Microsoft.BizTalk.ResourceManagers)

Failed to update binding information. (mscorlib)

Cannot update receive port "WcfReceivePort_FvmIndberetningCommon_CVR/FvmIndberetningCommon_CVR". (Microsoft.BizTalk.Deployment)

Cannot update receive location "WcfService_FvmIndberetningCommon_CVR/FvmIndberetningCommon_CVR". (Microsoft.BizTalk.Deployment)

The following items could not be matched up to hosts due to name and/or trust level mismatches:
Item: 'WcfService_FvmIndberetningCommon_CVR/FvmIndberetningCommon_CVR' Host: 'FVM_Indberetningsplatform_IsolatedHost' Trust level: 'Untrusted'
You must do one of the following:
1) Create hosts with these names and trust levels and try again
2) Re-export the MSI without the binding files and have a post import script apply a suitable binding file. (Microsoft.BizTalk.Deployment)

Now, the error message is pretty easy to understand. What had me baffled was, that the host exists and it IS untrusted. So there is no mismatch and the two ideas as to what to fix don’t seem to apply to my situation.

It turned out that the issue was that after creating the needed host and host instances, I had forgotten to add the necessary Receive Hander on the appropriate adapter for the receive location. But the error message doesn’t say anything about that – it just says that I need to create the host with the right trust level.

So, this post is just to let you know that there is another reason for the error message than what the error message states.

--
eliasen

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

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

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:

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:

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:

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:

or to be a sequential convoy like this:

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:

“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!

--
eliasen