DEF File Management Naming Convention DEF files should follow a standard naming convention: <Driver Version> <Accounts>
<Location> <F1100 OR F1100 & F990>.DEF Examples: 7.5 All Accts AP F1100 AND F990 7.5 All Accts CR F1100 Version Control When any changes are going to be made to a DEF file, the current DEF file should be exported and saved with the current name and the date appended to the end. Example: 7.5 All Accts AP F1100 AND F990 5_27_09.DEF This should be done prior to importing a new DEF. Old DEF files with dates appended to the file name should not be deleted. A copy of the new DEF that is being imported should also be saved with no date at the end. This will indicate which DEF is currently active. Backup Location A folder called DEF Files will be created in each environment in the same root that the Siebel app servers are installed on. The directories are stored in the following locations for each environment: Name Test Staging Pre-Prod Production IP [Link] [Link] [Link] [Link] Location E:\DEF Files E:\DEF Files E:\DEF Files E:\DEF Files
Commenting DEF Files When a new DEF file is created, comments should be added to the top of the DEF file explaining the purpose of the new DEF, the changes to the DEF and the date the DEF was imported. Note that when a DEF file is exported and saved, the comments are not in the new exported DEF file. So when exporting the active DEF, copy the comments from the DEF file that has no date (since it should be the DEF file that is currently active) and paste the comments in the exported DEF file that will have a date appended to it.
Comments should be added to top of the DEF file with the following format: ;//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// ;Date - <Date here> ;Author - <Name here> ;Comments - <What is being changed and why> ;////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Importing DEF Files Profiles Profiles are overwritten with profiles in the DEF being imported Example: Existing DEF contains profiles A and B Profile being imported has profiles C and D After the import, DEF will only have profiles C and D (ie, A and B are deleted) Profile Parameters Parameters are merged If a parameter exists in existing DEF and DEF being imported, the parameter takes the value from the DEF being imported If a parameter exists in existing DEF and NOT in the DEF being imported, the existing parameter remains after the import If you want to completely replace profile parameters with what is being imported, the profile must be deleted from the current DEF and imported. Commands Command are overwritten with the commands from the DEF file being imported Example: Current DEF file contains commands 1-70 DEF being imported contains commands A-Z After the import, the only commands will be A-Z Command parameters are overwritten with what is in the DEF being imported if the command exists in the old and new DEF file. Event Handlers Event Handlers are overwritten with the event handlers from the DEF file being imported Example: Current DEF file contains event handlers 1-70 DEF being imported contains event handlers A-Z After the import, the only event handlers will be A-Z Event handler parameters are overwritten with what is in the DEF being imported if the event handler exists in the old and new DEF file.