Overview
The catalog utility enables administrators and report developers to export the reporting object-related files from the catalog where all the pixel-perfect reports are stored, and to import them to a different catalog.
Use this tool to manage pixel-perfect reports using a third party tool as a source control or to move a specific set of reports from a development environment to a quality assurance or production environment. The catalog utility can also be used to help manage translations of reporting objects. You must first run the GenerateBIPUtility script to generate the BIPCatalogUtil utility. See Generate the Utilities.
Use the catalog utility to perform the following tasks:
-
Export pixel–perfect reports from the catalog
-
Import pixel–perfect reports into the catalog
-
Extract translatable strings and generate a translation file (XLIFF)
-
Generate a security.xml file that contains the reporting object-level permission settings
When to Use the Catalog Utility
Use the catalog utility to move Publisher report artifacts from one environment to another.
For example, use the catalog utility to move reports from a development environment to a quality assurance environment. This process is illustrated in the figure below.
Other Options for Moving Catalog Objects
You can download and upload catalog objects to transfer objects across environments.
To download or upload a small number of objects, the download feature of the catalog enables you to bundle and download multicomponent objects (such as reports) in an archive file. You can then use the upload feature to unarchive the data to another location in the catalog.
Note:
Do not manually edit the Publisher files in the file system. Publisher uses metadata files to maintain information about catalog objects. Manually editing objects in the file system can result in the corruption of the metadata files. If the metadata file corrupts, then you can restore it by deleting the corrupt file and restarting Publisher.
What Files Are Moved
Styles and skins are organized into folders that contain Cascading Style Sheets (CSS) and images.
Object | Files |
---|---|
Report Example: Balance+Letter.xdo |
|
Data Model Example: myDataModel.xdm |
|
Subtemplate Example: mysubtempate.xsb |
|
Style Template Example: myStyleTemplate.xss |
|
Maintaining Identical Folder Names and Structure Across Environments
A pixel-perfect report references the following components using the physical path to the component in the catalog: data models, subtemplates, and style templates.
When you move a report between environments the report maintains the physical mappings to the referenced components. Therefore if you move a data model into a different folder location under Shared Folders in the new environment, the report cannot find the data model and the report doesn't run. In the case of style templates or subtemplates, the report may run, but the referenced component is not applied.
For example, assume in your test environment Report A references Data Model B located in Shared Folders/Test/Data Models. When you move this report and its data model to the production environment you place Data Model B under the different path Shared Folders/Data Models. When you run the report in the new environment it still expects the data model to be located under Shared Folders/Test/Data Models. The report cannot find the data model and doesn't run.
You can correct the mapping in the new environment by opening the report in the report editor, selecting the data model in its new location, and saving the report.
To avoid manual steps, Oracle recommends that you maintain the same folder names and structure in the environments across which you intend to move reports.