Thursday, August 26, 2010

Microsoft BizTalk Server 2009

Bear with me please, this is my first real blog post and I don't have a lot of technical experience. I am 22 years old and I have recently started using Microsoft BizTalk Server 2009...before I get into anything technical, let me give you an idea of where my views are coming from. I graduated from Drake University in Des Moines, IA with a bachelor's degree in Information Systems this May (2010). I got my first real job this summer as a computer programmer working for an insurance company here in Des Moines. My title is Programmer I and the main software that I will be discussing in this post and more to come is Microsoft BizTalk Server 2009, Team Foundation Server 2010 and Visual Studio 2008.

My first impression of BizTalk is that it is a very intricate, complicated and frustrating product. Our first application just went into production last night and it's a relatively simple application. The application waits for an index file to appear in a folder, BizTalk uses the index file to import the documents listed in the index file and uploads them all to our electronic content manager. This is a fairly straight-forward application as I am sure many of you can attest to.

However, even as relatively simple as this application seems, BizTalk gave us countless headaches as we delt with the quarks that come along with it. Some of these include running into problems writing the .dll files during builds, not having a built-in component or method for archiving the files being uploaded, references dropping out of projects and a lack of a usable version control for all the builds and different versions of our source code.

We have tried using pre-build script to take care of the .dll issue and most of the time this worked. However, this is not the rule but seems to be the exception. The other times we have to manually rename the old .dll file with an extension such as .tst and then build. This takes care of that problem. We had a need to archive the files that were being uploaded in case we needed to run the application again or have a backup. There was no built-in archiving functionality that we could find anywhere and building a custom pipeline component didn't seem feasible. We took care of this by writing a .bat file that uses WinZip to archive the files. This seems to work just fine, however WinZip must be installed on the production server now.

Finally, the most frustrating of all the issues I have been facing is a very poor version control method built-in to the BizTalk, Visual Studio or TFS environment. The best method that we have come up with is to use source control and label points in time with version numbers so we have references to working applications if somebody makes a change that break the application. What we really want is something more like what my co-workers are used to in the Java development environment where versions of each source code appear along with the code all the time. We haven't found anything like this within the BizTalk environment.

Thank you for reading and please feel free to leave comments or questions you may have. The point of this blog is to help others and myself learn more about the world of BizTalk as the application looks to be a huge time/money saving investment for many companies!

No comments: