Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 11g リリース1 (11.1.1) B63028-05 |
|
![]() 前 |
![]() 次 |
この付録では、マルチユーザー開発環境を使用する際のOracle BIリポジトリのライフサイクルの管理に関するベスト・プラクティスについて説明します。
マルチユーザー開発環境を使用してOracle BIリポジトリを構築すると、次のことが可能になります。
大規模で統合化されたセマンティック・モデルを構築できます。
複数の独立したセマンティック・モデルを個別に構築して、同一のOracle BIサーバーおよびプレゼンテーション・サービス・サーバーで稼働できます。
本番バージョンで緊急の不具合や機能拡張の要求に対応しながら、様々なスケジュールで複数のブランチを並列して開発できます。
個人レベルおよびチーム・レベルで、段階的に設計およびテストできます。
個別の開発者で管理可能なサブセットを相互に影響することなく設計およびテストできます。これらの変更は、段階的に管理され、他の開発者と共有できます。
テスト・システムまたは本番システムへの変更を、まとめてまたは段階的に移行できます。
この付録では、Oracle BIリポジトリの開発ライフサイクルについて説明します。ここでは、プレゼンテーション・サービスで使用されるOracle BIプレゼンテーション・カタログの開発ライフサイクルについては触れません。また、販売用の製品としてポータブルBIアプリケーションを構築する独立ソフトウェア・ベンダー(ISV)組織のマルチユーザー開発環境を使用する方法についても触れません。
一般的なビジネス・シナリオでマルチユーザー開発環境を使用する方法の詳細な例は、付録B「MUD事例: Eden Corporation社」も参照してください。
この付録のトピックは次のとおりです。
この項では、マルチユーザー開発を開始する前に計画フェーズの一環として実行する必要があるタスクについて説明します。
この項には次のトピックが含まれます:
共有リソースに関する決定を行い、多数の利害関係者間の衝突を解決するには、強力で効果的な管理プロセスを提供する必要があります。いかなるビジネス・プロセスでも強力なビジネス・スポンサーが必要であり、運営委員会には効率的に交渉を行い長期にわたり不変となる最適な決定を行うことができる強力なビジネス・パーソンが不可欠です。効果的な管理プロセスを持つということはOracle Business Intelligenceによるマルチユーザー開発を成功させるための唯一の最も重要な要素であることが立証されています。
マルチユーザー開発プロジェクトを開始する前に、表A-1の説明にあるように、まず、ビジネスの値、プロパティ、ロードマップおよび要件を設計し、さらに低レベルの詳細設計も行う必要があります。
表A-1 計画フェーズで実行するタスク
対象 | 必要なタスク |
---|---|
戦略的な要件 |
|
リポジトリ・オブジェクトのビジネス要件 |
|
セキュリティ要件 |
|
開発 |
|
プロジェクト管理 |
|
運用 |
|
この項では、リポジトリ開発およびそのライフサイクルにかかわる実際的なロールについて説明します。会社およびチームの大きさに応じて、それらのいくつかのロールを1人で務める場合もあります。
リポジトリ開発ロールには次のようなものがあります。
MUD開発者(各開発チームに1人+代替要員)
リポジトリ・パスワードの割当て
MUDプロジェクトの設定および保守
マスター・リポジトリ共有ディレクトリの管理
ブランチおよびブランチ・マージの管理
リポジトリの移行の管理
テストおよび本番の接続プールの管理
独立のセマンティック・モデルの管理(すべてのモデルでのメタデータの読取り/書込み権限の付与)
リポジトリ開発者(開発チームごとに多数)
リポジトリ・パスワードの認識
必要なすべてのOracle Business Intelligenceコンポーネントが含まれる個人の開発サンドボックスの所有、操作および保守
サンドボックス・スタック上でのユーザーおよびアプリケーション・ロール・プロビジョニングの管理
リポジトリの機能およびデータ認可コンテンツの作成
ユニット・テストの実行
必要に応じたチェックアウト、マージ、公開の実行
本番運用スタッフ
リポジトリ・パスワードの認識(接続プールの管理およびパッチの適用のため)
更新されたリポジトリの適用、および稼動中のBIサーバーのリポジトリへのXMLパッチの更新の適用
本番のコンピュータにログインしてOracle Business Intelligenceディレクトリの読取り/書込みまたはプログラムの実行が可能
リポジトリ・ディレクトリ、ログおよび構成ファイルを含む本番のファイル・システムの管理
本番サーバー(管理サーバー、Javaコンポーネントを含む管理対象サーバー、およびOracle BIサーバーやプレゼンテーション・サービスなどのOracle Business Intelligenceシステム・コンポーネント)の管理
本番のセキュリティの管理(ユーザー、グループおよびアプリケーション・ロールのプロビジョニングを含む)
本番のアプリケーション・ロールの管理および移行
本番の接続プールの管理(MUD管理者が本番の接続情報のセキュリティ権限を持たない場合)
リポジトリ開発チーム外部の他のロールのユーザーも関係します。その中には、テスト環境を管理してテストを実行するユーザー、およびOracle BIプレゼンテーション・カタログ開発者も含まれます。
MUDおよびリポジトリのライフサイクル管理のベスト・プラクティスを理解する前に、開発環境のアーキテクチャを理解する必要があります。
この項には次のトピックが含まれます:
この項では、マルチユーザー開発のシステムの開発およびデプロイに関連する基本的な概念について説明します。
Oracle BIリポジトリ
Oracle BIリポジトリは、開発時の基本的なアーティファクトです。これによって、ユーザー・リクエストの解釈、ロールベースのセキュリティの適用、データソースへの問合せの生成、および結果の後処理を行うために、Oracle BIサーバーで使用されるすべてのメタデータが定義されます。マルチユーザー開発環境で使用するリポジトリは、MDS XML形式ではなく、バイナリ(RPD)形式であることが必要です。
アプリケーション・ロールおよびポリシー・ストア
開発時の2番目のアーティファクトは、アプリケーション・ロールのセットです。リポジトリ・ロジックでは、これらのアプリケーション・ロールに対して、ユーザー・オブジェクト権限、データ・アクセス・フィルタ、および問合せ制限(ガバナー)が定義されます。プレゼンテーション・サービスもその権限および許可の割当てにアプリケーション・ロールを使用します。
Oracle WebLogic Serverに組み込まれたデフォルトのポリシー・ストアを使用することも、個別の外部ポリシー・ストアを使用することもできます。組込みポリシー・ストアを使用する場合、Fusion Middleware Controlでアプリケーション・ロールを定義します。これはOracle WebLogic Serverのポリシー・ストアに保持されます。ここで、オンライン・モードで管理ツールを使用して、設計時にポリシー・ストアからアプリケーション・ロールをリポジトリに追加できます。Oracle BIサーバーは実行時に各ユーザーにプロビジョニングされたアプリケーション・ロールを使用して、正しいセキュリティ権限をユーザー・リクエストに適用します。
リポジトリのインスタンスは、通常、一度に1人のリポジトリ開発者のみで編集されます。複数の開発者は、「プロジェクト」というリポジトリのサブセット・インスタンスで並列的に作業します。開発者は個別のサンドボックス環境で作業し、その変更を頻繁にマスター・リポジトリ・インスタンスにマージして変更を配信し、チーム内の他のユーザーが行った変更を取得します。このアプローチにより、大規模なエンタープライズ・アプリケーションを構築することが可能になります。また、独立のセマンティック・モデルは個々のチームで開発して、単一のOracle BIサーバー・クラスタの本番ホスト用のマスター・リポジトリにマージすることもできます。さらに、チームが主要なプロジェクトで並列に作業できるようにブランチおよびマージを行ったり、進行中の開発プロジェクトを中断することなく本番のメイン・コード・ラインに緊急の修正を行うこともできます。
開発サンドボックスをインストールする場合、通常は管理インストール・タイプを使用します。
単一の共有リポジトリ
プレゼンテーション・サービスは、Oracle BIサーバーにアップロードされている1つのリポジトリにのみ接続されます。すべてのセマンティック・モデルのメタデータは、セマンティック・モデルでオブジェクトを共有していなくても単一のリポジトリに存在する必要があります。リポジトリのセマンティック・モデルの詳細は、「マルチユーザー開発スタイルについて」を参照してください。
リポジトリ・パスワード
リポジトリ・ファイルはリポジトリ・パスワードで保護されます。Oracle BIサーバーでは、起動時にリポジトリを開くまたはロードする際にこのパスワードが必要です。リポジトリ・パスワードはセキュアな資格証明ストアに格納されます。管理ツールまたはその他のユーティリティおよびlineコマンドでリポジトリを開く際もこのパスワードを入力する必要があります。ログオンの資格証明は、資格証明ストアではなく、アイデンティティ・ストアに保存されます。
Oracle BIプレゼンテーション・カタログ
Oracle BIプレゼンテーション・カタログは、レポート、ダッシュボード、KPI、スコアカードおよびその他のレポート・レイヤー・オブジェクトを定義するメタデータが含まれる重要なBIアプリケーション・アーティファクトです。このドキュメントでは、Oracle BIプレゼンテーション・カタログについては触れません。Oracle BIプレゼンテーション・カタログの開発の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』のOracle BIプレゼンテーション・カタログのオブジェクトの管理に関する項を参照してください。
完成したリポジトリは、Fusion Middleware Controlを使用してテスト・システムおよび本番システムに移行されます。ローリング再起動でクラスタ化された本番のOracle BIサーバーをリフレッシュできるため、停止時間は不要です。
移行時のデプロイ・パラメータ
開発、テストおよび本番システム間でリポジトリを移行する場合、接続プール設定などの一部のリポジトリ・パラメータを変更する必要があります。これらのパラメータを変更するのは、それらがアプリケーション・ロジックではなくデプロイに基づいているためです。Oracle BIサーバーXML API (biserverxmlexec -B
)を使用すると、これらの更新を自動化できます。マルチユーザー開発時は、コンテンツをマージする開発者は、自動的にマスター・リポジトリ・テスト接続プールおよびデータベース・パラメータをローカル・ユニット・テスト・パラメータで上書きすることができなくなります。
アプリケーション・ロール(ポリシー・ストア)の移行
開発、テストおよび本番システム間でアプリケーション・ロールを移行するには、いくつかのオプションがあります。このドキュメントでは、簡潔にするために、少数のアプリケーション・ロール名を手動で再入力することにします。アプリケーション・ロールの移行の詳細およびその他の移行に関する検討事項については、『Oracle Fusion Middleware管理者ガイド』のOracle Business Intelligenceのターゲット環境への移行に関する項を参照してください。
ユーザーおよびアイデンティティ・ストア
設計時には、ユーザーをリポジトリのメタデータ・オブジェクトで表さないことをお薦めします。また、リポジトリでは資格証明を管理または保存しません。そのかわり、実行時環境では常にユーザーをアプリケーション・ロールにプロビジョニングして、ユーザーが権限を受信する必要があります。ユーザーの資格証明およびグループを介したアプリケーション・ロールへのユーザーのマッピングは、外部のアイデンティティ・ストアで管理されます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』を参照してください。
管理ツールおよびユーティリティの環境の設定
現在のディレクトリ構造では、メタデータ、データおよび構成ファイルの配置が一般化されます。そのため、起動する各プログラムまたはユーティリティには、そのプログラムが属するOracleインスタンスの構成の初期設定が必要です。コマンドライン・ユーティリティでは、まずbi-init
ユーティリティを起動してパラメータを設定してから、bi-init
ウィンドウ内のコマンドラインからユーティリティを起動します。管理ツールを含むほとんどのOracle BIサーバー・ツールでは、bi-init
ユーティリティを透過的に実行します。最初にインスタンス環境を設定せずにコマンドを実行すると、通常、プログラムは外部ファイルを検索できなくなります。
詳細は、「Oracleインスタンスに初期化したシェル・ウィンドウを起動するためのbi-initの実行」を参照してください。
開発のスタイルは、チームのサイズ、チームおよび並列のイニシアティブの数、およびセキュリティおよび可用性の要件に応じて選択します。表A-2に、マルチユーザー開発のスタイルを示します。
表A-2 マルチユーザー開発のスタイル
スタイル | 説明 |
---|---|
シリアル開発(図A-1) |
開発者が少数で同時実行性が低い場合、この方法を使用できます。開発ユーザーは、電子メール、共有ディレクトリまたは共有開発システムを介してリポジトリ・ファイルを共有し、一度にそのうちの1つのみで変更を行います。これらは、開発スケジュール上で相互に調整する必要があります。 |
パッチ・ファイルによるシリアル開発(図A-1) |
シリアル開発のバリエーションとして、ベース・バイナリ・リポジトリを共有し、パッチ・ファイルを使用してユーザー間にのみ変更を送信できます。 |
共有オンライン開発(図A-2) |
一度に1人の開発者のみが単一のOracle BIサーバーとそのリポジトリに対してオンライン・モードでメタデータを開発するということをお薦めします。ただし、チーム・メンバー間で頻繁にコミュニケーションがあり、高い競合リスクも許容可能で、管理オーバーヘッドを最小限にすることが目標であるような開発環境では、複数のオンライン・ユーザーで開発することも選択できます。 |
MUD (図A-3) |
マルチユーザー開発機能により、1つの共有エンタープライズ・リポジトリで、100名を超える開発ユーザーが平行して作業できます。各ユーザーは、メタデータの管理可能なサイズのサブセットのみを使用して個別のサンドボックス環境で開発およびユニット・テストを実行できます。1つの作業ユニットが完了したら、それを自動的にブランチにマージして公開できます。そこで、他のユーザーはそれらの変更を取得してそれらを自分のメタデータと統合できます。プロジェクト・フェーズのプロモーションの準備が整ったら、MUD管理者がそれをテスト環境に、そして最終的に本番に移行します。MUD管理者は、ブランチおよびサブブランチを管理して独立したイニシアティブまたは修正の平行開発を可能にし、それらをメイン・ブランチにマージし、テストおよび本番環境にそれらを増分移行します。MUD管理者は、ファイングレイン「プロジェクト」も管理する必要があります。これは、個別の開発者がローカル・サンドボックス環境にチェックアウトする管理可能なサイズのリポジトリ・サブセットです。詳細は、「マルチユーザー開発環境の概要」を参照してください。 |
単一の統合されたエンタープライズ全体モデルではなく、複数の独立したセマンティック・モデルが必要なケースがあります。これはセキュリティ要件により、または業務上無関係の部署間で共通のOracle Business Intelligenceインフラストラクチャを共有している場合に、一般的に発生します。MUD管理者は各モデルにブランチを作成します。これにより、各チームのセマンティック・モデルで並列開発と統合テストが可能になります。独立のセマンティック・モデルのブランチで本番へのプロモーションの準備ができると、MUD管理者は簡単にブランチをメインにマージできます。MUD管理者は、各開発者が割り当てられたセマンティック・モデルのみを参照できるように、またMUD管理者および選択された本番運用スタッフのみが統合されたメイン・モデルにアクセスできるように、ブランチのセキュリティを設定できます。 |
|
独立のセマンティック・モデルが様々なスケジュールで様々な組織により開発されている場合、中心となるMUD管理者は望ましいローカル管理レベルを提供できないことがあります。その場合、それぞれの独立なセマンティック・モデルのブランチに専用のMUD管理者を用意することができます。ブランチ管理者は、通常のMUD管理者と同様に操作を行います。 このシナリオでは、MUDスーパー管理者が各組織のブランチを定義し、サブセット・リポジトリをチェックアウトして、それをブランチ管理者に提供します。モデルの本番へのプロモーションの準備が整ったら、ブランチ管理者はリポジトリをスーパー管理者に戻します。スーパー管理者はそれをプロモーション用のメイン・ブランチにマージして、組み合せたリポジトリを本番に移行します。 |
図A-1 マルチユーザー開発のシリアル開発スタイル
図A-2は、マルチユーザー開発の共有オンライン開発スタイルを示します。
図A-3は、ブランチによる実際のマルチユーザー開発を示します。
図A-4は、複数の独立したセマンティック・モデルを含むリポジトリのアーキテクチャを示します。
表A-3は、様々なセキュリティおよび可用性の要件を満たすマルチユーザー開発スタイルを示します。
表A-3 マルチユーザー開発スタイルで満たされる要件
要件 | シリアル | 共有オンライン | 単一のセマンティック・モデルを含むMUD | 複数のセマンティック・モデルを含むMUD | 委任管理を含むMUD |
---|---|---|---|---|---|
開発者なし |
はい |
いいえ |
いいえ |
いいえ |
いいえ |
最大5人までのコンカレント開発者 |
いいえ |
はい |
はい |
はい |
はい |
5人を超えるコンカレント開発者 |
いいえ |
いいえ |
はい |
はい |
はい |
Oracle BI Applicationsなどの大規模なリポジトリの管理可能なサブセットでの作業 |
いいえ |
いいえ |
はい |
はい |
はい |
組込みのチェックアウト、マージおよびロールバック |
いいえ |
いいえ |
はい |
はい |
はい |
単一のリポジトリでの独立なセマンティック・モデルのホスト |
はい |
はい |
いいえ |
はい |
はい |
作業ユニットから本番への段階的な移行 |
いいえ |
いいえ |
はい |
はい |
はい |
独立なセマンティック・モデルの開発者は相互のメタデータを参照できない |
いいえ |
いいえ |
いいえ |
可脚注 1 |
可脚注 1 |
独立の各セマンティック・モデルには独自のMUD管理者がいる |
いいえ |
いいえ |
いいえ |
いいえ |
はい |
脚注 1 セキュアMUDディレクトリが必要です。MUD全体管理者は、すべてのチームのすべてのメタデータへのアクセス権を持つ必要があります。
MUDを使用する場合、それぞれの開発者は独自の専用のサンドボックスOracle Business Intelligenceシステムで作業します。開発およびユニット・テストに必要なすべてのコンポーネントが含まれるようにサンドボックスを設定する必要があります。
最初に、Oracle Business IntelligenceスタックにUNIXとWindowsのどちらのサーバーを使用するか決定する必要があります。次のガイドラインに従ってください。
Windows専用オプションを選択する場合、システムに十分なメモリーがあることを確認してください。同じハードウェア上でデータベースをホストするように選択すると、さらにリソースが必要になります。ハードウェアの最小要件の詳細は、「システム要件と動作要件」を参照してください。
UNIXオプションを選択する場合でも、管理ツールを実行するためにWindowsシステムが必要になります。UNIXシステムではOracle Business Intelligence簡易インストール・タイプを使用し、Windowsシステムではクライアント・インストール・タイプを使用して管理ツールをインストールします。
オンライン・モードでは、Oracle BIサーバーはUNIXシステム上の次のローカル・リポジトリ・ディレクトリからリポジトリをロードします。
ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/coreapplication_obisn/repository
Windows上の管理ツールでもデフォルトでローカル/リポジトリ・ディレクトリが指定されていますが、オフライン開発では任意のディレクトリを使用できます。
また、開発データベースもインストールする必要があります。このデータベースは、専用データベース、個人データベース、または複数のリポジトリ開発者で共有できるデータベースを指定できます。開発データベースについては、次の点に注意してください。
プラットフォーム: 十分なメモリーがある場合、サンドボックス・コンピュータで開発データベースをホストするように選択できます。また、中央に配置された共有サーバーでこれをホストすることもできます。図A-5に両方のシナリオを示します。
RCU: データベースには、Oracle Business Intelligenceで必要なスキーマを格納する必要があります。スキーマは、リポジトリ作成ユーティリティ(RCU)を使用してロードします。それらのスキーマにより、Oracle BIスケジューラおよびOracle Scorecardと戦略管理の注釈をサポートできます。また、使用状況トラッキングのサンプル表が用意されているほか、多数の機能を使用できます。Oracle Business Intelligence用Oracle WebLogic Server管理対象サーバーとそれに依存するすべてのサーバーでは、必要なRCUスキーマで操作するために稼働中のデータベースにアクセスする必要があります。
データソース・スキーマ: 開発時のメタデータにもデータソース・スキーマが必要です。オプションでRCUデータベースにデータソース・スキーマを含めることもできます。データソース・スキーマについて次の追加情報にも注意してください。
テスト・データ: データソース・スキーマはテスト・データとともにロードする必要があります。ユーザーが読取り専用メタデータをテストする場合、複数の開発サンドボックス間でスキーマを共有できます。十分なメモリーが使用可能であれば、開発サンドボックス・コンピュータにそれらを配置できます。
複数のソース: オプションで、他のリレーショナル・ソース、Essbase、Hyperion Financial Management、Microsoft Analysis Services、SAP B/Wなど、自身のイニシアティブに必要な複数のデータ・ソースを環境に含めている場合があります。これらのソースは、共有でも専用でも、ローカルでもリモートでもかまいません。
接続: 管理ツールおよびOracle Business Intelligenceスタックからそれぞれのデータソースへの接続を設定する必要があります。この構成には、必要なドライバまたはクライアントのインストール、ODBC DSNの設定、ネイティブ接続の設定およびその他の手順を含めることができます。詳細は、第5章「メタデータのインポートとデータ・ソースの操作」および第16章「LinuxおよびUNIXでのデータソースの設定」を参照してください。
Oracle Database接続の場合、Oracle Business IntelligenceにはORACLE_HOME/network/adminにTNSnames.oraのインスタンスが必要です。
図A-5に、マルチユーザー開発サンドボックスのアーキテクチャを示します。
注意: ほとんどの開発者は、開発サンドボックスのキャッシュを無効に設定しています。そうすることで、ログを使用して物理問合せを検証およびデバッグしやすくなります。キャッシュが有効な場合、リクエストがキャッシュで実行されている場合があるので、物理SQLがログに記録されないことがあります。このリリースでは、Fusion Middleware Controlを使用してキャッシュを無効にする必要があります。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のFusion Middleware Controlを使用した問合せキャッシュの有効化および無効化に関する項を参照してください。 |
MUD全体のアーキテクチャには、前の項で説明されている開発者サンドボックス・システム、およびテスト・システムおよび本番システムが含まれる必要があります。また、次のようないくつかの追加の主要コンポーネントがあります。
Windows MUD管理システム。このシステムは、MUD管理者により保守されます。このシステムについては、次の点に注意してください。
これには、メイン・ブランチの1つの共有ネットワークMUDディレクトリ、および各サイド・ブランチの追加の共有ネットワークMUDディレクトリが用意されています。各共有ディレクトリのWindows権限のみで開発者のそのブランチへのアクセスを許可します。各共有ディレクトリには、そのブランチのマスター・リポジトリ、およびMUD機能の様々なコントロールおよび履歴ファイルが保存されます。
これには、Oracle Business Intelligenceのクライアント・インストールがあります。管理ツールおよびOracle BIサーバー・ユーティリティは、MUDプロジェクトの作成および管理、マージの実行、パッチの作成、およびその他のMUD管理者タスクに使用されます。その他のOracle BIサーバーなどのOracle Business Intelligenceプロセス、ポリシー・ストアおよび資格証明ストアは、一般的にはこのプラットフォームでは使用されません。
このコンピュータ上では、Oracle Business Intelligence Javaコンポーネント、システム・コンポーネント、他のインフラストラクチャのいずれも使用されないので、32ビット・システムでも64ビット・システムでも使用できます。
1つ以上のテスト・システム。これらのシステムは、マージされたコンテンツの統合テストを実行するために使用されます。ここでは、完全なOracle Business Intelligenceスタックが実行され、UNIXベースでもWindowsベースでも稼働します。これらのシステムは柔軟にクラスタ化されます。
Oracle BIプレゼンテーション・カタログ・システム。オプションで、Oracle BIプレゼンテーション・カタログのコンテンツを開発するために、完全なOracle Business Intelligenceスタックを持つシステムを構築することもできます。
クラスタ化された本番システム。最終的には、サポートされるOracle Business Intelligenceプラットフォームのいずれかでクラスタ化された本番システムを構築します。
外部アイデンティティ・ストア。これは、Oracle Internet Directoryなどの外部アイデンティティストアを使用することを想定しています。
図A-6は、マルチユーザー開発環境を使用したリポジトリ・ライフサイクルのサンプル・デプロイ・アーキテクチャを示します。
MUDは、リポジトリ・モデル内の相互関係および依存性が複雑であっても、開発者のチームによる任意のサイズのプロジェクトで並列作業を実現できる機能のセットです。次の処理を実行できます。
リポジトリ・ファイルのサブセットへの分割
リポジトリが大規模な場合、ユーザーは管理可能なサブセットで作業できます。
各開発者またはチームでサブセットごとに独立にテストできます。
ブランチ・サブセットをチェックアウトした後でマージが管理しやすくなります。
独立のセマンティック・モデルを開発用のセキュアなブランチに分割できます。
段階的な開発、テストおよび移行
ユーザーの変更間の競合に対処するサブセットおよびブランチのマージ
変更を終えてパッケージ化されたBIアプリケーションへのOracle更新の適用
個別に開発されたアプリケーションの単一のリポジトリへのマージ
履歴ログおよび監査情報へのアクセス
過去のリポジトリ状態へのロールバック
マルチユーザー開発機能には、その他にも次のような有用な機能があります。
マスターへのマージの調整(元のリポジトリ・ファイルの追跡など)
ロックを使用した確実な更新
変更のログへの記録
破損が発生する可能性のある各操作の前の、リポジトリの自動バックアップ
この項には次のトピックが含まれます:
複数のユーザーでの基本的な作業フローは次のとおりです。
開発者は、「初期」物理レイヤーおよび基本ファクトおよびサブジェクト・エリアを定義します。これにより、MUDプロジェクトをアンカーするためのいくつかの基本オブジェクトを指定します。
MUD管理者はプロジェクトを定義し、RPDをメイン・ブランチのMUDディレクトリに配置します。マスター・リポジトリが格納されるMUDディレクトリは、Oracle BIサーバー・ローカル・リポジトリ・ディレクトリと同じにすることはできません。
これで、開発者は1つ以上のプロジェクトをチェックアウトして、開発作業を実行し、変更をMUDディレクトリに公開することでマスターにマージできます。
その間に、他の開発者は、同じプロジェクトまたは別のプロジェクトをチェックアウトして開発作業を行います(プロジェクトは、サブセット用のものであり、セキュリティを適用するためのものではありません)。公開手順では3方向マージを使用するため、ユーザーは変更のチェックアウト、開発、公開を任意の順序で実行できます。複数のユーザーによる1つのオブジェクトに対するプロパティの変更もマージできます。ユーザー間で競合が発生した場合、3方向マージ機能では開発者がどのオブジェクトを保持するのかを選択できます。競合の回避および解決にはユーザー間のコミュニケーションが重要であり、そのような競合を回避するために、管理プロセスによって主要なオブジェクトの所有権が割り当てられるようにする必要があります。
開発フェーズを完了したら、MUD管理者はコンテンツをテスト・システムに移行できます。チェックアウト、不具合の修正、公開および再テストの順に何回か繰り返す場合があります。リポジトリがテスト・フェーズに合格したら、MUD管理者はそれを本番環境に移行できます。
MUD管理者は、複数の開発ブランチを大きなMUDプロジェクトとして作成および管理できます。ブランチは1つの開発チームのみで作業するように保護できます。ブランチは、独自の委任MUD管理者により、メインとして再帰的に処理することもできます。
マルチユーザー開発機能は、プロジェクトというメタデータ・オブジェクトの周辺で構築されます。プロジェクトとは、マスター・リポジトリからのチェックアウト、およびその後のマージおよび公開までの単位です。マスター・リポジトリが大規模になると、プロジェクトは開発者がチェックアウトして作業できる程度の管理可能なサイズのサブセットになります。これは、整合性チェッカ(コンパイル時のコードのチェックのようなものです)を実行して、Oracle BIサーバー上でアンサーなどのクライアントにより実行時にそれをテストできるように、自己完結型に設計されています。結果に満足であれば、それをマスター・リポジトリにマージしなおして、大きなアプリケーションの一部にすることができます。一方、履歴はログに記録され、リポジトリ・バックアップは主要な時点で自動的に作成されます。
管理ツールのMUD機能では、ファイングレイン開発者プロジェクトに対してこのフローを合理化します。同様に、スーパーセット・プロジェクトでもブランチの管理およびマージを合理化します。
プロジェクト・サブセットには、メタデータ・オブジェクトのセットが含まれます。オブジェクトの最小セットを明示的に含めるようにプロジェクトを定義しますが、その他の多数のオブジェクトは暗示的に含まれます。オブジェクトを暗示的にプロジェクトに追加することで、プロジェクト管理タスクが単純化されます。
次のオブジェクトは、MUD管理者によりプロジェクトのメンバーとして明示的に指定されます。
論理ファクト表
プレゼンテーション・レイヤーのサブジェクト・エリア
アプリケーション・ロール
ユーザー(ただし、RPDロジックでアプリケーション・ロールのみを使用することをお薦めします)
初期化ブロック
変数
その他すべてのオブジェクトはプロジェクトに暗示的に含まれており、チェックアウト処理時に管理ツールで表示されます。例:
明示的に定義されたオブジェクトの子孫。たとえば、論理ファクト表が明示的に含まれる場合、そのすべての論理列もプロジェクトに暗示的に含まれます。
選択された論理ファクト表に結合された論理ディメンション表および結合オブジェクト自身。
含まれている論理ファクト表およびディメンション表の論理表ソース。
プロジェクトに含まれる論理表にマップされた物理表およびそれらの間の結合。
マーケティング・ターゲット・レベルおよびリスト・カタログ。
明示的に定義されたオブジェクトのリストにあるオブジェクトは、暗示的に含まれる場合もあります。たとえば、論理列の式に変数が含まれる場合、MUD管理者が明示的にそれを追加しなくても、その変数はプロジェクトに暗示的に含まれます。
プロジェクトは重複しても問題ありません。1つのプロジェクトに表示されるオブジェクトが、別のプロジェクトにも表示されても問題ありません。たとえば、独立したセマンティック・モデルごとに全体的なプロジェクトを作成するとともに、個別の開発作業ユニットをチェックアウトするために、各独立モデル内により小さいプロジェクトを作成することを好む顧客が存在します。複数のプロジェクトを同時にチェックアウトし、より大きなセットのメタデータで作業することもできます。
詳細は、「プロジェクトの設定」も参照してください。
この項では、ブランチ、サイド・ブランチおよび委任管理ブランチの作成方法について説明します。
この項には次のトピックが含まれます:
最終的なマスター・リポジトリは、通常、メイン・ブランチでソースが管理され、すべてのブランチ、さらに最終的にはすべての開発プロジェクトは、そこからチェックアウトします。通常、メイン・ブランチは本番でリポジトリをステージングします。つまり、コンテンツを本番に移行するには、それをメイン・ブランチに移行してから、メイン・リポジトリを本番システムに移行します。
同様に、本番の不具合を修正するには、通常、開発者はメイン・ブランチからチェックアウトします。開発者は不具合を修正すると、それをテストおよび本番への移行用のメイン・ブランチにマージしなおします。一方、サイド・ブランチの並列開発には影響しません。
MUD管理者としてメイン・ブランチを作成するには、まず共有ディレクトリを作成して、マスター・リポジトリ・ファイルをそこにコピーする必要があります。ディレクトリはWindowsまたはUNIX上のいずれに配置してもかまいませんが、UNIX共有の場合はWindowsユーザーがアクセスできるようにする必要があります。
適切な開発者のみにアクセスを許可するように共有上にセキュリティを設定します。要件に応じて、メイン・ブランチ・マスター・リポジトリではなく、サイド・ブランチ・マスター・リポジトリのみに開発者のアクセスを許可することもできます。
これが新規プロジェクトの場合、一般的には、ブランチ・プロジェクトに容易に分割できる初期コンテンツでリポジトリをシードするように開発者に指示します。
ブランチを使用する場合、スーパーセットMUDプロジェクトで開始して、MUDチェックアウト、マージおよび公開機能を使用することをお薦めします。そこで、個々のユーザーまたはサブブランチでファイングレイン・プロジェクトを使用してブランチ・マスターからチェックアウトします。この機能のMUDを使用すると、チェックアウト・ポイントで自動バックアップが提供され、元のリポジトリが追跡されて正しいマージが確保され、ユーザーの介入が少なくて済む、より楽観的なマージの想定を使用して、履歴およびロールバックを使用できます。
MUD管理者としてサイド・ブランチを作成する手順は次のとおりです。
メイン・マスター・リポジトリで、ブランチに必要なすべてのコンテンツを抽出するプロジェクトを作成します。次のガイドラインに従ってプロジェクトを作成します。
リポジトリにメタデータがほとんど(またはまったく)設計されていない場合、プロジェクトをアンカーできるコンテンツでそれをシードすることをお薦めします。そうすることで、論理ファクト表のサポートに必要な物理コンテンツをプロジェクトで抽出しやすくなります。通常は、少なくともいくつかの代表列が含まれる1つ以上の論理ファクト表を作成するということになります。列はファクト表のサポートに必要な物理表および結合にマップする必要があります。最後に、プロジェクトを作成して、それに属するオブジェクトを定義します。
コンテンツがすでに存在している場合、プロジェクトを作成し、そのブランチで必要なオブジェクトを定義します。ブランチは、必要に応じて他のプロジェクトと重複することができます。
また、チェックアウト用に空のプロジェクトを作成することもできます。ただし、開発者がそれをチェックアウトする場合、プロジェクトに暗黙的に追加する必要があるすべての物理オブジェクトは、変更を公開する前に論理ファクト表にマップされるようにする必要があります。同様に、開発者は変更を公開する前にディメンションが結合されてそれが確実に組み込まれていることを確認し、サブジェクト・エリア、変数、初期化ブロック、アプリケーション・ロールおよびユーザーを明示的に追加する必要があります。この方法は、プロジェクトをシードしてからそれを定義する方法よりエラーが発生しやすくなります。
通常、本番などの環境の接続プールは、保護される必要があります。マスター・リポジトリの接続プール設定は、必ず開発者がアクセスできるようにします。通常、開発者はそのローカル・テスト・データベースに適合するように設定を変更します。変更を公開するときには、マスター・リポジトリでの設定の上書きを回避するため、接続プールおよびデータベース設定はマージされません。
本番および他の環境への移行時に必要な接続プールの変更を自動化するには、Oracle BIサーバーXML APIを使用します。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンスのテストから本番環境への移行に関する項を参照してください。
ブランチのMUDディレクトリを作成します。各ブランチには、それぞれ独自のMUDディレクトリを持つ必要があります。そのブランチで作業する開発者のみがそれにアクセスできるように権限を設定します。
開発者が他のチームに属するメタデータを参照できないように、ブランチ権限をプロジェクト・サブセットと組み合せて使用することができます。あるチームに関連するメタデータのみが抽出されるように、プロジェクトを注意深く設計します。チームで、異なるビジネス・モデル、サブジェクト・エリア、物理モデル、変数、初期化ブロックおよびアプリケーション・ロールを使用している場合、この目標は最も実現しやすくなります。
また、ブランチの命名および採番に一貫したシステムを使用することもお薦めします。
「ファイル」→「マルチユーザー」→「チェックアウト」を選択して、ブランチ・プロジェクトをチェックアウトします。これは、ローカル・リポジトリ・ディレクトリやその他のディレクトリにチェックアウトできます。
リポジトリをブランチMUDディレクトリにコピーします。これは、マスター・リポジトリとして機能します。
開発者がブランチからチェックアウトするためのファイングレインMUDプロジェクトを定義します。開発用のブランチの準備ができたことを開発者に通知します。
プロジェクト計画に基づいて、開発者が開発およびユニット・テストを完了すると、その変更の最終マージおよび公開を実行します。
フェーズで計画されたすべてのコンテンツの変更が公開されると、ブランチ・プロジェクトに統合テストを実行する準備が整います。これを実行するには、ブランチ・マスター・リポジトリ・ファイルをテスト環境に移行します。不具合が見つかると、割り当てられた開発者は適切なプロジェクトをチェックアウトして、不具合を修正してから、メタデータをテストします。変更を公開したら、ブランチ・リポジトリを再度テスト環境に移行します。このブランチ・プロジェクトは他のブランチの開発作業に影響することも影響されることもなくテストできます。
統合テストが完了すると、ブランチは本番にプロモートする準備が整います。ユーザーが変更できないように、ブランチ・マスター・リポジトリをブランチ共有ディレクトリから削除します。それをローカル・リポジトリ・ディレクトリにコピーしなおして、管理ツールを使用してそれをメインにマージします。これでメインは統合テストおよび本番に移行する準備が整います。
一般的には、MUD管理者は再度ブランチをチェックアウトして、次の開発フェーズ用のブランチ・リポジトリを共有ディレクトリに配置します。チェックアウト中は、他のブランチからの変更またはメイン・ブランチからの不具合の修正は、ブランチ・リポジトリで取得されます。
ブランチを使用して、メタデータ・サブセットを管理および保守する組織にそのローカル管理を委任できます。そのためには、ブランチMUD管理者をブランチに割り当てます。ブランチMUD管理者はメインMUD管理者と同じロールを実行します。メタデータが他のグループと重複しないような独立のセマンティック・モデルでは、このアプローチが最適に機能します。
委任ブランチMUD管理者は、詳細ブランチのプロジェクトの定義や開発者用のファイングレイン・プロジェクトの作成などを含め、メイン・ブランチ管理者と同じタスクを実行します。
メインMUD管理者として委任管理ブランチを作成する手順は次のとおりです。
メインMUD管理者(およびメインMUD管理者の代替要員)のみがアクセス権を持つようにメインMUDディレクトリに権限を設定します。
前の項で説明されているように、ブランチMUDプロジェクト、ブランチMUDディレクトリ、およびチェックアウトされたブランチ・マスター・リポジトリを作成します。
メインMUD管理者および委任ブランチMUD管理者がアクセス権を持つようにブランチMUDディレクトリにセキュリティを設定します。
ブランチ管理者は、詳細ブランチのプロジェクト、および開発者用のファイングレイン・プロジェクトを定義します。必要に応じて、ブランチ管理者は開発イニシアティブの委任ブランチ以外の追加ブランチを、開発者がそのリポジトリにチェックアウトできるように権限を設定してデプロイします。
個々の開発者は、メイン・ブランチへのアクセスが許可されていないため、委任ブランチMUDディレクトリからチェックアウトして本番の不具合を修正します。
開発者がすべての変更を公開したら、ブランチ管理者は統合テスト用の委任ブランチにそれらのブランチをチェックインします。
統合テストが完了した後に委任ブランチを本番にプロモートするには、メインMUD管理者は次の2つの手順を実行します。
委任ブランチ・リポジトリ共有ディレクトリからブランチ・マスター・リポジトリを削除して、管理ツールを使用してそれをメイン・ブランチにチェックインしなおします。
メイン・ブランチ・マスター・リポジトリを本番に移行します。
通常、メインMUD管理者はブランチを再度チェックアウトして、次の開発フェーズ用の委任ブランチ共有MUDディレクトリにブランチ・リポジトリを配置します。ブランチ管理者は次のレベルのブランチをチェックアウトしてブランチ共有MUDディレクトリにリポジトリを配置することで、開発者がファイングレイン・プロジェクトをチェックアウトして作業を開始できるようにします。
様々な状況や環境に対して最適化される様々なマージ・ツールがあります。使用するマージ・アプローチおよびユーティリティを決定する場合、WindowsまたはUNIXシステムでタスクを実行する必要があるかどうかを検討する必要があります。また、セマンティック・モデルに加えた変更をマージする必要があるかどうか、様々な開発の取組みから2つのセマンティック・モデルを組み合せる必要があるかどうかなどの要件も検討する必要があります。
表A-4は、様々な要件を満たすマージ・アプローチおよびツールを示します。
表A-4 様々なマージ・アプローチで満たされる要件
要件 | マージ・アプローチ | 使用するツール | プラットフォーム |
---|---|---|---|
|
3方向マージ |
|
Windows |
|
3方向マージ |
|
Windows |
|
3方向マージ |
|
|
|
2方向マージ |
|
Windows |
|
挿入-更新-削除 |
|
すべて |
|
挿入-更新-削除 |
|
Windows |
マージの詳細は、「リポジトリのマージ」を参照してください。
この項では、マルチユーザー開発環境で作業する上でのヒントおよびベスト・プラクティスについて説明します。
この項には次のトピックが含まれます:
次のガイドラインに従って、サイド・ブランチを作成します。
マスター・リポジトリが格納されるMUDディレクトリは、Oracle BIサーバー・ローカル・リポジトリ・ディレクトリと同じにすることはできません。
ブランチはチェックアウトされたMUDプロジェクトにします。そうすることで、正しい元のリポジトリの使用などの、ブランチをメイン・ブランチにマージしなおすタスクの多くが自動化および合理化されます。
チェックアウトされたブランチ・マスター・リポジトリは、必ず独自のMUDディレクトリに配置します。開発者には、そのブランチ・マスター・リポジトリからファイングレイン・プロジェクトをチェックアウトするように指示します。ブランチの開発、公開およびテストが完了したら、ブランチ・リポジトリ・ディレクトリからマスターを削除し、管理ツールを使用してそれをメイン・ブランチ・マスター・リポジトリに公開しなおします。そこで、それを再度チェックアウトして次のフェーズの開発用にブランチMUDディレクトリに新しいバージョンを配置します。
ブランチMUDディレクトリのWindows権限を使用して、それにアクセスできる開発者を制御します。
ブランチMUDディレクトリに.optファイルを作成して、マルチユーザー開発オプションを設定します。特定の管理者を定義して、整合性チェックを必須にするおよび「マージ中に等化」を「はい」に設定することをお薦めします。詳細は、「マルチユーザー開発オプションの設定」を参照してください。
本番に配信する機能の増加分に応じて、ブランチを計画します。各ブランチには、ユニットとして移行する増加分を含めるようにします。
誤った順序でブランチをマージしてしまったら、MUD履歴を使用してそれをロールバックすることができます。詳細は、「マルチユーザー開発の履歴の表示と削除」を参照してください。
次のガイドラインに従って、プロジェクトを設定します。
RPDを便利に使用できるようになるべく小さくファイングレイン・プロジェクトに分割します。そうすることで、パフォーマンスが向上し管理が容易になります。
論理ファクト表を小さなパーティーションに分割して、小さな個別のプロジェクトを使用できるようにします。
各サイド・ブランチで、ブランチのコンテンツを抽出する大きなプロジェクトをオーバーレイします。そうすることで、プロジェクトで、元のリポジトリの追跡を含め、ブランチのチェックアウトおよびマージの管理が可能になります。個々の開発者は、チェックアウトしたブランチ・プロジェクトから開発プロジェクトをチェックアウトできます。すべての開発プロジェクトは、それをメイン・ブランチにマージしなおす前にサイド・ブランチに公開しなおす必要があります。
新しいコンテンツをリポジトリに追加する場合、必ずそれがプロジェクトの一部であることを確認してからチェックインしてください。プロジェクトの一部でないオブジェクトを作成および公開すると、次にそのプロジェクトをチェックアウトするときに、抽出対象に含まれなくなります。その場合、管理者またはMUD管理者はリポジトリ全体、または新しいコンテンツがたまたま含まれていた別のプロジェクトを最低でもいくつかは編集し、オブジェクトをそのときのプロジェクトに追加する必要があります。
複数のプロジェクトを同時に抽出して、必要なすべてのコンテンツを取得する必要がある場合があります。
ヒント: サブジェクト・エリア、プレゼンテーション表、プレゼンテーション階層などのプレゼンテーション・レイヤー・オブジェクトが、ここでプロジェクトに明示的に含めるオブジェクトになります。以前のリリースと異なり、管理ツール・ユーザーのセキュリティ設定は、チェックアウトするときにプロジェクトに含まれるサブジェクト・エリア、プレゼンテーション表またはプレゼンテーション列には影響しません。そのかわり、プレゼンテーション・レイヤー・オブジェクトのセットで、プロジェクトの有効範囲が決定されます。 |
詳細は、「プロジェクトの設定」を参照してください。
3方向マージを実行する場合は、次のガイドラインに従います。
変更されたリポジトリと現在のリポジトリの両方の構築元のリポジトリがあることを確認します。
この手順は、MUDマージで自動的に実行されます。
一般的には、現行用としてに開発リポジトリを開き、変更済としてメイン・リポジトリを使用し、オリジナルとしてブランチの開始点を使用します。
マージする前にユニット・テストを実行します。
リポジトリ・マージ・ウィザードでは、「マージ中に等化」と「マージされたRPDの整合性のチェック」を選択することをお薦めします。オブジェクトの等価の重要性の詳細は、「オブジェクトの等化」を参照してください。
MUDマージを実行する場合は、次のガイドラインに従います。
マージする前にユニット・テストを実行します。
マージ後(ただし公開前)にユニット・テストを実行します。マスター・リポジトリ上でロックを保持することになるので、簡潔に実行してください。
「ツール」→「オプション」→「マルチユーザー」タブで、自分のフルネームが正しいことを確認します。そうすることで、誰がロックを保持しているかログに記録されチェックできるようになります。
変更を公開するときは、「ロック情報」画面に、役に立つコメントを必ず書き込んでください。後で自分自身または他の管理者がロールバックまたは他のタスクを実行する必要がでてきた場合、そのコメントを使用してリポジトリの履歴を特定しやすくなります。
MUD管理者がマスターRPDを編集しているときは、チェックアウト・ユーザーがそれにアクセスできないようにする必要があります。このようにするために、共有ディレクトリからそれを一時的に削除してから別のディレクトリに配置したり、編集前にその名前を変更できます。編集が完了したら、必ずそれを元に戻してください。
また、リポジトリをオフライン・モードで開いて、他のユーザーをWindowsファイル・システムでロックアウトすることもできます。この方法は、すべての作業が1つのアトミック・セッションで終了することが確実な場合にのみ使用してください。
頻繁にマージを行います。小さなマージでは競合リストや必要な決定は、わかりやすいものです。マージが大きすぎると、変更数はわかりにくくなり、ヒューマン・エラーが回避しにくくなります。ロールバックする必要がある場合、廃棄される変更数も大きくなります。パフォーマンスも小さいマージの方が向上します。
マージのパフォーマンスに問題がある場合、プロジェクトをいくつかのより詳細なファイングレイン・プロジェクトに分割することを検討してください。また、マージの変更数が少なくなり高速になるようにより頻繁にマージしてください。
ローカル接続プールの変更は、変更を公開するたびにマスター・リポジトリの接続プール設定で上書きされるので、それがマスターと異なる場合は、チェックアウトするたびにローカルテスト設定を再度適用する必要があります。これに最適な方法は、Oracle BIサーバーXML APIを使用して、ローカル接続プール設定の適用を自動化することです。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンスのテストから本番環境への移行に関する項を参照してください。
成功を収める多くの大規模なチームには、リポジトリ開発者とMUD管理者と間のコミュニケーションおよびタスクに関する正式なプロセスの要件および想定が存在します。たとえば、MUD管理者にプロジェクトを作成するよう要求するフォームが用意されています。多くのチームには、サービス・レベルの合意およびリード・タイムを持ちます(プロジェクトを作成するために24時間必要など)。
MUDマージ中に整合性チェックを強制するオプションを設定します。クリーン整合性チェックでは、コードが正しく生成されるかどうかを調べるコンパイラによるチェックと同様の方法で、Oracle BIサーバーでモデルを正しくロードできることが確認されます。マージが成功したと思われる場合でも、一貫性のないリポジトリによって、Oracle BIサーバーの起動、オンラインのリポジトリの編集チェックイン、それに続くマージに問題が生じることがあります。この機能を有効にする方法の詳細は、「マルチユーザー開発オプションの設定」を参照してください。
マージする前に等化を強制するオプションを設定します。開発者は同じ物理表をインポートすることなどが多いので、この設定を行うことで重複するオブジェクト数が削減されます。この機能を有効にする方法の詳細は、「マルチユーザー開発オプションの設定」を参照してください。
オブジェクトの等化の重要性の詳細は、「オブジェクトの等化」を参照してください。
他のユーザーが必要なコンテンツは、そのコンテンツの所有者である場合や他の開発者と連携している場合を除いて、削除または変更しないでください。プロジェクトで不要になる列を削除すると、他のユーザーがそれに依存していても、マージしたときに通常はそれがマスターから削除されます。
ヒント: プレゼンテーション・オブジェクトの別名は、マージの際に特別な扱いを受けます。その目的は、名前が変更されたときに古いレポートが破損しないように、オブジェクトの従来の名前を保持することです。開発中にどのように名前を変更しても、新しい別名が追加されます。マージ時には、いずれの新しく作成した別名も保持するかしないかを選択できます。また、従来のレポートが存在する場合もあるので、過去の別名のいずれかまたはすべてを保持するオプションもあります。 |
詳細は、「マルチユーザー開発のマージ・プロセスについて」を参照してください。
個別に開発された2つのリポジトリを単一のリポジトリに結合する必要がある場合、2方向マージを使用します。単一のリポジトリに2つのセマンティック・モデルをホストする必要がある場合、このような状況が多く発生します。
2方向マージを実行する場合は、次のガイドラインに従います。
意図せず名前の変更やオブジェクトのマージが行われないように、各リポジトリのトップレベル・オブジェクトには異なる名前があることを確認してください。次のオブジェクトをチェックします。
ビジネス・モデル
サブジェクト・エリア
物理データベース
変数
初期化ブロック
アプリケーション・ロール
ユーザー
マーケティング・オブジェクト
マージする前に等化を行います。そうすることで、管理対象のすべての完全修飾名が考慮され、2つのリポジトリ間で競合が発生しないようにアップグレードIDが割り当てられます。オブジェクトの等化の重要性の詳細は、「オブジェクトの等化」を参照してください。
管理ツールで、元のファイルとしてのブランク・リポジトリと完全マージを実行します。
ブランク・リポジトリを作成するには、新規リポジトリを開いて、ソースのインポートやオブジェクトの作成を行わずにそれを保存します。このリポジトリにはデフォルトのセキュリティ・オブジェクトが含まれていますが、これらがマージに影響することはありません。
注意: 管理ツールの「リポジトリからのインポート」やコピー/貼付けなどの機能を使用してメタデータを段階的に移動しないでください。このようなアプローチでは、変更が正しくマージされません。 これらの機能を使用すると、多くの場合に期待どおりの結果が得られますが、それは単なる幸運です。それ以外のときは、メタデータ・オブジェクトのアップグレードIDの値が競合し、事実上オブジェクトがランダムに上書きされます。しかし、その問題は、かなり後のリグレッション・テストを実行するときまで発見されない場合があります。アップグレードIDは連続して割り当てられており、1つのリポジトリ内で一意であるため、競合が起こりやすくなります。 また、 |
また、2方向マージの詳細は、「共通の親を使用しない完全なリポジトリ・マージの実行」を参照してください。
テストから本番に移行する場合は、次のガイドラインに従います。
本番クラスタ上でメタデータを更新する場合、変更のロード中に停止時間が発生しないように、ローリング再起動を実行して一度に1つのOracle BIサーバーを再起動します。BI Systems Management APIを使用してOracle BIサーバーをプログラムで起動および停止したり、Fusion Middleware Controlで各Oracle BIサーバーを手動で再起動することができます。
詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceの起動と停止およびOracle BI Systems Management APIを使用したOracle Business Intelligenceの起動と停止に関する項を参照してください。
管理ツールを使用してオンライン・モードで本番のメタデータを変更することはお薦めしません。
biserverxmlcli
ユーティリティを使用してオンライン・モードで本番のメタデータを更新することはお薦めしません。
アプリケーション・ロールおよびユーザーを使用して作業をする場合は、次のガイドラインに従います。
リポジトリ内のユーザー・オブジェクトの周辺では、データ・アクセス・セキュリティを構築しないでください。かわりに、アプリケーション・ロールに基づいて、リポジトリ権限、フィルタおよびガバナーを定義します。
アプリケーション・ロールのセットは、管理委員会で定義する必要があります。ビジネス・チームは、どのようなビジネス・ロールがあり、どのユーザーがどのデータを参照できるように割り当てられ、あるアプリケーションから次のアプリケーションまででどのロールが同じになるかを習熟しています。そのため、管理委員会はアプリケーション・ロールを定義および指名し、どのロールをアプリケーション間で共有するかを決定するする立場にあります。
新しいアプリケーション・ロールを作成する場合、マージ後にそれを再度チェックアウトできるように、それをプロジェクトに追加してください。また、オフライン・モードで、管理ツールでプレースホルダ・アプリケーション・ロールを作成する場合、後でそれをポリシー・ストアに追加してください。
オンライン・モードで管理ツールからリポジトリを開いて整合性チェッカを実行することで、リポジトリで使用されるアプリケーション・ロールがシステムでプロビジョニングされているかを確認できます。リポジトリおよびアプリケーション・ロールを新しいシステムに移行するたびにこのチェックを実行することをお薦めします。
環境間で少数のアプリケーション・ロールのみを移行する必要がある場合、Oracle WebLogic Serverで組込みポリシー・ストアを使用していれば、ターゲット・システム上のFusion Middleware Controlでそれを手動で入力できます。
この項では、一般的な問題とその解決法方について説明します。
ユーザーが変更をネットワークに公開するコマンドを発行することでロックを設定した場合、それは公開が完了するまでクリアされません。そのユーザーがそれを忘れて2週間の休暇をとってしまった場合、MUD管理者はそのロックを解除できます。
ロックは、マスター・ディレクトリの非表示のシステム・ファイルに格納されます。ロック・ファイルが見つからない場合は、Windowsのエクスプローラで「ツール」を選択し、「フォルダ オプション」を選択します。「表示」メニューで、「すべてのファイルとフォルダを表示する」オプションが選択されていることを確認します。
ロック・ファイルは、マスターRPDと同じ名前を持ち、.lckという拡張子が付きます。ロック・ファイルを削除すると、リポジトリのロックが解除されます。
図A-7に、リポジトリ・ロック・ファイルを示します。
他のユーザーで削除されたオブジェクト
必要なオブジェクトを他のMUD開発者が削除した場合、次のオプションを選択できます。
以前のバージョンにロールバックして、当初からのすべての変更を再適用します。一般的には、ロールバックの最も簡単な方法は、履歴ログで履歴をたどることです。そのためには、「ファイル」→「マルチユーザー」→「履歴」を選択して、エントリを選択し、「アクション」→「ビュー」を使用します。
詳細は、「マルチユーザー開発の履歴の表示と削除」を参照してください。
削除されたオブジェクトを再作成し、将来のマージでそれが同じオブジェクトとして処理されるように等化します。
チェックアウト後にプロジェクトがない場合に必要な物理表および結合
物理オブジェクトは明示的にプロジェクトに属しているわけではありません。物理オブジェクトはプロジェクトの論理ファクト表にマップされ、それがチェックアウト時に抽出されているのです。
ローカルの抽出時に必要な物理オブジェクトを取得するには、必要な物理オブジェクトへのマッピングを持つ追加プロジェクトをチェックアウトします。そのようなプロジェクトがない場合、リポジトリ全体を編集してプロジェクトで論理ファクト表へのマッピングを作成する必要があります。MUD管理者はオフラインでリポジトリの変更を行うことができます。次のチェックアウトでその物理オブジェクトを含める必要があります。
前回のセッションで追加されたオブジェクトがチェックアウトされたリポジトリにない
最近追加されたオブジェクトがチェックアウトされたリポジトリにない場合、マージおよび公開する前にオブジェクトをプロジェクトに追加することを忘れた可能性があります。プロジェクト内のオブジェクトまたはプロジェクトから推論されたオブジェクト(ディメンションや物理オブジェクトなど)のみが、抽出されるリポジトリに含まれます。
この問題を解決するには、そのオブジェクトをマスター・リポジトリのプロジェクトに追加するようにMUD管理者に依頼します。
#1の追加によるオブジェクトの名前の変更
2つのオブジェクトが同じ完全修飾名で異なる内部アップグレードIDを使用してマージされている場合に、このような状況が発生します。このような状況でマージ・ロジックは、これらのオブジェクトは意味的に異なるオブジェクトと判断し、オブジェクトの名前を変更して一意性を保持します。
この問題を解決するには、equalizerpds
ユーティリティを実行します。これは、2つのリポジトリで同じ完全修飾名を持つオブジェクトが同じアップグレードIDを持つようにアップグレードIDを再び割り当てるユーティリティです。その後、再度マージを試行してください。2つのオブジェクトは、名前が変更されることなく、マージされます。
詳細は、「オブジェクトの等化」を参照してください。
マルチユーザー開発環境では、適切なチェックポイントでRPDのバックアップ・コピーを保存します。破損が発生する可能性のある操作が実行されるたびに、新しいバックアップがマスター・ディレクトリに保存されます。これはRPDの名前を持ち、3桁のインクリメント整数の拡張子を持ちます。個々の開発者も、開発時はいつでもRPDファイルをコピーできます。
開発者のサンドボックスでは、チェックアウトされたプロジェクトの元のバージョンはoriginalrpd_name.rpdという名前で保存されています。開発者が変更を廃棄すると、自動的にこのバージョンが使用されます。
また、次の手順を実行して、古いバージョンを参照したりロールバックすることもできます。
リポジトリでなく、管理ツールを開きます。
「ファイル」→「マルチユーザー」→「履歴」を選択します。
目的のバージョンを選択してから、「アクション」→「ビュー」→「リポジトリ」を選択します。
「ファイル」→「名前を付けてコピー」を選択して、そのバージョンを新しい名前に保存します。
古いバージョンを使用して最新のバージョンを置き換えるか、マスター・リポジトリを古いバージョンで置き換えます。
例A-1 最新バージョンの置換
この例では、古いバージョンをコピーして最新バージョンを置き換える方法を説明します。現在はバージョン1000であり、バージョン900にロールバックするとします。この状況では、repository.900、repository.1000およびrepository.rpd(現在のバージョン)の3つのファイルがあります。ロールバックを実行するには、repository.900のコピーを作成し、その名前をrepository.1001に変更します。(これにより、バージョン履歴にrepository.1000を保持できます。)その後、repository.900をrepository.rpdにコピーします。
マスターMUDリポジトリの手動更新
マルチユーザー開発(MUD)環境におけるOracle BIリポジトリの開発の過程で、マスター・リポジトリを手動で変更する必要がある可能性があります。MUDプロセスは高度に制御されており、MUDの履歴ログ・ファイル(.mhl)にはアカウンティング情報が格納されているので、手動の手順を実行する際には注意する必要があります。マスター・リポジトリに対して手動で作業するには、MUDディレクトリとは別のディレクトリにあるリポジトリで作業する必要があります。その後、マスターRPDと、MUDディレクトリにある最新バージョンのリポジトリの両方を交換する必要があります。
たとえば、master.rpdという名前のリポジトリを手動で更新するには、次の手順に従います。
MUDディレクトリからマスター・リポジトリ(master.rpd)をローカル・ディレクトリにコピーします。
管理ツールを使用して、マスター・リポジトリ(master.rpd)のローカル・コピーに必要な変更を加えます。
手動編集が完了したら、master.rpdをMUDディレクトリのmaster.rpdとしてコピーします。例:
copy c:\local\master.rpd c:\mud\master.rpd
MUDディレクトリで、バージョン番号を持つ最新のリポジトリを特定します。たとえば、master.7011などです。
master.rpdをMUDディレクトリにコピーし、リポジトリの最新バージョンを上書きします。例:
copy c:\local\master.rpd c:\mud\master.7011