Strategy Administrator - Object Manager is the component in the Strategy Product Suite that allows system administrators to conduct project life-cycle management. Schema objects, the building blocks of business intelligence and application objects that generate useful analytical information, can be transferred within or between projects of the same repository or different repositories. This document is intended to provide a general guidance to assist system administrators in evaluating the methodology best suited for the specific needs of their environment. It also provides some explanation on the design of the product and addresses questions that may arise during a Strategy Administrator - Object Manager operation.
Background information:
Strategy Product Suite utilizes the concept of Object ID or the Globally Unique Identifier (GUID). Each object: a report, a metric, a fact or a hierarchy is recognized by Strategy products base on its Object ID. Following this rule, Strategy Administrator - Object Manager compares the Object ID of the objects involved in an operation and determines the status of the objects. If an existing object is not found, the new object is duplicated. If an object of the same Object ID already exists in the designated location, conflict resolution is required.
It is important to note that certain hidden objects are involved in schema object operations. While Strategy Administrator - Object Manager is responsible for the integrity of these hidden objects, system administrators should have the knowledge of their existence. Examples of hidden objects include transformation attributes, columns and physical tables.
Schema objects are also interrelated with one another. An attribute, for example, maintains a reference of the parent and child attributes, hierarchies where it locates, tables and columns it uses and so on. These object references are transparent to the Strategy users. However, system administrators may find objects not involved in a Strategy Administrator - Object Manager operation updated. More details are provided in this document.
Prerequisite:
Strategy Administrator - Object Manager requires that two projects be related if a cross-project operation is desired. The projects can be in the same or different project sources. Each project is uniquely identified by an Object ID and version ID. In addition, a schema ID is assigned to each project to track the relationship between the projects. For example, if Project A and Project B are both duplicates of the same source Project C, Strategy Administrator - Object Manager can be used to transfer objects among the three projects.
Every newly created project has a different schema ID. Therefore, it is required that all projects are duplicates of one source project. The Duplication Wizard can be located at either Strategy Desktop or Strategy Administrator - Object Manager.
Database backup restores can be used instead of a project duplicated by the Strategy Project Duplication Wizard with certain restriction. In version 7.1.x and earlier versions, the duplicated project's name has to be modified for the two projects to be uniquely identified. In addition, no configuration objects, such as schedules and users, can be copied across two metadata. This is due to the fact that the two metadata have the same Configuration ID. Starting in version 7i- 7.2.x, the project description in Project Configuration can be changed instead of the project name. Furthermore, the restriction on the configuration objects can be removed by adding a new user to one of the projects.
Starting in version 9.0.2, System Object ID Unification was introduced. Object Manager migrations can be done between unrelated projects, as long as their System Objects ID's have been unified. Refer to the following technical note for further information about this feature:
KB34982: New feature in MicroStrategy 9.0.2: Perform System Object ID Unification
Setting up the environment:
Strategy customers are encouraged to maintain at least two environments: development and production. A test environment is also recommended if new or modified schema objects are transferred between the development and production environment. The test environment should be a duplicate copy of the production environment to simulate the exact procedure involved to promote the objects.
Database backup should be performed on the production environment before changes are made.
Supporting multiple warehouses:
Customers may use different warehouses for the development and production projects. This is a supported configuration as long as the warehouse tables have the same name and table structure.
When a new table is added to the development warehouse and the project's Warehouse Catalog, a logical table is created. This table can be used as a source table for an existing attribute/fact or a new attribute/ fact. When this object is ready to be transferred to the production environment, the system administrator first need to confirm the existence of the table in the production warehouse. The table should not be added to the production project's Warehouse Catalog. Doing so will create a new Object ID for a logical table of the same name. The system administrator should use Strategy Administrator - Object Manager to copy the schema object. The logical table from the development project will be copied to the production project as a dependent. If an existing schema object is in the production project, select 'Replace' in the Conflict Resolution Dialog.
Multiple sessions:
Object caches at the Strategy Intelligence Server and the client level are maintained by Strategy products to improve performance. At the client level, however, Strategy Desktop and Strategy Administrator - Object Manager do not share the object cache because they run in different processes. It is strongly recommended that only one session of Strategy - Object Manager is opened on the client machine at one time. For system administrators who wish to run reports in Strategy Desktop to confirm the objects' working status prior to object duplication, the Strategy Desktop project must be closed before the same project is opened in Strategy Administrator - Object Manager. If the issue persists in 3-tier mode, purge the server object cache from Strategy Desktop's Project Configuration caching tab as well.
Object duplication:
Strategy Administrator - Object Manager utilizes the Object ID of objects to maintain metadata integrity. System administrators can use the Conflict Resolution Dialog to determine the action required for each related object in the operation. When assessing the operation, it is important to note that several objects' version ID change in relation to other objects. For example, a logical table's version ID is changed if an attribute using the table is modified. Also, a fact's version ID is changed if the fact entry levels are recalculated upon schema update. If an object is saved and closed without change, the version ID is modified regardless. Version IDs are maintained and utilized by all Strategy products. Users do not need to be concerned if the version IDs are not consistent between the projects. The Conflict Resolution Dialog gives a good indication if an action is required.
Strategy Administrator - Object Manager checks for the object dependencies. As a result, it is not required that base objects, such as the attributes and metrics of a report, have to be duplicated before the report. Furthermore, multiple objects can be moved or copied at the same time.
Troubleshooting tips:
Strategy Administrator - Object Manager is an independent product in the Strategy Administrator suite. If a known issue is encountered in an older version of the product, the latest release of Strategy Administrator - Object Manager may be installed on a separate machine. When prompted to update the metadata for the latest properties, simply click on 'No'. The metadata can be updated at a later date when the Strategy Intelligence Server is upgraded. Please contact Strategy Technical Support to determine if installing a new Strategy Administrator - Object Manager will address the issue encountered.
Strategy Administrator - Object Manager requires the destination project to have the same metadata version than the source project. This means, if the system administrator updates the development project metadata when prompted, the production project metadata will also have to be updated before Strategy Administrator - Object Manager can be used to perform cross project operations.
Strategy Administrator - Object Manager discontinues the duplication process if one of the objects involved failed due to a metadata inconsistency or Strategy administrator - Object Manager issue. When this issue is encountered, system administrators should try to narrow down the object by copying fewer items at the same time. For example, copy a subfolder under the Reports folder instead of the entire Reports folder. This will provide valuable information when contacting Strategy Technical Support.
Please refer to Strategy Knowledge Base documents KB4200-007-0004 for details on Strategy Administrator - Object Manager features and functionalities. Every product release also includes a document on the issues and enhancements addressed. Additional documents are also available regarding specific issues one may encounter while using Strategy Administrator - Object Manager. Please contact Strategy Technical Support if further assistance is needed.
