PTC クラウドでの DPM のアップグレード
PTC クラウドのデプロイメントシナリオで DPM をアップグレードするには、次のセクションの手順を実行します。
アップグレード前のアクティビティ
アップグレードを開始する前に次の手順を実行します。
• カスタマイズした構築ブロックがある場合は、カスタマイズした内容をバックアップしてください。
• ローカライズテーブルは、アップグレード中に上書きされます。ローカライズテーブルでトークンをカスタマイズしている場合は、アップグレードを実行する前に、カスタマイズしたローカライズテーブルをエクスポートします。アップグレード後に、エクスポートしたローカライズテーブルをインポートすれば、修正を維持できます。
ThingWorx と DPM のアップグレード
PTC クラウドのデプロイメントシナリオでは、データベース、ThingWorx Platform、および DPM は、PTC クラウドで PTC によってすべてアップグレードされます。詳細については、
PTC Cloud Engagement Guide を参照してください。
アップグレード後のアクティビティ
DPM のアップグレードの完了後、更新されたシステムを使用可能にする前に、次の手順を実行します。
1. データベース内のイベントを集計します。次の手順を実行します。
a. ThingWorx Composer で、PTC.OperationKPIImpl.EventsAggregationScheduler に移動します。
b. 「サービス」で、AggregateEvents サービスを実行します。
3. アップグレード前に ThingWorx Composer からエクスポートした、カスタマイズされたローカライズテーブルをインポートします。
5. 必要に応じて、材料名と材料が属するサイトを更新します。
DPM 1.1 では、個々の材料は 1 つのサイトにしか属さず、材料名は各サイト内で一意であることが要求されました。したがって、同じ名前を持つ複数の材料が存在し、それぞれが異なるサイトに属している可能性がありました。DPM 1.2 では、材料は 1 つまたは複数、あるいはすべてのサイトに属することが可能となり、材料名はエンタープライズ全体で一意であることが要求されるようになりました。データ移行サービスは、重複する名前を持つ材料を次のように処理します。
◦ 特定の名前で最初に検出された材料は、そのまま移行されます。
◦ その後検出された同じ名前の材料には、移行中に材料名_サイト名という形式で、その材料が属するサイト名が名前の後ろに付けられます。
移行の完了後、
「材料」テーブルで並べ替えやフィルタを実行して、移行した材料のうち、重複するものを簡単に見つけることができます。
材料を編集して、必要に応じて名前を変更し、別のサイトに追加することができます。使用しない重複する材料は、
無効にすることができます。
たとえば、DPM 1.1 に Material1 という名前の材料が 3 つあり、それぞれが Boston、London、Berlin というサイトに属しているとします。次の表に、DPM 1.1 におけるそれぞれの材料名とサイト、および DPM 1.2 への移行後のそれぞれの材料名とサイトを示します。この例では、データ移行サービスは Boston サイトに属する Material1 を最初に検出しています。
DPM 1.1 における材料名とサイト
|
DPM 1.2 への移行後の材料名とサイト
|
Material1, Boston
|
Material1, Boston
|
Material1, London
|
Material1_London, London
|
Material1, Berlin
|
Material1_Berlin, Berlin
|
「材料」テーブルで、「Material1」をフィルタして、これらの材料のインスタンスをすべて見つけることができます。3 つのサイトすべてに属する Material1 という名前の単一の材料を使用する場合は、Material1 を編集して London サイトと Berlin サイトを追加し、Material1_London と Material1_Berlin を無効にできます。
6. すべてのクライアントマシンのブラウザキャッシュをクリアすることをお勧めします。