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