Administering the Metadata

You can change the metadata in your models to meet your specific modeling goals.

You can do the following:

	Copy, move, rename, or delete your projects to organize them in meaningful ways for your reporting environment .
	Analyze the changes made to a model to see how they affect the packages and the reports that use the model .
	Remap an object to a new source .
	Export your model to exchange metadata between different data warehouse tools and repositories .
	Reuse the same model and reports with different sets of data .
	Move a model from one relational database to another .

Copy, Move, Rename, or Delete a Project

You should organize projects in a meaningful way so that you can easily find them. Within Framework Manager, you can copy , move , rename , and delete projects.

You can manage your projects using repository control , segmenting , and linking . These project management features help maintain version control, organize a project according to business rules and organizational needs, set run time processing options, and give other users access to sections of the project.

A project that is connected to a repository loses all repository information when you copy, move, or rename the project. Saving a project as a new project also removes all repository information.

You can also identify the vendor-specific functions that you want to use for each data source you import into your project.

If your project is segmented, the segments are treated as standalone projects. If you save or copy a project within an existing project, it is treated as a segment.

Copy a Project

When you copy a project, you create a replica of that project in another location. All files in the project folder, including sub-folders, are copied to the new location. When you make changes to the project in one folder, these changes are not reflected in copies of the project in other folders.

Copying a segmented model copies all segments as well as the main project.

There may be times when you cannot copy a project and must use Save As instead. Saving the project with a new name creates a new project folder while saving the project with the existing name overwrites the current project. This is useful if you want to save changes made to a read-only project or if you want to save a project with a different name or to a new location without overwriting the original project.

You cannot create a copy of a project in the same folder as the original. If you copy a project under an existing project folder, Framework Manager treats it like a project segment .

If a project or segment is open when you copy it, the last saved version is copied.

Steps

1. From the File menu, click Manage Projects, Copy.

2. In the From box, click the browse button and select the .cpf file for the project you want to copy.

   Note: The project folder name is shown in the text box.

3. In the To box, type the project name.

   By default, the project name and the directory where the project is saved are the same.

4. In the Location box, type the new location or click the browse button and select the new project location.

5. Click OK.

Move a Project

You may decide to move a project if your folder becomes so full that it is difficult to locate particular projects. When you move a project, you are actually copying it to a new folder and deleting it from the current folder. All files in the project folder, including sub-folders, are moved to the new location.

Moving a segmented model moves all segments as well as the main project.

Before you can move a project, the project must be closed in Framework Manager.

Steps

1. From the File menu, click Manage Projects, Move.

2. In the From box, click the browse button and select the .cpf file for the project you want to move.

   Note: The project folder name is shown in the text box.

3. In the To box, type the new location or click the browse button and select the new project location.

4. Click OK.

Rename a Project

When you rename a project, you provide a new name for the .cpf file. You are not changing the location of the project. Secondary project files and log files keep their original name.

If a project appears in the recent projects list on the Framework Manager Welcome page and you proceed to rename it, you cannot open the project by clicking the link. You must open the project using the Open command from the File menu.

Before you can rename a project, the project must be closed in Framework Manager.

Steps

1. From the File menu, click Manage Projects, Rename.

2. In the From box, click the browse button and select the .cpf file for the project you want to rename.

   Note: The project folder name is shown in the text box.

3. In the To box, type the new name for the project and click OK.

If the original project folder and .cpf file have the same name, both the folder and .cpf file are renamed.

Delete a Project

When you delete a project, the project folder and all its contents, including any user files, are deleted from the file system and sent to the recycle bin.

If your project is segmented and you delete the main project, the segments are deleted as well. Deleting a project segment deletes only the segment and not the model it is based on.

We recommend that you delete segments from within the model. If you delete the segment using Delete from the File menu, it appears as if the segment still exists within the model. For more information, see Segmenting and Linking Projects.

Before you delete a project, ensure that the project and all its segments are closed. Framework Manager does not support a file locking mechanism so it is possible under certain circumstances to delete a project with open segments. If you delete a project with open segments, the segments can no longer be saved.

Steps

1. From the File menu, click Manage Projects, Delete.

2. In the Project Folder box, click the browse button and select the .cpf file for the project you want to delete.

   Note: The project folder name is shown in the text box.

3. Click OK.

The project folder and all its contents are deleted.

Analyze the Impact of Changes to a Package

Before publishing packages and running reports, you can see how the changes you make to a model will affect the package and the reports that use it. You can find the changes that were made to the package, and see details about each change and which reports are affected by a specific selected change.

Reports that are created using the package may be impacted by changes that you made to the model. For example, adding new objects to a package does not affect a report. Changing the name of a query item does affect a report. The report definition will not be valid because the query item is not in the package definition.

Note: Because a report uses a published package, if you make changes to the model but do not publish the package that uses it, the report is not impacted by the changes.

If you change the name of an object, it shows up as "modified" in the results of the analysis.

The analysis is done on objects that a model uses directly, not the underlying objects. For example, you have a model query subject that is based on a data source query subject. If you change the model query subject, it will show up as a modified object. If you change the data source query subject, it will not show up as a modified object.

The following types of objects are analyzed: query subjects, query items, measures, regular dimensions, measure dimensions, hierarchies, levels, stand-alone filters, and stand-alone calculations.

Steps

1. In the Project Viewer, click a package that has been published.

2. From the Actions menu, click Package, Analyze Publish Impact.

3. Choose what you want to do:

   Goal	Action
   View report dependencies	See Find Report Dependencies.
   View the dependencies for an object	See Show Object Dependencies.
   See the details for an object	Click the row that contains the object. The details for the object appear under Change Details for.
   Find an object in the Project Viewer	In the row that contains the object, under Actions, click Find in Project View.
   Sort the results	Click Sort at the top of a column.
   Display modeler’s comments, last changed by, and last date changed	Click the double down arrow.

4. Click Close.

Find Report Dependencies

You can find the reports that use an object.

Steps

1. From the Analyze Publish Impact dialog box, do one of the following:

   • Select each object for which you want to determine the report dependencies by selecting individual check boxes.

   • Select all objects by selecting the check box at the top of the check box column.

2. Click Find Report Dependencies.

3. Specify the scope of the search:

   Goal	Action
   Search all folders	Click All Folders.
   Restrict the search to a specific folder	Click Restrict Search (Browse and select a folder). Type the name of the folder or click Browse to search for a folder.

4. Click Search.

   A list of report names appears in the Report Dependency window under Impacted Reports.

5. To sort the results, click Sort at the top of a column.

6. Click Close.

Show Object Dependencies

You can find objects that depend on other objects, or show the dependencies of a child object.

Steps

1. In the Project Viewer, click an object.

2. From the Tools menu, click Show Object Dependencies.

   The objects that depend on the selected object appear under Dependent objects.

3. To show the object identifier for the dependent objects, select the Show Object ID check box.

4. If the object has children and you want to see the dependencies for a child object, click the plus sign (+) beside the object that contains the child object.

5. Click a child object under the parent object.

   The objects that depend on the child object appear under Dependent objects.

Note: You can also show object dependencies from the following:

• The Project Viewer by right-clicking an object and selecting Show Object Dependencies.

• The Context Explorer window by right-clicking an object and selecting Show Object Dependencies.

• The Analyze Publish Impact window by clicking the Show Dependencies icon under Actions in the row that contains the object.

Remap an Object to a New Source

During the life cycle of a Framework Manager model, you may need to change the data source it uses. For example, you may want to use the model against a different database with the same data, migrate the model from a transactional schema to a star or snowflake schema, or replace a previously existing database or import view with a new view. All of these actions can affect your reports. For example, if you change the names of objects, reports may no longer validate.

You can minimize the effect of model changes and data source changes by remapping higher level model objects so that they continue to run and return correct data. When you remap, you match and substitute object references or names in an original object, to object references or names in another object. You can remap query items and measures. You can remap individual objects manually or you can remap multiple objects at the same time. When remapping multiple objects, Framework Manager matches items in the original object to items in the other object using the matching criteria you specify. Only the objects that meet the matching criteria are remapped. You can use the object name or the object reference as the matching criteria for both the original and other objects.

If a model query subject or model dimension contains a filter or calculation, the model filter or calculation is also remapped when you remap the model query subject or model dimension. You do not see a message or warning about this.

Note: We recommend that you validate all affected reports whenever you make changes to your model. To identify affected reports, see Show Object Dependencies and Find Report Dependencies.

Steps

1. In the Project Viewer, right-click an object and select Remap To New Source.

2. If you want to change the matching criteria, click Options and do the following:

   • Choose the matching criteria for the object you are using to remap, and for the original object that you are remapping.

     You can match objects by name or by object reference.

   • The default criteria options are By Name for the object you are using to remap, and By Object References for the original object that you are remapping.

   • If you want to set these choices as the default, select the Set as default check box.

   • Click OK.

   • To use the criteria you specified, select the Use matching criteria options check box.

   Notes:

   • If the matching criteria is By Name to By Name, spaces within the string are removed.

   • If there is no object reference, the object name is used.

3. Do one or more of the following:

   Goal	Action
   Remap an individual object manually	Under Available Model Objects, drag an object to the object that you want to remap under Query Items, Measures, Calculations, and Filters. The new value for the object appears under Remap To.
   Remap multiple objects automatically	Under Available Model Objects, drag a query subject to any row under Query Items, Measures, Calculations, and Filters. All of the objects that meet the matching criteria are remapped and their values appear under Remap To.
   Change the expression for an object	Click the ellipsis (…) button beside the object. For information on how to create an expression, see Create a Calculation.
   Restore a remap value to the original source value	Right-click the row that contains the object that you want to restore, and select Restore to Original Value.
   Clear the remap value and the original value for the selected object	Click the row that contains the object, and click Clear.
   Clear the remap value for all objects	Click Clear All.

4. Click OK when you are finished remapping.

Export Metadata

You can export your Framework Manager model as a Common Warehouse Metamodel (CWM) file. CWM exchanges metadata between different data warehouse tools and repositories. Each instance of the CWM metamodel is exchanged using XMI (.xml metadata interchange) documents.

When you export a Framework Manager model as a Common Warehouse Metamodel (CWM) file, joins, folders, namespaces, prompts, and calculations are not exported. Only query subjects, query items, and functions are exported.

When you export to CWM, we recommend that you use the default options, which optimize the metadata export. Only change these options if you have specific information that affects your export. For more information about export options, see the Meta Integration® Web site.

Steps

1. Right-click the root namespace of the metadata you want to export, and click Export Model.

   You are prompted to save the project.

2. Select the export target.

3. In the File Name box, browse to locate the file that contains the appropriate metadata type and click Save, and then click Next.

   An example is Sales_cwm.xml.

4. In the Framework Manager Specific Export Options dialog box, click the options you want.

   Note: We recommend that you use the default options. These default options optimize the third party metadata import. If you change the options, you may see unexpected results. To revert to the default options, click Use Defaults.

5. Click Next.

6. In the Third Party Specific Export Options dialog box, click the options you want.

   In the Option Description pane, you see a description of the options available. The options are based on the selected third party data source. For more information, see the third party data source vendor documentation.

   Note: We recommend that you use the default options. These default options optimize the third party metadata export. If you change the options, you may see unexpected results. To revert to the default options, click Use Defaults.

7. Click Next.

   The input validation results from the export process appear.

8. Click Next and click Finish.

Project Reuse

You may have to use the same model and reports with different sets of actual data. The data sets may be different databases, accounts, or schemas in a single database. You may encounter multiple data sets

• when you use a different data set than used in production

• in large enterprises, where each division has it own data set

• in OEM applications, which have no direct control over customer data

The tables and columns used by the project must be logically the same across all data sets. You must also ensure that the correct data set is identified in each case.

Data sources in Framework Manager contain information that identifies the location of any data source tables needed for the query subjects. This information is the name of the data source in the content store, as well as the optional catalog and schema names. Ensure that the catalog and schema names use the desired data set.

If different content stores are in use, and a different version of the project is deployed to each content store, you can specify the data source information in the project for each site. If you have only one content store, you can publish each project as a separate package. These solutions require a lot of manual maintenance. To reduce this level of maintenance, you can use one of the following options.

If some data sets use the same content store, create a separate connection for each data set in a single content store. For more information, see the Administration and Security Guide. For information about how Framework Manager handles multiple connections, see Multiple Data Source Connections.

Because the data source name in the content store can differ from the name of the customer database, this solution offers a lot of flexibility. However, it still requires that the catalog and schema names be identical across all data sets. Even if all the data sets use the same database type, this may be difficult to ensure. If different database types are involved, it may be impossible. For example, SQL Server has a catalog level, but Oracle does not.

Steps

1. Create a single session parameter whose value identifies whether you are in design mode. When you are in design mode, set the value of this session parameter to a specific value, such as design. Otherwise, leave the value empty.

   Tip: If you use a project or override value, you must set it each time you open the model for editing.

2. For each catalog and schema in each project data source, create a parameter map that contains

   • an empty default value.

   • a key whose name is the design value of the session parameter above, and whose value is the name of the design mode catalog or schema for that data source.

3. Select the data source, and replace the catalog and schema property values with a macro that uses the corresponding parameter map and session parameter.

   For example, use

   #$DBSchemaName ($DeployOrDesign) #

Model Portability

You can use a Framework Manager model to access data from different database instances. The database instances can be from the same or different vendors.

There are several things to consider when moving a Framework Manager model from one relational database to another. Unlike changing from one identical database to another on the same platform, it may not be sufficient to change the data source connection information.

Review the generation of determinants and relationships based on indexes and do not assume that the indexes reliably describe functional dependencies or relationships for reporting.

Scalar functions are imported into a model prefixed by a catalog or schema qualification in the SQL statement. As with tables and views, you may have to remove or alter the location qualification when switching vendors. For example, if you create a model against an ORACLE database, and the connection is changed to point to an equivalent SQL Server database, an error results because the model data source type has remained OR instead of changing to the appropriate data source type.

To move a model from one relational database to another, do the following:

	Evaluate the DDL (Data Definition Language) to determine portability for physical names by constraining physical names to a lowest common denominator, such as 31 characters. avoiding using reserved key words in the ANSI standard and vendor documentation. avoiding using vendor specific data fields. avoiding conversions. confirming that precision and scale is supported across all vendors. using consistent and compatible collations. using a consistent case on names, such as all lowercase.
	Evaluate the DDL to determine portability for database qualification.
	Evaluate the DDL to determine portability for data types in terms of compatibility and the precision and scale of data types.
	Review any native SQL statements in your models and reports for relational-specific syntax that may or may not be supported.
	Review usage of vendor-specific functions. There may not be an equivalent vendor function or common function. A common function that is unsupported by the relational database may result in local processing that did not previously occur.
	Review the data source properties type. If you change the RDBMS you use, such as from Oracle to SQL server, change the type property for the data source in Framework Manager.
	Update the data source queries. When you import tables, Framework Manager imports physical information about the tables and columns that is used internally at run time. For example, collation information is reconciled only by rebuilding the physical tables.
	Test the moved model. There will be other differences, such as performance characteristics, how data is ordered based on collations, and so on, that are revealed only by testing.

Moving a Model to Another Environment by Using Log Files

In Framework Manager, you can view and play back actions performed on the project or you can use Script Player to play back transactions in batch mode. An action log is an XML file that contains a set of transactions. Each transaction has a sequence number and one or more actions. Each action is made up of a name and input parameters. Some actions also have output parameters. The action log file is in the project folder.

For example, you make changes to a project in a test environment. When it is time to move the project to production, you can use log files to play back every action, or series of actions, that you performed in the test environment to create an identical project in the production environment.

There are two action log files. The log.xml file contains all the transactions that have been run and saved in the project. This file is created the first time you save the project and exists until you delete the project. The temporary file contains transactions that have been run during the current session, but not saved. The temporary file is deleted when you close the project.

Note: If the script has dependencies on the existing project, you must ensure that the project is aligned with the script transactions to ensure the desired results.

View and Save Transaction History

You can view the transaction history in an action log file and then save it as a script.

Steps

1. From the Project menu, click View Transaction History.

   Tip: To make the dialog box larger, double-click the caption. Double-click again to restore the dialog box to its original size.

2. Click the transaction numbers that you want.

   Tip: To view the details of a transaction, click the plus sign (+) next to a transaction number.

3. Click Save as Script.

4. Type a name for the file.

5. Click Save. Do not save the file in the logs folder.

6. Click Close.

Play Back Transactions From a Log File

You can choose to play back a specific transaction or a combination of transactions in a project or segment action log file.

When you play back transactions from a log file, the script player applies the commands in the log file to the contents of the existing model. Errors appear if objects created by the log file already exist in the model.

After the script in a log file has run successfully, a backup of the original project is created in the parent directory of the project. If you want to undo the transactions performed in the script, you can use the backup to restore the project to its original state.

You must disable or clear any commands that will conflict with the contents of the model. You can then run the script again. Or, you can use the Synchronize command, which begins with an empty model.

If you generate your own script outside Framework Manager, time stamps must be in ascending order with no duplicates.

Steps

1. From the Project menu, click Run Script.

2. Select the script you want, and click Open.

3. If you want to view the details of a transaction, click the transaction.

4. Set the starting or stop point that you want.

   • To set the starting point for running the script, select the script and then click Set the starting point. You can do this at any time to skip an instruction or run instructions that have already been executed .

   • To set a stop point for the script, select the script and then click Set the stop point .

     You can stop the script to make a manual fix and then start it again.

     Tip: To remove the stop point, click Remove the stop point 

      .

5. Using the toolbar buttons, choose the run action that you want.

   Button	Description
   	Runs the script After an error is encountered, clicking this button attempts to re-execute the failed instruction.
   	Skips to the next transaction and runs the script to the end
   	Runs the selected transaction only
   	Skips to the next transaction and stops, but does not run any transactions

   The project window is updated as the script is run.

6. Fix any errors encountered by the script either by retargeting objects or modifying the temporary project as required.

   For more information, see Fixing Errors Caused by Invalid Objects.

7. When the script has completed, click Accept to accept the changes or click Revert to undo the changes.

   Note: After clicking Accept or Revert, you cannot use Undo and Redo for the current session.

Running Action Logs in Batch Mode

BmtScriptPlayer [-c|-m] <projectname> [-a <actionlogname>][options]

BmtScriptPlayer -m goSales.cpf -a import.xml

-a FILEPATH

-b NUM

-c FILEPATH

-e NUM

-g

-k DIRECTORY

-m FILEPATH

-n

-p PASSWORD

-s NAMESPACE

-t DIRECTORY

-T PASSPORT

-u USER

-x

-y PASSPORT

BmtScriptPlayer -c <projectname>

BmtScriptPlayer -c <projectname>
-a <actionlogname>

BmtScriptPlayer -c <projectname>
-a <actionlogname> -b2 -e20	

BmtScriptPlayer -m <projectname>
-a <actionlogname> -e20

BmtScriptPlayer-m <projectname>
-a <actionlogname> -n

Fixing Errors Caused by Invalid Objects

You may encounter errors when running script files or verifying models if an object that is referenced by a transaction no longer exists, or if you renamed objects.

If an object no longer exists, retarget the missing object to another object.