TFS Integration Platform – Translation Service … how does it work?

  • Article

Ever had the feeling that you think you understand something, but have this eerie feeling that perhaps you have missed the boat? Well, it dawned on me recently that my brain started clogging up when trying to understand how  translation service in the TFS Integration Platform actually works. Once again I had an interesting discussion with Terry and have made the following notes, which will hopefully clarify the service to you, simplifying configuration debugging excursions or more importantly custom adapter development.Clipart Illustration of a White Character Lying On His Belly And Using A Laptop

Special thanks to Terry, Huyng and Andrew from the TFS Integration Platform team for input and reviewing of this post and the patience in terms of explaining it over and over again until the Penny finally dropped and for spotting the off gremlins that sneaked in during the early hours of the morning.

Context

In the TFS Integration Platform we have two levels of abstraction in term of paths. Communication between the adapter and the platform is based on adapter-specific server paths, for example Unix, Windows and SharePoint, whereas paths are formatted and processed in canonical format within the platform. The core of platform calls the adapter server path translation services to transform the path syntax from source to canonical and canonical to target, allowing the adapter to deal with any adapter specific settings and not relying on the platform translation service.

Let us assume the following scenario as shown: 
image

  1. On the left we have a directory c:\pocdrop containing one directory demo with one file A.txt.
  2. On the right we have a Team Foundation Server with a directory $/poc in source control, containing a folder demo with one file B.txt

Moving changes from left to right

image

During the migration session, the following translation focused events  occur:

  1. The platform determines that c:\PocDrop\Demo\A.txt needs to move across the pipeline
  2. The platform translates the c:\PocDrop filter string to /C/PocDrop using the left adapter translation service
  3. The platform translates the $:/Poc path to /Poc  using the right adapter translation service.
  4. File c:\PocDrop\Demo\A.txt is now being processed, which initiates the following events:
    1. Platform asks the source adapter to create a canonical name, which is returned as /C/PocDrop/Demo/A.txt
    2. Platform does a string find of the source filter pair path converted in step 2, and performs a string replacement with the target filter pair path converted in step 3, which results in /Poc/Demo/A.txt
    3. Platform asks the target adapter to convert the canonical name, to its adapter specific format, giving us $/PoC/Demo/A.txt
  5. The file is added to the TFS repository.

Moving changes from right to left

Moving from right to left is the same process as above. Turn around the above diagram in your mind, placing the right as the source on the left and the left as the target on the right and you have the correct process picture.

image … or just reverse the flow from right top left as shown :)

Hope this clarified a few things. See you next time.

2010-03-14 ... see continuation (part 2) at https://blogs.msdn.com/willy-peter_schaub/archive/2010/03/14/tfs-integration-platform-translation-service-how-does-it-work-part-2.aspx.