+ All Categories
Home > Documents > IBM Cognos 8 Framework Manager - Enabling a Multi...

IBM Cognos 8 Framework Manager - Enabling a Multi...

Date post: 24-Mar-2021
Category:
Upload: others
View: 11 times
Download: 0 times
Share this document with a friend
26
Proven Practice IBM Cognos 8 Framework Manager - Enabling a Multi- Developer Environment Product(s): IBM Cognos 8 Framework Manager (MR2) Area of Interest: Modeling
Transcript
Page 1: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

Proven Practice

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

Product(s): IBM Cognos 8 Framework Manager (MR2)

Area of Interest: Modeling

Page 2: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 2

IBM Cognos Proprietary Information

Copyright Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC is an IBM Company. While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. Cognos does not accept responsibility for any kind of loss resulting from the use of information contained in this document. This document shows the publication date. The information contained in this document is subject to change without notice. Any improvements or changes to the information contained in this document will be documented in subsequent editions. This document contains proprietary information of Cognos. All rights are reserved. No part of this document may be copied, photocopied, reproduced, stored in a retrieval system, transmitted in any form or by any means, or translated into another language without the prior written consent of Cognos. Cognos and the Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated) in the United States and/or other countries. IBM and the IBM logo are trademarks of International Business Machines Corporation in the United States, or other countries, or both. All other names are trademarks or registered trademarks of their respective companies. Information about Cognos products can be found at www.cognos.com This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to [email protected] .

Page 3: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 3

IBM Cognos Proprietary Information

Contents

1 INTRODUCTION ............................................................................................ 4

1.1 PURPOSE ................................................................................................................ 4 1.2 APPLICABILITY ......................................................................................................... 4 1.3 EXCLUSIONS AND EXCEPTIONS ..................................................................................... 4

2 METHODS FOR ENABLING THE MULTI-DEVELOPER ENVIRONMENT ........... 4

2.1 SEGMENTING AND LINKING FUNCTIONALITY..................................................................... 4 2.2 INTEGRATION WITH CVS AND MICROSOFT VISUAL SOURCESAFE........................................... 4

3 SEGMENTING AND LINKING......................................................................... 4

3.1 LIMITATIONS OF SEGMENTING AND LINKING PROJECTS....................................................... 4 3.2 LEVERAGING A READ-ONLY PROJECT ............................................................................. 5 3.3 SCENARIO ONE – HUB/SPOKE...................................................................................... 5 3.3.1 Enabling the Hub/Spoke Environment .................................................................... 6 3.4 SCENARIO TWO – FUNCTIONAL AREA RESTRICTED METADATA ............................................. 8 3.4.1 Enabling the Functional Area Specific Metadata Environment ................................... 9 3.5 SCENARIO THREE – DISTRIBUTION BY LAYERS ............................................................... 11 3.5.1 Enabling the Distribution by Layers Approach ....................................................... 13

4 FRAMEWORK MANAGER REPOSITORY CONTROL FUNCTIONALITY .......... 16

4.1 INSTALL AND SETUP OF THE REPOSITORY FEATURE ......................................................... 16 4.1.1 The IBM Cognos Configuration Tool ..................................................................... 16 4.2 CREATE A REPOSITORY USING VISUAL SOURCESAFE ........................................................ 18 4.3 CONFIGURING A VSS REPOSITORY IN FRAMEWORK MANAGER ............................................ 18 4.4 CREATE A REPOSITORY USING CVS............................................................................. 19 4.5 CONFIGURING A CVS REPOSITORY IN FRAMEWORK MANAGER ............................................ 19

5 BEST PRACTICES FOR SEGMENTING AND LINKING PROJECTS ................. 20

5.1 USING THE REPOSITORY WITH SEGMENTED PROJECTS...................................................... 20 5.1.1 How to Create a Segmented Project in a Repository.............................................. 20 5.1.2 Procedure for Adding or Deleting a Segment in a Repository Project ...................... 22 5.1.3 Adding an Already Segmented Project to a Repository........................................... 23 5.1.4 Working with Segments with Multiple Users.......................................................... 24 5.1.5 Opening a Segment as a Separate Project ............................................................ 25 5.1.6 Upgrading Segmented and Linked Projects ........................................................... 25 5.1.7 Using the Revision History Feature....................................................................... 25 5.1.8 Using the Synchronize Command with a Repository Project ................................... 26

Page 4: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 4

IBM Cognos Proprietary Information

1 Introduction

1.1 Purpose

This document describes the existing functionality in Framework Manager for enabling a robust multi-developer environment. Choose the method, or combination of the methods, that best match the required environment as defined by your development efforts.

1.2 Applicability

This document is applicable to IBM Cognos 8 Framework Manager MR2.

1.3 Exclusions and Exceptions

Details regarding any possible exceptions or caveats that may be encountered during the implementation of the below will be identified with a NOTE.

2 Methods for enabling the multi-developer environment

2.1 Segmenting and Linking Functionality

Segmenting helps divide large models into smaller easier to manage sections. It enables many developers to effectively build their respective portion of the model in isolation from other project development. Linking projects allows multiple developers to reference shared metadata elements, while protecting those common elements from unwanted changes.

2.2 Integration with CVS and Microsoft Visual SourceSafe

Use CVS or VSS for repository control to manage projects, control versions, enable file recovery, and provide multiple developers access to the latest changes of any Framework Manager projects.

3 Segmenting and Linking

Use Framework Manager to create and link: segments, projects and folders. In conjunction with repository control, Segmenting and Linking provide both an effective means to protecting your code while enabling an adaptable multi-developer environment. Projects designed to enable multi-developer modeling, are usually driven by a few key development requirements of the organization.

NOTE: Segments or links are granular to the namespace level. For instance, query subjects within a namespace can not be segmented on their own.

Two common scenarios where you may find segmenting and linking functionality useful are known as Hub and Spoke, and Distinct Development Paths. There are different recommendations when using each approach. Please also review the section later in this document called Best Practices for Segmenting and Linking Projects.

3.1 Limitations of Segmenting and Linking Projects

Please note the following limitations:

Page 5: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 5

IBM Cognos Proprietary Information

� You cannot change or test objects in a read-only linked segment. Changes to a read-only segment can only be performed by a modeler with write permission.

� You cannot test objects in a segment or linked project if they refer to objects that exist in an unavailable segment.

� You cannot create new objects that are based on objects referencing objects existing in an unavailable segment

3.2 Leveraging a Read-Only Project

You can make a read-only project available for other developers to leverage while protecting the project from unwanted change.

Steps for setting up a read-only project:

1. Create a shared directory or shared network location that will host the project that is to be protected.

2. Grant read-only access and remove other rights to the new directory or network share for any developer or group leveraging the project. This will allow the developer to read the files while preventing modifications. Consult your operating system documentation for details on creating, sharing, and securing directories on a file system.

Note: Changing the properties of the project files to read-only, will not achieve the desired result as users will still be able to overwrite the read-only file if they are allowed write access to the files.

3.3 Scenario One – Hub/Spoke

Common metadata exists that should be shared by all functional areas of the organization. This approach requires a central model containing a fully modeled ‘Physical Layer’ that will be leveraged by multiple functional area branch modelers.

Page 6: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 6

IBM Cognos Proprietary Information

A central data modeler will generate a Root model, containing all the basic elements for the functional areas they support. Functional area developers enhance branch models linked to the Root, with functional area specific information. The functional areas are allowed to view and use content from the Root model but are not capable of changing that original root model. A Read Only copy of the root model is made available to all functional areas. This method allows for reuse and protection of the parent model metadata against unsanctioned or accidental change by a functional area developer and ensures consistency of the physical layer across all functional areas.

3.3.1 Enabling the Hub/Spoke Environment

1. In a shared resource create the following folder structure; create a shared folder called Root.

2. Grant read/write access to your central data modeler responsible for creating the physical layer in the Root model. Grant read-only access to this share for all functional area modelers (i.e. Finance Developer).

Page 7: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 7

IBM Cognos Proprietary Information

3. Create one shared folder for each functional area (I.e. Sales Project, Human Resources Project, and Finance Project). Grant read\write access to the central data modeler. Grant read/write access for each functional area modeler to their corresponding folder.

4. The central data modeler can now create a Root project in the Root folder created in the first step. All required languages should be added, and a complete physical layer should be defined.

Page 8: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 8

IBM Cognos Proprietary Information

5. Each functional area model developer will create a new project and link to the root model to expose the entire physical layer or specific subset/namespace for further functional area specific development.

6. Each developer can now open their corresponding branch model to complete development with functional area specific information. Business packages may now be defined and published to IBM Cognos Connection.

3.4 Scenario Two – Functional Area Restricted Metadata

Multiple developers need to work concurrently on a project, but do not or should not have access common or shared metadata. This requires a central model to link and coordinate the restricted metadata from distributed models. Functional Area modelers must not be able to see development by other areas.

Page 9: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 9

IBM Cognos Proprietary Information

3.4.1 Enabling the Functional Area Specific Metadata Environment

1. Create one folder for each functional area (I.e. Sales Project, Human Resources Project, and Finance Project). Grant read\write access to the central data modeler. Grant read/write access for each functional area developer to their corresponding folder.

Page 10: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 10

IBM Cognos Proprietary Information

2. The individual functional area owners can now import and model the physical and business layers specific to their own functional area.

3. In a shared resource create a shared folder called Combined.

4. Grant read/write access to your central data modeler responsible for creating the presentation layer in the Combined model. Optionally, grant read-only access to this folder for all functional area modelers (i.e. Finance Developer).

5. The central data modeler can now create a blank Combined project in the Combined folder created in the first step with all the required languages.

Page 11: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 11

IBM Cognos Proprietary Information

6. The central data modeler can now create one functional area project and initial model structure for every functional area. Storing the correct project in the correct functional area folders created in a previous step.

7. The central data modeler links each of the functional area models to the Combined model, exposing only specific public portions of the physical or business layer for that functional area.

8. The central data modeler can now define a presentation layer in the Combined model that will format the publicly exposed metadata from the functional areas for consumption by multiple functional area users. If there are no common links between the functional areas then the presentation layers can be defined in the functional area models.

9. The central data modeler can now create a package in the Combined model that contains the multiple functional areas. This package can now be published to IBM Cognos Connection.

10. Each developer can now open their corresponding model to complete or update the functional area specific information. Business packages published from the Combined model will reflect the changes made within each functional area linked model.

3.5 Scenario Three – Distribution by Layers

Common metadata exists that should be shared by all functional areas of the organization. Requirements as follows:

� A physical model containing a fully modeled ‘Physical Layer’ to be leveraged in the Development Layer model.

� A development model linked to the physical model. This model will contain a fully modeled ‘Development Layer’ to be leveraged in the Business model.

Page 12: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 12

IBM Cognos Proprietary Information

� A business model linked to the physical model. This model will contain a fully modeled ‘Business Layer’; where reporting packages may now be defined and published for user consumption.

A central data modeler will generate a Physical Model, containing all the basic elements of a Framework Manager best practice physical layer; to support a second model called the Development Model.

The Development Model is linked back to the Physical Model and contains all the elements required to support a third model called the Business Model.

The Business Model is linked back to the Development Model and will contain all the final elements required to create and publishes the reporting packages to IBM Cognos Connection.

The Development modelers are allowed to view and use content from the Physical Model but are not capable of changing that model. A Read Only copy of the Physical Model is made available to Development Modelers.

The Business modelers are allowed to view and use content from the Development Model but are not capable of changing that model. A Read Only copy of the Development Model is made available to Business modelers.

This method allows for reuse and protection of the physical/development layer models metadata against unsanctioned or accidental change by second and third stage modelers.

Page 13: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 13

IBM Cognos Proprietary Information

3.5.1 Enabling the Distribution by Layers Approach

1. In a shared resource create the following folder structure; create a shared folder called Physical.

2. Grant read/write access to this share to your central data modeler responsible for creating the physical layer in the Physical Layer Model. Grant read-only access to this share for all other developers.

3. Create one share for each successive layer (I.e. Development; and Business).

4. Grant read\write access to the Development share to the modeler responsible for creating the Development Layer model. Grant read access to the Business Layer modeler to the Development share.

5. Grant read\write access to the Business share to the Business Layer modeler.

Page 14: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 14

IBM Cognos Proprietary Information

6. The central data modeler can now create a Physical Layer project in the Physical share created in the first step. All languages are added, and a complete physical layer is modeled.

7. The Development Layer modeler can now create a project and models a complete development layer. Store the project in the correct share created in a previous step. Note: Define all required project languages before beginning your modeling.

Page 15: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 15

IBM Cognos Proprietary Information

8. The Development Layer modeler links to the Physical Layer model, thereby exposing the entire physical layer.

NOTE: you will not be capable of creating shortcuts off objects from the linked physical layer. You will not be able to create relationships between objects from the linked physical layer to new objects in the development layer. Make use of model query subjects and create new relationships in the development layer to work around these restrictions.

9. The Business Layer modeler can now create a project and models a complete Business layer storing the project in the correct share created in a previous step. Note: Define all required project languages before beginning your modeling.

Page 16: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 16

IBM Cognos Proprietary Information

10. The Business Layer modeler links to the Development Layer model, thereby exposing the entire development and physical layer. (Note: you will not be capable of creating shortcuts off these layers. Use model query subjects instead )

11. Business packages may now be defined and published to IBM Cognos Connection.

4 Framework Manager Repository Control Functionality

Using Framework Manager you can create a connection to a Visual SourceSafe (VSS) or Concurrent Versions System (CVS) repository. Use repository control to help manage your Framework Manager projects. Control versions of a project to ensure that each version of a file is recoverable. Ensure users in a large organization have access to the most recent changes or versions of a project or segment. Add new or existing projects to the repository. After connecting and adding your project to the repository you will be able to check in\Check out projects, segments, or related child models. By using this functionality, developers may get the latest version of a project, or view project history without ever leaving the Framework Manager modeling environment.

4.1 Install and Setup of the Repository Feature

4.1.1 The IBM Cognos Configuration Tool

In IBM Cognos Configuration define a group of Source Control System properties to allow Framework Manager to locate an existing (local) source control system. Framework Manager can connect to multiple source control systems, although only connection to one type of source system can be configured at a given time. Here are some tips for using the IBM Cognos Configuration Tool to set up a repository system:

� On the Explorer tab, select Environment | Source Control System

� From the Edit menu, invoke New Resource | Source Control System…

Page 17: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 17

IBM Cognos Proprietary Information

� Enter a name to identify the repository in Framework Manager. This name is arbitrary, but should help the user identify the repository system.

� Select the repository type: CVS, or Visual SourceSafe.

� Now you must identify the executable file to handle the repository. For SourceSafe browse (using the little pencil icon on the right) to identify where SourceSafe is installed, and select SS.EXE.

NOTE: Ensure that you do not select SSEXP.EXE by mistake.

For CVS, select the CVS executable file.

Page 18: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 18

IBM Cognos Proprietary Information

4.2 Create a Repository Using Visual SourceSafe

If you use Visual SourceSafe as your repository, connect to it using your Windows user name and password. When you open a project stored in Visual SourceSafe, you can automatically log on using your Windows user name and password

1. Start Visual SourceSafe Administrator.

2. From the Tools menu, click Create Database.

3. Specify where you want to create the database.

4. Select the New 6.0 Database Format check box, and click OK to create the database.

5. From the Users menu, click Open SourceSafe Database.

6. Locate the srcsafe.ini file, and click Open.

7. You can choose to change the database name. Click OK.

8. Click the database you just created, and click Open.

9. A list of the users assigned to the database appears.

10. Ensure that a user with the same credentials as your Windows account exists.

11. Tip: To add a user, from the User menu, click Add User and enter the credentials of your Windows account.

12. From the Tools menu, click Options, and on the General tab, select the Use network name for automatic user log in check box.

13. Close Visual SourceSafe Administrator.

14. Using a text editor, open the srcsafe.ini file, and type the following command at the end of the file:

15. Update_No_Change=Update

16. This command ensures that the project is updated each time there is a check in.

17. Save the srcsafe.ini file and close the editor.

4.3 Configuring a VSS Repository in Framework Manager

1. Start Framework Manager and, from the Welcome page, click Repository, Connection Manager.

Tip: If you have Framework Manager open, from the Repository menu, click Connection Manager.

2. 2. Click the New button.

3. In the Connection Name box, type a name for the connection.

4. In the Type list box, click SourceSafe://.

5. In the Settings window, click in the Value pane, and browse to the location of the srcsafe.ini file.

Note: Do not include the filename of the srcsafe.ini filename in the location.

6. Click Test.

Page 19: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 19

IBM Cognos Proprietary Information

If you specified your path using a drive letter, you will be prompted to replace it with a network (UNC) path. This is recommended if the repository is to be shared with other computers. Press Yes to use the UNC path, or press No to keep the drive letter.

7. Click OK.

4.4 Create a Repository Using CVS

You can use Concurrent Versions System (CVS) as a Framework Manager repository.

Create a directory for the CVS repository. An example is:

C:\cvs_repository.

Create a subdirectory named CVSROOT. An example is:

C:\cvs_repository\CVSROOT.

4.5 Configuring a CVS Repository in Framework Manager

1. Start Framework Manager and, from the Welcome page, click Repository, Connection Manager.

Tip: If you have Framework Manager open, from the Repository menu, click Connection Manager.

2. Click the New button.

3. In the Connection Name box, type a name for the connection.

4. In the Type list box, click SCCS://.

5. In the Settings window, click in the Value pane, and browse to the location of the repository.

Do not specify the CVSROOT in the path. The repository location must be different from the location where the new project is stored.

An example is C:\cvs_repository.

6. Click Test.

Page 20: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 20

IBM Cognos Proprietary Information

If you specified your path using a drive letter, you will be prompted to replace it with a network (UNC) path. This is recommended if the repository is to be shared with other computers.

7. Click OK.

5 Best Practices for Segmenting and Linking Projects

A segment is part of a single project, while a linked project may be shared by multiple projects. Here are some basic rules for managing segments and links:

� A segment is owned by a Root project, and its project files will be created in a sub-directory below it.

NOTE: If you want to rename the folder or namespace, this must be done before converting it into a segment.

� Create segments from the root project outwards. This means do not convert a folder or namespace into a segment if it already contains a segmented folder below it because the new model segment will be created without references to other linked or model segments that may be contained in the original folder or namespace.

� A linked project is shared by other projects.

NOTE: Linked projects should not be created in a sub-directories below the root project. Linked projects are not affected by the Revision History feature, so repository actions must be done on them by opening the linked project.

5.1 Using the Repository with Segmented Projects

5.1.1 How to Create a Segmented Project in a Repository

Segmented projects intended for a repository should be created as follows:

� Use the “New Project” dialog to create a root project and add it to the repository. The root project should remain checked out.

Page 21: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 21

IBM Cognos Proprietary Information

� Set up the desired folder structure.

� Use the “Create Segment” dialog to create segments on the desired namespaces and folders. If the segments are to be nested, always work from the root project down. Check the “Add to Repository” checkbox, and do not change the default “Connection” and “Location in Repository” text strings.

Page 22: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 22

IBM Cognos Proprietary Information

� Check in the segments.

� Check in the root project.

NOTE: The segment structure is not saved until the root project is checked in, so do not let other users work on the project until you have finished with these steps.

5.1.2 Procedure for Adding or Deleting a Segment in a Repository Project

� Check out the root project.

NOTE: Segments can only be created by one user at a time from the Root project.

� If there is more than one segment level, also check out the project where the new segment is being created

Page 23: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 23

IBM Cognos Proprietary Information

� For example, a new segment is required under Segment One in the above picture; so check out both the Root Project and Segment One from the repository.

� Create the new segment and add it to the repository; or alternatively delete an existing segment.

� Check in the new segment, and then check in each segment up the hierarchy to the root project. Finally check in the root project.

NOTE: The segment structure is not saved until the root project is checked in.

� All other users should perform Get Latest Version after the root segment has been checked in.

5.1.3 Adding an Already Segmented Project to a Repository

� Add the root project to the repository, and keep it checked out.

Page 24: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 24

IBM Cognos Proprietary Information

� Add the segments to the repository, starting from the root and working out.

� Check in the segments from the outer ones and work toward the root project.

� The root project must then be checked in. The segment structure is not saved until the root project is checked in.

5.1.4 Working with Segments with Multiple Users

� A single user should be responsible for any changes to the segment structure of the project (add or remove segments). See the procedures described above. Multiple users may each check out their own segment.

NOTE: There is no need to check out the root to work on a segment (it is only required to create one).

� When checking in, provide a clear comment, and start it with the name of the segment. This will make the Revision History easier to understand.

Page 25: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 25

IBM Cognos Proprietary Information

5.1.5 Opening a Segment as a Separate Project

� It is suggested that you do not make any changes to a segment when opened as a project because those actions will not appear in the Revision History of the root project. If a single Revision History is required; it is a better practice for each modeler to open a copy of the root project and then check out their respective segment only (not the root).

� If you do opening a segment as a separate project, ensure there are no checked out segments below the segment, including the root.

NOTE: Do not create a nested segment inside your segment, because this will not get recorded in the root segment.

5.1.6 Upgrading Segmented and Linked Projects

A project must be upgraded starting from the child segments, and proceed toward the root project. A linked project must be upgraded before using any projects that use that project. It is suggested that repository projects be checked in before upgrade, but it is not necessary. Upgrade should be done as follows:

� Open each segment (if they are nested, start from the outermost segment) as a separate project.

� The Upgrade Model dialog will appear – press OK.

� After the project opens, do File | Save. If the project was checked in, you will be prompted to check it out. Press OK. Do not Check in the segment.

� After you have upgraded the root project, then you should check in each of the segments, and finally check in the root project.

5.1.7 Using the Revision History Feature

The Revision History feature allows you to restore a repository project to a previous revision. If the project contains segments, they are co-coordinated with the root project.

� Always select the root project before invoking Repository | View History. You will be warned if you do not do this.

� To revert to a previous version, all segments should be checked out, perform the sync (not to be confused with the Synchronize command found under the Project menu), and then check all segments in.

NOTE: You can revert to a previous version while all segments are checked in, but you will not be able to check out to make further changes.

� Rather than synch to a version of a segment that had a segment created in it, it is better to synch to the root version that was checked in after the segment was created. You may get warning messages that segments could not be found. If you accept these warnings, you will get your project without these segments. The segments can be restored by synching to a later version.

NOTE: When reverting to an earlier version, segments that were created after that version are not deleted from disk; they are simply no longer linked into the main project.

Page 26: IBM Cognos 8 Framework Manager - Enabling a Multi ...public.dhe.ibm.com/software/dw/dm/cognos/modeling/design/...IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer Environment 26

IBM Cognos Proprietary Information

� Do not delete a segment, and then create a new one with the same name. This may cause problems when tracking revision history.

5.1.8 Using the Synchronize Command with a Repository Project

NOTE: It is suggested you do not use the Synchronize command with repository projects. If you do so, keep in mind the following:

� After the Synchronize command is done, all repository information will be removed from the project. You must manually remove the old project from the repository, and then use Framework Manager to add the project back into the repository. All revision history information will be lost.

� When adding segments to a repository project that will be synchronized, do not use the feature on the Create Segment dialog that adds the segment to a repository. You must first create the segment, and then use the Add Project to Repository dialog instead. Synchronize will fail if it is not done this way.

� If you use the Revision History feature to revert to an earlier version, the log files for the revisions that should be removed are not deleted. Synchronize will execute these log files; therefore it will not correctly reproduce the revision that it should.

NOTE: You will have to manually identify and remove log files to make this work.


Recommended