Microsoft BizTalk 2010 Administration Essentials

Our book is available for pre-order at PackT.

Release Date : November 2012

Overview

• First BizTalk book that is completely oriented for System Administrators
• Covers combined experiences of many renowned BizTalk Administrators from all around the world
• Written in clear concise step-by-step style and includes real world issues and solutions

Technorati Tags: BizTalk Administration,BizTalk Operations

---

BizTalk Community series: Introducing Howard S. Edidin

 

Steef-Jan Wiggers was kind enough to write an article about me on his blog,  Azure Thoughts, EAI Challenges.

 

You can read the article here

Not just a BizTalk Anti-Pattern

This is a follow up to my last BizTalk Anti-Pattern post

This is primarily for the Technical Recruiter.

My last contract was mutually terminated. I had worked for this client architecting their BizTalk 2006 R2 / ESB 1.0 EAI implementation.  I was contracted to architect their migration to BizTalk 2010.

There was a disconnect between what the client expected and what a BizTalk Architect role does.

After I completed their 2006 R2 / ESB implementation, the client had cloned the ESB 1.0 and deployed it on web servers. Not only did they duplicate the Itinerary functionality, but they customized it. They created their own custom core components and pipeline components.  

I won’t go into the details (saving these for the Anti-Pattern List). One of my tasks was to help the developers migrate their custom ESB Web Application to ESB 2.1.  All their tests were failing.  I was expected to help their developers. 

It would benefit everyone if you would ask the client for explicit details on what they expect of a role.  The client would rely on you more often to find the right person for the job..

A good source that describes the BizTalk Architect Role can be found on the TechNet Wiki.http://social.technet.microsoft.com/wiki/contents/articles/6243.biztalk-roles.aspx#BizTalk_Architect

If you search the TechNet Wiki http://social.technet.microsoft.com/wiki/, you should be able to details on other roles.

Technorati Tags: Anti-Patterns,BizTalk Architect Role,BizTalk 2010,BizTalk,Contract,ESB Toolkit,Recruiter

More BizTalk Anti-Patterns

Just assuming is also a BizTalk Anti-Pattern

About a month ago I accepted a contract as a BizTalk Developer for a major care product service provider. The project was to incorporate United Parcel Services mapping and routing services into existing BizTalk 2009 Applications. This was a major project with a fairly large budget. They were willing to pay a fairly high rate.

Part of the scope of the project was to incorporate the Windows Azure Service Bus.

Unfortunately I did not ask any questions about their current environment.  I just assumed….

• It wasn’t until I started that I found out they were using BizTalk 2009 Standard.

• They were not using Maps, WCF-Lob Adapters, Pipeline Components, or the ESB Toolkit. The only had a few schemas

• They did everything in .Net code and WCF Services and called these services from Expression Shapes in Orchestrations

I was told that the were only using BizTalk for Guaranteed Delivery.

I demonstrated how they could easily develop this application in BizTalk without the need to write a lot of code.

 

They had no interest in changing their use of BizTalk. Nor were they interested in upgrading to Enterprise.

 

Technorati Tags: BizTalk,Anti-Patterns,Bad Practices

BizTalk Server 2010 Cookbook

It’s about time someone authored a BizTalk Cookbook that all BizTalk Roles could relate to. Most BizTalk 2010 books have been geared towards developers only.

I had ordered this book several months ago and just received my copy yesterday. I hadn’t had a chance to read the book in depth. Normally I look at the table of contents and just read the chapters that interest me. I found this book a little different; all the chapters included sections that sparked my interest.

The author, Steef-Jan Wiggers is considered to be one of the top BizTalk experts in the world. He is well known and widely respected for his contributions to the BizTalk Community. He is a MVP for BizTalk, a distinction not easily earned.

Unlike most cookbooks, in which the chapters do not follow a pattern, I found that the recipes read much like tutorials. Steef-Jan has included sample code for each chapter.

Once I have time to thoroughly read the book and work through some of the samples, I will continue this review. From what I have seen so far, this book is a “must buy” for anyone involved with BizTalk. As I mentioned previously, this book is not only geared for BizTalk Developers.

The book is available from Amazon or from PackT.

BizTalkIn: The BizTalk Anti-Pattern List

BizTalkIn: The BizTalk Anti-Pattern List

The BizTalk Anti-Pattern List

I changed the name of the “Bad Practices” List on the TechNet Wiki.

It’s now called The BizTalk Anti-Pattern List

The BizTalk Bad Practices List is now on the TechNet Wiki

Wiki  >  TechNet Articles  >  The List of “Bad Practices” for Designing, Developing, and Administering BizTalk / ESB Solutions

We all learn from our mistakes and reading about the mistakes of others. Hopefully the information in this list would benefit someone. .

Lex Hegt has added “The disadvantages of using SMTP” to the list.

Do you have something that you would like to share?

.

Technorati Tags: Bad Practices,Anti-Patterns,TechNet Wiki

The BizTalk Bad Practices List

The List of “Bad Practices” for Designing, Developing, and Administering BizTalk / ESB Solutions

Since I specialize in providing Guidance and Training for companies implementing BizTalk, I have run into many situations where the client has already started designing and developing BizTalk Applications. Several have done so without any formal training or direction.

There have been many articles and blog postings about “Best Practices” and I thought we needed one about “Bad Practices”. Simply stating that this is a bad practice doesn’t mean anything. There is needs to be a reason why. And the best way to do this is provide real-life* scenarios I have experienced.

The "Bad Practices" in this list are not in order of importance. I have decided to append each one to this post rather than create a separate post for each one. I plan on adding a new "Bad Practice" once or twice a week.

If anyone has a particular "Bad Practice" they would like to share, please add it into a comment.

The List of “Bad Practices”

Start designing your ESB Itineraries first

The client had decided that they needed an ESB to send data from SharePoint to a Data Repository. I don’t believe that they fully understood the capabilities of BizTalk 2010 and how the ESB Toolkit 2.1 is used. Apparently they had no actual experience in architecting and designing BizTalk / ESB Solutions. They did have quite a bit of experience and knowledge in architecting .NET Applications and WCF Services. Having read all about the use of Itineraries in the ESB Toolkit 2.1, it was decided that their newly trained and inexperienced Lead BizTalk Developer would develop a framework of Itineraries for routing messages, that could be reused. The inexperienced developer simply took the samples included with the ESB Toolkit and “adapted” them. The developer was told  that Itineraries would be designed first. At this time they had no requirements for BizTalk Applications. To add fuel to the fire, it was dictated that they would use SCRUM for all projects. The BizTalk Developers would develop their Itineraries in multiple sprints. Notice that there has been no reference to designing BizTalk Applications.

Using the Generated Operations Name for the Action (SOAP Action Header) from a WCF LOB Adapter

A BizTalk developer was using the WCF LOB SDK to generate a WCF LOB SQL Adapter service to perform several CRUD Operation on database tables. The developer built the application, deployed it, and imported the generated bindings. The section showing the Operations is shown below.

The Bindings for the SOAP Action header is shown below.

The developer needed to create an Orchestration to consume the service. He created a new BizTalk Project with an Orchestration. The Orchestration was to be used to Insert data into two tables He then added a new Request/Response Port with two operations as shown below.

If you compare the difference between the WCF LOB Service Operations names and what the developer used for the Port Operations Names you will notice that they do not match. After deploying the Orchestration the developer, he then tried to test it. An Insert Request Message was sent to the WCF Service. He did not receive an Response Message. After checking the Applications Event Log, he discovered that he had an invalid type error. He came to me for help and we discovered he had misnamed the Operations on the WCFLOBPort in his Orchestration. The issue here is that both the Operations Name in the Bindings and the Operations Name for the Orchestration Port must be the  named the same. Recommendation:

Naming your Port Operations so you can easily identify them in the Orchestration is a good practice. You will need to modify the Operation Name for the Action on your port to match. Using the generated “Insert1”, “Insert2”, “Select1”, etc. makes it difficult to identify, especially when you could have multiple Select, Insert, Update, and Delete Operations within an Orchestration.

Using ADO.Net instead of SQL Stored Procedures for CUD Operations within an Orchestration

A client wanted to promote the reuse of WCF LOB SQL Adapter services. It was decided that they would use separate Stored Procedures for Create, Update, and Delete operations. They didn’t want the Stored Procedures to contain any business logic.

There was a requirement to:

Insert a record into a table Return the identity for the record Insert the a record along with the identity into another table Repeat for a few more tables.

They wanted to handle this within an Orchestration. I told them that they needed to validate each operation within a Scope and if any operation after the initial Insert failed, they would need to use the Delete Operations for Compensation.

I suggested a better way to handle it was to create a Stored Procedure with a Transaction to handle all the operations. This way they would be able to eliminate the need for an Orchestration.

They didn’t like the idea of putting this “business logic” in a Stored Procedure. It didn’t fall in with their overall Architecture.

Their Architect decided that using ADO.Net classes was a better way to solve the problem. They could call these from within an Orchestration.

Spending the entire budget for BizTalk Development and leaving nothing for Administration and Operations

A former client decided that they wanted to use BizTalk 2010 for their Messaging Solution. They had very little exposure to BizTalk 2010. They decided that they would need to train their .NET developers on BizTalk Development. They decided the best way to do this was to being in a qualified BizTalk Training provider.

At first, they had planned on training five developers. Someone came up with the idea that it would be worthwhile for all their architects and other developers go through the same training.

Can you imagine what the cost was for several weeks of training…?

Prior to my starting with the client, they had migrated several HL7 feeds from their legacy system to BizTalk. The legacy system administrator became the BizTalk Administrator. They had also contracted for an experienced BizTalk Administrator who had HL7 experience.

Their BizTalk Administrator had done an excellent job of installing and configuring their production environment. IMO, this was the first good decision the client made.

They had sent their BizTalk Administrator for a week of training. It was my job to continue his training and guide him on the administration and operations tasks necessary for an enterprise BizTalk 2010 infrastructure

I recommended that they implement SCOM 2007 R2 or another third-party tool to monitor their BizTalk infrastructure. We were told us that they ran out of budget money

I suggested that they create a VM, so the BizTalk Admins could learn how to use SCOM and to evaluate other monitoring tools. Again, they ran out of budget money for another VM.

It seems that all the architects and developers were provided with a VM and they did not have the resources to create one for the BizTalk Administrators.

To be continued…