We have had a few moments of confusion in recent adapter development around the translation service and this post continues from Translation Service … how does it work? in an attempt to clear up some of the last dust storms.
The area I would like to focus on is highlighted within the red oval:
The following questions appeared on the horizon:
- Must the adapters implement a strict UNIX canonical path syntax?
- No, the canonical form is not a strict one, as discussed in the next question.
- If my filter string is as per the configuration extract below, what canonical form should the adapter create?
- Example configuration:
<FilterItem MigrationSourceUniqueId="00000000-0000-0000-4000-000000000001" FilterString="http://localhost:40414/Shared Documents/" />
<FilterItem MigrationSourceUniqueId="00000000-0000-0000-2000-000000000001" FilterString="$/POC" />
- The suggestion for the canonical translation is to create a canonical path that you can work back to your environment.
- http://localhost:40414/Shared Document/ could be converted to: /http://localhost:40414/Shared Document/ by just adding a / prefix from step 2 to 4 in the above illustration.
- Following this path, with a hypothetical file A.txt, we would see the following flow the the above illustration:
- http://localhost:40414/Shared Documents/A.txt is given to the left adapter translation service in step .
- /http://localhost:40414/Shared Documents/A.txt would be returned by the translation service and handed over to the platform .
- Platform strips the filter pair item related path from left, leaving it with A.txt, then replaces it with the filter pair item on the right, resulting in /POC/A.txt.
- /POC/A.txt is given to the right translation service and asked to convert to local adapter path.
- Translation service, which is VC specific in this case, knows to append a $ prefix to the path and returns $/POC/A.txt.
The key take-away is that the canonical path is TFS Integration Platform internal specific and does not need to adhere to any strict standard. The mapping between source and target filter pairs is the magic dust that the platform sprinkles on the processing flow and adapter specific path knowledge resides in the specific adapters. True abstraction :)