Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.1.0) E77227-02 |
|
前へ |
次へ |
ローカル・コンピュータでメタデータを変更し、テストした後、開発者はローカルで行った変更をマルチユーザー開発ディレクトリのマスター・リポジトリに公開する必要があります。
Oracle BIリポジトリの開発プロセスでは、3方向のマージを使用して同時開発を管理します。最初にローカル環境でメタデータのマージが実行され、次にマスター・リポジトリとマージされます。3方向のマージでは、次のリポジトリ特性に基づいてローカルの変更が特定されます。
マスターRPD
プロジェクト抽出時のベースラインRPDまたはマスターRPDのスナップショット
ローカルで開発および変更された現在のRPD
変更は、マージと調整によって管理されます。マージ・プロセスのほとんどは自動で、変更内容は競合しません。競合するメタデータ・ソースがある場合、開発者はそれらを特定して解決できます。
また、管理者は複数のリポジトリの変更内容を手動でマージしたり、特定のMUD環境外の様々なリポジトリからオブジェクトをインポートすることもできます。
変更内容は頻繁にマージしてください。マージ・プロセスは非常に複雑で、多数の変更が加えられている場合はプロセスが困難になることがあります。マージ・プロセスでオブジェクトがどのようにマージされるかの詳細は、マージ・ルールを参照してください。
定期的にサブセット・リポジトリをリフレッシュし、競合を早期に特定することをお薦めします。サブセットのリフレッシュによって、サブセットがマスターの最新バージョンと再度マージされ、リポジトリが開いたままになり、公開する準備ができるまで変更を続行できるようになります。
この項では、次の項目について説明します。
このトピックでは、マルチユーザー開発のマージ・プロセスについて説明します。
マージ・プロセスには次のファイルが含まれます。
オリジナルまたは現在(リフレッシュ済)のいずれかのローカル(サブセット)リポジトリ。ローカル・サブセット・リポジトリは、次のいずれかです。
サブセットのリフレッシュが実行されていない場合、オリジナルの抽出したままのプロジェクトまたはリポジトリ全体の状態が含まれています。このリポジトリの名前は「original」で始まります(例: originalDevelopment2.rpd)。
サブセットのリフレッシュを実行済である場合、サブセットのリフレッシュ中に行われた最後のマージ以降のプロジェクトまたはリポジトリ全体の状態が含まれています。このリポジトリの名前は「current」で始まります(例: currentDevelopment2.rpd)。
変更済ローカル(サブセット)リポジトリ。開発者によって変更された後の、抽出されたプロジェクトが格納されます。このバージョンは、ローカル・サブセット・リポジトリのオリジナルまたは現在のバージョンと同じ場所に保存されます。
最新のマスター・リポジトリ。最新のマスターはローカルにコピーされてマージされ、マージ後にマルチユーザー開発ディレクトリに公開されます。このマージの前に、別の開発者がファイルに変更を加えた可能性があります。
マージ中には、管理ツールによって、追加されたオブジェクトがあるかどうかがチェックされ、オブジェクトが見つかった場合は警告メッセージが表示されます。この手順では、次の処理が実行されます。
追加されたオブジェクトに関する警告。プロジェクトをチェックアウトする開発者は、そのプロジェクトを変更し、再度チェックインすることができます。削除と変更では、プロジェクトの整合性が維持されます。ただし、オブジェクトを追加した場合は、どのプロジェクトにも属さないオブジェクトがリポジトリに挿入される可能性があります。そのため、プロジェクト関連のすべてのオブジェクトがチェックされ、新しいオブジェクトが見つかった場合は警告メッセージが表示されます。
注意:
新しく作成したメタデータをプロジェクトのその後の抽出バージョンに表示するには、マスター・リポジトリのプロジェクト定義に追加する必要があります。たとえば、開発者がプロジェクトをチェックアウトし、新しいオブジェクトを追加して、チェックインした場合、プロジェクト定義に明示的に追加するまで、新しいオブジェクトはプロジェクトの抽出バージョンに表示されません。手順については、プロジェクトの作成を参照してください。
関連オブジェクトの集約。警告メッセージでは、親オブジェクトのみが報告されます。メッセージをより便利にするために、管理ツールによってすべてのオブジェクトが集約されます。たとえば、開発者が新しいビジネス・モデルを追加した場合、警告メッセージにはビジネス・モデルのみが含まれ、表、列、ディメンションなどの名前は表示されません。
開発者が変更内容をネットワークに公開すると、次の処理が行われます。
マルチユーザー開発ディレクトリのマスター・リポジトリが、開発者が加えた変更を含むリポジトリで上書きされます。
master_repository.lckファイルが削除されます。別の開発者が、変更されたプロジェクトをマスター・リポジトリからチェックアウトする、またはリポジトリ全体をチェックアウトすると、最初の開発者が加えた変更が他の開発者に公開されます。
マルチユーザー開発の公開プロセスでは、標準のリポジトリ・マージ・プロセスと同じテクノロジが使用されますが、重要な違いがいくつかあります。
たとえば、MUDマージの場合は、開発者によるマスター・リポジトリのパスワードやその他の重要オブジェクトの上書きを防止するため、通常、セキュリティ設定とデータ・ソースの変更を保持しないことが望まれます。このため、セキュリティ設定とデータ・ソース接続の変更は、MUDマージでは保持されません。さらに、挿入(作成されたオブジェクト)が自動的に適用されます。
詳細は、マルチユーザー開発マージのマージ・ルールと動作を参照してください。
公開プロセスが始まると、Oracle BI管理ツールによって、現在のバージョンのマスター・リポジトリがマルチユーザー開発ディレクトリから開発者のコンピュータ上のローカル・リポジトリ・ディレクトリに自動的にコピーされます。
公開される場所は、ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repository
のようになります。公開プロセスでは、ローカルおよびマルチユーザー開発ディレクトリのログ・ファイルも更新されます。これが必要なのは、開発者がプロジェクトをチェックアウトした後または最後のサブセットのリフレッシュ以降にマルチユーザー開発ディレクトリのマスター・リポジトリが変更されている可能性があるためです。
マルチユーザー開発オプション・ファイルでMandatory Consistency CheckオプションをYesに設定することで、ネットワークへの公開手順中に必須の整合性チェックを強制できます。
オプション・ファイルの詳細は、マルチユーザー開発オプションの設定を参照してください。
このオプションをYesに設定すると、整合性チェッカが公開プロセスの一部として実行されます。指定したリポジトリにエラーがある場合、公開を続行することはできません。
整合性エラーが発生した場合は、メッセージが表示されます。次のいずれかのオプションを選択します。
はい: 整合性チェック・エラーをただちに修正するにはこのオプションを選択します。このプロセス中はマスター・リポジトリがロックされたままになります。
このオプションを選択してから気持ちが変わった場合(マスターのロックを解除する必要がある場合や変更の修正が予想以上に複雑である場合など)は、「ファイル」→「マルチユーザー」→「公開を元に戻す」を選択します。このオプションで、マスター・リポジトリのロックが解除され、現在マージされているマスター・リポジトリから抽出したままの最新のサブセット・リポジトリに戻ります。
いいえ: 公開手順を取り消し、整合性チェック・エラーを後で修正するには、このオプションを選択します。マスター・リポジトリはロック解除され、最新のサブセット抽出リポジトリに戻ります。