Originally posted by: SystemAdmin

The integration flow designer does not appear to support relative directory references, (e.g. .\ and ..\ ) for the Map Source File specification in the Map Component settings, requiring you to specify a fully qualified path name to the map source file, instead of being able to specify that the source is in a folder with a location relative to the current .msd file being edited, as you can, for example, with the .mtt type tree files in the card settings within the map designer.

Therefore, when you copy and paste a map component, for example, from your development .msd file into your test or qa .msd file, the component still references your development .mms source and you must manually edit the component to point to the correct source in the target environment.

Does anyone have a solution that would allow us to eliminate this design time hard coding and enable us to migrate map components from an .msd file in a one environment into another without having to rely on manually editing the map component settings to ensure that the correct source is being compiled and deployed ?
#DataExchange
#IBM-Websphere-Transformation-Extender
#IBMSterlingTransformationExtender

Originally posted by: SystemAdmin

One way would be to maintain the directory structure in each environment.
Relative pathing can cause accidental problems, especially when you move to a different environment, there is a map or tree etc. with the same name, but different content.

If I had a dime for every after hours production call caused by human error like this, well, I wouldn't be eating at a burger joint today :-)

Worst incident was when a new RUN map was deployed and it had the same name as a previous map, but there was nothing in common about the maps. Deployed on Wed. for a different msl. Original RUN map was called Sunday at 3AM by a time triggered map. I was called at 3:15 AM. :-(
#IBM-Websphere-Transformation-Extender
#DataExchange
#IBMSterlingTransformationExtender

Originally posted by: SystemAdmin

Aren't you in dangerous teritory using different sources for different test environments?
Surely you should use the same source and just move compiled maps to the various environments.
Unless you are doing parallel development where you need different sources for different environments which leads to all sorts of problems.
#IBM-Websphere-Transformation-Extender
#IBMSterlingTransformationExtender
#DataExchange

Originally posted by: SystemAdmin

I have used global search and replaces after a copy and paste to an MSD for another environment. Have used the same techinique when moving from Windows to UNIX. Hopefully directory structures and naming conventions have been designed to be parallel enough to support such a technique.
#DataExchange
#IBMSterlingTransformationExtender
#IBM-Websphere-Transformation-Extender

Originally posted by: SystemAdmin

You would not believe the directory structures I have seen. :-) Why do you think we had to expand the length of command lines?
#IBM-Websphere-Transformation-Extender
#DataExchange
#IBMSterlingTransformationExtender

Originally posted by: SystemAdmin

In our environments, we completely rely on and enforce the directory structures and map names being the same in all of our environments, and have never had an issue with relative directory references.

Having hard coded references to environmental specific resources within our source has given us the headaches. When developers miss scanning and replacing path references, test code winds up getting deployed into production, etc.
#IBMSterlingTransformationExtender
#DataExchange
#IBM-Websphere-Transformation-Extender