| PMC の概要 |  |
| この文書では、製品のメンテナンスと管理 (PMC) モジュールの概要を提供します。 この文書には以下のセクションがあります。 PMC のアーキテクチャ PMC モジュールの場所 依存情報 個別ソリューション コレクション フィーチャパックとパッチ PMC 配布側機能 PMC 受取側機能 PMC のアーキテクチャ 次の図は PMC モジュールのアーキテクチャを示したものです。 ソフトウェア開発者は、開発者の ERP システムの ｢データディクショナリ｣ においてソフトウェア構成要素を作成または更新します。ソフトウェアは PMC 配布側によってパッケージ化され PMC レジストリに保存されます。ソフトウェアは FTP サーバで公開されます。また、ソフトウェアは、CD-ROM など他のメディアで出荷したり、E メールで送信することもできます。 顧客は、FTP サーバからソフトウェアをダウンロードすることもできますし、ソフトウェア CD-ROM をオーダすることもできます。PMC 受取側は、顧客の ERP システム上に PMC レジストリを構築または更新します。顧客の PMC レジストリ内のソフトウェアは顧客のデータディクショナリにインポートできます。 PMC モジュールの場所 PMC モジュールは Infor Enterprise Server の一部です。ソフトウェア供給者はソリューションの配布側であり、アプリケーションのユーザまたは顧客が受取側です。PMC モジュールには、配布側と受取側の両方の役割に関する機能およびセッションが含まれます。 PMC モジュールの受取側部分にアクセスするには、以下のステップを実行します。 ERP LN にログオンします。 ERP メニューブラウザでツール → ソフトウェアインストール → その他 → 受取側をクリックします 設定、運用、その他をクリックします 以下のステップを実行して PMC モジュールの受取側部分にアクセスすることもできます。 ERP LN にログオンします。 ERP メニューブラウザで、ツール → アプリケーション開発 → 製品のメンテナンスと管理 → 受取側をクリックします 設定、運用、その他をクリックします 下図は受取側セッションを示したものです。 PMC モジュールの配布側部分にアクセスするには、以下のステップを実行します。 ERP LN にログオンします。 ERP メニューブラウザで、ツール → アプリケーション開発 → 製品のメンテナンスと管理 → 配布側をクリックします 設定と運用をクリックします 下図は配布側セッションを示したものです。 依存情報 PMC 受取側がソフトウェア更新をインストールすると、受取側は必要な依存ソリューションの存在を検査します。 依存タイプには 3 種類あります。 事前必須 相互依存 事後要求 次の図は事前必須の依存を示します。ソリューション 1 がソリューション 2 の前にインストールされていなくてはなりません。 次のセクションでは、ある顧客のシナリオについて説明します。 例 依存により、ソフトウェア構成要素の以前のバージョンを最初にインストールする必要があります。ERP LN を、カスタマイズやソリューションを含まず、マスタ CD-ROM からインストールしたものとします。｢販売オーダのコピー (tdsls4201s000)｣ セッションの更新バージョンを受け取ります。これにはセッションオブジェクト、スクリプト、およびフォームが含まれており、それらは互いに独立しています。 ダンプをインストールしないことにした 2、3 ヶ月後に、スクリプトを変更して、販売員が品目を販売できない問題を修正する必要があることが判明します。変更は、セッションオブジェクトとスクリプトのみを含むダンプとして送信されます。ダンプは最初のソリューションの適切なフォームを必要とするので、ソフトウェア構成要素の以前のバージョンがインストールされている場合のみ、このダンプをインストールできます。PMC は自動的に以前のソリューションをインストールします。 たとえば ｢販売オーダのコピー (tdsls4201s000)｣ セッションの既存バージョンがカスタマイズ済かどうか不明などの理由により、意図的にソリューションをインストールしなかったとします。PMC モジュールはこれに対する対策も提供します。この場合、PMC は現行バージョンがカスタマイズ済であることを通知します。PMC は更新 VRC レベルを使用し以前のすべてのソフトウェア構成要素のコピーをメンテナンスするので、ソフトウェアを上書きすることはできません。この初期設定により、履歴の任意の時点まで容易に更新を元に戻すことができます。 個別ソリューション PMC 配布側は個別ソリューションを作成および公開します。 Infor の標準製品に対して作成された個別ソリューションは、Infor サポート Web サイト http://www.infor365.com から年中無休でいつでもダウンロードできます。 これらのソリューションは 1 つずつしかダウンロードできません。 ソリューションをダウンロードして走査した後、PMC 受取側は他のソリューションとの依存を検査します。場合によって、インストールシステムにおいて他の依存ソリューションが不足していて、ダウンロードおよび走査が必要なことがあります。多くの依存ソリューションをダウンロードおよび走査する必要がある場合、個別ソリューションのインストールプロセスには長時間かかることがあります。 複数レベルダウンロード機能を使用すると、ユーザへの問合せなしにすべての依存ソリューションをダウンロードでき、ダウンロードプロセスを簡素化および高速化できます。 コレクション コレクションダンプにより、顧客は最新ソフトウェアでシステムを更新できます。 コレクションは、一定期間に発行されたすべての個別ソリューションのグループです。 これらの個別ソリューションは PMC 配布側で 1 つのダンプファイルに集められます。 Infor の標準製品に関するコレクションは、FTP サーバ上に公開されます。 コレクションは 1 回の操作で走査できます。コレクションをソリューション/パッチファイルの走査 (ttpmc2200s000) セッションで走査する間、ダンプファイルはコレクションに含まれていたすべての個別ソリューションに分割されます。 その後、個別ソリューションをインストールできます。 コレクションダンプの使用方法には、積極的インストールと修正インストールの 2 とおりの方法があります。 積極的インストール ユーザはコレクションのすべての個別ソリューションをインストールします。ユーザは、最新の発行済修正を含め、ソフトウェアの最新バージョンを実行します。 修正インストール コレクションの個別ソリューションはインストールされません。PMC レジストリにおけるソリューションの状況は ｢有効｣ です。ユーザが問題に直面し、その問題に対するソリューションが勧められると、ユーザはそのソリューションを直ちにインストールできます。依存ソリューションはすべて自動的にインストールされます。 フィーチャパックとパッチ 個別ソリューションは定期的にフィーチャパックやパッチにまとめられます。一般に、このタイプの更新は、コレクションよりも長い期間中に作成されたソリューションを集めたものです。PMC ツールでは、｢パッチ｣ という語はフィーチャパックとパッチの両方に対して使用されます。パッチエンティティは PMC 配布側と PMC 受取側の両方で認識されます。フィーチャパックとパッチは、分割不可能なソリューションのセットです。PMC 受取側によって、フィーチャパックやパッチに属する個別ソリューションをインストールあるいはアンインストールすることはできません。フィーチャパック全体またはパッチ全体のインストールまたはアンインストールのみ可能です。フィーチャパックとパッチの間に依存が存在する場合があります。 以降のセクションでは、フィーチャパックとパッチの正当な理由、特徴、および違いについて説明します。 フィーチャパックとパッチの正当な理由 製品のライフサイクルにおいて、一般に 2 種類の変更が製品に実装されます。 デフェクトに対する修正 製品をより高めるための機能拡張 機能拡張には、データモデルの変更、ユーザインタフェースの変更、およびアプリケーションの動作の変更を伴うことがよくあります。一般に、機能拡張を運用環境にインストールする前には慎重な準備が必要です。PMC はソリューション間の依存情報を生成します。これには、ソリューションが正しい順序でインストールされており、必要なソリューションがスキップされていないことを保証する構成要素が含まれます。場合によって、ユーザが比較的軽度のデフェクトに対する修正をインストールする前に、いくつもの機能拡張をインストールしなくてはならないことがあります。機能拡張のインストールには、思いがけず長時間かかる場合があります。 フィーチャパックによって、修正のフローから機能拡張を分離することができます。この分離により、ユーザはより管理された方法で機能拡張を適用および実装することができます。パッチにはこの可能性はありません。 フィーチャパック フィーチャパックにより、機能拡張から修正を分離できます。製品に対して複数のメンテナンスベースラインが平行して存在します。すべての新規ベースラインは一意の基準 VRC にリンクされます。機能拡張は、原則として新規ベースラインの開始時のみ実装されます。 フィーチャパックの仕組みは以下のとおりです。 フィーチャパック 1 は基準 VRC A1 にリンクされます。フィーチャパックにはいくつかの修正および機能拡張が含まれます。このフィーチャパックに対して修正メンテナンスが実行された結果、上の図のソリューション 1、2 および 3 が生じます。 平行して、ソフトウェア配布側は基準 VRC A2 にリンクされるフィーチャパック 2 を開発します。可能ならいつでも、配布側はフィーチャパック 1 上に作成した修正ソリューションをフィーチャパック 2 に直ちに移植して含めることができます。上の図のソリューション 1 および破線の矢印を参照してください。移植されたこれらのソリューションはフィーチャパック 2 においていわゆる廃止ソリューションとして登録されます。 配布側が VRC A3 にリンクされるフィーチャパック 3 を開発する場合にも、同じプロセスを繰り返します。 フィーチャパック 2 および 3 の発行後、配布側はこれらのフィーチャパック上にも修正ソリューションを作成します。 受取側でフィーチャパック 2 をインストールする場合、フィーチャパック 1 上にインストールされているソリューションがすべてフィーチャパック 2 でも使用可能かどうかを PMC ツールが検査します。 フィーチャパック 2 に対してこれらのソリューションを 2 つの異なる形で使用できます。 廃止ソリューションとして フィーチャパック 2 に含まれます。上の図のソリューション 1 および破線の矢印を参照してください。これらの廃止ソリューションはフィーチャパック 2 に統合され、個別の物理ソリューションダンプを持ちません。 個別ソリューションとして フィーチャパック上で使用できます。上の図のソリューション 2 および 3 を参照してください。これらのいわゆる不足ソリューションはフィーチャパック 2 に含まれず、物理ソリューションダンプを持ちます。 注意: フィーチャパック 1 が複数の更新 VRC にインストールされている場合、PMC ツールはフィーチャパック 1 を含むすべての更新 VRC で不足ソリューション検査を実行します。 デフォルトでは、フィーチャパック 1 の上にインストールされているソリューションにフィーチャパック 2 で使用できないものがある場合、PMC ツールはフィーチャパック 2 のインストールを拒否します。このようにしないと、フィーチャパック 2 のインストール後に古いデフェクトが再び生じる可能性があります。配布側は、後続フィーチャパックを公開する前に、以前のフィーチャパックのすべてのソリューションが後続フィーチャパックでも使用可能であることを確実にする責任があります。 注意 追加の個別ソリューションなしでフィーチャパック更新をインストールできるように、このデフォルトの動作を変更できます。詳細については、｢クリーン｣ フィーチャパックをインストールするにはを参照してください。 フィーチャパックは累積的です。すべての新規フィーチャパックには、以前のすべてのフィーチャパックも含まれています。これにより、PMC 受取側でフィーチャパックのインストールをスキップすることができます。たとえば、フィーチャパック 2 を途中でインストールしなくても、フィーチャパック 1 からフィーチャパック 3 に直ちにアップグレードできます。インストールプロセスが最適化され、現在インストールされているフィーチャパックと照らして変更された構成要素のみがインストールされます。 フィーチャパックは既存の更新 VRC にインストールできます。そのため、新規更新 VRC を作成する必要はありません。この結果、受取側システムの VRC 構造はそのままにできます。ただし、更新 VRC にリンクされる基準 VRC は変わります。もちろん、必要に応じて新規更新 VRC に新規フィーチャパックをインストールすることもできます。 ｢クリーン｣ フィーチャパックをインストールするには PMC または Installation Wizard を介してフィーチャパックを使用して既存環境を更新する場合、PMC では、以前のフィーチャパックの上にインストールされているすべてのソリューションが、新規フィーチャパックについてもインストールされていることが必要です。PMC では、これらの追加ソリューションにより、フィーチャパックのインストール後に古い問題が再発しないようにする必要があります。これは、フィーチャパックを別の更新 VRC にインストールする場合や、新規更新 VRC にインストールする場合にもあてはまります。その理由は、会社をその更新 VRC のパッケージコンビネーションへアップグレードすることができるので、古い問題に再度遭遇する可能性があるためです。 状況によっては、たとえば、異なるフィーチャパックレベルで異なる顧客についてカスタマイズを開発する場合などは、この機能は厳密すぎます。 このデフォルトの動作を変更するためには、PMC_IGNORE_SOL 環境変数を 1 に設定します。こうすると、すでにインストールされているフィーチャパックや追加ソリューションの内容を気にせずに、｢クリーン｣ フィーチャパックをインストールすることができます。 環境変数は、さまざまな方法で指定できます。 BW 構成ファイルのコマンドフィールドで (-set PMC_IGNORE_SOL=1)。この方法では、設定は、この構成を使用するユーザにのみ適用されます。 $BSE/lib/bse_vars ファイルで (PMC_IGNORE_SOL=1 行を追加)。Installation Wizard を使用した場合、この行を追加できるのは、bse_vars 構成ファイルの変更を求めるプロンプトが表示された時のみです。この方法では、設定はすべてのユーザに適用されます。 注意 フィーチャパックのインストール後に必ず、PMC_IGNORE_SOL 設定を削除することをお勧めします。 既存の更新 VRC にフィーチャパックをインストールすると、以前のフィーチャパック用の更新 VRC にインストールされているソリューションが、新規フィーチャパックにもインストールされます。したがって、追加ソリューションを無視する機能は、他の更新 VRC のソリューションにのみ適用されます。 例 フィーチャパック 2 をインストールするとします。これには、すでに、廃止ソリューションとしてソリューション 133、146 および 154 が含まれています。 下表に、各種フィーチャパックと追加ソリューションがインストールされている、いくつかの更新 VRC を示します。 PMC_IGNORE_SOL が設定されていない場合の結果はどうなるでしょうか。 PMC_IGNORE_SOL が設定されている場合の結果はどうなるでしょうか。
| 更新 VRC
| B61U_a_stnd | B61U_a_fp1 | B61U_a_fp2
インストールされるフィーチャパック | - | 廃止ソリューション 133 および 146 を含む FP1 | -
インストールされるソリューション | 133 146 154 168 | 154 168 172 | -
動作 | いくつかの個別ソリューションがインストールされた状態で ｢FP0｣ 更新 VRC に FP2 をインストールする。 | FP1 およびいくつかの追加ソリューションがインストールされた状態で更新 VRC に FP2 をインストールする。 | 新規更新 VRC に FP2 をインストールする。
PMC_IGNORE_SOL が設定されていない場合の結果 | 追加ソリューション 168 および 172 が存在しない限り、失敗します。 失敗の理由: ソリューション 168 はこの更新 VRC にすでにインストールされており、ソリューション 172 が更新 VRC B61U_a_fp1 の上にインストールされました。 | 追加ソリューション 168 および 172 が存在しない限り、失敗します。 失敗の理由: どちらのソリューションもすでにこの更新 VRC にインストールされています。 | 追加ソリューション 168 および 172 が存在しない限り、失敗します。 失敗の理由: ソリューション 168 および 172 が、更新 VRC B61U_a_fp1 の FP1 の上にインストールされました。
PMC_IGNORE_SOL が 1 に設定されている場合の結果 | 追加ソリューション 168 が存在しない限り、失敗します。 失敗の理由: ソリューション 168 がこの更新 VRC にインストールされており、そのため、FP2 上で必要です。 ソリューション 172 は無視できるようになりました。 | 追加ソリューション 168 および 172 が存在しない限り、失敗します。 失敗の理由: 両方のソリューションがこの更新 VRC にインストールされました。そのため、それらを無視することはできません。 | 正常に実行されます。 成功の理由: PMC は、すべてのソリューションを無視できます。新規更新 VRC であるためです。
重要 フィーチャパックを更新 VRC とパッケージコンビネーションにインストールし、会社をこのパッケージコンビネーションにアップグレードする予定の場合は、PMC_IGNORE_SOL を 1 に設定しないでください。1 に設定すると、古い問題が再発する可能性があり、以前のフィーチャパックの上においた追加ソリューションにより新規テーブルフィールドが導入された場合は、データが消失する可能性もあります。 パッチ パッチでは機能拡張から修正を分離できません。製品のメンテナンスベースラインは 1 つだけ存在します。変更は常にソフトウェア構成要素の最新バージョンに実装されます。基準 VRC はそのままです。機能拡張は依存する修正ソリューションのチェーンに含まれます。 パッチの仕組みは以下のとおりです。 この図でソリューション 3 をインストールするには、まず機能拡張を含むソリューション 2 をインストールする必要があります。 パッチは累積的ではないので、受取側ロケーションでパッチのインストールをスキップすることはできません。たとえば、パッチ 3 をインストールするには、必ず事前にパッチ 2 をインストールしなくてはなりません。パッチ 1 からパッチ 3 に直接アップグレードすることはできません。 配布側の方針 ソフトウェア配布側は、フィーチャパックとパッチのどちらを適用するかを判断します。両方を混合することも可能です。 フィーチャパックを適用する場合、配布側は、発行済フィーチャパックの 1 つの上の個別 PMC ソリューションとして機能拡張を発行できます。 フィーチャパックを適用する場合、配布側は、フィーチャパックの上にパッチを定期的に発行することもできます。 フィーチャパックを適用する場合、配布側の方針により、平行してメンテナンスされる基準 VRC の数および基準 VRC のメンテナンス期間が決まります。 PMC 配布側機能 ソフトウェア開発者は追加ソフトウェアを生成し、既存の ERP LN ソフトウェアパッケージにソフトウェア変更を加えます。 ERP LN ソフトウェアの供給者は PMC 配布側機能を使用してソフトウェア更新を管理し、顧客に配布するそれらの更新を準備します。 以下は PMC 配布側モジュールのプロセス概要です。 個別ソリューションの作成 ソリューションに対する一意の識別子および簡単な説明を定義します 1 つまたは複数のソフトウェア構成要素をソリューションにリンクします 他のソリューションとの依存を定義または生成します ソリューションをエクスポートします。ソフトウェアダンプが作成されます ソリューションを発行します。これでソリューションの配布準備ができました コレクションの作成 コレクションに対する一意の識別子および簡単な説明を定義します 1 つまたは複数の個別ソリューションをコレクションにリンクします コレクションをエクスポートします コレクションを発行します パッチの作成 パッチに対する一意の識別子および簡単な説明を定義します 1 つまたは複数の個別ソリューションをパッチにリンクします 他のパッチへの依存を定義または生成します パッチを確認します パッチをエクスポートします パッチを発行します フィーチャパックの作成 フィーチャパックに対して新規基準 VRC を定義します。 フィーチャパックに対する一意の識別子および簡単な説明を定義します。 以前のフィーチャパックへの依存を定義します。 フィーチャパックを生成します。つまり、指定された VRC のすべての構成要素をフィーチャパックにリンクします。 フィーチャパックを検証します。 フィーチャパックをエクスポートします。 フィーチャパックを発行します。 その他の配布側機能 複数レベルエクスポート ソフトウェア構成管理の統合 更新履歴 PMC 受取側機能 顧客は PMC 受取側モジュールを使用して ERP システムに ERP LN ソフトウェア更新をインストールします。 以下は PMC 受取側モジュールのプロセス概要です。 ソリューションのダウンロード ソリューションは FTP サーバからダウンロードするか、CD-ROM などのメディアからコピーすることができます。 ソリューションの走査と接続 ダウンロードしたソリューションファイルは走査できます。すなわち、ユーザはソリューションを抽出して PMC レジストリに保存する必要があります。また、抽出されたソリューションは更新 VRC に接続されます。 ソリューションの処理 インストール前の検査。インストール前およびインストール後の作業指示、カスタマイズ済み構成要素、および不足依存ソリューションをレポートします ソリューションのインストール: ソフトウェア構成要素をデータディクショナリに保存し、追加のインストール後作業指示をレポートします その他の受取側機能 アンインストール 複数レベルダウンロード インストール済ソリューションの比較 ソリューション履歴 PMC の掃除 PMC レジストリのコピー インストール実行の表示 |