| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1) E70045-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1) E70045-01 |
|
前 |
次 |
この付録では、特定のビジネス・ケースで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社ではリポジトリ・ファイルの構造を計画することの重要性を認識しています。主要なオブジェクトには所有者が割り当てられるため、開発者は競合が発生したときに誰に照会したらよいか、自身で変更してはならないオブジェクトはどれかがわかります。
ヒント: 複数の独立したセマンティック・モデルをホストする場合、トップレベル・オブジェクトの名前を列挙して、名前が重複しないようにしてください。
表B-1および表B-2に、イニシアティブSおよびイニシアティブHでmain.rpdの高レベル・オブジェクトを示します。これらは、プロジェクトおよび所有者にマップされます。Adamは、イニシアティブSおよびイニシアティブHの全体の所有者です。
表B-1 プロジェクトおよび所有者にマップされたイニシアティブSのリポジトリ・オブジェクト
| オブジェクト・タイプ | オブジェクト | 所有者 | 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 |
はい |
はい |
はい |
表B-2 プロジェクトおよび所有者にマップされたイニシアティブHのリポジトリ・オブジェクト
| オブジェクト・タイプ | オブジェクト | 所有者 | 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が平行して開発を行います。Sallyが初期コンテンツを作成し、Adam Straightがそれを複数のプロジェクトに分割します。その後、彼はMUDディレクトリを作成し、SallyとScottがチェックアウトして開発を行えるようにします。ユニット・テストの後、彼らの変更をマージして公開し、その後、Adamがリポジトリをテスト環境に移行します。不具合の修正サイクルの後、Adamがリポジトリを本番にプロモートします。
次の項では、フェーズIの開発について説明します。
Sally Andreは、空のRPDからイニシアティブSを開始します。いくつかの論理スターおよびサブジェクト・エリアを最初に定義している場合、リポジトリをMUDプロジェクトに分割する方が容易なため、始めにフェーズIに必要な物理モデルを開発します。独自のローカル・テスト・データソースの接続プールの詳細も含まれます。
ヒント: 物理モデルには、物理表、すべての物理表に別名を定義して意味のある名前を付けるためのベスト・プラクティス、および結合が含まれます。
図B-1に、イニシアティブSの物理モデルを示します。
Sallyは、物理レイヤーをビジネス・モデルおよびマッピング・レイヤーにドラッグしていくつかの初期コンテンツを作成します。また、不要な表を削除したり、スター結合が正しくなるようにします。さらに、開発時に必要なすべての物理表が開始論理表からのマッピングを持たせ、チェックアウトするときにそれらがプロジェクトに含まれるようにします。Sallyはこれらの手順を使用してF10 RevenueおよびF50 Quotasの2つのファクト表を作成し、これらはプロジェクトの基盤として機能します。
また、Sallyはビジネス・モデルのプロジェクトをマップするためのサブジェクト・エリアをいくつか持つ必要があります。ビジネス・モデル全体をドラッグすることができますが、ビジネス・モデルを右クリックして「Logical StarsとSnowflakes向けのサブジェクト・エリアの作成」を選択するとこの機能をより便利に実行できます。この機能を使用すると、それぞれの論理ファクト表からサブジェクト・エリアを作成できます。
Sallyは、この時点でサブジェクト・エリアのコンテンツについて考慮する必要はありません。重要なのは各サブジェクト・エリアを同じプロジェクトの論理ファクト表にマップするということです。ただし、サブジェクト・エリアは管理ミーティングSales QuotaおよびSales Revenueで合意された計画に基づいて名前を付けます。
Sallyはこの時点で、RevenueおよびQuotaファクト表に基づいて最初の2つのプロジェクトを作成するための十分なMUD管理者のコンテンツを持ちます。これらを確認するには、Sallyは最低でも次の基準を満たしていることを確認する必要があります。
別のプロジェクトに対する、管理計画に応じた最低1つの論理ファクト表。論理ファクト表の列は、完成していなくても、さらには正しく名前が付けられていなくてもかまいませんが、すべての物理コンテンツをマップできる程度に完成している必要があります。
リポジトリが整合性チェックに合格できる十分な論理ディメンション。
プロジェクトに含められる1つ以上の論理ファクト表にマップされる物理コンテンツ。
管理計画に応じて必要なサブジェクト・エリア。
Eden Corporation社のMUD管理者Adam Straightは、ここで次の手順を実行してプロジェクトを作成し、それらをチェックアウトできるようにします。
彼は、最初に、マスターRPDを格納するRPD_mainというMUDディレクトリを作成します。このマスターRPDには、開発者用のコンテンツのスーパーセットが含まれています。ユーザーはこのマスターからプロジェクトをチェックアウトし、変更を共有する場合はそれらを戻してマージします。Sallyは自分の初期RPDをマスター・フォルダにコピーし、Adamが最初の2つのプロジェクトProjRevenueとProjQuotaを作成できるようにします。
最初に、Adamは管理ツールでマスターRPDを開き、「管理」→「プロジェクト」を選択します。ここで、プロジェクト・マネージャで、「アクション」→「新規プロジェクト」を選択します。彼はこのプロジェクトに「ProjRevenue」という名前を付けてから、プロジェクトの中央の論理ファクト表を選択します。リストの一番上のオブジェクトが開き、論理ファクト表が表示されます。また、論理ファクト表が属するビジネス・モデルごと、またはサブジェクト・エリアごとにまとめて表示することもできます。
図B-2は、Adamが論理ファクト表を表示できる各種の方法を示します。
図B-2 ビジネス・モデルおよびサブジェクト・エリアごとにグループ化されたファクトを含むプロジェクト・ダイアログ
Adamは、サブジェクト・エリアのグループを使用して同じファクト表を選択できたかもしれませんが、便宜上、ビジネス・モデルごとにファクトをグループ化することに決めます。彼はこのプロジェクトに指定されたファクト表、さらにデフォルトのアプリケーション・ロールおよびサブジェクト・エリアを追加します。カスタムで定義されたアプリケーション・ロール、ユーザー、変数または初期化ブロックはまだないため、それらをプロジェクトに追加することはできません。Adamは、2番目のプロジェクトのProjQuotaでもこの処理を繰り返します。
ヒント: 一部の明示的なオブジェクトは、両方のプロジェクトでアプリケーション・ロールを共有しているため、両プロジェクトで同一になります。同様に、多くの暗示的なプロジェクトのオブジェクトも共有されます(特に論理モデルと物理モデルの両方のディメンション表など)。作業しやすい小さなサブセットを複数作成すると、プロジェクトは使用しやすくなります(セキュリティの目的ではありません)。それぞれのトップレベル・オブジェクトの所有者がチーム全体に割り当てられてドキュメントが作成される管理プロセスにおいては、開発者が競合を回避できることからも、これは重要になります。
プロジェクトの論理ファクト表F10 Bill Revの所有者はSally Andreであり、このプロジェクトの所有者であるScott Bakerではありませんが、Adamはこれをこのプロジェクトに含めています。これは、Scottが両方のファクト表(販売ノルマの割合)のメジャーから導出するメジャーを作成する必要があるため、このようにしています。要は、ユーザーが所有するオブジェクトのみでなく、ユーザーの要件の実装に必要なコンテンツのサブセットもユーザーに提供されるということです。
Adamは、マスターRPDを共有ドライブRPD_Mainに「sales.rpd」として保存します。これで、ユーザーはプロジェクトをチェックアウトし、作業を平行して進められるようになります。
ここで、2人の開発者は、マスター・リポジトリの管理ツール・クライアントを設定して、プロジェクトをチェックアウトし、作業を開始します。Sallyはまず、マスター・リポジトリを使用するように管理ツール・クライアントを設定します。そのためには、「ツール」→「オプション」を選択してから、「マルチユーザー」タブを選択します。そこで、マスター・リポジトリ・ディレクトリへのポインタを設定します。また、ログやロックで便利になるので、彼女のフルネームも入力します。次に、彼女は自分のプロジェクトをチェックアウトして、そのプロジェクトでの作業を開始します。
一方、マスター・リポジトリ・ディレクトリには、sales.000とsales.mhlという2つの新しいファイルが作成されています。図B-3に、これらの新しいファイルを示します。
sales.000ファイルは、Sallyがsales.rpdをチェックアウトするときに作成されるsales.rpdの自動バックアップ・ファイルです。問題が発生した場合、このファイルを使用してロールバックできます。sales.mhlファイルでは、プロジェクト、コンピュータ、ユーザーなどのパラメータおよびチェックアウト・ステータスを追跡します。
一方、Sallyのローカル・リポジトリ・ディレクトリには、3つのファイルが作成されています。
originalProjRevenue.rpd: このファイルは、チェックアウト時のプロジェクト・サブセットRPDです。これは、3方向のマージ処理において後でオリジナルとして使用されます。またSallyが変更を廃棄する場合にも使用されます。
ProjRevenue.rpd: このファイルには、自己完結のサブセット・プロジェクト(ProjRevenue)のみが含まれます。これは、編集時に開くファイルです。
ProjRevenue.rpd.Log: このファイルは、管理ツールのこの編集セッション用のログ・ファイルです。管理ツールで「ファイル」→「マルチユーザー」→「履歴」を選択すると、そのコンテンツを表示できます。
図B-4に、ローカル・リポジトリ・ディレクトリの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」→「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 Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。
SallyのOracle BIサーバーはLinuxシステム上にあるため、管理ツール・クライアントからそこのBIサーバーにアクセスできるように彼女のWindowsコンピュータにODBC接続を設定する必要があります。
Sallyは、Linuxコンピュータ上のOracle BIサーバーを指すように、Oracle BIサーバーODBC DSNを手動で追加します。Oracle BIサーバーのODBC DSNの作成方法の詳細は、『Oracle Fusion Middleware 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 Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のアプリケーション・ロールの作成に関する項を参照してください。
次に、Sallyは新しいアプリケーション・ロールを彼女のリポジトリに追加して、それらをオブジェクトの権限およびデータ・アクセス・フィルタに使用する必要があります。そのためには、Sallyは次の処理を実行します。
Sallyは管理ツールを開き、「ファイル」→「開く」→「オンライン」を選択します。そこで、彼女のローカルOracle Business Intelligenceスタックに接続するローカルWindows ODBC DSNを選択して、リポジトリ・パスワードを入力し、さらにインストール時に作成したスタックを管理するためのデフォルトのユーザー名とパスワードも入力します。
次に、「管理」→「アイデンティティ」を選択して、Identity Managerを開きます。ナビゲーション・ツリーで「BIリポジトリ」をクリックしてから、「アプリケーション・ロール」タブをクリックします。すると、5つのデフォルトのアプリケーション・ロールに加えて、作成したばかりの新しいロールも表示されます。
Sallyは、Sales Repアプリケーション・ロールをダブルクリックして、「権限」をクリックします。「データ・フィルタ」タブで、このロールに属するユーザーは自分自身で作成した売上を参照することのみが許可されることを示す式を含むデータ・フィルタを追加します。「オブジェクト権限」タブで、Sales Repユーザーに収益の参照を許可しノルマやコスト情報の参照を許可しないように、「読取り」、「読取り/書込み」、「アクセス権なし」を設定します。「問合せ制限」タブでは、「最大行数」および「最大時間」をデフォルトのままにして、時間の制限は何も設定しません。「OK」をクリックしてIdentity Managerに戻ります。
次に、「Sales Management」アプリケーション・ロールをダブルクリックして、管理委員会の決定に基づいてこのロールに最適な「データ・フィルタ」、「オブジェクト権限」および「問合せ制限」を設定します。
最後にIdentity Managerを終了します。
Sallyは、「変更のチェックイン」メニュー・オプションを使用して、オンライン・モードで行った変更をコミットします。このアクションによってオンライン・モードでの変更が彼女のローカル・サブセット・リポジトリ(ProjRevenue.rpd)に伝播されますが、マスターMUDリポジトリにはコミットされません。Sallyは、後のステップでマスター・リポジトリに変更を公開します。
Sallyが次に自分のプロジェクトをチェックアウトするときに新しい変数とアプリケーション・ロールがそれに含まれているようにするには、自分の変更をチェックインする前にプロジェクトにそれらを追加する必要があります。これを行うには、Adamがプロジェクトを作成したときと同じ手順を実行します。「管理」→「プロジェクト」を選択し、自分のプロジェクトを選択し、左のペインで新しいオブジェクトを選択して、「追加」をクリックします。
Sally AndreはProjRevenueプロジェクトで作業を行っていますが、Scott BakerはProjQuotaで作業を開始します。彼はMUDの管理ツール・オプションを設定し、プロジェクトをチェックアウトして、作業を開始しています。
Scottは、オンライン・モードを選んで作業します。Oracle BIサーバーで稼働中にリポジトリを変更するので、オンライン・モードで作業することで開発とユニット・テストの循環が強化されます。管理ツールのツールバーで「変更のチェックイン」をクリックするたびに、稼働中のサーバーに変更が適用されます。その直後にアンサーに移動して、そこで変更をテストできます。プレゼンテーション・レイヤー・オブジェクトを追加、削除、名前変更または再編成する場合、アンサーの基準タブでメタデータをリロードして、そこに表示されているツリーをリフレッシュする必要があります。
最初に、Scottは自分のローカルOracle Business Intelligenceスタックを開始し、チェックアウト済のリポジトリをアップロードします。Oracle BIサーバーを再起動して、管理ツールを開き、オンライン・モードでリポジトリを開きます。
Scottは、接続プールの設定を変更し、自分のローカル・テスト・データベースを指すようにする必要があります。これは、マスター・リポジトリにはSallyの設定が含まれているためです。このマージ・プロセスで、これらの接続プールの変更は、すでにマスター・リポジトリに存在する接続プールによってオーバーライドされます。したがって、Scottは、次にチェックアウトするときに自分のローカル・テスト接続プールの変更を再び適用することが必要になります。
ヒント: 本番および他の環境への移行時に必要な接続プールの変更を自動化するには、Oracle BIサーバーXML APIを使用します。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンスのテストから本番環境への移行に関する項を参照してください。
Scottの次のタスクは、キーを削除して彼の論理ファクト表をクリーンアップすることです。また、メジャーにSUM集計ルールおよび業務上わかりやすい名前(Quota Amount)を指定します。
F10論理表はSallyが所有しているので、Scottは表内の何も変更しません。彼女がマスターRPDに対して変更をマージおよび公開したら、彼も同じことを行います。そこで、彼は再度チェックアウトして彼女の変更を取得します。
次に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はここで、マスター・リポジトリで直接いくつかのタスクを実行する必要があります。つまり、「ファイル」→「マルチユーザー」→「チェックアウト」ではなく、「ファイル」→「開く」→「オフライン」を使用します。
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 Fusion Middleware 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をチェックアウトすることを選択します。
SallyとScottがフェーズIIを開発している間に、CEOの緊急リクエストが彼らにエスカレートされます。CEOは主要な販売マネージャにダッシュボード上の「Sales Quota Variance」という新しいメジャーを2日以内に閲覧させたいと考えています。
Scottは、フェーズIIブランチの新しいプロジェクトの作業を閉じます。これはチェックアウトの状態が続きます。その後、新しいメジャーを含むプロジェクトProjQuoteをメイン・ブランチ・マスター・リポジトリ(sales.rpd)からチェックアウトします。彼は新しいメジャーおよび対応するプレゼンテーション列を作成して、ローカルでそれをテストし、再び変更をメイン・ブランチに公開します。
Scottは、チェックアウトされたフェーズIIリポジトリをローカルドライブから再度開いて、開発を続行します。
一方、Adamは新しいsales.rpdをテスト環境に送信し、そこでテスト・チームが修正を検証します。
次に、Adamは修正したリポジトリを本番環境に送信する準備をします。リポジトリ全体ではなく、変更のパッチを送信します。
パッチを作成するために、Adamは変更されたリポジトリと本番で現在稼働中のリポジトリを比較します。本番で稼動しているリポジトリは、新しい変更をマージする直前のメイン・リポジトリと同じです。そのため、それはMUDディレクトリのバックアップ・リポジトリの1つです。本番で稼動している現在のリポジトリは、sales.006というバックアップであり、これは彼が今後のブランチのマージのオリジナルとして特定しているものと同じです。彼は、これをsales.006.rpdにコピーし、管理ツールでそのファイルを表示して開けるようにします。(後で別のマージに必要となる可能性があるため、単にその名前を変更できません。)
図B-6に、sales.rpdとsales.006が含まれるMUDディレクトリのファイルを示します。
次に、Adamは更新sales.rpdが含まれるリポジトリを開きます。「ファイル」→「比較」を選択してから、比較する古いバージョンにsales.006.rpdを選択します。「リポジトリの比較」ダイアログには、パッチに含まれるバージョン間の差異が表示されます。
図B-7に、「リポジトリの比較」ダイアログを示します。
次に、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つは人事部用)を使用することを決定しました。この手法では、共有オブジェクトがないことと、それらのコンテンツに矛盾が発生しないことを確実にするために2つのチームが必要です。これを確実にする最も簡単な方法は、トップレベル・オブジェクトの名前が競合しないようにすることです。変数およびアプリケーション・ロールも異なるものにする必要があります。
ヒント: ある管理委員会では、それぞれのトップレベル・オブジェクトの名前の前に各セマンティック・モデルに固有の接頭辞(販売部には「S_」、HRには「H_」など)を付けることを開発者に指示することで、トップレベル・オブジェクトが競合しないようにしています。このプラクティスにより、どのオブジェクトがどちらの組織に属しているかわかりやすくなります。別の委員会では、トップレベル・オブジェクトのマスター・リストを保持し、競合が発生しないように確認するためにトップレベル・オブジェクトの名前を提出することを新しいアプリケーションに求めたいと考えています。また、2方向マージでは、上書きによりコンテンツを破損したり予期しないオブジェクト名の変更が発生する前に、誤りを捕捉できます。
別のセキュリティ要件は、正しい開発者のみがそれぞれのリポジトリにアクセスできるように個々のMUDディレクトリにセキュリティを適用する必要があるということです。SallyとScottはSales MUDディレクトリから参照およびチェックアウトのみ実行できます。またHelenはHR MUDディレクトリから参照およびチェックアウトのみ実行できます。Mainディレクトリは本番に実際に存在するマージされたマスターを保持する必要があるので存在し続けますが、Adamのみがそのディレクトリを参照および変更する権限を持ちます。
Eden Corporation社の最後のセキュリティ要件は、独立のセマンティック・モデル開発者がマージ後にオンライン・モードで稼働中のリポジトリにアクセスする機能を無効にすることです。リポジトリ・パスワードは1つしかないので、リポジトリのパスワードおよびアクセス権を持つ開発者はオフライン・モードでそのすべてのコンテンツを参照および変更できます。ただし、オンライン・モードでは、開発者はOracle BIサーバーにログオンするためにデータ・アクセス・ユーザー名とパスワードも必要です。このセキュリティ要件を施行するために、Adamは開発者が本番にログオンしたり、このように本番をテストする権限を与えないようにする必要があります。また、本番運用スタッフはリポジトリ・パスワードを自分たちしか知らないパスワードに変更できますが、リポジトリ・パスワードは管理ツールを使用して変更されるため、Windowsコンピュータでこのタスクを実行する必要があります。
SallyとScottは、新しいセキュアな販売部ブランチMUDディレクトリから彼らのプロジェクトをチェックアウトします。彼らは自分の作業を開始します。
Helenはセキュアな独立のセマンティック・モデルで1人で作業しているので、まだプロジェクトをチェックアウトする必要はありません。実際は、ローカル・コンピュータ上の新しいブランク・リポジトリからコンテンツの構築を開始する必要があります。彼女は、コンテンツの構築およびユニット・テストを通常の手順で段階的に実行します。
Helenはユニット・テストが完了すると、独立のリポジトリが完成します。彼女はそれをAdamに送信し、Adamはマスター・リポジトリを手動で更新するか、別々の場所で2方向マージを実行します。Adamは、次のマージの手順のいずれかを実行します。
手動でリポジトリを更新
最初に、Adamは2つのリポジトリを補正して、トップレベル・オブジェクトに付与された異なる名前を考慮してIDを再割り当てします。このプラクティスにより、マージ時に競合が発生しなくなります。
次に、Adamはマスター・リポジトリをMUDディレクトリからローカル・ディレクトリにコピーして、必要な更新を手動で実行し、Helenのリポジトリのコンテンツをマスター・リポジトリに追加します。それから、マスター・リポジトリをマスター・ディレクトリに再度コピーします。
別の場所で2方向マージを実行
最初に、Adamは2つのリポジトリを補正して、トップレベル・オブジェクトに付与された異なる名前を考慮してIDを再割り当てします。このプラクティスにより、マージ時に競合が発生しなくなります。
次に、Adamはマスター・リポジトリをMUDディレクトリからローカル・ディレクトリにコピーして、「リポジトリ・マージ・ウィザード」を使用して2方向マージを実行し、マスター・リポジトリをマスター・ディレクトリに再度コピーします。
ヒント: 空のリポジトリを作成するには、「ファイル」→「新規リポジトリ」を選択します。その後、名前(blank.rpdなど)とリポジトリ・パスワードを指定します。「メタデータのインポート」には「いいえ」を選択し、「終了」をクリックします。
マージ後に、Adamは展開されるコンテンツを管理するための新しいプロジェクトhr_payrollを作成します。彼はHelenのコンテンツをそのプロジェクトに追加します。また、それをメインからチェックアウトし、HR Branch MUDディレクトリに送信します。プロジェクトのチェックアウトを使用すると、後でIDおよびマージの管理が容易になります。
Adamは接続プール・パラメータを調整し、リポジトリをテスト・コンピュータに移行します。不具合が見つかった場合は、Helenがhr_payrollプロジェクトをチェックアウトし、それを修正して、ユニット・テストをしてから公開します。(彼女は、チェックアウトしたブランチ・プロジェクトから自分の機能プロジェクトをチェックアウトします。)Adamは、それをテスト・システムに移行してさらにテストします。テストが完了したら、彼は、完了したHRブランチ・リポジトリをメイン・ブランチに戻してマージし、統合されたリポジトリをテスト・システムの統合テストに送信します。
統合されたリポジトリでテストが完了すると、本番への移行の準備が整います。ここでは、完全なリポジトリの移行、またはpatchrpdを使用した本番環境へのパッチの適用というオプションがあります。両方の方法ともローリング再起動が必要です。
この手順の実行後には、本番リポジトリにイニシアティブSとイニシアティブHの両方のコンテンツが格納されます。
