Saturday, February 25, 2012

The BizTalk Bad Practices List

BAD PRACTICES


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.
binding
The Bindings for the SOAP Action header is shown below.
soapaction
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.
orchports1 insert1insert2
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:

  1. Insert a record into a table
  2. Return the identity for the record
  3. Insert the a record along with the identity into another table
  4. 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…