PMC の概要

次の図は PMC モジュールのアーキテクチャを示したものです。

ソフトウェア開発者は、開発者の ERP システムの ｢データディクショナリ｣ においてソフトウェア構成要素を作成または更新します。ソフトウェアは PMC 配布側によってパッケージ化され PMC レジストリに保存されます。ソフトウェアは FTP サーバで公開されます。また、ソフトウェアは、CD-ROM など他のメディアで出荷したり、E メールで送信することもできます。

顧客は、FTP サーバからソフトウェアをダウンロードすることもできますし、ソフトウェア CD-ROM をオーダすることもできます。PMC 受取側は、顧客の ERP システム上に PMC レジストリを構築または更新します。顧客の PMC レジストリ内のソフトウェアは顧客のデータディクショナリにインポートできます。

PMC モジュールは、Infor Enterprise Server (ツール) の一部です。ソフトウェア供給者はソリューションの配布側であり、アプリケーションのユーザまたは顧客が受取側です。PMC モジュールには、配布側と受取側の両方の役割に関する機能およびセッションが含まれます。

PMC 受取側がソフトウェア更新をインストールすると、受取側は必要な依存ソリューションの存在を検査します。

次の図は事前必須の依存を示します。ソリューション 1 がソリューション 2 の前にインストールされていなくてはなりません。

次のセクションでは、ある顧客のシナリオについて説明します。

PMC 配布側は個別ソリューションを作成および公開します。

Infor の標準製品ごとに作成された個別ソリューションは、Infor サポート Web サイト http://www.infor.com/inforxtreme からいつでもダウンロードできます。

これらのソリューションは 1 つずつしかダウンロードできません。

ソリューションをダウンロードして走査した後、PMC 受取側は他のソリューションとの依存を検査します。場合によって、インストールシステムにおいて他の依存ソリューションが不足していて、ダウンロードおよび走査が必要なことがあります。多くの依存ソリューションをダウンロードおよび走査する必要がある場合、個別ソリューションのインストールプロセスには長時間かかることがあります。

複数レベルダウンロード機能を使用すると、ユーザへの問合せなしにすべての依存ソリューションをダウンロードでき、ダウンロードプロセスを簡素化および高速化できます。

コレクションダンプにより、顧客は最新ソフトウェアでシステムを更新できます。

コレクションは、一定期間に発行されたすべての個別ソリューションのグループです。

これらの個別ソリューションは PMC 配布側で 1 つのダンプファイルに集められます。

Infor の標準製品に関するコレクションは、FTP サーバ上に公開されます。

コレクションは 1 回の操作で走査できます。コレクションをソリューション/パッチファイルの走査 (ttpmc2200s000) セッションで走査する間、ダンプファイルはコレクションに含まれていたすべての個別ソリューションに分割されます。

その後、個別ソリューションをインストールできます。

個別ソリューションは定期的に機能パックやパッチにまとめられます。一般に、このタイプの更新は、コレクションよりも長い期間中に作成されたソリューションを集めたものです。PMC ツールでは、｢パッチ｣ という語は機能パックとパッチの両方に対して使用されます。パッチエンティティは PMC 配布側と PMC 受取側の両方で認識されます。機能パックとパッチは、分割不可能なソリューションのセットです。PMC 受取側によって、機能パックやパッチに属する個別ソリューションをインストールあるいはアンインストールすることはできません。機能パック全体またはパッチ全体のインストールまたはアンインストールのみ可能です。機能パックとパッチの間に依存が存在する場合があります。

以降のセクションでは、機能パックとパッチの正当な理由、特徴、および違いについて説明します。

機能拡張には、データモデルの変更、ユーザインターフェイスの変更、およびアプリケーションの動作の変更を伴うことがよくあります。一般に、機能拡張を運用環境にインストールする前には慎重な準備が必要です。PMC はソリューション間の依存情報を生成します。これには、ソリューションが正しい順序でインストールされており、必要なソリューションがスキップされていないことを保証する構成要素が含まれます。場合によって、ユーザが比較的軽度のデフェクトに対する修正をインストールする前に、いくつもの機能拡張をインストールしなくてはならないことがあります。機能拡張のインストールには、思いがけず長時間かかる場合があります。

機能パックによって、修正のフローから機能拡張を分離することができます。この分離により、ユーザはより管理された方法で機能拡張を適用および実装することができます。パッチにはこの可能性はありません。

機能パックにより、機能拡張から修正を分離できます。製品に対して複数のメンテナンスベースラインが平行して存在します。すべての新規ベースラインは一意の基準 VRC にリンクされます。機能拡張は、原則として新規ベースラインの開始時のみ実装されます。

機能パックの仕組みは次のとおりです。

機能パック 1 は基準 VRC A1 にリンクされます。機能パックにはいくつかの修正および機能拡張が含まれます。この機能パックに対して修正メンテナンスが実行された結果、上の図のソリューション 1、2 および 3 が生じます。

平行して、ソフトウェア配布側は基準 VRC A2 にリンクされる機能パック 2 を開発します。可能ならいつでも、配布側は機能パック 1 上に作成した修正ソリューションを機能パック 2 に直ちに移植して含めることができます。上の図のソリューション 1 および破線の矢印を参照してください。移植されたこれらのソリューションは機能パック 2 においていわゆる廃止ソリューションとして登録されます。

配布側が VRC A3 にリンクされる機能パック 3 を開発する場合にも、同じプロセスを繰り返します。

機能パック 2 および 3 の発行後、配布側はこれらの機能パック上にも修正ソリューションを作成します。

受取側で機能パック 2 をインストールする場合、機能パック 1 上にインストールされているソリューションがすべて機能パック 2 でも使用可能かどうかを PMC ツールが検査します。

デフォルトでは、機能パック 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 に設定します。こうすると、すでにインストールされている機能パックや追加ソリューションの内容を気にせずに、｢クリーン｣ 機能パックをインストールすることができます。

パッチでは機能拡張から修正を分離できません。製品のメンテナンスベースラインは 1 つだけ存在します。変更は常にソフトウェア構成要素の最新バージョンに実装されます。基準 VRC はそのままです。機能拡張は依存する修正ソリューションのチェーンに含まれます。

パッチの仕組みは次のとおりです。

この図でソリューション 3 をインストールするには、まず機能拡張を含むソリューション 2 をインストールする必要があります。

パッチは累積的ではないので、受取側ロケーションでパッチのインストールをスキップすることはできません。たとえば、パッチ 3 をインストールするには、必ず事前にパッチ 2 をインストールしなくてはなりません。パッチ 1 からパッチ 3 に直接アップグレードすることはできません。

機能パックを適用する場合、配布側の方針により、平行してメンテナンスされる基準 VRC の数および基準 VRC のメンテナンス期間が決まります。

ソフトウェア開発者は追加ソフトウェアを生成し、既存の LN ソフトウェアパッケージにソフトウェア変更を加えます。

LN ソフトウェアの供給者は PMC 配布側機能を使用してソフトウェア更新を管理し、顧客に配布するそれらの更新を準備します。

顧客は PMC 受取側モジュールを使用して ERP システムに LN ソフトウェア更新をインストールします。