Dynamic physical architecture

Question

Hello All,
I wonder if it is possible to have a physical architecture be dynamic....
I have a comprehensive ODI framework, which calls upon certain flat files and (mostly) reads/writes from/to these using a variety of interfaces. The names (and location (directories)) of the flat files are stored as variables (extracted from a table.) The information about file locations is, therefore found in two locations: 1) in the variables and 2) in the physical architecture.
I would like to have the location information stored in the variables only and assigned dynamically to the physical architecture, so that I can have applications and users change the location.
Is this possible? In other words, can the physical architecture pointer for a flat file be represented as a variable (#<PROJNAME>.<Directory>)? If so, when is the pointer resolved and what, if any, are the constraints?
Alternatively, can the physical architecture pointers be left blank, and can the entire file resolution be done in a variable (in the interface)? In other words, can the issue of physical architecture be postponed to a point where it is resolved by the interface execution.
Here is an example....
I want to access a file, X.JNK, stored in the directory C:\MYDIR on the host A.
Today the physical architecture points to C:\MYDIR, and the interface code identifies X.JNK (as a variable <PROJNAME>.<FILENAME>, e.g. #MYPROJ.JUNKFILE = X.JNK).
The directory is also stored in a variable (as <PROJNAME><DIRECTORY>, e.g. #MYPROJ.JUNKDIRECTORY = C:\MYDIR), and so the fully qualified "address" for the file is:
#<PROJENAME><DIRECTORY>\#<PROJNAME><DIRECTORY> =
#MYPROJ.JUNKDIRECTORY\#MYPROJ.JUNKDIRECTORY =
C:\MYDIR\X.JNK
Given that setup, can the physical architecture be left blank (except for host information) and the interface be executed with #MYPROJ.JUNKDIRECTORY\#MYPROJ.JUNKDIRECTORY?
Best,
pajacobsen

Answer 1

Dev,
Yes, it works, although, for reasons unknown, I had to completely redo all interfaces that drew upon the affected models (I attempted a variety of other changes (modifying, for instance, the alias), but, ultimately, nothing worked until I rebuilt all the interfaces.
So, in sum, this issue is closed with the proviso that it is necessary to redo the interfaces.
Best,
pajacobsen
P.S. I often end up having to redo interfaces (rather than edit them) once I introduce changes to the models. Although the interfaces, on the surface, looks fine after the modification of the model, they don't work (I suspect a pointer problem.) I guess there are limits to ODI's flexible nature.
Edited by: user11102735 on Nov 23, 2010 1:59 PM