What do you do to backup FDM? Your FDM database is probably backed up regularly by IT so the complete FDM application can be restored. Is this enough? Of course it’s enough because it’s the whole database. Is it what you want though? A database restore can take time and restores everything and will of course delete all the changes made since the backup. What if you want to restore just parts of the application?
I am often asked what monthly backups and procedures do I suggest for FDM. I recommend taking extracts of the Maps and Application so that individual elements of the application can be restored. Increasingly I have come across clients where their FDM application is being audited so they need to keep track of any changes to the application (particularly the maps). This is not easily done with just a database backup.
You might also consider a clean-up routine for the data files that FDM creates and uses. I have seen applications where there are tens if not hundreds of thousands of these files and they do affect performance. I usually suggest a cut-off of 90 days – if the file is more than 90 days old, then delete it. The data is already in the target and you can drill-back to FDM so I don’t see why these files need to be kept.
Maps
In some applications the maps are more or less static while in others they can change each month. It is a good idea to have an external backup of the maps for each location. It’s not essential because FDM does store the maps that were used for each data load; these are called the Historic maps. You can view them by running the Dimension Map for POV report in the Location Analysis Reports folder. You can use them by selecting Restore in Maps followed by the appropriate Category and Period.
If they are already in the application why do you need to take a separate backup? The Historic maps are driven by a data import. When you import data, a copy of the maps is taken. If someone is working on their maps without importing data, there is no backup. In an application where the changes to the maps are audited, the users must make the changes to individual maps in FDM so no file imports, no Delete All, no Restore Maps, no Copy Maps. Auditors sometimes ask for the maps and the changes that have been made. While the Map Monitor reports in the Audit Reports folder do give some information on the changes to the maps, not all changes are tracked. If your application allows the maps to be loaded from files, there are gaps in the Monitor reports and the only way you can get the maps for previous periods is to restore them.
So it’s a good idea to have the maps backed up externally and if it can be automated and doesn’t take up much space, you have nothing to lose. You are covered if anyone wants to restore or review the maps. The easiest way of exporting the maps is to use a script which reads through all the data import locations and exports the maps for all dimensions to files. This script can then be automated.
Here is an example script that will create a file for each location that contains all the maps for that location. The output is to a text file because it’s easier and you don’t need Excel installed on the server. It is in a format that can be imported into Excel and then with the addition of name ranges can be used to update the location maps. You will need to rename it from .key to .uss.
Application
At first glance, the backup of the application is not as simple because it involves exporting the locations, import formats, logic groups, reports and so on. However, the FDM API contains the METAEXPORT object which automates the File | Export function in Workbench Client. This object is not documented anywhere but with a little tinkering I managed to get it to work.
Here is an example script that will create an XML file containing all the FDM application elements. You can set the script to include the location maps as well. I prefer not to do that because I have previously had problems trying to restore maps from an XML export and you have to restore the maps for all locations. This XML file can then be used to update the application through the Workbench File | Import menu. You will ned to rename it from .key to .uss.
With these two scripts, you can use the FDM Task Manager to take a backup of your FDM application and maps at regular intervals.
FDMEE
FDMEE has current and historic maps but the tables are not split by a segment number: it is simply one table (TDATAMAPSEG). The segment split is a legacy from the original FDM product when the data was held in Access databases rather than SQL Server or Oracle. A copy of the maps is taken whenever data is imported and these can be retrieved using the Restore Mappings function in Data Load Mapping. For FDMEE, you have to be in a POV that has historic maps and these will be restored to the same point of view. This means that you can’t go back to a particular period and use those as the current maps.
FDMEE has two separate reports similar to FDM: the Dimension Map for POV report runs against the historic maps and the Dimension Map (Dimension) report is for the current maps.
FDMEE doesn’t have any of the export API calls that FDM has. You could duplicate the map export script using either VBScript or Jython but the METAEXPORT object just doesn’t exist. For FDMEE, the easiest way of taking a backup is to use LCM. From 11.1.2.3, FDMEE is fully integrated into LCM so it is relatively straightforward to automate the export of the application and the maps. You can do this by using the Utility and ACR scripts (.bat for Windows and .sh for Unix) with a migration definition xml file. The LCM manual has instructions on how to do this.
There are a couple of downsides to LCM though. Firstly, you have to restore the maps for all locations and secondly, it’s in XML format which is not as easy to read as an Excel spreadsheet. So, you use LCM for backing up the application but you use a script to backup your maps.