13 General New Features in Release 10.1.3.4.1

Oracle BI EE Release 10.1.3.4.1 introduces the following new features:

Section 13.1, "Configuring for Connections to EPM Workspace."
Section 13.2, "Validating the Catalog."

13.1 Configuring for Connections to EPM Workspace

You can configure Oracle BI EE to work with EPM Workspace, as described in Section 12.5, "Integration with Oracle Enterprise Performance Management Workspace, Fusion Edition." In addition, you can use the ManageEPMWorkspaceConnection privilege to control whether the "Manage EPM Workspace Connection" link is displayed on the Administration page for certain users.

You can include the following element in the instanceconfig.xml file to control whether Oracle BI EE connections to Workspace are allowed:

<ServerInstance>
<ManageEPMWorkspaceConnection>true</ManageEPMWorkspaceConnection>
</ServerInstance>

13.2 Validating the Catalog

Over time, inconsistencies can develop in the catalog as links are broken, users are deleted, or NFS file system issues are encountered. These inconsistencies can eventually lead to incorrect behavior, such as the inability to edit an agent's recipient list. You can periodically take the production system offline and validate the catalog, to be informed of and to take corrective action on inconsistencies.

This section contains the following topics about validating that catalog:

Section 13.2.1, "Process: Validating the Catalog."
Section 13.2.2, "Important Guidelines for Validating the Catalog."
Section 13.2.3, "Performing a Basic Validation of the Catalog."
Section 13.2.4, "Specifying the Elements for Validating the Catalog."

13.2.1 Process: Validating the Catalog

The process of validating the catalog involves creating a report for the catalog in offline mode and seeing the objects that require adjustment or removal. You might fix some objects manually in offline mode. Then run the validate operation again to allow the system to "clean" by deleting any unnecessary objects. You repeat the process of creating the report, manually fixing errors, and cleaning the catalog until it is validated.

13.2.2 Important Guidelines for Validating the Catalog

Before you validate the catalog, keep the following guidelines in mind:

When you turn on any validation of the catalog, all ACLs (that is, all privileges and every item's permissions) are "scrubbed," which means that dead accounts are removed from them and any changed items are written to disk. Therefore, even if you simply create a report without fixing any broken items automatically, you might find that the catalog is still extensively "changed."
Before validating the catalog in a clustered environment, do one of the following:
- Shut down the Presentation Services cluster and run the validation directly against the cluster's catalog.
- Make a copy of the cluster's catalog and run the validation against that copy.
  
  Before using the 7-Zip utility to make a copy of a catalog, first shut down all nodes in the Presentation Services cluster or put all nodes in that cluster into Maintenance Mode (which is the recommended approach).
  
  Be aware that any changes that are made to the catalog online concurrently to the validation process are not included in the validation.
  
  While backing up the catalog is always good practice, there is no practical difference between running validate against the catalog directly versus running the validation on a backup copy.

13.2.3 Performing a Basic Validation of the Catalog

You can perform a basic validation of the catalog on an ad-hoc basis as needed, immediately before pushing content from a development environment to a production environment, or per a regular schedule, such as on the first Tuesday of every month.

To validate the catalog:

Stop Presentation Services.
Back up the catalog by using the 7-Zip utility to create a compressed file for it.
Create a backup copy of the instanceconfig.xml file.
Edit the instanceconfig.xml file so that it contains the appropriate elements for performing the validation. You must set the elements to perform the tasks for creating the report and "cleaning" the catalog at the appropriate times.

For information on these elements, see Section 13.2.4, "Specifying the Elements for Validating the Catalog."
Start Presentation Services to run the validation according to the values that you specified in the instanceconfig.xml file.
Edit the instanceconfig.xml file again so that it contains the appropriate elements for performing the validation. You must set the elements to perform the tasks for creating the report and "cleaning" the catalog at the appropriate times.
Repeat Steps 4 through 6 until the catalog is validated.
Stop Presentation Services.
Create a backup copy of the instanceconfig.xml file in which you added the validation elements and rename the file similar to instanceconfig_validate.xml. In this way, you have a version of the file to use as a starting point for subsequent validations.
Restore the backup version of the instanceconfig.xml that you created earlier to use as the current version.
Start Presentation Services.

13.2.4 Specifying the Elements for Validating the Catalog

As part of the process of validating the catalog, you include elements in the instanceconfig.xml file that run the validation when you restart Presentation Services. The following procedure describes how to edit the instanceconfig.xml file to include these elements.

To specify the element for validating the catalog:

Open the instanceconfig.xml file for editing.
Locate the Catalog section in which you must add the elements that are described in Table 13-1.
Include the elements and their ancestor element as appropriate, as shown in the following example. In this example, the validation runs when Presentation Services starts, and Presentation Services is stopped when the validation is complete. Inconsistent accounts (such as those for deleted users), links, and objects are removed. Inconsistent users' home directory names are logged but directories are not removed.
```
<ServerInstance>
  <Catalog>
      <Validate>OnStartupAndExit</Validate>
      <ValidateAccounts>Clean</ValidateAccounts>
      <ValidateHomes>Report</ValidateHomes>
      <ValidateItems>Clean</ValidateItems>
  </Catalog>
</ServerInstance>
```
Caution:
Include only one Catalog element in the instanceconfig.xml file or unexpected results might occur. Unless expressly noted, include most nodes (such as that for the Catalog element) in an XML document only once.
Save your changes and close the file.

Table 13-1 Elements for Validating the Catalog

Element	Description	Default Value
Validate	Performs the validation of the catalog according to the values of the other Validate-related elements in this section. Values are described in the following list: None — Performs no validation. OnStartupAndExit — When Presentation Services starts, performs the validation, performs Report or Clean operations, then stops Presentation Services. You run through multiple cycles of Report, Clean, Report, and so on for each element (such as ValidateAccounts, ValidateHomes, ValidateItems, and ValidateLinks) until the catalog is validated. If this value is not None, then all privileges and each object's ACLs in the entire catalog are cleaned of terminated accounts, regardless of the settings of the other Validate-related elements.	None
ValidateAccounts	Verifies that all information about users, roles, and groups in the catalog is consistent. Values are described in the list after this table.	None
ValidateHomes	Verifies that all information about home directories in the catalog is consistent. Values are described in the list after this table. ValidateHomes is executed only if ValidateAccounts is set to either Report or Clean.	None
ValidateItems	Verifies that all information about objects in the catalog is consistent. Values are described in the list after this table.	None

The elements have the values that are described in the following list:

None — Specifies that no validation is performed.
Report — Specifies that details about each inconsistent object are written to the sawlog.log file.
Clean — Specifies that details about each inconsistent object are written to the sawlog.log file and that each object is removed from the catalog.