Taking Backups in PowerCenter. How to do that! – Part 2

A “real” backup of a PowerCenter repository usually is an administrative task and hence implemented and executed by your administrator team. For a “normal” developer a backup file is not really helpful because:

• You need an empty database (or DB schema) to restore that backup file,
• You need the right domain privileges to perform such an action,
• You usually only need a very small part of the backup.

A XML export may contain almost all sorts of objects in a PowerCenter repository: source definitions, mappings, worklets, workflows, etc. Only the following objects cannot be exported to a XML file:

• Connections of all kinds,
• Labels,
• Deployment groups.

These XML files may contain one or more objects from one or more folders. You may export whatever objects you want, there is (in theory) no maximum number of objects in one single XML file.

A quite common method to deploy developments from e.g. DEV to TEST environment uses one special feature of pmrep: you can use pmrep to export a complete folder (plus all objects in shared folders used in this folder) to one single large XML file. Then this XML file is transported to DEV environment, the original folder is renamed (to keep a “safety” copy in case the import fails), the contents of the XML file are then imported into the newly created folder in one step, and in the end (when the import has succeeded without warnings) the original folder is removed.

Once such a XML file has been created, its contents may be imported into some repository. One may import one single object or many objects into a repository, depending on your needs. Such an import can be performed using the following methods:

• The command-line tool pmrep can import everything. However, you need to open a CMD window on a Windows machine (be it a PowerCenter server or a PC with the client tools installed) or some shell window on a Unix/Linux machine to get access to pmrep. For pmrep to import objects from a XML file, one needs to provide a so-called “import control file”; details can be found in the Command Reference guide, part of the documentation set for PowerCenter and for the Informatica Platform. This is the standard method for automatic deployment processes.
• The Repository Manager (assuming you are allowed to use it) can be used to import anything from a XML export file; details can be found in the Repository Guide for PowerCenter. This used to be one standard method by repository administrators, but during the past years this method has been replaced more and more by an automatic import via pmrep.
• The Designer tool can be used to import source definitions, target definitions, reusable transformations, mapplets, mappings, and/or user-defined functions.
• The Workflow Manager can be used to import reusable tasks, reusable sessions, worklets, and workflows.

There are some practical considerations to take into account. XML files should not be too large. The usual limitations built into PowerCenter for XML source or target files apply to XML exports as well. From my own experience it is not advisable to import files of more than app. 100 MB in size. The GUI tools are 32-bit applications, and their ability to handle XML files is limited by the 32-bit libraries used by these applications. Memory management is always an issue when importing objects from a XML file. This even applies to pmrep, be it on a Windows client machine or on a server machine.

In addition it is worth noting that an import from some XML file is always executed in one single transaction on the database server holding the PowerCenter repository. Very often it happens that a folder export of e.g. 120 MB cannot be imported into the repository because the rollback segments of the repository database are not configured large enough to hold the complete transaction (because the import process not only consists of the newly imported objects but also of those objects which are deleted / changed during that process). Which means that a folder export cannot always be imported in one single step. There is a strategy how this can be remedied, but this is nothing for novices, you should have some experience with administrative tasks before following this route:

1. Rename the original folder (e.g. EDW_PREPARE) to e.g. EDW_PREPARE_bkp_20210624 (current date appended in short ISO format).
2. Re-create the folder with the correct name.
3. Make sure you “copy” all access permissions from the renamed original folder.
4. Import source definitions first.
5. Import target definitions next.
6. Import reusable transformations.
7. Import mapplets.
8. Import mappings.
9. Import reusable tasks.
10. Import reusable sessions.
11. Import reusable worklets.
12. Import workflows.
13. If all went well, check in all imported objects (in case of a repository with version control enabled).
14. After reconciliation runs have been executed successfully, you may want to remove the original folder.

Keep in mind that even this strategy may still fail due to the rollback / undo segments not being large enough. In this case you will have to import not only as indicated in this list, you may even have to import all objects per “group” (e.g. all workflows) in several steps of e.g. 50 workflows per run.

Now on to a folder export. Using pmrep you can create a XML export file for one complete folder (including all shared folders to which there are shortcuts in the folder to be exported).

Each PowerCenter client installation does contain a pmrep.exe executable which you can use. As long as you are allowed to open a CMD window on your client PC, you can use this feature, namely like this:

1. Find out where the PowerCenter clients are located on your Windows PC. Under Windows 10, for example, you can right-click the menu item for the Designer and – from the context menu – choose to open the folder where the Designer is stored. Now perform a right click on the Designer icon and choose Properties; there you will find the directory where the Windows clients are installed.
   For this example, let’s assume the PowerCenter clients are installed in C:\Informatica\10.4.1\Clients .
2. Open a CMD window.
3. Enter the following command in the CMD window:
   path C:\Informatica\10.4.1\Clients\clients\PowerCenterClient\client\bin;%PATH%
4. Enter the following command to check whether the domains.infa file (the file which tells the PowerCenter clients where the PowerCenter servers are located and via which IP port they can be reached) is stored in some special location:
   echo %INFA_DOMAINS_FILE%
5. If the output of the previous command is %INFA_DOMAINS_FILE% , then most likely the domains.infa file is located in (assuming the example installation directory above) C:\Informatica\10.4.1\Clients\clients\PowerCenterClient. To verify this assumption, enter the following command:
   dir c:\Informatica\10.4.1\Clients\clients\PowerCenterClient\domains.infa
   If the file size and date/time of its creation are displayed, fine, we can use it; if an error message is displayed (like “File not found”), then please ask your system administrator where this file is stored and write down that file path, you will need it in step 7 below.
6. If the output of the “echo” command is some file path and name, you can skip the next step.
7. In order for pmrep to work correctly, it is recommended to make sure it connects to the correct server(s). To achieve this, we can set the environment variable INFA_DOMAINS_FILE to the path and name of the domains.infa file as identified earlier. This can be done (assuming a standard installation in the sample directory path given above) by executing the following command:
   set INFA_DOMAINS_FILE=C:\Informatica\10.4.1\Clients\clients\PowerCenterClient\domains.infa
8. Now we can connect to the repository using the following command (assuming the Informatica domain is named MyDomain and the PowerCenter repository is named MyRepository and you are using the native user ID RepoAdmin):
   pmrep connect -d MyDomain -r MyRepository -u RepoAdmin
   You should be asked for the password, otherwise please ask your system administrator for help.
9. After having connected to the repository, you can create the XML export of any folder (in this example the folder is named DWH_PROJ_1):
   pmrep objectexport -f DWH_PROJ_1 –u DWH_PROJ_1.xml
   Depending on the size of the folder it may take several minutes until all the objects have been exported to the XML file. At the end you should see a message like this:
   objectexport completed successfully.
10. Don’t forget to close the pmrep session:
    pmrep cleanup

This way you will finally have a XML file named DWH_PROJ_1.xml in the current directory. This contains all objects in this folder plus all objects from any shared folder(s) which are used as shortcuts in this project folder.

As indicated earlier, there are four methods to create some backup file(s).

1. Full repository backup.
2. XML export of a complete folder.
3. XML export of one or more objects of the same kind (e.g. three mappings).
4. XML export of one or more arbitrary objects from one or more folder(s) in one single XML file.

Let us continue with exporting one or more object(s) of the same kind (e.g. a mapping) to a XML file. For this task you can use either pmrep or the Repository Manager or the Designer resp. the Workflow Manager, depending on the kind of object you want to export:

• pmrep and Repository Manager work always.
• Designer can be used to export and import all objects which are handled within it: source definitions, target definitions, reusable transformations, mapplets, mappings, user-defined functions.
• Workflow Manager can be used to export and import all objects which are handled within it: reusable tasks, sessions, worklets, and workflows.

Creating a XML export of a single object (or several objects of the same type) is easy: start the Repository Manager; open the respective folder (double-click the folder name); in the Navigator tree below the folder name, open the respective object type in the tree (e.g. the Mappings sub-tree); again in the left tree, mark all objects which you want to export; right-click on one of them and choose Export… from the context menu; choose the correct directory where you want to store the XML file; and finally click OK.

If you export e.g. one or more mappings this way, then all objects used within these mappings (source definitions, target definitions, reusable transformations, mapplets) will or will not be included in the XML export depending on the choices you make under the link Advanced Options. With the standard settings all four check boxes in the Advanced Options are set, and that means all “lower-level” objects will be included. That means the XML export will not only contain those mappings but also all source definitions, target definitions, reusable transformations, mapplets, and user-defined functions used within these mapping.

If you turn off those options, only the objects you choose will be saved in the XML files, but no “lower-level” objects. There might be a situation where you want to re-create only this special mapping or that particular workflow but nothing else. XML files become notably smaller this way, so – depending on how the deployment schemes are set up in your organisation – an automatic deployment may depend on the XML exports containing only those objects which really have changed since the last deployment. In this particular case it may be useful to export only the mappings and nothing else. If in doubt, ask your system administrators, they should be able to help you clarifying any issues here.

Usually you should leave all four check boxes checked (as they are by default). Disk space is not much of an issue nowadays, and it is safer to have all “dependent objects” within the XML exports.

Creating one XML export of objects of distinct types is a little more complex; please refer to the chapter “Working with pmrep Files” in the Command Reference guide (a PDF file) to be downloaded from the Informatica Network (https//network.informatica.com).