Just wanted to share a quick “lessons learned” for a metadata integration project that I have recently run into.
In a current project, the metadata members all include a dash “-” and then the member name, which is good practice for metadata design to keep all members and aliases unique in Planning. Unfortunately, sometimes when new metadata members are copied from emails or documents from Microsoft products (Outlook, Word, etc.) sometimes the short-dash “-” gets converted to a long-dash “—”, and as we are all human, sometimes this doesn’t get caught when getting input into DRM.
When loading metadata files manually through Workspace’s Outline Load Utility, the metadata files all load correctly. No issues with comma delimited .txt files.
However, when loading DRM export files to Planning using ODI, you can run into some issues with the long-dash. For some reason – ODI will convert the “—” to “â??” (I think it has to do with the type of encoding used in ODI, ascii vs. utf-8). This conversion causes Planning to throw an error when loading the file:
Alias using Long-Dash: Sample Alias for Testing Purposes — T1000183
Error: Line 1677: ODI-40466: String is too long: Sample Alias for Testing Purposes â?? T1000183
Even though the string is not 80 Characters (the alias length limit for Planning), it will throw and error that the string is too long. However, just changing the long-dash to a short-dash fixes the issue and it loads successfully.