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

I was chatting the other day with someone about adapters for connecting to LOB applications and an interesting point came up which I thought id share my thoughts on.

The scenarios is that if you have a line of business application for arguments sake lets say its dynamics CRM which has a BizTalk adapter available but also has an existing web service API (or some other protocol based API). Which should you use for integration? In my opinion the answer to this is the usual "it depends" answer. I think what is particularly important are some of the considerations which you should make when deciding your approach.

I thought id put down a few thoughts from my past experience and see where we end up.

1. Testability

In order to deliver a high quality integration solution its important to be able to test your solution very effectively. With some line of business applications if there is a standards based interface and an open protocol then its usually fairly easy to stub out the dependent system making it easy to test your solution in isolation.

If you have an application adapter then this can often create a partial coupling to the line of business system for your testing. There are techniques that BizTalk people can use to handle this such as changing to a different adapter for some BizUnit tests in the development environment to allow you to do this testing.

With a little up front thinking you can usually plan how your development process will work in relation to this dependency but I have seen projects where they ended up with a problem because the integration team could not work because of the dependency on a line of business application which was also in development at the same time and the application developers had broken something which was a blocker for the integration team.

The key point here is that a protocol adapter probably makes it easier to stub out your dependencies.

2. Dependencies

Application adapters will often require some kind of client side components to be installed on the BizTalk server. Protocol adapters are usually unlikely to have many client side requirements.

You should be aware of these dependencies and ensure you can install and manage them and that there are no conflicts with other software you need.

I remember once there was a project where we were integrating into both Cognos and Teradata and the client side dependencies of the vendor components we were using to connect to these systems were incompatible meaning the two integration components could not co-exist on the same server.

3. Vendor support

If your using a protocol adapter then in most cases you are probably using the normal out of the box BizTalk ones which will be part of your existing BizTalk support agreement. You will also be likely to have an agreement with the vendor for your application about the API they expose. In this case unless you have a less common protocol then for most cases your normal support agreements will cover things.

In the case of an application adapter then you need to consider who is the vendor for the adapter. If it's a Microsoft adapter then your probably in the same situation as with your normal BizTalk support agreement. If the vendor is a third party or the same as the vendor for the application then you would be likely to need additional support costs and considerations. In the case when the adapter vendor is a 3rd party you often will have a partner who is an expert in this kind of integration but also you could find it difficult to workout if a problem is BizTalk itself, the adaptor or the application.

The support position should be an important consideration.

4. Vendor Technology Road maps

Its important to be aware of the technology road maps for the application, BizTalk and any adapter vendor.

In the case of a normal protocol adapter there is probably only two parties involved and the communication would usually be standards based so it should be easy to workout any compatibility issues. You then just have the challenge of a contract-based interface to manage and any information about breaking behavior of contract changes.

The application adapter could be a much more complicated scenario. You need to think about the following:

  • If I upgrade the LOB application will it work with my existing adapter
  • If I upgrade my LOB application and need to update the adapter will this work with my version of BizTalk
  • If I upgrade BizTalk will the adapter continue to work with the new version of BizTalk

 

I think in the application adapter scenario you need to have a much closer a alignment between the road maps in your organization for compatibility of BizTalk, the adapter and the LOB application.

5. Current Organisation Approaches

You should think about if your organization already integrates with the application in a certain way from outside of BizTalk. If it does and there are similarities then you can have a certain degree of confidence in what to expect. You will also have in place some processes to manage this.

If you find your organization has an existing way of doing this that works well and fits with the strategy then definitely follow it. If the existing way doesn't work then definitely look to change it.

6. Cost

Adapters which aren't free from Microsoft or included with BizTalk are likely to cost something.

This is an obvious factor to consider. But also consider the costs of not buying an adapter. It's much harder to quantify something you build but the long term cost of ownership may be much higher than the original vendor purchase.

7. Assumptions

When you connect to an application you are making assumptions about the contract based on something like wsdl if it's a web service interface. You are also making assumptions about the behavior of the API usually based on the documentation which comes from the application vendor.

Typically when we integrate with an application using a protocol adapter I would normally look to develop some tests, which will flex the API without any of the stuff I will build on top of it. These tests will really prove my assumptions about how the application will work and potentially give me an indication of performance. When I am using a protocol adapter this kind of test is usually relatively easy to write in .net code even if the protocol adapter ends up being something from a 3rd party.

When I use a BizTalk application adapter it is likely to be a little bit harder to validate these assumptions. I can still do it but I will have to build a fairly simple BizTalk application which will allow me to push some messages through the adapter and prove how the interface will work. Its usually just more time consuming to develop tests in this way.

One point to note is that if the adapter is a WCF LOB adapter then it is often possible to use this adapter outside of BizTalk so you can potentially write the same .net tests mentioned above but use a WCF LOB adapter directly from .net code.

The key thing with this section is that it's a good idea to prove how the interface will work before you start using it so you can reduce the integration issues and mitigate the risk that you could have problems with the assumptions you make about the vendor API.

 

8. Feature set

With a BizTalk application adapter there is usually a reason why they have been built. It is important to be clear on the feature set offered by the adapter and what it offers above just using a protocol adapter.

In some circumstances you will have the situation where a BizTalk adapter was built and then a new version of the LOB application comes out and part of this new version includes an improved API which is more standards based and other good things. The adapter may still be compatible.

In other situations there will be clear features offered by the application adapter which you would either have to develop yourself or things which just improve the integration experience.

Carefully evaluate the features offered by each adapter to workout what you get extra and how valuable it is.

9. Buy Versus Build

Some organisations have a clear buy versus build strategy. Without going into too much detail this could significantly influence your decision.

10. Be Open Minded

One of the things that can be quite frustrating is when a design decision is made simply because that's the way its always been done and there is fear of change or something that the team do not understand. Just because you always use a certain way to connect to a given application doesn't mean a different way does not have its own merits and might not be better. Particularly if a new version of an adapter comes out.

On this point I would say don't always jump to your default choice. At the very least try out the other options.

Summary

As I said at the start of this article there is no one answer for every situation, but in practice I often find that the application adapter could be more work or cost to your solution. In this case I usually want to have clear justification for why we are using the application adapter over the protocol adapter so that we have a well defined design decision for our project which is also inline with our integration strategy.

This was a bit of a brain dump from my experience and it would be interesting to see if others agree or disagree with my thoughts.

Posted on Friday, June 3, 2011 4:25 PM BizTalk | Back to top


Comments on this post: Should I use a Protocol adapter or an application adapter

# re: Should I use a Protocol adapter or an application adapter
Requesting Gravatar...
Interesting post with some very good points to remember.
Left by Steve Culshaw on Jun 12, 2011 6:51 PM

Your comment:
 (will show your gravatar)


Copyright © Michael Stephenson | Powered by: GeeksWithBlogs.net