Chapter 8. Maintaining Projects

Framework Manager models are not static objects and once a model has been implemented it transitions into a maintenance mode characterized by the need for small changes over time. The underlying relational database may be changed by adding or removing columns from the tables, changing the data types of columns on the tables, or even changing the database vendor. These types of changes, and others, have to be reflected in the model through a managed change process. This chapter will cover some of the methods used to maintain these changes within the Framework Manager project.

We will also look at some of the methods available to allow multiple modelers to work with the same model.

This chapter will cover the following topics:

• Analyzing the impact of changes made to packages

• Finding report dependencies

• Showing item dependencies

• Remapping an item to a new source

• Branching and merging projects

• Segmenting and linking projects

By the end of this chapter you will be able...

Analyzing the impact of changes made to packages

Changes made to a project may impact reports already created using packages from the model, especially if query item names are changed or removed.

Adding new items to your model will not affect any existing reports that are based on packages from the model; however, if you rename or delete a query item from your model then any reports created using those items will no longer be valid because the query item is no longer part of the model package. Before republishing a package, you can see if any changes you have made to your model will affect any existing reports that use the package. You can find all of the changes that have been made to the package in the current session, as well as see details for each change and find out the names of reports affected by a specific change.

Note

If you do not publish any of the packages using your model then no reports will be affected by the changes.

You can make use of package versions when publishing your...

Remapping an item to a new source

Over time you may want to make more radical changes to your Framework Manager model. You may, for example, want to change the model to replace an existing import view with a new import view, or use a different database with the same data.

You can reduce the impact of making changes to your data sources by remapping your model at the import layer of your model. When you remap items in your model you are replacing the original items with new items. You can remap single items or you can remap multiple items at the same time. When you remap multiple items, Framework Manager only matches and replaces those items that meet your chosen matching criteria; any other item will be ignored.

Note

If your report authors have already created reports then run Analyze Publish Impact, and use Find Report Dependencies to identify any affected reports when you remap any item in your model.

How to remap an item

The procedure to remap an item is as follows:

1. In the Project Viewer window...

Reusing a project

Sometimes you may want to use an existing model and reports with different data sources, which could be different accounts or schemas within a single database. For this process to work successfully, all of the database tables and columns used by the project must be identical across all the data sources.

It is possible to use multiple data source connections in a single data source to assist the migration of your Framework Model from one environment to another. If you have access to multiple data source connections in a single data source, when you open Framework Manager you will be prompted to select the data source connection to use for the project.

For example, you can use multiple data source connections to work with metadata from a development and a production data source. When you create your new Framework Manager project and add the data source you will be prompted for the data source connection to use, to select the development data source connection, and create and...

Model portability

Sometimes it is necessary to change your Framework Manager project to access data from a different database vendor, for example moving your database from Oracle to SQL Server.

There are several things that need to be considered when making such migrations. Unlike changing from one identical database to another on the same platform, it may not be sufficient to just change the data source connection information.

To move the model from one relational database to another, here are a few of the tasks you will need to carry out:

• Review the Data Definition Language (DDL) used by the different databases to check for the portability of physical names and data. Not all databases support the same data types or precision of data; some databases may have restrictions on the length of table names, or may require the table names to be in lower- or uppercase.

• If you have used any native SQL statements in your models you will need to check that any vendor specific syntax is changed or removed...

Moving a model by using the log file

You can move your Framework Manager model from one environment to another by using the Framework Manager log file.

The log file is created the first time you save your project and exists until you delete the project. The log file, log.xml, is saved in the project folder with the other project files. Every action that has been run and saved in the project since the model was originally created is stored in this log file.

Within Framework Manager, you can view and play back any of the actions saved in the log file. Alternatively, you can use the command line Script Player, BmtScriptPlayer, to play back the actions in batch mode.

It is easy to use the log file to transfer your Framework Manager project from a development to a production (or any other) environment. You only need to make changes to your mode in the development environment, and when you want to move the model to your production environment you can use the log file to replay the actions to create...

Multiuser modeling in Framework Manager

You can implement multiuser modeling in Framework Manager in the following ways:

• Using branching and merging: When you use this method, each user has their own branch copy of either the entire project or a subset of the project, and can make changes to this branch without affecting other parts, or other users. The individual branches can later be merged back into the main project.

• Using segmenting and linking: Every user can use the same parts of the overall model, but it is important that each user only modifies specific parts of the project. The project is generally made from one or more segments which are linked together for the main project.

Branching and merging projects allows multiple modelers to work on the model at the same time, since each has its own separate branch model which has been created from an overall model. There is no limit to the number of branches that a model can have; it is also possible to create a branch from an existing...

Segmenting and linking projects

Using segmenting and linking projects components can be created and shared between different models. It is only necessary to create the components once, the components can then be segmented, and linked to other projects when required.

Each project segment is a complete project and changes to the project will affect all projects to which the segment is linked.

Note

Do not change the import layer in a segment. Any change will be reflected in the linked parent model and will impact all model segments that share data source query subjects. Changes may not be apparent until the model is closed and reopened.

Before a project is segmented it is important to ensure that the folder and namespace are named correctly, since once you have created the segment it is not possible to rename either the segment or the namespace.

The main project has access to the entire model, including the segments. You can make changes to any of the segments when working in the main project.

If...

Summary

In this chapter, we have looked at managing your project when the data source or items in the model change. We have looked at how you can find out what effect any change made to the model will have on any report that makes use of packages published from the model.

We have also looked at the techniques available for multiuser modeling, allowing more than one person to work on a Framework Manager model simultaneously.

In the next chapter, we will look at the Model Design Accelerator. This is a new feature added to IBM Cognos Framework Manager which is designed to make it quicker to create a new Framework Manager model.