PMC 配布側の手順

更新の配布側が PMC 管理を初期設定する手順です。

後のセクションで手順の詳細を説明します。

配布側初期設定手順の最初のステップは、PMC パラメータの定義です。

詳細については、パラメータ (ttpmc0100s000) セッションを参照してください。

ソリューション、コレクション、パッチおよびフィーチャパックを作成して基準 VRC にリンクする前に、基準 VRC を定義する必要があります。

基準 VRC はソフトウェア製品の管理用識別子であり、物理 VRC ではありませんが、ソフトウェア構成要素を含む物理 VRC に常に接続される必要があります。

PMC 配布側は基準 VRC をエクスポート VRC に接続し、PMC 受取側は基準 VRC を更新 VRC に接続します。

詳細については、基準 VRC (ttpmc0110m000) セッションを参照してください。

基準 VRC 間の関係を定義するには基準 VRC 結合が必要です。

基準 VRC は、別の基準 VRC との関係がなくても、常に基準 VRC 結合のメンバーでなくてはなりません。

基準 VRC を基準 VRC 結合にリンクしていないと更新を作成できません。

次の例は、関係を持つ 2 つの基準 VRC の基準 VRC 結合を示したものです。

詳細については、基準 VRC 結合 (ttpmc0111m000) セッションを参照してください。

必要に応じて、コレクション履歴を表示します。履歴を表示するには、更新履歴 (ttpmc1560m000) セッションを使用します。

必要に応じて、パッチ履歴を表示します。パッチ履歴は、更新履歴 (ttpmc1560m000) セッションで表示できます。

必要に応じて、フィーチャパック履歴を表示します。フィーチャパック履歴は、更新履歴 (ttpmc1560m000) セッションで表示できます。

このセクションでは、フィーチャパックの開発および構築プロセスに該当するさまざまな局面について説明します。

次の初期設定では、配布側が開発/メンテナンスの結合環境を含むものとします。この結合環境は、発行済フィーチャパックのメンテナンス、新規フィーチャパックの開発、およびソリューションやフィーチャパックの物理的な作成をサポートします。

これ以降の図は、時間の経過に伴う変化を示したものです。

初期マスタ製品 B61_a (簡略化するため、以下 ｢フィーチャパック 0｣ とします) が発行されるとすぐに、メンテナンス VRC B61M_a で B61_a のメンテナンスが開始します。新規フィーチャパックの開発は B61D_a1 で実行されます。B61M_a における修正はすべて B61D_a1 に移植されます。B61D_a1 の PMC レジストリにおいて、これらの修正は廃止ソリューションとして登録されます。B61D_a1 が凍結された後、最終的なフィーチャパックが作成され、同じ環境にインストールされてこのフィーチャパックのメンテナンスを行うことができます。

現在、B61M_a および B61M_a1、すなわちフィーチャパック 0 とフィーチャパック 1 を平行してメンテナンスできます。フィーチャパック 1 の凍結時からフィーチャパック 1 のインストール時までにフィーチャパック 0 に対して作成されたバグ修正を移植する必要があります。フィーチャパック 2、すなわち B61D_a2 が現在開発中です。

新規フィーチャパックについて、このサイクルを何度でも繰り返すことができます。

ローカライズや拡張などの派生製品を扱うと、初期設定がやや複雑になります。

フィーチャパック 1 の上にローカライズを作成する必要があるとします。

新 VRC はフィーチャパック 1 の上に作成されます (B61D_a1_loc1)。

ローカライズは標準フィーチャパックの上に構築され、PMC において 1 つのフィーチャパックとして配布されます。したがって、派生製品用のマスタメディアを作成する必要はありません。ローカライズのフィーチャパック 0 が使用可能になるとすぐに、このフィーチャパックはメンテナンス VRC、B61M_a1_loc1 にインストールされます。

ローカライズは開発 VRC B61D_a2_loc1 にもコピーされます。

最初に実行しなくてはならない処理は、標準 VRC B61M_a1 のバグ修正をすべてローカライズメンテナンス VRC B61M_a1_loc1 にマージし、ローカライズ用の PMC ソリューションを作成することです。

さらに、B61D_a2 の機能拡張を B61D_a2_loc1 にマージする必要があります。

この時点から、ローカライズは標準ソフトウェアと同じフィーチャパックサイクルに従います。

フィーチャパック 2 について同じアプローチを繰り返します。

標準ソフトウェアとローカライズの物理フィーチャパックは、別個の VRC ツリー (B61_a2 および B61L_a2_loc1) に作成およびインストールされます。新規メンテナンス VRC および開発 VRC が作成されます。

ローカライズ用のメンテナンスおよび開発 VRC には、インストール済フィーチャパック B61L_a2_loc1 の構成要素が入ります。

このセクションでは、カスタマイズの開発およびメンテナンスに関する様々な局面について説明します。

カスタマイズは、多くの場合、関連する親製品の作成者以外の組織によって構築されます。

カスタマイズを構築するベンダは、標準の親製品を更新 VRC にインストールします。

カスタマイズはインストールされた親標準製品の上に構築されます。

このような開発環境は PMC が受取側と配布側の両方の働きをするという点で特殊な状況です。

標準親製品のベンダは、場合によって、追加更新を市場に提供する方法としてフィーチャパックではなくパッチを適用します。フィーチャパックと異なり、パッチは累積的ではありません。更新 VRC にパッチをインストールするには、同じ更新 VRC に以前のすべての更新 VRC もインストールする必要があります。この問題には、配布側での VRC 初期設定という結果があります。

多くの場合、単一の環境を使用して複数のカスタマイズを開発およびメンテナンスします。すべてのカスタマイズを特定パッチ上で構築します。さらに、既存のカスタマイズを定期的に新パッチにアップグレードする必要があります。このため、標準親製品の複数のフィーチャパックが別個の VRC にインストールされていなくてはなりません。以下は、これを実現する最適な方法です。

標準親製品のパッチ 1 を更新 VRC P10U_a1_stnd にインストールします。パッチ 2 が使用可能になったら、P10U_a1_stnd から派生した新しい別の更新 VRC、P10U_a2_stnd にそのパッチをインストールします。パッチ 2 はパッチ 1 を前提条件とします。新規更新 VRC、P10U_a2_stnd にはパッチ 1 がインストールされていないので、この新規更新 VRC にパッチ 2 をインストールすることはできません。そのため、ソリューションレジストリの派生更新 VRC へのコピー (ttpmc2290m000) セッションを実行して、更新 VRC P10_a1_stnd のレジストリを P10_a2_stnd にコピーしてください。このステップを実行すると、パッチ 2 を更新 VRC P10U_a2_stnd に直接インストールできるようになります。このプロセスを後続パッチについて繰り返すことができます。P10U_a<n>_stnd VRC は、正味パッチのみ含んでいなくてはなりません。該当するパッチに属さない追加ソリューションをこれらの VRC にインストールしてはなりません。

この時点で、正味パッチが別の VRC にインストールされた VRC ツリーがあります。一般に、カスタマイズは正味パッチに基づいて開発されます。ただし、カスタマイズが正味パッチから派生されない場合や、カスタマイズと構成要素が重複する親標準製品ソリューションを顧客がインストールしたくない場合があります。その結果、顧客は親標準製品の任意の可能なメンテナンス段階からカスタマイズ VRC を派生するオプションを持つ必要があります。これを実現するために、更新 VRC P10U_a<n>_stnd が導入されます。すべてのカスタマイズについて、基礎となるパッチに属さない標準ソリューションをインストールできる中間 VRC 層が導入されます。再度、ソリューションレジストリの派生更新 VRC へのコピー (ttpmc2290m000) セッションを使用して、P10U_a<n>_std 更新 VRC 用の PMC レジストリを登録できます。

カスタマイズ VRC P10C_a_cusA、P10C_a_cusB、および P10C_a_cusC は、様々なパッチから派生する様々なカスタマイズを表します。カスタマイズ P10C_a_cusA は正味パッチ 1 に基づいて開発されるものとします。このカスタマイズの開発中、P10U_a1_stdA VRC はまだ空のままです。カスタマイズが発行されて顧客がそれをインストールした後、顧客が標準親製品のソリューションをインストールしたい場合がありますが、それにはカスタマイズの更新も必要です。この場合カスタマイズベンダは、親標準製品のソリューションを P10U_a1_stdA VRC にインストールし、P10C_a_cusA にそのソリューションを移植することにより、該当ソリューションをカスタマイズ VRC に提供できます。P10U_a1_stdA VRC におけるソリューションのインストールは、P10C_a_cusA カスタマイズにのみ影響し、環境内の他のカスタマイズには影響しません。

システム設定は、ある程度まで、フィーチャパック開発セクションでローカライズおよび拡張について説明している初期設定と似ています。主な違いは、親標準製品のフィーチャパックは PMC を使用して更新 VRC にインストールされるという点です。もう 1 つの違いは、フィーチャパックは累積的であるということ、すなわち、フィーチャパックには以前のすべてのフィーチャパックも含まれているということです。カスタマイズをより高いフィーチャパックレベルにアップグレードするには、標準親製品のフィーチャパックの正味変更のみを含む VRC が有効であることが有用です。親標準製品のフィーチャパック 1 上にカスタマイズを作成する必要があるとします。フィーチャパック 1 は更新 VRC B61U_a1_stnd にインストールされ、新 VRC B61W_a1_cusA がフィーチャパック上に展開されます。

カスタマイズは標準のフィーチャパック上に構築され、PMC においてフィーチャパックとして配布されるので、カスタマイズ用にマスタメディアを作成する必要はありません。カスタマイズ用のフィーチャパック 0 が使用可能になるとすぐに、このフィーチャパックはメンテナンス VRC B61M_a1_cusA にインストールされます。

親標準製品のフィーチャパック 1 のソリューションは B61U_a1_stnd VRC にインストールされます。親標準製品についてソリューションの走査を行う場合に、カスタマイズレポートを出力することもできます。カスタマイズレポートは、B61M_a1_cusA VRC で更新が必要な構成要素について概要を提供します。標準ソリューションをインストールするとすぐに、変更を B61M_a1_cusA VRC にマージして、カスタマイズに対応する PMC ソリューションを作成することができます。

後続フィーチャパックへのアプローチは次のようになります。親標準製品のフィーチャパック 2 を、B61U_a VRC から派生する B61U_a2_stnd VRC にインストールします。B61M_a1_cusA VRC の内容を B61W_a2_cusA VRC にコピーします。その結果、コピー処理の時点までにカスタマイズのフィーチャパック 0 上で作成されたすべてのメンテナンス変更が、B61W_a2_cusA VRC において直ちに使用可能になります。コピー後、B61M_a1_cusA VRC 内のすべてのメンテナンス変更を B61W_a2_cusA VRC に移植する必要もあります。標準製品のフィーチャパック 2 は累積的です。つまり、フィーチャパック 1 で実装済の変更はすべてフィーチャパック 2 にも存在します。したがって、フィーチャパック 1 と比較してフィーチャパック 2 において変更されたすべての構成要素の概要を作成する必要があり、これらの構成要素がカスタマイズにも存在しなくてはなりません。これには、パッケージ VRC の比較 (ttadv6450m000) セッションを使用します。このセッションで以下のようにフィールド値を指定します。

この設定を使用すると、親標準製品のフィーチャパック 2 と互換性を持つために更新が必要なカスタマイズ済構成要素の概要を作成できます。次に、標準製品のフィーチャパック 2 に実装済のすべての変更を B61U_2_stnd VRC から B61W_a2_cusA VRC にマージできます。これにより、B61D_a2_cusA VRC の内容に基づいて、カスタマイズ用のフィーチャパック 1 を構築できます。

この手順は、フィーチャパックについて何度でも繰り返すことができます。さらに、標準親製品の様々なレベルで平行して複数のカスタマイズを開発およびメンテナンスできます。

たとえば B61U_a1_stnd VRC から複数のカスタマイズ VRC が派生している場合、すべてのカスタマイズについて、カスタマイズ VRC と B61U_a2_stnd VRC との間に追加更新 VRC 層 B61U_a1_std が必要です。追加更新 VRC 層を使用して、カスタマイズに移植する必要がある、親製品の追加ソリューションをインストールできます。ソリューションレジストリの派生更新 VRC へのコピー (ttpmc2290m000) セッションを使用して、B61U_a1_std 更新 VRC 用の PMC レジストリを登録する必要があります。更新 VRC B61U_a1_stdA における追加ソリューションのインストールは、VRC B61M_a_cusA にのみ影響し、VRC B61M_a1_cusB には影響を及ぼしません。

カスタマイズに関する個別ソリューション、パッチ、フィーチャパックは、親標準製品の対応する更新に依存する必要があります。このタイプの依存がないと、カスタマイズの更新もインストールしなくてはならないのに標準親製品のソリューションしかインストールされていない場合に、ランタイム互換の問題が生じる場合があります。

これらの依存を確立する最善の方法は、親製品の更新とそれに対応するカスタマイズ済製品の更新との間に、相互依存の依存情報を定義することです。親標準製品にも使用されているソリューション番号と同じ番号をカスタマイズが使用すると、相互依存の依存情報が自動的に生成されます。もちろん、この方法が機能するのは、カスタマイズの基準 VRC が標準親製品の基準 VRC とともに、配布側で同じ基準 VRC 結合の一部である場合のみです。受取側においても、親標準製品の更新 VRC とカスタマイズの更新 VRC が VRC 結合に含まれている必要があります。

相互依存関係は、一方向しかありません (カスタマイズから標準親製品へ)。この一方向の相互依存があるため、親製品の対応する標準ソリューションを同時にインストールせずに、カスタマイズに関するソリューションだけをインストールすることはできません。しかし、カスタマイズ済ソリューションの走査をしない限り、カスタマイズの対応するソリューションを同時インストールせずに、標準親製品についてソリューションをインストールすることができます。この結果、ランタイム互換の問題が生じる場合があります。カスタマイズレポートによってこの問題が解決されます。カスタマイズ済環境において標準ソリューションを検査する場合、オプションでカスタマイズレポートを出力できます。このレポートはカスタマイズ済構成要素を示し、標準ソリューションとともにカスタマイズの更新もインストールしなくてはならないことを受取側に知らせます。

派生製品の更新規則セクションおよびフィーチャパックおよび Infor Installation Wizard の構築セクションで説明している事項は、カスタマイズの開発およびメンテナンスにもあてはまります。