Solution Central を使用した DPM のアップグレード

• ローカライズテーブルは、アップグレード中に上書きされます。ローカライズテーブルでトークンをカスタマイズしている場合は、アップグレードを実行する前に、カスタマイズしたローカライズテーブルをエクスポートします。アップグレード後に、エクスポートしたローカライズテーブルをインポートすれば、修正を維持できます。

ThingWorx のアップグレード

次の手順を実行します。

1. ThingWorx のインストールをアップグレードします。詳細については、ThingWorx Help Center ヘルプセンターの ThingWorx のアップグレードを参照してください。

DPM 1.2 と互換性のある ThingWorx リリースについては、DPM システム要件を参照してください。

2. ThingWorx サーバーを再起動します。

DPM のアップグレード前に

DPM をアップグレードする前に、次の情報をレビューし、必要な操作を実行してください。

• アップグレード中 DPM は使用できなくなります。つまり、その時間中に生産データは入力できません。PTC は、生産システムをアップグレードする前に、まずテストシステムでアップグレードすることをお勧めします。これは、生産システムが使用できない期間を決定するのに役立ちます。

• アップグレードを実行する前に、スクリプトのタイムアウト設定の期間を延長します。この設定は、アップグレードが完了した後、以前の値に戻すことができます。スクリプトのタイムアウト設定を更新するには、ThingWorx 管理者が次の手順を実行する必要があります。

1. ThingWorx サーバーで、ThingWorxPlatform フォルダに移動します。

2. platform-settings.json ファイルをテキストエディタで開きます。

3. ScriptTimeout の設定を検索して 12000 に更新します。

4. platform-settings.json ファイルを保存して閉じます。

5. ThingWorx サーバーを再起動します。

スクリプトログに次のようなメッセージが表示された場合は、上記の手順を繰り返して ScriptTimeout 設定をさらに増分します。

[message: Execution of Script terminated after : 12000 seconds. Timeout configured for 12000 seconds.]

詳細については、ThingWorx ヘルプセンターの「platform-settings.json コンフィギュレーションの詳細」を参照してください。

DPM のアップグレード

DPM をアップグレードするには、次の手順を実行します。

1. Solution Central を使用して、新しいバージョンの DPM をデプロイします。

DPM HA システム上で ThingWorx をデプロイしている場合は、クラスタを 1 つのインスタンスまで引き下げ、拡張機能をインストールしてから、クラスタをスケールアップすることをお勧めします。これにより、新しい拡張機能が起動するたびに各サーバーによってロードされるため、パフォーマンスが向上し、最終的に一貫性の問題が防止されます。詳細については、ThingWorx ヘルプセンターの「ThingWorx HA での ThingWorx 拡張機能の管理」を参照してください。

Solution Central を使用して DPM ソリューションを ThingWorx インスタンスにデプロイするには、ThingWorx 管理者は次の手順を実行する必要があります。

a. DPM ライセンスが ThingWorx Composer にインストールされていることを確認します。詳細については、PTC 知識ベースのテクニカルサポートのアーティクルを参照してください。

b. Solution Central を設定します。詳細については、Solution Central Help Center の Getting Started with Using Solution Central を参照してください。

c. Solution Central において、ThingWorx インスタンスを登録します。詳細については、Solution Central Help Center の Registering Your ThingWorx Instance を参照してください。

d. ThingWorx Composer において、「管理」 > 「Solution Central」 > 「PTC ソリューション」に移動します。

e. 「Digital Performance Management」の横にあるチェックボックスをオンにして、「ワンクリックデプロイ」をクリックします。ウィンドウが開いて、DPM ソリューションの一部としてデプロイされるすべての拡張機能がリストされます。

f. 「すべてデプロイ」をクリックします。

拡張機能がダウンロードされてインストールされます。これには、数分かかる場合があります。プロセスが完了すると通知されます。

詳細については、ThingWorx Solution Central Help Center を参照してください。

2. ThingWorx サーバーを再起動します。

3. UpgradeSolution サービスのコンフィギュレーションパラメータを取得します。

a. ThingWorx Composer で、PTC.Base.Manager Thing に移動します。

b. 「サービス」で、GetSolutionUpgradeConfigurationParameters サービスを検索して実行します。このサービス出力は、UpgradeSolution サービスに必要なコンフィギュレーションパラメータ (存在する一連の構築ブロックに基づいて動的に変化する) を含む JSON です。サービス出力 JSON は、次のようになります:

{
"databaseUser": {
"types": [
"STRING"
],
"description": "Name of the database user used for DPM database Thing",
"optional": false
},
"automatedMigration": {
"types": [
"Boolean"
],
"description": "When TRUE, the MigrateSolution service is automatically called by the UpgradeSolution service after the upgrade action completes. When FALSE, the MigrateSolution service must be manually executed.",
"optional": false
},
"overrideComponentDeploymentState": {
"types": [
"BOOLEAN"
],
"description": "If true, the current component deployment state is ignored and the DeployComponent service will be rerun.",
"optional": true
},
"databasePassword": {
"types": [
"STRING"
],
"description": "Password of the database user used for DPM database Thing",
"optional": false
},
"databaseJDBCString": {
"types": [
"STRING"
],
"description": "JDBC Connection String for the DPM database Thing",
"optional": false
},
"databaseThing": {
"types": [
"STRING"
],
"description": "The default database thing (PTC.DBConnection.SQLThingDatabase)",
"optional": true
}
}

c. サービス出力に返された JSON をコピーし、それをテキストエディタに貼り付けます。

d. この JSON を編集して、各コンフィギュレーションパラメータの中括弧で囲まれたコンテンツを、サイト固有の値に置き換えます。

▪ databaseUser - システム管理権限を持つデータベースユーザーのログイン名。

▪ databasePassword - システム管理権限を持つデータベースユーザーのログインパスワード。

▪ databaseJDBCString - DPM データベースの JDBC 接続文字列。

▪ databaseThing - デフォルトのデータベース Thing (PTC.DBConnection.SQLThingDatabase)。

▪ overrideComponentDeploymentState - この値は false でなければなりません。

▪ automatedMigration - この値が true である場合、MigrateSolution サービスが自動的に実行され、すべてのソリューションデータが更新されたデータベーススキーマに移行されます。移行されるデータの量によっては、この移行に時間がかかることがあります。この値が false である場合、MigrateSolution サービスは自動的に実行されず、後で手動で実行する必要があります。

次は、入力 JSON の例です:

{
"databaseUser": "DPMadmin",
"databasePassword": "945DaTaBase!39525",
"databaseJDBCString": "jdbc:sqlserver://localhost:1433;databaseName=dpmdb",
"databaseThing": "PTC.DBConnection.SQLThingDatabase",
"overrideComponentDeploymentState": false,
“automatedMigration”: true
}

4. 手順 3.d で編集した JSON を、サービスの config 入力パラメータとして使用して、UpgradeSolution サービスを実行します。

サービスが完了すると、出力には、アップグレード、デプロイ、および移行が行われた構築ブロック (MigrateSolution サービスが自動的に実行された場合)、およびそれらの構成ステータス (Successful、Not Processed、または Error) をリストするインフォテーブルが表示されます。サービスが構築ブロックを処理している間にエラーが発生した場合、サービスは停止します。その構築ブロックのステータスは Error として表示され、残りの構築ブロックには Not Processed のステータスが存在します。

ステータスが Error または Not Processed の構築ブロックがある場合は、次のトラブルシューティング手順を実行します。

a. JSON で指定されているデータベースの資格証明が有効であることを確認してから、UpgradeSolution サービスを実行します。

b. サービス出力にステータスが Error または Not Processed の構築ブロックがまだ存在する場合は、ThingWorx アプリケーションとスクリプトのエラーログを参照して、そこで見つかったエラーを解決します。解決後 UpgradeSolution サービスを実行します。

c. その後、サービス出力にステータスが Error または Not Processed の構築ブロックがまだ存在する場合は、以下を含めるように JSON を更新してから UpgradeSolution サービスを実行します:

"overrideComponentDeploymentState": true

5. MigrateSolution サービスが UpgradeSolution サービスによって自動的に実行されなかった場合は、MigrateSolution サービスを実行します。このサービスには必須の入力パラメータがありません。

MigrateSolution サービスのサービス出力、ステータス、およびトラブルシューティングの手順は、手順 4 に示した UpgradeSolution サービスのものと同じです。すべての構築ブロックに Successful のステータスが存在するまで、トラブルシューティングの手順を繰り返します。

MigrateSolution サービスが正常に実行されるまで、アップグレードは完了しません。データが移行されるまでは、DPM 1.2 は使用できません。

アップグレード後のアクティビティ

DPM のアップグレードの完了後、更新されたシステムを使用可能にする前に、次の手順を実行します。

1. データベース内のイベントを集計します。次の手順を実行します。

a. ThingWorx Composer で、PTC.OperationKPIImpl.EventsAggregationScheduler に移動します。

b. 「サービス」で、AggregateEvents サービスを実行します。このサービスは、完了するまでに時間がかかる場合があります。

出力枠に「結果なし」というメッセージが表示された場合は、サービスが正常に完了しています。

サービスでエラーが発生した場合は、エラーに対処してからサービスを再度実行します。

2. DPM をカスタマイズしている場合、カスタマイズおよびアップグレードを参照して、アップグレードによるカスタマイズへの影響に対処してください。

3. ThingWorx をアップグレードする前に ThingWorx Composer からエクスポートした、カスタマイズされたローカライズテーブルをインポートします。

4. DPM をアップグレードする前にスクリプトのタイムアウト設定を延長していた場合は、それを以前の設定に戻します。

5. 初期管理アクティビティをレビューし、新しい機能に必要なアクティビティを実行します。詳細については、初期 DPM 管理アクティビティを参照してください。

6. 必要に応じて、材料名と材料が属するサイトを更新します。

DPM 1.1 では、個々の材料は 1 つのサイトにしか属さず、材料名は各サイト内で一意であることが要求されました。したがって、同じ名前を持つ複数の材料が存在し、それぞれが異なるサイトに属している可能性がありました。DPM 1.2 では、材料は１つまたは複数、あるいはすべてのサイトに属することが可能となり、材料名はエンタープライズ全体で一意であることが要求されるようになりました。データ移行サービスは、重複する名前を持つ材料を次のように処理します。

◦ 特定の名前で最初に検出された材料は、そのまま移行されます。

◦ その後検出された同じ名前の材料には、移行中に材料名_サイト名という形式で、その材料が属するサイト名が名前の後ろに付けられます。

移行の完了後、「材料」テーブルで並べ替えやフィルタを実行して、移行した材料のうち、重複するものを簡単に見つけることができます。材料を編集して、必要に応じて名前を変更し、別のサイトに追加することができます。使用しない重複する材料は、無効にすることができます。

たとえば、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 を無効にできます。

7. すべてのクライアントマシンのブラウザキャッシュをクリアすることをお勧めします。

これは役に立ちましたか?