Transaction FILE : Configuration/Usage Best Practice

[Bryan_Pierce1]

Looking for information regarding the best practice configuration for the transaction FILE. In particular, the activity is currently configured as a transportable object to where we have to define values in our DEV system and then promote through to PRD. This seems a bit off. I've looked all over to try and determine if this is a default setting and to see if other folks have turned this off as a best practice but I've yet to find any relevant info. Everywhere I read about using the functionality no one ever complains about the transport process... so this leads me to beleive that it really should not be setup that way.

So, can anyone point me to a SAP Note, or White Paper, or anything, with an official recommendation on how to configure as transportable or not.

I'm not necessarily looking for opinions... I'm really looking for some hardcopy recommendations.

Thanks in advance.

Bryan

[Bryan_Pierce1]

Looking for information regarding the best practice configuration for the transaction FILE. In particular, the activity is currently configured as a transportable object to where we have to define values in our DEV system and then promote through to PRD. This seems a bit off. I've looked all over to try and determine if this is a default setting and to see if other folks have turned this off as a best practice but I've yet to find any relevant info. Everywhere I read about using the functionality no one ever complains about the transport process... so this leads me to beleive that it really should not be setup that way.

So, can anyone point me to a SAP Note, or White Paper, or anything, with an official recommendation on how to configure as transportable or not.

I'm not necessarily looking for opinions... I'm really looking for some hardcopy recommendations.

Thanks in advance.

Bryan

[Former Member]

FILE is basically useful for the Logical and Physical File mapping.

The end user is not aware of any physical path.

Its difficult to remember the physical path.

Eg:
BWSWEB\Interfaces\Out\File\Bank\RBS\ is mapped to simple and easy to remember logical path like Z_Bank_RBS

The configuration is very easy and transportable.

Developer can do it if have the authorization else BASIS will do it.

YOu need to enter the logical path, physical path and the file system to configure it.

YOu can also pass the run time parameters like System ID and Client.

Eg:
BWSWEB\DE1\300 will be development and the same will be dynamically changed to
BWSWEB\QE1\300 for Quality.

Hope this helps.

[Bryan_Pierce1]

Thanks for the response. I'm pretty well versed on the transaction useage. However, the whole transport concept for making the physical location changes is a bit burdensome in many cases where we need to coordination system moves. I'm hoping to find that there's a recommendation that this set of functions doens't have to be transportable at all. It really causes issues with a tiered landscape to try and build logic so that each environment behaves differently for file access.

Does anyone use this transaction directly in a production system for file path maintenance?

Thanks,

[matt]

In all the clients I've worked in the past 15 years, none have maintained FILE in production. Always by transport from development. There are components for system id and client, so, as long as you have the same directory structures for each system and client, there's no problem.

E.g. /usr/D01/011/inputdata - for development box D01, client 11,

/usr/D01/100/inputdata - for development box D01, client 100,

/usr/P01/011/inputdata - for production box P01, client 11.

[Bryan_Pierce1]

Ok, thanks. This is probably our best option at this point... we've done some of this but haven't standardized on it yet.