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
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.
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.
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.
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.
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:
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.
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.
The below articles are all other anti-patterns and bad practices which people have contributed and links to those resources:
Great Howard! I love to read these type of articles, not only it shares us the experience from learning the mistakes and how to make it better next time. But in additions, this could stir some debates which could be constructive by the end of the day. In regarding to "Start designing your ESB Itineraries first", I have the similar experience in my early days and it would be good if there were someone senior enough to guide me to right direction, and I learnt through the long winded way. A good way to tackle an inexperience integration developer in "Start designing your ESB Itineraries first" is asked him to explain what his understanding of an ESB in terms of principles and purposes, and any visions on how to get there(The tutorial won't give these details)? These questions could be the anwers to itself. The needs to understand integration maturity of an organisation needs to look back how they evolve from "spagethi" to "bespoke/hub", then to SOA, and to ESB integration. Here, it needs to understand that ESB is a mechanism to SOA enabling. To have your service to implement that meets SOA, the service must has at least the following characteristics include loose coupling, flexible implementations, modular access to applications, shared services and standards-based protocols. To summary, an ESB implementation is a journey with a vision roadmap and strong governance practices to get you there. So an implementation using ESB without these in minds will not be any benefits to your business(may be good from the developer's resume).
guys ive just added some more external links to other patterns