Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.1.0) E77227-02 |
|
前へ |
次へ |
次のトピックを確認することで、マルチユーザー開発環境のアーキテクチャを理解できます。
この項では、次の項目について説明します。
マルチユーザー開発のシステムの開発およびデプロイに関連する基本的な概念について説明します。
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 BIプレゼンテーション・カタログについては触れません。Oracle BIプレゼンテーション・カタログ開発の詳細は、Oracle Business Intelligence Enterprise Editionユーザーズ・ガイドを参照してください。
移行
完成したリポジトリは、Fusion Middleware Controlを使用してテスト・システムおよび本番システムに移行されます。ローリング再起動でクラスタ化された本番のOracle BIサーバーをリフレッシュできるため、停止時間は不要です。
移行時のデプロイ・パラメータ
開発、テストおよび本番システム間でリポジトリを移行する場合、接続プール設定などの一部のリポジトリ・パラメータを変更する必要があります。これらのパラメータを変更するのは、それらがアプリケーション・ロジックではなくデプロイに基づいているためです。Oracle BIサーバーXML API (biserverxmlexec -B
)を使用すると、これらの更新を自動化できます。マルチユーザー開発時は、コンテンツをマージする開発者は、自動的にマスター・リポジトリ・テスト接続プールおよびデータベース・パラメータをローカル・ユニット・テスト・パラメータで上書きすることができなくなります。
アプリケーション・ロール(ポリシー・ストア)の移行
開発、テストおよび本番システム間でアプリケーション・ロールを移行するには、いくつかのオプションがあります。このドキュメントでは、簡潔にするために、少数のアプリケーション・ロール名を手動で再入力することにします。アプリケーション・ロールの移行の詳細およびその他の移行に関する検討事項については、Oracle Fusion Middlewareの管理のOracle Business Intelligenceのターゲット環境への移行を参照してください。
ユーザーおよびアイデンティティ・ストア
設計時には、ユーザーをリポジトリのメタデータ・オブジェクトで表さないことをお薦めします。また、リポジトリでは資格証明を管理または保存しません。そのかわり、実行時環境では常にユーザーをアプリケーション・ロールにプロビジョニングして、ユーザーが権限を受信する必要があります。ユーザーの資格証明およびグループを介したアプリケーション・ロールへのユーザーのマッピングは、外部のアイデンティティ・ストアで管理されます。詳細は、 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上のOracle BI管理ツールでもデフォルトでローカルの/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 BI管理ツールおよびOracle Business Intelligenceスタックからそれぞれのデータ・ソースへの接続を設定する必要があります。この構成には、必要なドライバまたはクライアントのインストール、ODBC DSNの設定、ネイティブ接続の設定およびその他の手順を含めることができます。詳細は、メタデータのインポートとデータ・ソースの操作およびLinuxおよびUNIXでのデータ・ソースの設定を参照してください。
Oracle Database接続の場合、Oracle Business Intelligenceには、BI_DOMAIN/config/fmwconfig/bienv/core
にあるTNSnames.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 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などの外部アイデンティティ・ストアを使用することを想定しています。
この図は、マルチユーザー開発環境を使用したリポジトリ・ライフサイクルのサンプル・デプロイ・アーキテクチャを示しています。