When mappings fail migration
Some less common issues that may prevent FDMEE mappings from migrating between environments.
I originally started blogging as a way to write notes to my future self so that I would be able to come back later an refresh my memory and this post is for exactly that purpose. Oracle FDMEE which replaced FDM several years ago has become a much better tool than its predecessor over the years with one glaring exception. Its still not able to migrate/upgrade easily.
Without fail FDMEE consistently makes things difficult that should be fairly easy. The latest such occurrence for me is one that I have seen before but forgot to write down. I am in the process of migrating mappings from a 11.1.2.3 instance to a 11.1.2.4 and so far its going fairly well. FDMEE migrations have come a long way but some issues are still head scratchers.
This particular implementation pulls data from a external system that produces some values FDMEE doesn't seem to like to map. The first is that some of the fields in a particular column contain asterisks (*), like "*** Special Account Name". Naturally the client has created an explicit mapping to ensure values corresponding to this field get to the right place. Unfortunately FDMEE's import tool treats asterisks as wildcards (except in mutlidim maps) and does not appear to offer a way to escape that character and since explicit maps don't have "Rule Names" the tool seems to think the mapping is an invalid Like map so the entire export fails. A second issue is that the import tool seems to think only rows containing asterisks in the source column are Like mappings which means Like mappings with no asterisk but a question mark or underscore get loaded in as In mappings. Interestingly 11.1.2.4 FDMEE has added the ability to specify the delimiter in the target application settings, unfortunately comma's still seem to hold a special place in the heart of FDMEE so any source value with commas (Some account (102, 103, 105)) will load as an In mapping even if it exported as an explicit.
If anyone at Oracle is reading this, I would greatly appreciate having some way to escape these characters in the future (11.2 please.)