-
-
One of major announcements at the Tech-Ed is the VS 2005 teamsystem and this one makes me very happy. Chris Sells posted an overview of links to relevant information.
-
-
Scott Colestock published a sample to automate deployments using NAnt extensions here. Although I haven't tested it, I like the approach very much.
-
-
I've done a lot of refactoring in BizTalk lately and concluded that BizTalk doesn't really support that in it's tools. But lukely everything is mostly XML (mixted with some plain text). That make refactoring a lot easier. You can use Search and Replace and do some educated copy and paste of large pieces of code. Which is good.
But today I looked at a pretty complex Tracking Profile with 5 activities and 5 orchestration, that needs upgrading to a new assembly version. There are only some small changes in orchestration flow and no schema changes. I haven't found a way in the TPE in which I can even tell that I want to use another version. Even worse, the tool won't even open the file if the correct assembly version isn't found in the database. Well, I thought, let me just fix it up in the XML, instead of recreating the same profile on a different version.
BUT A BTT-FILE ISN'T XML, IT LOOKS LIKE IT'S BINARY. Sorry? I was so stunned I closed notepad down immediately, in shock. Mmm, the last bit is not really true ;-).
But I do feel the great effect of XML on my programming. I have had some troubles getting tools to do what I want, having no alternative because the proprietary binary fileformats those tools used.
BTW, there is text in the BTT-file, and it looks like you can at least change the version number there, just haven't tried that out yet. But I don't think you can easily refactor bindings by the looks of it and that's a great miss because the Tracking Profile Editor is not really a User Friendly Tool.
-
-
When you have long-running orchestrations that receives messages from a direct port on another orchestration, a subscription is created for every running orchestration that listens to the version of the partner orchestration that is current at that moment. That means that if you need to create a new version of the sending orchestration that replaces the current one, the living orchestration can no longer receive messages.
I don't think there is a simple solution to this. It's a direct result of the way versioning works in BizTalk. I did find a way around it though, which should be used with much care. It is possible to change the subscriptions in BizTalk MessageBox database. Since I do not master this technique yet, I won't discuss how to do it. But anyone interested should look at the bts_ReadSubscriptions stored procedures and the EqualsPredicate table in the MessageBox database and find a field that points to the old assembly-version. Changing that to the new version will work (I did restart BizTalkApplication just to be secure).
Did I mention that I don't take any responsibility and that it's probably a bad hack which is not supported by Microsoft and that you shouldn't direct edit the MessageBox and so on and sofort? ;-)
BTW, I used the Subscription Viewer tool to get more info about subscription data. The Arch Hacker pointed it out here, which was a great help.
-
-
Good reference article if you ever need to dive into CAS. Read it here.
-
-
If you are refactoring your project or have large amounts of similar orchestrations that you copy over, you quickly bump into the problem that search and replace doesn't really work in orchestrations.
The solution is pretty simple, the orchestration is an XML file that you open with the HTML/XML editor by right-clicking the file in the solution explorer and choose Open With. Now you do have full search and replace capabilities.
-
-
Charles Young tries to clear some of the unclearity that is surrounded around how BizTalk handles messages in an orchestration. Read it here.
Very useful and informational article.