Introduction

There have been many articles and blog postings about “Best Practices” and I thought we needed one about “Anti-Patterns”. We have all experienced them. Simply stating that something is a bad practice or anti-pattern doesn’t mean anything, it is simply an opinion.

There needs to be a reason why. And the best way to do this is for us to provide real-life scenarios we have all experienced. We all learn from our mistakes and reading about the mistakes of others. Hopefully the information in this list would benefit someone.

The "Anti-Patterns" in this list are not in any specific order.

Start designing your ESB Itineraries first

A client had decided that they needed an ESB to send data from SharePoint to a Data Repository. They had selected BizTalk 2010 with the ESB Toolkit 2.1.

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 designing .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, which could be reused. The developer simply took the samples included with the ESB Toolkit and “adapted” them. The developer was toldthat 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 Operations on database tables.
The section showing the Operations is shown in the figure below.

The Bindings for the SOAP Action header is shown in the figure below

He then added a new Request/Response Port with two operations as shown in the figures 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 a 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 bindingsto 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 initially recommendedthat they needed to validate each operation within a Scope and if any operation after the initial Insert failed, they shoulduse the Delete Operations for Compensation.

I suggested that 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.
• They decided that using ADO.Net classes was a better way to solve the problem.
• They would call these 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.

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.

The training would include Monitoring and Troubleshooting.

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 also suggested that they create a VM, so the BizTalk Admins could learn how to use SCOM and to evaluate other monitoring tools.This VM was to be used for their training.

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

Apparently they thought their solution architects needed a VM with BizTalk installed more so than their BizTalk Admin's and Operations team members

---

The disadvantages of using SMTP

Using SMTP has a number of advantages. The biggest advantage is probably that most organisations already have the infrastructure they need to exchange messages per email. So that makes SMTP very interesting to use in integration solutions.

From a BizTalk perspective however, there is an important down-side. This has to do with the state of your orchestrations when things go wrong.

Say your company build bikes. For different bike parts it has different suppliers. When you run out of parts, your BizTalk system orders the needed parts at these suppliers. Communication takes place with a SMTP Send port. The Send Port is configured with a valid email address and a local mailserver is configured as the SMTP Host. In normal situations the mails sent by the orchestrations flow to the configured email address and the orchestrations continue their work fine.

But now there's a problem with an upstream mailserver. Your mail is sent to that local mailserver, but never reaches the supplier Since BizTalk has correctly sent that email to the local mailserver, the orchestration has continued its processing, like updating the state of that order in your BizTalk system.

So now we have a problem. BizTalk, or better the orchestration, thinks it has succesfully delivered that email, while in fact it has not been delivered to the configured email address and the message lost in space. The process is broken.

For this reason, I think SMTP is not the best protocol of choice and should be replaced with another protocol, a solid compensating scenario or another pattern.

 

---

 

External Anti-Patterns & Bad Practices

The below articles are all other anti-patterns and bad practices which people have contributed and links to those resources:

Article	Overview	Author
Don’t over complicate your maps	Discussed how sometimes maps are made more complicated than they need to be by ignoring the scripting functoid	Michael Stephenson
Integrate Early but not all of the time	Discusses a common bad development practices where development teams tie together their coding efforts so developer A can not write because developer B is writing their code	Michael Stephenson
Plug & Play SOA	Discussed how some organisations buy BizTalk and magically think they now have an ESB or SOA without much thought into how to use it	Michael Stephenson
More Logging than a Lumberjack	Discusses a common development practice where a developer will not test their code properly and end up putting in so much logging code just so they can workout what their code does when in test environments or production because they have little confidence in how it works.	Michael Stephenson
Map that does everything but the kitchen sink	Given a complex process with many complex rules, everything (business logic, related and unrelated procedures, etc) is shoved into the map	Minty Fresh
Chuck it in the config file because its an easy place to put it	Discussing when it might be in appropriate to put custom configuration settings in BTSNTSVC.exe.config	Michael Stephenson
Just assuming is also a BizTalk Anti-Pattern	Unfortunately I did not ask any questions about their current environment. I just assumed….	Howard S. Edidin
5 minutes on the lips a lifetime on the hips	Thoughts on how BizTalk solutions often end up having increased technical debt in them due to work arounds for application integration challenges	Michael Stephenson