Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.4.0) E96106-04 |
|
前 |
次 |
この付録の内容は次のとおりです。
架空の会社を提示して、Oracle Business Intelligenceのイニシアティブの例を説明します。
Eden Corporation社(架空の会社)は、最近Oracle Business Intelligenceを購入しました。この会社の2つの部署がライセンスを保有し、製品を使用する予定です。
そのため、この会社には2つの個別のイニシアティブがあります。
イニシアティブS
販売部では、Oracle Business Intelligenceを使用して、計画に対する収益のダッシュボードおよび分析を行うことを考えています。初期フェーズを本番にすばやくデプロイし、直近のニーズを満たす必要があると考えています。その後、フェーズIIおよびIIIでさらに機能をロール・アウトすることを考えています。イニシアティブSは、2人の開発者にとって十分な大きさです。
イニシアティブH
人事部(HR)では、HRデータのダッシュボードおよび分析を作成する必要があります。イニシアティブHは小さなイニシアティブのため、1人の開発者しかいません。この部署では、イニシアティブSのフェーズIIとフェーズIIIとの間でアプリケーションを本番に配信する予定です。
販売部と人事部の開発者は、お互いのデータおよびメタデータを参照することはできません。すべてのメタデータのセキュリティ権限を持つユーザーは、メタデータ管理者のみです。
多くの組織と同様に、緊急要求の定型的な傾向や本番での不具合も時折ある可能性があります。長期間のイニシアティブSとイニシアティブHがともに開発期間中であっても、開発者はその修正バージョンを数日以内に配信する必要があります。
技術チームのロールおよび職責について
Eden Corporation社では、次のようなチームを配置しています。
Adam Straight - MUD管理者
Sally Andre - 販売部のRevenueプロジェクトの開発者
Scott Baker - 販売部のQuotaプロジェクトの開発者
Helen Rowe - 人事部の開発者
Eden Corporation社の開発フェーズについて
Eden Corporation社では、次のタイムラインに基づいてRPDを本番にデプロイします。
1月 - 販売フェーズI (プロジェクトRevenueおよびQuota)
2月 - 販売フェーズII (プロジェクトTargetの追加、プロジェクトRevenueおよびQuotaの拡張)
3月 - HR (1つのプロジェクトを使用)
4月 - 販売フェーズIII (3つすべてのプロジェクトの拡張)
Eden Corporation社のトポロジについて
Eden Corporation社では、マルチユーザー開発環境に次のシステムを使用する予定です。
MUD管理者 - NTコンピュータ(共有)
Sally Andre - 管理ツール・クライアント用NTコンピュータ、およびOracle Business Intelligenceスタックの実行用Linuxコンピュータ
Scott Baker - 高機能NTコンピュータ
Helen Rowe - 前述のいずれか
テスト - Linuxコンピュータ
本番 - クラスタ化されたLinuxコンピュータ
リポジトリ・アーキテクチャについて
Eden Corporation社のビジネス構造およびイニシアティブのため、リポジトリに2つの独立したセマンティック・モデル(1つは販売部用、1つは人事部用)が必要です。これらのモデルそれぞれが、複数のプロジェクトを持つ可能性があります。
リポジトリ構造の計画
リポジトリ・ファイルの構造次第で組織のマルチユーザーの開発ニーズをサポートできるため、Eden Corporation社ではリポジトリ・ファイルの構造を計画することの重要性を認識しています。主要なオブジェクトには所有者が割り当てられるため、開発者は競合が発生したときに誰に照会したらよいか、自身で変更してはならないオブジェクトはどれかがわかります。
ヒント:
複数の独立したセマンティック・モデルをホストする場合、トップレベル・オブジェクトの名前を列挙して、名前が重複しないようにしてください。
これらの表は、イニシアティブSおよびイニシアティブHのmain.rpdの高レベル・オブジェクトを示しています。これらは、プロジェクトおよび所有者にマップされます。Adamは、イニシアティブSおよびイニシアティブHの全体の所有者です。
オブジェクト・タイプ | オブジェクト | 所有者 | ProjRevenue | ProjQuota | ProjTarget |
---|---|---|---|---|---|
物理データベース |
Sample App Data |
Sally |
はい |
はい |
はい |
ビジネス・モデル |
Sales |
Sally |
該当なし |
該当なし |
該当なし |
論理ファクト表1 |
F10 Billed Rev |
Sally |
はい |
はい |
いいえ |
論理ファクト表2 |
F30 Facts Targets |
Scott |
いいえ |
いいえ |
はい |
論理ファクト表3 |
F50 Facts Quotas |
Scott |
いいえ |
はい |
いいえ |
論理ディメンション |
(各種オブジェクト) |
Sally |
はい |
はい |
はい |
サブジェクト領域(1) |
Sales Quota |
Scott |
いいえ |
はい |
いいえ |
サブジェクト領域(2) |
Sales Revenue |
Sally |
はい |
いいえ |
いいえ |
サブジェクト領域(3) |
Sales Target |
Scott |
いいえ |
いいえ |
はい |
変数 |
S_Last_Load |
Sally |
はい |
はい |
はい |
初期化ブロック |
S_Last_Load |
Sally |
はい |
はい |
はい |
アプリケーション・ロール(1) |
Sales Management |
Sally |
はい |
はい |
はい |
アプリケーション・ロール(2) |
Sales Rep |
Sally |
はい |
はい |
はい |
オブジェクト・タイプ | オブジェクト | 所有者 | ProjHR |
---|---|---|---|
物理データベース |
Human Resources Data |
Helen |
はい |
ビジネス・モデル |
HR |
Helen |
該当なし |
論理ファクト表1 |
Payroll Facts |
Helen |
はい |
論理ファクト表2 |
Medical Ins Facts |
Helen |
はい |
論理ディメンション |
(各種オブジェクト) |
Helen |
はい |
サブジェクト領域(1) |
HR Payroll |
Helen |
はい |
サブジェクト領域(2) |
HR Medical |
Helen |
はい |
変数 |
H_Last_Load |
Helen |
はい |
初期化ブロック |
H_Last_Load |
Helen |
はい |
アプリケーション・ロール(1) |
HR Management |
Helen |
はい |
アプリケーション・ロール(2) |
HR Rep |
Helen |
はい |
架空の会社例の最初のフェーズでは、Sally AndreとScott Bakerの2人が並行して開発します。
Sallyが初期コンテンツを作成し、Adam Straightがそれを複数のプロジェクトに分割します。彼はMUDディレクトリを作成し、SallyとScottがチェックアウトして開発を行えるようにします。ユニット・テストの後、彼らの変更をマージして公開し、その後、Adamがリポジトリをテスト環境に移行します。不具合の修正サイクルの後、Adamがリポジトリを本番にプロモートします。
次の項では、フェーズIの開発について説明します。
架空のMUDプロジェクトにおいて、Sally AndreがイニシアティブSを空のRPDから開始します。
いくつかの論理スターおよびサブジェクト・エリアを最初に定義している場合、リポジトリをMUDプロジェクトに分割する方が容易なため、始めにフェーズIに必要な物理モデルを開発します。独自のローカル・テスト・データソースの接続プールの詳細も含まれます。
ヒント:
物理モデルには、物理表、すべての物理表に別名を定義して意味のある名前を付けるためのベスト・プラクティス、および結合が含まれます。
この図は、イニシアティブSの物理モデルを示しています。
Sallyは、物理レイヤーをビジネス・モデルおよびマッピング・レイヤーにドラッグしていくつかの初期コンテンツを作成します。また、不要な表を削除したり、スター結合が正しくなるようにします。さらに、開発時に必要なすべての物理表が開始論理表からのマッピングを持たせ、チェックアウトするときにそれらがプロジェクトに含まれるようにします。Sallyはこれらのステップを使用してF10 RevenueおよびF50 Quotasの2つのファクト表を作成し、これらはプロジェクトの基盤として機能します。
また、Sallyはビジネス・モデルのプロジェクトをマップするためのサブジェクト・エリアをいくつか持つ必要があります。ビジネス・モデル全体をドラッグすることができますが、ビジネス・モデルを右クリックして「Logical StarsとSnowflakes向けのサブジェクト・エリアの作成」を選択するとこの機能をより便利に実行できます。この機能を使用すると、それぞれの論理ファクト表からサブジェクト・エリアを作成できます。
Sallyは、この時点でサブジェクト・エリアのコンテンツについて考慮する必要はありません。重要なのは各サブジェクト・エリアを同じプロジェクトの論理ファクト表にマップするということです。ただし、サブジェクト・エリアは管理ミーティングSales QuotaおよびSales Revenueで合意された計画に基づいて名前を付けます。
Sallyはこの時点で、RevenueおよびQuotaファクト表に基づいて最初の2つのプロジェクトを作成するための十分なMUD管理者のコンテンツを持ちます。これらを確認するには、Sallyは最低でも次の基準を満たしていることを確認する必要があります。
架空の会社例で、Eden Corporation社のMUD管理者Adam Straightは、ここで次のステップを実行してプロジェクトを作成し、それらをチェックアウトできるようにします。
Adam Straightは、MUDディレクトリ(RPD_main)を作成して、このディレクトリにマスターRPDを保存します。このマスターRPDには、開発者用のコンテンツのスーパーセットが含まれています。ユーザーはマスターからプロジェクトをチェックアウトし、変更を共有する場合は、そのプロジェクトをマスターに戻してマージします。Sallyは自分の初期RPDをマスター・フォルダにコピーし、Adamが最初の2つのプロジェクトProjRevenueとProjQuotaを作成できるようにします。
Adamは『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』でマスターRPDを開き、「プロジェクト」を選択します。ここで、彼はプロジェクト・マネージャで、「新規プロジェクト」を選択します。彼はこのプロジェクトに「ProjRevenue」という名前を付けてから、プロジェクトの中央の論理ファクト表を選択します。リストの一番上のオブジェクトが開き、論理ファクト表が表示されます。また、論理ファクト表が属するビジネス・モデルごと、またはサブジェクト・エリアごとにまとめて表示することもできます。
この図は、Adamが論理ファクト表を表示できる様々な方法を示しています。
Adamは、サブジェクト・エリアのグループを使用して同じファクト表を選択できたかもしれませんが、便宜上、ビジネス・モデルごとにファクトをグループ化することに決めます。彼はこのプロジェクトに指定されたファクト表、さらにデフォルトのアプリケーション・ロールおよびサブジェクト・エリアを追加します。カスタムで定義されたアプリケーション・ロール、ユーザー、変数または初期化ブロックはまだないため、それらをプロジェクトに追加することはできません。Adamは、2番目のプロジェクトのProjQuotaでもこの処理を繰り返します。
ヒント:
一部の明示的なオブジェクトは、両方のプロジェクトでアプリケーション・ロールを共有しているため、両プロジェクトで同一になります。同様に、多くの暗示的なプロジェクトのオブジェクトも共有されます(特に論理モデルと物理モデルの両方のディメンション表など)。プロジェクトは、作業が簡単になる小さなサブセットを作成する場合に役立ちます。プロジェクトは、セキュリティには向いていません。それぞれのトップレベル・オブジェクトの所有者がチーム全体に割り当てられてドキュメントが作成される管理プロセスにおいては、開発者が競合を回避できることからも、これは重要になります。
プロジェクトの論理ファクト表F10 Bill Revの所有者はSally Andreであり、このプロジェクトの所有者であるScott Bakerではありませんが、Adamはこれをこのプロジェクトに含めています。このようにした理由は、Scottが両方のファクト表のメジャー(販売ノルマの割合)から導出するメジャーを作成する必要があるためです。要は、ユーザーが所有するオブジェクトのみでなく、ユーザーの要件の実装に必要なコンテンツのサブセットもユーザーに提供されるということです。
Adamは、sales.rpdという名前でマスターRPDを共有ドライブRPD_Mainに保存します。これで、ユーザーはプロジェクトをチェックアウトし、作業を平行して進められるようになります。
管理者は、マスター・リポジトリの管理ツール・クライアントを構成して、プロジェクトをチェックアウトし、作業を開始します。
開発者Sallyはまず、マスター・リポジトリを使用するように管理ツール・クライアントを設定します。「ツール」、「オプション」を選択し、次に「マルチユーザー」タブを選択します。「マルチユーザー」タブで、マスター・リポジトリ・ディレクトリへのポインタを設定します。また、ログやロックで使用される彼女のフルネームも入力します。彼女は自分のプロジェクトをチェックアウトし、作業を開始します。
マスター・リポジトリ・ディレクトリには、sales.000とsales.mhlという2つの新しいファイルが作成されています。この図は、新しいファイルを示しています。
sales.000ファイルは、Sallyがリポジトリをチェックアウトしたときに作成されたsales.rpdファイルの自動バックアップ・ファイルです。問題に起因してロールバックが必要な場合は、バックアップ・ファイルが使用されます。sales.mhlファイルは、プロジェクト、コンピュータ、ユーザーなどのパラメータおよびチェックアウト・ステータスを追跡します。
Sallyのローカル・リポジトリ・ディレクトリには、次の3つのファイルが作成されています。
originalProjRevenue.rpdファイルは、チェックアウト時のプロジェクト・サブセット・リポジトリです。originalProjRevenue.rpdは、後で3方向のマージ処理においてオリジナルとして使用されます。またSallyが変更を廃棄する場合にも使用されます。
ProjRevenue.rpdファイルには、自己完結のサブセット・プロジェクト(ProjRevenue)のみが含まれます。ProjRevenue.rpdファイルは編集可能です。
ProjRevenue.rpd.Logファイルは、管理ツールの編集セッション用のログ・ファイルです。ProjRevenue.rpd.Logファイルの内容は、管理ツールで「ファイル」、「マルチユーザー」を選択し、次に「履歴」を選択します。
この図は、ローカル・リポジトリ・ディレクトリの3つのファイルを示しています。
Sallyは自分のアプリケーションのモデルでの作業をオフライン・モードで開始します。彼女は初期コンテンツを作成したときに独自のテスト・データソース接続プールの詳細を使用していたので、接続プール設定を変更する必要はありません。
Sallyはまずファクト表を開いて、モデリングのベスト・プラクティスに基づいて使用されていないキーを削除します。次に、Discnt_Value、RevenueおよびUnitsの3つのメジャーにSUM
集計ルールを追加します。また、Discnt_Valueの名前をDiscount Amountに、UnitsをUnits Soldに、RevenueをSales Revenueに変更します。
また、D10 Product表にProd_Dsc列の大文字バージョンとなる新しいPRODUCT DESCRIPTIONという列を追加する必要があります。この列は、Upper("Sales"."D10 Product (Dynamic Table)"."Prod_Dsc")
という式を使用します。ディメンション階層を追加し、Constant Oneという変数を作成して、それを値1に初期化します。この変数を使用して新しいメジャーConstant Oneを作成します。最後に、自分の作業を保存します。
Sallyは、アプリケーション・ロールを追加できるようにサンドボックスOracle Business Intelligenceスタックを開始してから、アンサーを使用してリポジトリをテストします。次のステップに従ってコンポーネントを正しい順序で開始し、システム環境を構成します。
標準コントロールを使用して、RCUスキーマが含まれるデータベースを開始します。このデータベースは、ローカル・サンドボックス開発者データベースです。
サンドボックスのOracle WebLogic Server管理サーバーを起動します。たとえば、Windowsの「スタート」から「プログラム」を選択して、「Oracle WebLogic」を選択します。Oracle WebLogicでは、「User Projects」、「bifoundation_domain」、「Start Admin Server for WebLogic Server Domain」の順に選択して、入力を求められたらインストール時に作成したユーザー名とパスワードを入力します。
ノート:
エンタープライズ・インストールまたはソフトウェアのみインストールのタイプを使用している場合、Oracle WebLogic Server管理コンソールを使用してOracle WebLogic Server管理対象サーバーも起動する必要もあります。通常、開発サンドボックスをインストールしている場合は、簡易インストール・タイプを使用します。
正しいリポジトリ・パスワードを入力して、ローカル・サンドボックスのFusion Middleware Controlにログインし、リポジトリ・ファイルをアップロードします。マスター・リポジトリではなく、ローカル・サブセット・リポジトリ(Sallyの場合はMUDチェックアウト・リポジトリ、ProjRevenue.rpd)をアップロードします。
また、問合せログの解析が容易になるように、Fusion Middleware ControlでOracle BIサーバー・キャッシュをオフにします。
さらに、Fusion Middleware ControlのBusiness Intelligence概要ページからシステム・コンポーネントを起動します。
ステップ2 - 5の詳細は、Oracle Business Intelligence Enterprise Editionシステム管理者ガイドを参照してください。
SallyのOracle BIサーバーはLinuxシステム上にあるため、管理ツール・クライアントからそこのOracle BIサーバーにアクセスできるように彼女のWindowsコンピュータにODBC接続を設定する必要があります。
Sallyは、Linuxコンピュータ上のOracle BIサーバーを指すように、Oracle BIサーバーODBC DSNを手動で追加します。Oracle BIサーバーのODBC DSNを作成する方法の詳細は、Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイドの「Oracle Business Intelligenceへの他のクライアントの統合」を参照してください。
Sallyは、Oracle WebLogic Serverの組込みポリシー・ストアを使用するため、2つのアプリケーション・ロールSales ManagementおよびSales Repを追加する必要があります。ロールを追加するには、WindowsコンピュータでWebブラウザを開き、(彼女のLinux上のOracle Business Intelligenceスタックを指す) Fusion Middleware Controlにログインします。Fusion Middleware Control を使用して新しいロールを作成し、それを適切なユーザー、グループまたは他のロールにマップして、そのロールに適切な権限を付与します。
ヒント:
『Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』の「アプリケーション・ロールの作成」を参照してください。
Sallyは新しいアプリケーション・ロールを彼女のリポジトリに追加して、それらをオブジェクトの権限およびデータ・アクセス・フィルタに使用する必要があります。次のステップを使用します。
Sallyが次に自分のプロジェクトをチェックアウトするときに新しい変数とアプリケーション・ロールがそれに含まれているようにするには、自分の変更をチェックインする前にプロジェクトにそれらを追加する必要があります。これを行うために、彼女はAdamがプロジェクトを作成したとき行ったステップと同じステップを実行します。「管理」、「プロジェクト」の順に選択します。Sallyは自分のプロジェクトを選択し、新規のプロジェクトを選択して、「追加」をクリックします。
架空の会社例で、Sally AndreはProjRevenueプロジェクトで作業を行っていますが、Scott BakerはProjQuotaで作業を開始します。
Scottは、MUDの管理ツール・オプションを設定し、プロジェクトをチェックアウトして、作業を開始します。
Scottは、オンライン・モードを選んで作業します。Oracle BIサーバーで稼働中にリポジトリを変更するので、オンライン・モードで作業することで開発とユニット・テストの循環が強化されます。管理ツールで「変更のチェックイン」をクリックするたびに、稼働中のサーバーに変更が適用されます。その直後にOracle BIアンサーに移動して、そこで変更をテストできます。プレゼンテーション・レイヤー・オブジェクトを追加、削除、名前変更または再編成する場合、アンサーの基準タブでメタデータをリロードして、そこに表示されているツリーをリフレッシュする必要があります。
Scottは自分のローカルOracle Business Intelligenceスタックを開始し、チェックアウト済のリポジトリをアップロードします。Oracle BIサーバーを再起動して、管理ツールを開き、オンライン・モードでリポジトリを開きます。
Scottは、接続プールの設定を変更し、自分のローカル・テスト・データベースを指すようにする必要があります。これは、マスター・リポジトリにはSallyの設定が含まれているためです。このマージ・プロセスで、これらの接続プールの変更は、すでにマスター・リポジトリに存在する接続プールによってオーバーライドされます。Scottは、次にチェックアウトするときに自分のローカル・テスト接続プールの変更を再び適用する必要があります。
ヒント:
本番および他の環境への移行時に必要な接続プールの変更を自動化するには、Oracle BIサーバーXML APIを使用します。『Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンス』の「テスト環境から本番環境への移行」を参照してください。
Scottの次のタスクは、キーを削除して彼の論理ファクト表をクリーンアップすることです。また、メジャーにSUM
集計ルールおよび業務上わかりやすい名前(Quota Amount)を指定します。
F10論理表はSallyが所有しているので、Scottは表内の何も変更しません。彼女がマスターRPDに対して変更をマージおよび公開したら、彼も同じことを行います。Scottは再びチェックアウトし、彼女の変更を取得します。
Scottは、Sales percent of quotaという新しいメジャーをF50表に追加します。このメジャーは、次の式を使用して両方のファクト表から導出します。
"Sales"."F10 Billed Rev."."Revenue" / "Sales"."F50 Facts Quotas"."Quota Amount"
Sallyが自分のプロジェクトでRevenueの名前を変更しても、マージ処理ではそれが同じオブジェクトと識別され、Scottの式で同じ名前が使用されます。オブジェクトのアップグレードIDは元のIDと同一であるため、マージ・ロジックで名前の変更を識別できます。
Scottは、管理委員会のミーティングで彼が知ったことを忘れています。それは、Sallyがすべてのディメンションを所有していることです。彼は、PRODUCT DESCRIPTIONというD10 Product.Prod_Dsc列のすべてが大文字になっているバージョンを必要としています。彼は、Sallyが作成したものと同じ列を作成します。この誤りは、すぐに、公開ステップの中のマージ・プロセスで検出され、解決されます。
Scottは、オンライン・モードで作業しているため、自分のリポジトリをアップロードしたり自分のシステムを再起動する必要はありません。そのかわり、変更をコミットした直後に、「変更のチェックイン」を使用してそのユニット・テストを行います。その間にSallyは、彼女の変更のテストを終えます。
Sallyは変更の最初のバッチの作成およびユニット・テストを終えたので、作業を保存してそれをマスター・リポジトリにマージします。
彼女は、「ファイル」、「マルチユーザー」を選択し、次に「ネットワークに公開」を選択します。新しいオブジェクトをプロジェクトに追加することを忘れても、詳細な警告が表示されるので、オブジェクトをプロジェクトに追加して再度マージできます。そうしないと、次に彼女がプロジェクトをチェックアウトしたときに、オブジェクトは抽出されません。
次に、他のユーザーがマージすることでSallyの変更が破損してしまうことなく彼女が自分の変更をマージできるように、管理ツールはマスター・リポジトリをロックします。
ヒント:
コメント・フィールドを使用して、公開する変更の説明を記録用に残しておくことをお薦めします。また、頻繁に公開すること、つまりサブセットのリフレッシュを実行することで、変更の追跡および後の履歴の監査が容易になります。管理ツールのモデリングでは、作業を段階的に行うことでテストを簡易化して各タスクの複雑性を低減することをお薦めします。
Sallyの変更により競合が発生することはないので、次に示す「マージ戦略の定義」のステップでは競合について触れていません。ただし、プレゼンテーション・オブジェクトの別名は特殊なケースで、変更(ローカル・バージョン)、現行(マスター)、または2つのマージを保持することを選択できます。Sallyが列名を変更すると別名が自動的に作成されるため、新しい名前を本番に配置したときに、古い名前に記述されたレポートが破損することはありません。Eden Corporation社にはまだレポートがないため、「現行」を選択しても別名は空のままです。彼女は「Sales Revenue」、「Units Sold」および「Discount Amount」に対してこれを行います。
ノート:
名前を複数回変更すると、一連の別名ができることがあります。古い名前を使用しているレポートのセットが存在する場合があるため、「マージ戦略の定義」画面で「選択内容のマージ」を選択して、「現行」に存在する別名および「変更」の新しい別名を保持できます。
マージ・ステップが完了すると、マスターsales.rpdは、Sallyによる変更で上書きされます。マージ・ログも保存されます。
架空の会社例で、Scottは、このフェーズの自分の開発作業を完了したので、「サブセットのリフレッシュ」を選択し、サブセットのリフレッシュを実行して、自分の変更をマスター・リポジトリの最新バージョンにマージします。
「マージ戦略の定義」画面で、プレゼンテーション列Quota Amountに対して作成された別名を保持するかどうかが確認されます。Sallyと同様に、Scottも、現在のリポジトリの値(別名を使用しない)を保持することを選択します。
サブセットがリフレッシュされた後、Scottは再び簡単にユニット・テストを実行します。彼はテスト中に、Sallyのものと同じPRODUCT DESCRIPTIONという列を誤って作成していたことに気づきます。Scottの列は個別に作成されているので、内部アップグレードIDはSallyのものとは異なります。そのため、名前が同じでも、マージ・ロジックではそれを別の列と認識し、上書きされることなく、名前に「#1 (PRODUCT DESCRIPTION#1)」が付加されます。
Scottは外部列を削除し、自分のロジックをSallyのPRODUCT DESCRIPTION列に接続して、再度簡潔にテストしてから、ネットワーク・マスター・リポジトリに変更を公開します。
Scottが様々なユーザーのオブジェクトを削除または変更していると、エラーの解決は困難になることがあります。その場合、オブジェクトの再作成および補正、またはリポジトリのバックアップ・バージョンへのロールバックおよび彼の変更の再作成が必要になることがあります。
テスト環境のリポジトリの準備をするために、MUD管理者Adam Straightはここで、マスター・リポジトリで直接いくつかのタスクを実行する必要があります。
MUD管理者のAdamは、sales.rpdリポジトリをオフライン・モードで開きます。その直後、他のユーザーはロックアウトされるので、それらのユーザーがプロジェクトをチェックアウトしようとするとWindows権限エラーが発生します。Adamが何度もファイルを開いたり閉じたりする必要がある場合、他のユーザーがそれぞれの変更の間にリポジトリ・オブジェクトをチェックアウトできないように、RPDを変更中は共有ディレクトリから削除する必要があります。
Adamはテスト環境に適合するように接続プール設定を変更します。管理ツール・ユーザーがプロジェクトをチェックアウトする場合、接続プール・パラメータはチェックアウトに含まれません。MUDディレクトリのマスター・リポジトリにはテスト接続プールが含まれますが、個々の開発者は独自にテスト・データベースに接続するために様々な設定が必要になる場合があります。マージおよび公開時は、マスター・リポジトリの接続プールは開発者の変更で上書きされないため、引き続き共有テスト・データベースを指すことができます。
Adamは新しいアプリケーション・ロールがテスト・システムに移行されていることを確認する必要があります。アプリケーション・ロールは2つしかないので、彼はテスト・システムのFusion Middleware Controlでそれらを再入力することにします。さらに、Adamはいくつかのテスト・ユーザーまたはグループを新しいアプリケーション・ロールにプロビジョニングして、セキュリティ・フィルタ、権限および問合せ制限をテストできるようにします。
Adamはリポジトリをテスト・システムをアップロードし、Oracle BIサーバーを再起動します。ローカルの管理ツールを使用して、テストOracle BIサーバーをオンライン・モードで接続し、整合性チェッカを実行します。このリポジトリで参照されるいずれかのアプリケーション・ロールに欠落またを不正があると、整合性チェッカでそのエラーのリストが出力されます。
架空の会社例を検討して、マルチユーザー開発環境でのテストについて学習します。
この時点でテスト・チームはリポジトリをテストできます。テスト中に、テスト・チームは"Sales"."F50 Facts Quotas"."Sales percent of quota"が式sales/quotaではなくquota/salesで誤って作成されているという不具合を発見します。テスト・チームは不具合レポートを記述し、不具合の修正はScott Bakerが割り当てられます。
Scottは管理ツールを開いて、ProjQuotaをチェックアウトし、変更を行い、ローカル・テスト・データベースを指すように接続プールを変更して独自のサンドボックスでテストします。その後、彼は変更を共有MUDディレクトリに公開します。彼は、不具合が修正され、リポジトリは再度テストするために送信する準備ができたことをAdamに通知します。
MUD機能によりマスター・リポジトリはチェックアウトされたプロジェクトの接続プールの変更から隔離されるので、Adamは接続プールが正しいテスト・システムで指定されていることを認識できます。リポジトリをアップロードして、Oracle BIサーバーを再起動します。
テスト・チームは完成するまでテストを行い、本番用のリポジトリはクリアされます。
リポジトリがテスト・フェーズで合格すると、リポジトリを本番にアップロードする前に、リポジトリのデータベース接続パラメータを更新する必要があります。
アプリケーション・ロールを移行およびプロビジョニングする必要もあります。
管理チームが立てた計画に基づき、本番運用チームは新しいアプリケーション・ロールが必要なことを認識します。本番運用チームは、Adamと同様に、テスト環境に新しいアプリケーション・ロールを作成します。また、管理チームからのセキュリティ仕様に基づき、ユーザーまたはグループをそれらのアプリケーション・ロールにプロビジョニングします。
本番に移行する前に、Adamは、接続プール・パラメータを本番データベースに必要な値に変更する必要があります。Eden Corporation社では、Adamは本番接続プールを表示する権限を持っていますが、他のリポジトリ開発者は持っていません。したがって、Adamかテストから本番に接続プールを変更できず、リポジトリをマスター・ディレクトリに残したままにします。それは、開発者が、それを読み取って書き込むためのWindows権限を持っているためです。かわりに、彼は本番に必要な接続プールのXMLパッチを作成します。次に、彼は、sales.rpdをセキュアなディレクトリにコピーし、そのパッチを適用してから、テストを実行してそれが実際に本番データ・ソースに接続していることを確認します。その後、リポジトリを本番システムにアップロードし、本番クラスタのサーバーを起動します。
ヒント:
本番および他の環境への移行時に必要な接続プールの変更を自動化するには、Oracle BIサーバーXML APIを使用します。『Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンス』の「テスト環境から本番環境への移行」を参照してください。
マスター・リポジトリはまだテスト・データベースを指しているため、管理ツール・ユーザーはそれを参照できます。一方、本番リポジトリの新しいバージョンは、XMLパッチ・ファイルの接続プールの変更を適用することで、いつでも構築できます。
ここで本番の検証が実行されます。テスト・システムへの移行と同様に、重要な検証では、アプリケーション・ロールがすべて正しくなるように、オンライン・モードで整合性チェッカが実行されます。この検証が完了すると、フェーズIは本番になります。
架空の会社の例のフェーズIIでは、開発は新しいフェーズIIブランチで続行され、メイン・ブランチでは本番アプリケーションを追跡します。
この作業を管理するために、Adamはブランチ・プロジェクトを追加して、2番目のマスター・リポジトリの共有ディレクトリを設定し、1つはメイン、もう1つは新しいフェーズIIブランチに指定します。
SallyはさらにコンテンツをProjRevenueに追加します。彼女がその作業をしている間、Scottは新しいコンテンツを追加します。Scottがマージおよび公開を終えたら、Adamは新しいプロジェクトProjTargetを作成し、Scottの新しいコンテンツをそれに移動します。一方、彼らは本番で発生したすべての不具合に対処する必要があります。これもメインsales.rpdブランチで行われます。
次の項では、フェーズIIの開発について説明します。
架空の会社の事例で、Adamは最初に、新しいブランチのマスターを保持するために別のMUDディレクトリを作成します。また、SallyとScottがそれを読書きできるように、Windows共有セキュリティを設定します。
次に、Adamは、メイン・リポジトリをメインMUDディレクトリに配置します。彼は、既存のすべての機能を含んだそのブランチの新しいプロジェクトを追加します。その後、彼はリポジトリを閉じ自分のローカルの管理ツール・リポジトリ・フォルダのブランチ・プロジェクトをチェックアウトします。彼は、それを、ブランチMUDディレクトリにコピーします。そこでは、ブランチのマスターとして機能するようになります。
SallyとScottは再度プロジェクトをチェックアウトして、Sales InitiativeフェーズIIの開発を相互に並列して、また本番中のフェーズIと並列して開始します。
Scottは新しいプロジェクトに新しいコンテンツを追加しているため、新しいコンテンツにマップまたは結合する必要がある共有オブジェクトを提供する他のプロジェクトを1つ以上チェックアウトする必要があります。彼は、ProjQuotaをチェックアウトすることを選択します。
架空の会社Edenを使用して、新しいメジャーの作成方法を示します。
SallyとScottがフェーズIIを開発している間に、CEOの緊急リクエストが彼らにエスカレートされます。CEOは主要な販売マネージャにダッシュボード上のSales Quota Varianceという新しいメジャーを2日以内に閲覧させたいと考えています。
Scottは、フェーズIIブランチの新しいプロジェクトの作業を閉じます。新しいプロジェクトはチェックアウトされたままです。彼は新しいメジャーを含むプロジェクトProjQuoteをメイン・ブランチ・マスター・リポジトリsales.rpdからチェックアウトします。Scottは新しいメジャーおよび対応するプレゼンテーション列を作成して、ローカルでメジャーをテストし、再び変更をメイン・ブランチに公開します。
Scottは、チェックアウトされたフェーズIIリポジトリをローカル・ドライブから再度開いて、開発を続行します。
Adamは更新されたsales.rpdをテスト環境に送信し、そこでテスト・チームが修正を検証します。
Adamは修正したリポジトリを本番環境に送信する準備をします。彼はリポジトリ変更のパッチをテスターに送信します。
パッチを作成するために、Adamは変更されたリポジトリと本番で現在稼働中のリポジトリを比較します。本番で稼働しているリポジトリは、新しい変更をマージする前のメイン・リポジトリと同じであり、MUDディレクトリのバックアップ・リポジトリの1つです。本番で稼働している現在のリポジトリは、sales.006というバックアップであり、これはAdamが今後のブランチのマージのオリジナルとして特定しているものと同じです。彼は、これをsales.006.rpdにコピーし、管理ツールでそのファイルを表示して開けるようにします。後で別のマージに必要となる可能性があるため、単にその名前を変更できません。
この図は、sales.rpdとsales.006が含まれるMUDディレクトリのファイルを示しています。
Adamは更新が含まれるリポジトリsales.rpd
を開きます。「比較」を選択し、次に比較する古いバージョンにsales.006.rpdを選択します。「リポジトリの比較」ダイアログには、Adamがパッチに含めることができるバージョン間の差異が表示されます。
この図は、「リポジトリの比較」ダイアログを示しています。
Adamは「パッチの作成」をクリックして、結果をPatch_variance.xml
として保存します。パッチには、2つの新しい列を適用する必要があるオブジェクトとそれに関連する相互接続のみが含まれます。
ヒント:
複雑なパッチを使用すると、オブジェクトを削除したり、新しいプロパティ値でマージするオブジェクトを上書きすることができます。
Adamのパッチは、次のようになります。
<?xml version="1.0" encoding="ISO-8859-1"?> <Repository xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DECLARE> <LogicalTable name="F50 Facts Quotas" parentName=""Sales"" parentId="2000:68667" parentUid="2160843965" id="2035:69454" uid="2160843966" x="718" y="288"> <Description/> <Columns> <RefLogicalColumn id="2006:69460" uid="2160844041" qualifiedName=""Sales"."F50 Facts Quotas"."Quota Amount""/> <RefLogicalColumn id="2006:69786" uid="2160845070" qualifiedName= ""Sales"."F50 Facts Quotas"." Sales percent of quota""/> <RefLogicalColumn id="2006:70033" uid="2160845342" qualifiedName= ""Sales"."F50 Facts Quotas"." Sales Quota Variance""/> </Columns> <TableSources> <RefLogicalTableSource id="2037:69456" uid="2160844747" qualifiedName=""Sales"."F50 Facts Quotas"." F50 Facts Quotas""/> </TableSources> </LogicalTable> <LogicalColumn name="Sales Quota Variance" parentName= ""Sales"."F50 Facts Quotas"" parentId="2035:69454" parentUid="2160843966" id="2006:70033" uid="2160845342" isDerived="true" isWriteable="false"> <Description><![CDATA[quota - sales]]></Description> <Expr><![CDATA["Sales"."F50 Facts Quotas"."Quota Amount" - "Sales". "F10 Billed Rev."."Sales Revenue" ]]></Expr> </LogicalColumn> <PresentationTable name="F50 Facts Quotas" parentName= ""Sales Quota".""" parentId="4004:69706" parentUid="2160844968" id="4008:69707" uid="2160844969" hasDispName="false" hasDispDescription="false"> <Description/> <Columns> <RefPresentationColumn id="4010:69711" uid="2160844973" qualifiedName= ""Sales Quota".."F50 Facts Quotas"." Quota Amount""/> <RefPresentationColumn id="4010:70032" uid="2160845338" qualifiedName= ""Sales Quota".."F50 Facts Quotas"." Sales percent of quota""/> <RefPresentationColumn id="4010:70036" uid="2160845345" qualifiedName= ""Sales Quota".."F50 Facts Quotas"." Sales Quota Variance""/> </Columns> </PresentationTable> <PresentationColumn name="Sales Quota Variance" parentName=" "Sales Quota".."F50 Facts Quotas"" parentId= "4008:69707" parentUid="2160844969" id="4010:70036" uid="2160845345" hasDispName="false" hasDispDescription="false" overrideLogicalName="false"> <Description><![CDATA[quota - sales]]></Description> <RefLogicalColumn id="2006:70033" uid="2160845342" qualifiedName= ""Sales"."F50 Facts Quotas". "Sales Quota Variance""/> </PresentationColumn> </DECLARE> </Repository>
ヒント:
このパッチを適用する前に接続プール変更を行う必要はありません。本番で稼動するリポジトリにはすでに正しい接続プールの設定が行われています。パッチがこのロジックに影響することはないので、接続プールは介入されることなく正しく動作し続けます。
Adamはこのパッチを本番システムに移行および適用しておく必要があります。これを実行するにはいくつかの方法があります。
オフラインのメイン・リポジトリのパッチおよびアップロード
Adamは、管理ツールを使用してパッチ・マージを実行することで、自分のWindowsコンピュータでローカルに本番リポジトリのコピーにパッチを適用できます。その後、Sallyが前に自分のサンドボックスで実行したように、本番システムにそのリポジトリをアップロードできます。本番システムはクラスタ化されているため、リポジトリをアップロードした後にすべてのOracle BIサーバーを再起動する必要があります。Adamは、Fusion Middleware Controlを使用して手動でサーバーを一度に1つずつ再起動できます。このようにしてローリング再起動を実行すると、エンド・ユーザーが使用できない状態になることはありません。かわりに、Adamまたは運用スタッフの1人は、BI Systems Management APIを使用したスクリプトを作成し、ローリング再起動を自動化できます。
patchrpdユーティリティを使用して適所で本番リポジトリにパッチを適用
運用スタッフは本番システムに直接ログオンし、patchrpd
ユーティリティを使用してXMLパッチを適用できます。なんらかの競合が発生すると、ユーティリティは更新をキャンセルし、変更を行わずに終了します。更新が成功すると、前のパラグラフの説明にあるように、運用スタッフはローリング再起動を実行できます。
biserverxmlcliユーティリティを使用して稼働中システムにパッチ
この方法は、本番システムには使用しないでください。
管理ツールを使用して本番のOracle BIサーバーにオンライン・モードでログオンする権限がある場合、「名前を付けてコピー」を使用してそれをローカル・ドライブにコピーできます。
SallyとScottは、新しいブランチで変更を完了し、それらを公開します。
AdamはScottの新しいコンテンツを新しいプロジェクトprojTargetに追加します。彼は以前と同様のステップを実行し、ブランチ・リポジトリをテスト・チームに送信します。
テストが完了したら、MUDマージを使用して、そのブランチをメイン・ブランチにマージしなおします。その結果、新しく開発されたコンテンツを持つ本番パッチが、後で本番に配置されるようにマージされます。
sales.rpdにはすべての変更が含まれ、ブランチは不要になります。Sales.rpdが、統合テストに送信され、マージされたコンテンツが既存のコンテンツに不具合を起こさないことが確認されます。統合テストが完了したら、Adamは変更を含む別のパッチを作成し、運用スタッフに、稼働中の本番システムにそれを適用してもらいます。Salesイニシアティブ・フェーズIIは、これで本番になります。
架空の会社の例の次のフェーズで、SallyとScottはSalesイニシアティブ・フェーズIIIの開発を開始します。
一方、Helen RoweはHRイニシアティブの最初のフェーズを構築して、新しい独立のセマンティック・モデルを本番に配置します。
次の項では、フェーズIIIの開発について説明します。
架空の会社の例で、Helenのアプリケーションには、給与や医療情報などの機密性の高い個人情報が保持されます。
一方、Salesアプリケーションには、法的に機密性の高い財務情報が含まれます。企業のセキュリティ・コンプライアンスにより、これらの2つのチームは相互のデータまたはメタデータを参照することはできません。また、この2つのチームには、時間ディメンションなどの一般的なディメンションを除いて共有できるコンテンツはほとんどありません。この2つのチームのビジネス・ドライバ、予算およびスケジュールも異なります。
これらの理由により、Eden Corporation社の管理委員会は、リポジトリで独立したセマンティック・モデル(1つは販売部用、もう1つは人事部用)を使用することを決定しました。この方法では、共有オブジェクトが1つもないことを2つのチームが確認する必要があります。2つのリポジトリの間に競合は存在できません。これを確実にする最も簡単な方法は、トップレベル・オブジェクトの名前が競合しないようにすることです。複数の変数およびアプリケーション・ロールを使用する必要もあります。
ヒント:
ある管理委員会では、それぞれのトップレベル・オブジェクトの名前の前に各セマンティック・モデルに固有の接頭辞(販売部には「S_」、HRには「H_」など)を付けることを開発者に指示することで、トップレベル・オブジェクトが競合しないようにしています。このプラクティスにより、どのオブジェクトがどちらの組織に属しているかわかりやすくなります。別の委員会では、トップレベル・オブジェクトのマスター・リストを保持し、競合が発生しないように確認するためにトップレベル・オブジェクトの名前を提出することを新しいアプリケーションに求めたいと考えています。また、2方向マージでは、上書きによりコンテンツを破損したり予期しないオブジェクト名の変更が発生する前に、誤りを捕捉できます。
別のセキュリティ要件は、正しい開発者のみがそれぞれのリポジトリにアクセスできるように個々のMUDディレクトリにセキュリティを適用する必要があるということです。SallyとScottはSales MUDディレクトリから参照およびチェックアウトのみ実行できます。またHelenはHR MUDディレクトリから参照およびチェックアウトのみ実行できます。Mainディレクトリは本番に実際に存在するマージされたマスターを保持する必要があるので存在し続けますが、Adamのみがそのディレクトリを参照および変更する権限を持ちます。
Eden Corporation社の最後のセキュリティ要件は、独立のセマンティック・モデル開発者がマージ後にオンライン・モードで稼働中のリポジトリにアクセスする機能を無効にすることです。リポジトリ・パスワードは1つしかないので、リポジトリのパスワードおよびアクセス権を持つ開発者はオフライン・モードでそのすべてのコンテンツを参照および変更できます。ただし、オンライン・モードでは、開発者はOracle BIサーバーにログオンするためにデータ・アクセス・ユーザー名とパスワードも必要です。このセキュリティ要件を施行するために、Adamは開発者が本番にログオンしたり、このように本番をテストする権限を与えないようにする必要があります。本番運用スタッフはリポジトリ・パスワードを自分たちしか知らないパスワードに変更できますが、リポジトリ・パスワードは管理ツールを使用して変更されるため、Windowsコンピュータで変更を実行する必要があります。
Helenはセキュアな独立のセマンティック・モデルで1人で作業しているので、プロジェクトをチェックアウトする必要はありません。ローカル・コンピュータ上の新しいブランク・リポジトリからコンテンツの構築を開始する必要があります。
Helenは、コンテンツの構築およびユニット・テストを通常のステップで段階的に実行します。Helenはユニット・テストが完了すると、独立のリポジトリが完成します。彼女はリポジトリをAdamに送信します。彼はマスター・リポジトリを手動で更新するか、別の場所で2方向マージを実行します。Adamは、次のマージの手順のいずれかを実行します。
手動でリポジトリを更新
Adamは2つのリポジトリを補正して、トップレベル・オブジェクトに付与された異なる名前を考慮してIDを再割当てします。このプラクティスにより、マージ時に競合が発生しなくなります。
Adamはマスター・リポジトリをMUDディレクトリからローカル・ディレクトリにコピーして、必要な更新を手動で実行し、Helenのリポジトリのコンテンツをマスター・リポジトリに追加します。それから、マスター・リポジトリをマスター・ディレクトリに再度コピーします。
別の場所で2方向マージを実行
Adamは2つのリポジトリを補正して、トップレベル・オブジェクトに付与された異なる名前を考慮してIDを再割当てします。このプラクティスにより、マージ時に競合が発生しなくなります。
Adamはマスター・リポジトリをMUDディレクトリからローカル・ディレクトリにコピーして、リポジトリ・マージ・ウィザードを使用して2方向マージを実行し、マスター・リポジトリをマスター・ディレクトリに再度コピーします。
マージ後に、Adamは展開されるコンテンツを管理するための新しいプロジェクトhr_payrollを作成します。彼はHelenのコンテンツをそのプロジェクトに追加します。また、それをメインからチェックアウトし、HR Branch MUDディレクトリに送信します。プロジェクトのチェックアウトを使用すると、後でIDおよびマージの管理が容易になります。
Adamは接続プール・パラメータを調整し、リポジトリをテスト・コンピュータに移行します。不具合が見つかった場合は、Helenがhr_payrollプロジェクトをチェックアウトし、それを修正して、ユニット・テストをしてから公開します。Helenは、チェックアウトしたブランチ・プロジェクトから自分の機能プロジェクトをチェックアウトします。Adamは、それをテスト・システムに移行してさらにテストします。テストが完了したら、彼は、完了したHRブランチ・リポジトリをメイン・ブランチに戻してマージし、統合されたリポジトリをテスト・システムの統合テストに送信します。
統合されたリポジトリでテストが完了すると、本番への移行の準備が整います。ここでは、完全なリポジトリの移行、またはpatchrpd
を使用した本番環境へのパッチの適用というオプションがあります。両方の方法ともローリング再起動が必要です。
このステップの実行後には、本番リポジトリにイニシアティブSとイニシアティブHの両方のコンテンツが格納されます。