How to create an adapter for the TFS Integration Platform - Part III: Overview of adapters
Note: This post is part of a series and you can find the rest of the parts in the series index.
The TFS Integration Platform has two types of adapters—a WI (for work items, tasks, bugs, etc.) and a VC (version control) adapter—and they are nothing more than .NET assemblies made up of a number of classes, which you will mostly inherit from interfaces in the Toolkit project. For both adapters, the key interfaces you need to implement are:
- IProvider: Gives the platform a way to invoke your adapter.
- IMigrationProvider: Used for writing to the adapter’s source system (e.g., SharePoint for me).
- IMigrationItemSerializer: Provides support for converting items to XML.
- IAnalysisProvider: Used for reading from the adapter’s source system.
As well, both require implementing the ChangeActionHandlers abstract class.
The VC adapter also requires:
- IServerPathTranslationService: Used to translate paths (i.e., directories and such) between adapters.
While the WIT adapter requires:
- IConflictHandler: Provides support for handling conflicts during migration.
Thus, in both adapters, you’ll need to implement at least six classes (excluding any extras required by your specific needs). The core concepts of the adapters are all explained in their respective interfaces, making them appear simple to implement—and, indeed, they are. However, there are some quirks that might catch you off guard, which we’ll cover in detail in future posts.
TraceManager
Something very nice about the platform is the TraceManager class—a wrapper around System.Diagnostics.Trace—that adds extras like logging to console windows and log files. You’ll see it sprinkled throughout my code because it’s invaluable for debugging later on.
Power Tip: The TraceManager logs all written information to log files, so never include sensitive data there.