構築ブロックの使用 > 構築ブロックのアップグレード > 顧客所有のシステムまたはクラウドでの構築ブロックのアップグレード > 「PTC ソフトウェアのダウンロード」ページを使用した構築ブロックのアップグレード
「PTC ソフトウェアのダウンロード」ページを使用した構築ブロックのアップグレード
Solution Central を使用して構築ブロックを 1.1 から 1.2 にアップグレードするには、次のセクションの手順を実行します。
* 
PTC は、本番システムに移行する前に、まずテストシステムでアップグレードすることをお勧めします。
Solution Central は、ThingWorx 環境の間で、たとえばテスト環境から本番環境へ、デプロイメントとカスタマイズを移行するために推奨されるツールです。詳細については、ThingWorx Solution Central Help Center を参照してください。
アップグレードプロセスを開始する前に
アップグレードプロセスを開始する前に、次の情報をレビューしてください。
ThingWorx ヘルプセンターの ThingWorx 9.3 システム要件
ThingWorx Help Center の ThingWorx のアップグレード
構築ブロックへのカスタマイズは、アップグレードプロセスの影響を受けます。詳細については、カスタマイズおよびアップグレードを参照してください。
ThingWorx をアップグレードする前に
ThingWorx をアップグレードする前に、次の手順を実行します。
カスタマイズした構築ブロックがある場合は、カスタマイズした内容をバックアップしてください。
ローカライズテーブルは、アップグレード中に上書きされます。ローカライズテーブルでトークンをカスタマイズしている場合は、アップグレードを実行する前に、カスタマイズしたローカライズテーブルをエクスポートします。アップグレード後に、エクスポートしたローカライズテーブルをインポートすれば、修正を維持できます。
ThingWorx のアップグレード
次の手順を実行します。
1. ThingWorx のインストールをアップグレードします。詳細については、ThingWorx Help Center ヘルプセンターの ThingWorx のアップグレードを参照してください。
構築ブロック 1.2 リリースと互換性のある ThingWorx リリースについては、システム要件を参照してください。
2. ThingWorx サーバーを再起動します。
構築ブロックをアップグレードする前に
構築ブロックをアップグレードする前に、次の情報をレビューし、必要なアクションを実行してください。
構築ブロックを使用して作成されたアプリケーションは、アップグレードの期間中は使用できなくなります。つまり、その間生産データは入力できません。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 コンフィギュレーションの詳細」を参照してください。
構築ブロックのアップグレード
構築ブロックをアップグレードするには、次の手順を実行します。
1. 「PTC ソフトウェアのダウンロード」ページから、新規バージョンの構築ブロックをダウンロードします。次の手順を実行します。
a. 次の URL で「PTC ソフトウェアのダウンロード」ページに移動します: https://support.ptc.com/appserver/auth/it/esd/index.jsp
b. 「ThingWorx Foundation」を選択します。
c. 次のフォルダを展開します: 「ThingWorx Foundation」 > 「Release 9.3」 > 「ThingWorx Digital Performance Management (DPM) 1.2」 > 「最新の製造コード」
d. MFG-Common-1-2 拡張パッケージの ZIP ファイルをダウンロードします。
2. 構築ブロックをインポートします。構築ブロックをインポートするには、ThingWorx 管理者が次の手順を実行する必要があります。
a. ライセンスThingWorx Composer にインストールされていることを確認します。詳細については、PTC 知識ベースのテクニカルサポートのアーティクルを参照してください。
b. ThingWorx Composer で、「インポート/エクスポート」 > 「インポート」に移動します。
c. 「インポート」ウィンドウの「インポートオプション」から「拡張機能」を選択します。
d. 「ファイル名」で、「ブラウズ」をクリックします。前のセクションでダウンロードした拡張パッケージの ZIP ファイルに移動して選択します。
e. 「インポート」をクリックします。インポートが終了した後、「閉じる」をクリックします。
f. インポート後に DPM ソリューションの拡張機能を表示するには、「管理」 > 「インストールされた拡張機能」に移動します。
3. ThingWorx サーバーを再起動します。
4. 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.MSSQLDatabase)",
"optional": true
}
}
c. サービス出力に返された JSON をコピーし、それをテキストエディタに貼り付けます。
d. この JSON を編集して、各コンフィギュレーションパラメータの中括弧で囲まれたコンテンツを、サイト固有の値に置き換えます。
databaseUser - システム管理権限を持つデータベースユーザーのログイン名。
databasePassword - システム管理権限を持つデータベースユーザーのログインパスワード。
databaseJDBCString - 構築ブロックデータベースの JDBC 接続文字列。
databaseThing - デフォルトのデータベース Thing (PTC.DBConnection.MSSQLDatabase)。
overrideComponentDeploymentState - この値は false でなければなりません。
automatedMigration - この値が true である場合、MigrateSolution サービスが自動的に実行され、すべてのソリューションデータが更新されたデータベーススキーマに移行されます。移行されるデータの量によっては、この移行に時間がかかることがあります。この値が false である場合、MigrateSolution サービスは自動的に実行されず、後で手動で実行する必要があります。
次は、入力 JSON の例です:
{
"databaseUser": "DPMadmin",
"databasePassword": "945DaTaBase!39525",
"databaseJDBCString": "jdbc:sqlserver://localhost:1433;databaseName=dpmdb",
"databaseThing": "PTC.DBConnection.MSSQLDatabase",
"overrideComponentDeploymentState": false,
“automatedMigration”: true
}
5. 手順 3.d で編集した JSON を、サービスの config 入力パラメータとして使用して、UpgradeSolution サービスを実行します。
サービスが完了すると、出力には、アップグレード、デプロイ、および移行が行われた構築ブロック (MigrateSolution サービスが自動的に実行された場合)、およびそれらの構成ステータス (SuccessfulNot 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
6. MigrateSolution サービスが UpgradeSolution サービスによって自動的に実行されなかった場合は、MigrateSolution サービスを実行します。このサービスには必須の入力パラメータがありません。
MigrateSolution サービスのサービス出力、ステータス、およびトラブルシューティングの手順は、手順 4 に示した UpgradeSolution サービスのものと同じです。すべての構築ブロックに Successful のステータスが存在するまで、トラブルシューティングの手順を繰り返します。
* 
MigrateSolution サービスが正常に実行されるまで、アップグレードは完了しません。データが移行されるまでは、DPM 1.2 は使用できません。
アップグレード後のアクティビティ
構築ブロックのアップグレード (ソリューションデータの移行を含む) の完了後、更新されたシステムを使用可能にする前に、次の手順を実行します。
1. 構築ブロックをカスタマイズしている場合、カスタマイズおよびアップグレードを参照して、アップグレードに伴うカスタマイズへの影響に対処してください。
2. アップグレード前に ThingWorx Composer からエクスポートした、カスタマイズされたローカライズテーブルをインポートします。
3. 構築ブロックをアップグレードする前にスクリプトのタイムアウト設定を延長していた場合は、それを以前の設定に戻します。
4. すべてのクライアントマシンのブラウザキャッシュをクリアすることをお勧めします。
これは役に立ちましたか?