Integrating to the max...BizTalk Style

  I had the weirdest issue, a helperclass that was called by a functoid did not returned to correct result in the debugger (And in the mapping result). After a redeploy, rebuild, clean solution, removing and adding the dlls in the GAC I couldn’t figure out what the issue was.. Somehow variables were shuffled, an Integer became a string and viceversa…. After finding out that the Incense warehouse was closed, I knew I had to do something unexpected…..I renamed the variables…magically it worked?? Well, another couple of hours of my life spent on utter ridiculous weirdness….so if you have this problem….do what you think shouldn’t be required, thinking different might do the trick. Kind regards, Sander

  The installer starts with the most ‘obvious’ check ever, we need at least 256 colors…can’t even remember a videogame in the Dos Era that did that…. Then the PATH variable is too long… I guess there is some room for minor improvements…   Please consider that I’m just posting this to free my mind and allowing it to relax. Cheers….now it’s time to use the time machine to go back in time and finish the installation….with great joy. Sander

  Inside orchestations it’s fairly easy to read ContextProperties (albeit Promoted/Distinguished). I had a strange issue where a was reading out a property multiple times in different scopes (in the main branch as well as the error handling to determine a value inside our msg): Start of the orchestration LOG( requestMessage             (Customer.Domain.Common. Schemas.AdminID, ….., ….. ); When I did the exact same thing inside the orchestration in another section… I got a exception about a missing property. So unexpected and not helpful….the incoming message was not altered inside a rule, the properties were of the MessageContextBase (so not bound to the messageType) and I used the same code. In the end I switched to a variable assignment; variable asssignment = msg(Property);   So my new rule is, assign context properties as soon as possible to variables, scoping and context properties seem to conflict sometim...

  Several weird issues I’ve encountered have made my think about a special blog theme ‘BizTalk Quircks’. The first one is the BizTalk mapper in 2010. As blogged earlier, there are some behavior differences, but to my opinion as well a few bugs. As I’ve not spent a lot of time reproducing the issues but have met colleagues with the same issues, here some issues you might encounter; A link to a functoid that is removed remains active in the functoid parameters This means that it isn't possible to create a new link, the parameter has to be manually removed in the mapper. Creating several links to a functoid (with e.g. 6 params) lets the mapper loose count I had a functoid with 6 parameters, filled them all, but somehow the link of parameter 6 created a void parameter 7, this meant i got a validation. When i removed the parameter in the functoid it was all fine and dandy. Creating a 'new' message (SalesOrder = SalesOrder) using a map doesn't filll all the values ...