Geeks With Blogs

News View Michael Stephenson's profile on BizTalk Blog Doc View Michael Stephenson's profile on LinkedIn
Michael Stephenson keeping your feet on premise while your heads in the cloud


This post is mainly about the design decision that you will face on a project where you have a system you want to integrate with but its interface does not have a supported out of the box BizTalk adapter.  We are quite lucky that in BizTalk 2006 there are an extensive set of adapters now with the Enterprise Line of Business adapters, but there are still lots of occasions when you have to use something else.  The design decision to be made is what that "something else" should be.  My intention with this post is to base it on what you would do with BizTalk 2006 and then in the future I will revisit this based on the adapter framework enhancements which are available in BizTalk 2006 R2 and cover how this may affect the decision you would make - I know R2 is just about to come out but its taken a while to get around to finishing this :-)


There were a couple of projects I was asked for advice on where they had to integrate with a system via socket connection and they had chosen different approaches to solve a very similar problem with differing results.


I believe this is one of those typical design decisions where there is no clear right answer, and there may be multiple bad answers.  The key is to analyse your situation and evaluate each option to help choose which is best for you.


Here are some thoughts on the various options which you might consider based around the situation I described above.


Third Party Adapter

There are a number of companies which develop custom adapters and tools to compliment BizTalk.  You might consider purchasing an adapter from a 3rd party company to facilitate the communication you require.  The following are some of the key points when considering a 3rd party adapter:


Cost: It will obviously cost money to purchase this adapter.  It may be quite expensive to purchase this adapter so you will have to evaluate the effect of this cost on your project budget.  Hopefully you will have identified this early in the project life cycle so you can include this cost in your budgeting.  Be sure to remember to factor costs for appropriate support agreements to meet your SLA.


Support: When you buy a 3rd party adapter you will need to be sure you can get any support you will need to meet the SLA for your project.  You need to be confident the company isnt going to go out of business and potentially leaving you in an awkward position having invested in their adapter but being stuck with an issue you require support for and no longer being able to get it.  This risk can be mitigated by looking on the Microsoft web site for partners who have been recognised for their ability to develop adapters.  To find out more about partners specialising in adapters check out this link


Experience: Development of adapters is one of the more difficult areas of BizTalk.  3rd Party companies who specialize in adapter development will have experience of developing numerous adapters and you will probably be purchasing a product which has been used on numerous projects.  This should increase your confidence level in the product.


Testing: Because the company is selling the adapter you can have a level of confidence that the product will be relatively well tested before it was released and also additional testing when used on projects.  It is probably worth checking out how long the adapter has been available for and how many projects it has been used on.


References: It is likely that the company will have a list of their referenced customers on their website so look for well known names as a sign of a quality product.  Also speak to your colleagues who may have used the adapter.  Good feedback about from people you know is good when considering any purchase.  One thing to remember is that if you offer to be a case study or reference for the 3rd party you may be able to negotiate a discount.


Trial: For most 3rd party company adapters there will be a free download trial version available which will allow you to evaluate the product before your decision is made.  It is probably worth doing a POC and if you have any questions on the use of the product contact the company and you will find out what their support and response times are like and get to know them before you commit to using their product.


Community Adapter

I am a big supporter of community projects and on the projects I mentioned above the TCPIP adapter samples which have been available in the community have been evaluated and considered in various forms.  Some of the considerations for community adapters and solutions are as follows:


Cost:  The great thing about community adapters is they are free.  People create these in their own time for intrinsic reasons and we should all be grateful for their contributions.  (Sorry if that seem a bit harsh but I remember back last year i think it was the NDoc i might be wrong project where they stopped working on it because people were hassling them for enhancements.  Remember community projects are done for fun not profit)


Support: With community projects you will be getting the product as is with no support agreements.  This may cause you problems if you create a heavy dependancy on this product and it turns out to have a problem.  Often with community projects the source code is available so you might be able to support yourself provided your team has the right skill set.


Experience: While the people on a given community project might be highly qualities people with lots of experience you can not always be sure of this and you will not always know much about where the adapter has been used before or what the results were like.


Source Code: If you can get the source code for the adapter you might want to decide if you should review the code and make any enhancements to it so it meets your project standards or add or remove features so it will fit better into your project.  You may also choose to integrate the project into your development process such as putting the code into your source control and continuous integration systems. 


References: The best places to find out about references for community adapters is to ask on the MSDN forums for other peoples experience, look at the website hosting the adapter for any feedback of discussion forums or to ask the project contributors about it.


Openness: With a community project you are likely to get an honest opinion about the adapter from people.  Because it is a not for profit project there will be no sales spin around what you will see.


Testing: You may be lucky and get a community adapter which has unit tests of the code, but there is a significant amount of code that can not be tested without being inside BizTalk and also there may be load testing issues which you will not necessarily be sure about how the adapter will perform.  This is similar to the issues with custom coded solutions.  The best way to mitigate this risk is to ensure you test these areas in your project well and also make sure to court the opinion of others on the adapter.



Custom Adapter

A custom adapter is a common choice the development team will create the adapter and manage the source code for the adapter.  Some of the considerations you need to make when considering a custom adapter are:


Cost: The custom adapter may seem on the face of it a cheap solution with a developer being able to "knock up some code" and then plugging it into a generated template, but in order to develop a quality adapter it should be treat as importantly as any other solution artefact.  It should adhere to all project standards and be extensively tested.  These are costs which when the decision is first considered may not be immediately thought of. 


In addition to these costs doing a poor job of the custom adapter can result in lost time troubleshooting issues or reworking the adapter, and in the worst case having to reconsider this decision and choosing a different option.


Testing: If you develop a custom adapter it is important that you test is extensively in isolation.  If you don't do this then to be honest you deserve what you get.  A good example of this was one project I was one where a proof of concept was done where a custom adapter was created to connect BizTalk to a legacy system.  This POC was created in less than 2 days to prove the connectivity could work.  A few months later the project which had appeared to be progressing ok started having issues during performance testing where it was found that the POC adapter was still being used exactly as it was from the POC.


Risk: There is a degree of risk associated with the custom adapter solution.  This is mainly around the confidence level you will have in the code.  It is likely that even though you may have very competent developers your adapter development will still not be tested to anything like the level of a 3rd party adapter.  I have experienced projects where the adapter is not really a core project deliverable in the same way that the execution of the business process is.  The project testing focuses on the functional aspects of the adapter and ignores things like how it deals with load until late in the project cycle when any issues become much bigger than they would be if identified much earlier. 


Appropriate Adapters:  Im not quite sure what the correct heading for this should be but basically what this point is about is when creating an adapter you should be creating something generic.  For example the Soap adapter is a generic adapter because it can call pretty much any web service and configured to call any method on that service.  You could also have a generic adapter for an application so it could call any service on a specific application.  What would not be a good practice would be to have to create a different adapter for each method on an application.  That would not fit with the adapter architecture used within BizTalk.


Web Service Facade

The web service facade option would involve writing the appropriate code to call the application you intend to integrate with and then exposing this as a web service.  You would then use one of the out of the box BizTalk adapters to connect BizTalk to this web service.  Some of the considerations with this choice are:


Coding: In terms of the coding this solution should be relatively simple.  There will be no infrastructure code for BizTalk to write.  You will be able to concentrate on the core code to call the external system.  You will also be able to separate the web service from the BizTalk solution if you want to allow one resource to focus on getting the service right while a BizTalk resource could continue with the BizTalk solution by integrating with a stub of the service.


Testing:  A web service is relatively to test and you can also use some of the Visual Studio features to run a basic performance session on the service.  You will be able to easily develop a fairly high confidence level in the web service code.  The BizTalk code will not be dependant on calling the external system during development so by stubbing the service you will be able to easily execute your test cases and get a high level of confidence in the BizTalk code.  It is still important to hook together the real service and BizTalk early and regularly to ensure that any unexpected issues become apparent.


Risk: The web service facade option is quite simple and uses common technologies and out of the box BizTalk features.  Based on this the risk level is relatively low.  The small risks that are associated with this option are easily managed.


Performance:  One of the key negatives about this solution is it can introduce an extra round trip.  In some cases this can be an important issue.


Cost: The costs of this upfront will be based around creating a new deliverable in the web service.  This kind of cost however can be estimated fairly easily.  The maintenance costs will be lower and also there should be a lower risk of hidden costs.


Encapsulation:  This solution does have the benefit that the interaction with this system or protocol should be encapsulated within the adapter.  I did see a good example where this would help, basically the 3rd party system interaction was encapsulated behind the web service.  We considered changing the decision because the application was found to have a COM API which was the recommended way to integrate.  Basically we were able to change the internals of the web service to work with the COM API without having any affect at all on BizTalk.  With a different solution we might have had to change the adapter then add new schema and maps to allow be able to send the right king of message.



Inline Pattern

Put simply the inline pattern involves writing a helper class to communicate with an external system and then calling this class from within an expression shape in an orchestration.  The key points of consideration with this choice are as follows:


Coupling: Using the inline pattern is a change to the normal architecture used within BizTalk.  Using the inline pattern will increase the level of coupling between the orchestration logic and the systems it will communicate with.


Loss of Features: By using the inline pattern you will lose the ability to use a number of BizTalk features.  These will include send port retries, alternative delivery location, failed message routing.  You will also lose the tracking within HAT.  I'm sure if I thought about this for a while longer there will be a lot of other things you must sacrifice.


Performance: One of the key benefits of the inline pattern is that it will increase performance of the process as you will lose the latency of having to go back to the message box and back before calling the external system.


I may revisit this at some point in the future as im sure there is more to add about the inline pattern.  In my experience though the only valid reason to use the inline pattern is for the performance benefits when you need to implement a low latency scenario.  I have also seen an occasion where the WSE adapter was not able to create schemas for a web service and the inline pattern was used to get around this.




Like most design decisions there is no clear right or wrong answer to this decision and it will nearly always be a case of what best suits your individual requirements.  I hope the above information will help you to make the correct choice by helping you with suggestions on the things you should consider.  In addition to all of the above the last couple of things i would like to say are:


  • Deal with this design decision early in the project life cycle, making your decision early and proving or validating that decision will minimize the likelihood of having to change it later in the project which could be costly.


  • Do proof of concepts to ensure the choices you make will work.


If you feel i have missed something, or disagree with something in this post please feel free to add a comment below.




I have noticed a few sites that seem to copy the content of blog articles and display them in their own site.  It is a bit annoying that they do not clearly reference or acknowledge the author so I have decided to put this note on the bottom of all of my posts from now so it is clear who wrote it.

This article was written by: Michael Stephenson

The source of this article is:

Posted on Saturday, September 1, 2007 9:11 PM BizTalk | Back to top

Comments on this post: BizTalk System Connectivity Design Decisions - (To Buy or Build)

# re: BizTalk System Connectivity Design Decisions - (To Buy or Build)
Requesting Gravatar...
nice post admin thanks.
mobdro for Windows
xender download app
Left by mobdro tv app for pc on May 12, 2017 7:35 PM

Your comment:
 (will show your gravatar)

Copyright © Michael Stephenson | Powered by: