I have gotten heavily involved with BizTalk since I have started my current employment a few months ago. It certainly has been a challenge to start with zero knowledge of BizTalk, and get involved into designing a fairly complex messaging architecture. I believe my prior involvement with a complex messaging system definitely helped me; however, the following steps were extremely beneficial in understanding and designing a BizTalk solution.
1) BizTalk Tutorials – I downloaded all the BizTalk tutorials from MSDN; but I believe I went through about 2/3 of them out of the 5/6 tutorials that are available. These tutorials definitely didn’t make me an expert; however, it gave me familiarity with many features of BizTalk.
2) Identifying What I Wanted – I believe my prior experience with messaging system really was useful in this regard. Without knowing much about BizTalk, I felt our messaging infrastructure as well as our related applications needed to do the following:
a. Integrate multiple external partners with a common messaging architecture.
b. Utilize loosely coupled entities to implement business processes.
c. Rely on a common framework and possibly a set of services.
d. Use a common schema for messaging purposes in relation to our line of business.
e. Flexibly transform messages to and from any external partners’ schemas.
f. Handle exceptions in a consistent manner.
g. Maintain consistency in instrumentation.
3) Enterprise Integration Patterns – I found this book (Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions) extremely helpful. It talks about numerous technology-agnostic patterns that can help design a messaging infrastructure. As I was reading through many of these patterns, I was like – “maybe I could use this, or that, or the other”. In other words, this book really got me thinking about some of the patterns, and prompted me to do further research about them in relation to BizTalk.
4) Google Knows Best – I conducted plenty of research using Google about the following in various stages of our design:
a. Implementation of various patterns in BizTalk
b. How to effectively utilize publish-subscribe mechanism in BizTalk to achieve loose-coupling and avoid monolithic structures
c. Custom Pipeline design
d. Exception Handling
e. And many more.
5) Test Applications – I not only conducted research about many BizTalk topics since I got involved with it, I also wrote test applications in order to connect the dots between my ideas and research. These mini-applications allowed me to get deeper into Orchestration, Pipeline, Configuration, Patterns and many more items.
6) Total Emersion – Finally, if not most importantly, I completely immersed myself into BizTalk. I literally ate, lived and breathed BizTalk and .NET in the last few months. I didn’t have the luxury to spend many months to become familiar with BizTalk. I needed to get up-to-speed in a hurry. So, I spent every little time I could find to learn anything and everything about BizTalk. I was heavily involved in the following during the entire design and development process:
a. Design a common framework to provide core functionality for all our applications.
b. Design schema for data interchange with our external partners.
c. Design schema for internal configuration, error handling etc.
d. Define and design business process
e. Integrate internal applications with BizTalk
f. Integrate external partners with BizTalk.
By no means, I consider myself an expert in BizTalk. There are still plenty of things to learn, and I am constantly learning many things each day. I am sure I will come across some surprises and challenges that would turn my hair greyer; however, I feel I was able to learn a great deal about BizTalk by utilizing the steps mentioned above.