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…