Simplicty bites
I am a big fan of simplicity, which is an unusual trait for us architects. But sometimes, it can waste some of your time.
In BizTalk 2004, while using VS2003, if you wanted to push up your solution to the server to test it, you had to (chant with me now) RE-build, RE-GAC, RE-start [the host]. This can be a huge hassle, and slows down your momentum during development. To the point that you almost avoid it as long as you can. This always caused problems for me, since I would be tempted to break the 'change one thing at a time rule.' This just led to more frustration on my part.
With the new BizTalk 2006 developer tools that plug into VS2005 they made this so much more simpler. You now right click the project, and choose 'deploy.' And that's it. It's all handled for you under the covers.
VS will rebuild (if needed), upload, regac, etc. to get you new code running. Very cool. It made huge increases in my productivity, and has made it easier for new BizTalk developers to get familiar with BTS. The old way was a huge barrier to someone learning this on their own.
The new process has worked for me just fine for a while now. But I generally stick to content based routing, and do as much as I can with pipelines/maps instead of orchestrations, at least with the stuff I happen to have been working on in BTS06. I have been working heavily withthe SQL adapter, and was doing tests on calling stored procs, updategrams, and debatching responses, so I had no need for orchestrations.
Then I was trying to do a quick and dirty orchestration one evening. I got the basic version up and running with no problems. I tend to develop my orch's in baby steps, with multiple short circuits to see what is happening. When I went to test the next baby step version, the new shapes in the orch weren't firing. The orch would just stop on the last shape the old version ran. HAT would step through just the old shapes, and ignore the new ones, even with break points! At the time I didn't recognize the true behavior that was going on, and it led to at least half hour of cursing. Eventually I went back to basics and re-started the host that the orch was running in. That fixed everything. My excuse, of course, was the I was tired from playing Oblivian. :)
[Side note: This also reinforces my rule number 8 of development: "The size of the root cause of your problem is directly proportional to the length of time to find it." Meaning, a major problem can be found quickly, and small problem, like a missing semicolon would take hours. ]
Of course, knowing about the orch's and assemblies, etc. this makes perfect sense, and I am ashamed this even happened to me. But I became dependant on the new simplicity in VS2005, and forgot a little of what was happening under the covers. The orch's assembly was loaded, and even though a new one was published to the gac/server, it didn't matter.
So, sometimes, simplicity can bite you. Sometimes it makes you forget the underlying 'stuff'.' Sometimes it causes you to take for granted what is happening. For Shame. :(
Ayway, I learned my lesson. I did find a new property on BizTalk projects in VS05 that allows you to have the host auto-restart. More Simplicity! I didn't turn it on, becuase there is a delay in deployment while studio waits for the host to restart. But it's nice that it's there. You can also set which BTS application your project is deployed too, which can be important.
-bhp
In BizTalk 2004, while using VS2003, if you wanted to push up your solution to the server to test it, you had to (chant with me now) RE-build, RE-GAC, RE-start [the host]. This can be a huge hassle, and slows down your momentum during development. To the point that you almost avoid it as long as you can. This always caused problems for me, since I would be tempted to break the 'change one thing at a time rule.' This just led to more frustration on my part.
With the new BizTalk 2006 developer tools that plug into VS2005 they made this so much more simpler. You now right click the project, and choose 'deploy.' And that's it. It's all handled for you under the covers.
VS will rebuild (if needed), upload, regac, etc. to get you new code running. Very cool. It made huge increases in my productivity, and has made it easier for new BizTalk developers to get familiar with BTS. The old way was a huge barrier to someone learning this on their own.
The new process has worked for me just fine for a while now. But I generally stick to content based routing, and do as much as I can with pipelines/maps instead of orchestrations, at least with the stuff I happen to have been working on in BTS06. I have been working heavily withthe SQL adapter, and was doing tests on calling stored procs, updategrams, and debatching responses, so I had no need for orchestrations.
Then I was trying to do a quick and dirty orchestration one evening. I got the basic version up and running with no problems. I tend to develop my orch's in baby steps, with multiple short circuits to see what is happening. When I went to test the next baby step version, the new shapes in the orch weren't firing. The orch would just stop on the last shape the old version ran. HAT would step through just the old shapes, and ignore the new ones, even with break points! At the time I didn't recognize the true behavior that was going on, and it led to at least half hour of cursing. Eventually I went back to basics and re-started the host that the orch was running in. That fixed everything. My excuse, of course, was the I was tired from playing Oblivian. :)
[Side note: This also reinforces my rule number 8 of development: "The size of the root cause of your problem is directly proportional to the length of time to find it." Meaning, a major problem can be found quickly, and small problem, like a missing semicolon would take hours. ]
Of course, knowing about the orch's and assemblies, etc. this makes perfect sense, and I am ashamed this even happened to me. But I became dependant on the new simplicity in VS2005, and forgot a little of what was happening under the covers. The orch's assembly was loaded, and even though a new one was published to the gac/server, it didn't matter.
So, sometimes, simplicity can bite you. Sometimes it makes you forget the underlying 'stuff'.' Sometimes it causes you to take for granted what is happening. For Shame. :(
Ayway, I learned my lesson. I did find a new property on BizTalk projects in VS05 that allows you to have the host auto-restart. More Simplicity! I didn't turn it on, becuase there is a delay in deployment while studio waits for the host to restart. But it's nice that it's there. You can also set which BTS application your project is deployed too, which can be important.
-bhp
Comments