What exactly are BizTalk’s adapters, and what do they do? For developers, I don’t think much time is spent thinking about these questions. The problem though is that other people hear that BizTalk has an adapter for something, for some odd reason they think they just have to install the adapter do a little configuration and everything just “works”.
In some cases this might be possible. However, I suspect that only occurs in really rare boring cases that I won’t ever see. A case where the two systems being integrated have been integrated so many times that everything has already been prepared ahead of time. All that is left is installation and a little bit of configuration.
For the rest, what is a BizTalk adapter and what does it do?
BizTalk adapters can be divided in to two groups – technology adapters and application adapters. In the case of technology adapters the adapter handles moving messages through the particular technology. For example – the BizTalk file adapter knows how to take a message out of the BizTalk message box and write as a file in a file system. The system administrator configures the adapter by specifying a path, filename and whether the adapter should create a new file each time or append to an existing file. Other adapters do similar things: the WCF adapter will take a message and send it to a WCF end point.
Application adapters are not much different from the technology adapters. They take messages and send them to applications. Applications can be trickier to communicate with though. In the case of CRM you have to talk to it’s web-services and it might require several round trips to finish processing the message. The SAP and Dynamics GP adapters are the same; they have well defined integration points that you must use in order to make your solution work. Applications typically have well defined integration points (web-services, APIs, integration files, etc) that you must conform to. The adapter hides those details so you can focus on other things.
In some cases even if the adapter is present the particular solution being built might be better off not using the adapter. Even in the case where the adapter is used it won’t turn the task in to a NOP (assembly language for NO OPERATION – 0 time to complete – go have a cup of tea). Custom solutions always require work. Adapters make that work possible, and the really good ones make the work a bit easier. But they do not do the work for you.
Where this becomes important is when you have to applications that are being integrated that were never meant to talk to each other. A customer might get the notion like “Look application XYZ has a BizTalk adapter! Cool! ALL WE HAVE TO DO IS PLUG IT IN RIGHT?”. Now prepare yourself for an hour or so of explanation about how it doesn’t work that way.
So as an integration architect working with business people who don’t have the time to know everything you do – be prepared to provide a clear and succinct explanation about this little detail.