10.2409.0 へのポストアップグレード

サービスイメージを 10.2409.0 に更新した後、特定の機能拡張を完全に利用するために移行手順を完了します。

手順

予約機能強化のための移籍手順
10.2409.0 リリースでは、予約機能のパフォーマンスが強化されました。この機能を完全に利用するには、既存の予約レコードをinv_reserv_summaryテーブルからinv_reserv_summary_v2テーブルに移行します。以前の記録が存在しない場合は、移行は必要ない。
1. 配備が完了した時刻をメモしておく。
2. アップグレード前に作成された既存の予約レコードの有効期限が切れるまで待つ場合は、移行APIを呼び出さないでください。例えば、既存のレコードの有効期限のタイムスタンプが今後24時間以内である場合、24時間待つことで、これらのレコードはすべて自動的に期限切れとなり、新しいテーブルにデータを移行する必要がなくなります。既存の記録が期限切れになるまで待ってから、ステップ3をスキップします。
3. アップグレード前に作成された既存のレコードの有効期限が長い場合、それらのレコードの有効期限切れを待つことは現実的ではないかもしれません。このような場合は、移行APIを呼び出してレコードを新しいテーブルに移行します。それでも、24時間待てば、ほとんどのレコードが期限切れとなり、移行が必要なレコードの数が減ります。
  1. アップグレード前に作成されたレコードを移行するには、デプロイから24時間後に移行APIを呼び出し、データベースの書き込みタイムスタンプに基づいて移行します。 modifiedBefore の値を、次の例のように、ステップ 1 で記録したデプロイ完了のタイムスタンプに設定します。
```
POST : https://<sip-domain>/inventory/v1/migration/reserv_summary
{
"tenantId": "string",
"filters": {
	       "modifiedBefore" : "<ReleaseDeploymentTS>" 
	     },
"pageSize": 5000
}
```
    このAPIはマイグレーション・ジョブを開始し、追跡目的のためにジョブIDを返す。詳しくは、API の資料を参照してください。
  2. 移行状況を確認するには、手順で取得したジョブIDを使用して、次のAPIを呼び出します。 3a。ジョブの状態が complete の場合、ステップ4に進みます。
```
GET : https://<sip-domain>/inventory/v1/migration/reserv_summary/<Job_id>
```
    詳しくは、API の資料を参照してください。
4. すべての Inventory Visibility のデプロイメントで、環境変数RESERVE_SUMMARY_MIGRATION_COMPLETEDをtrueに更新します。
  1. SIPEnvironmentで環境変数を定義する。
```
spec:
  serverProperties:
    envVars:
     - groupName: reservation
	propertyList:
	   RESERVE_SUMMARY_MIGRATION_COMPLETED: 'true'
```
  2. IVServiceGroupのステップ4aで定義したグループ名を適用します。
```
spec:
  property:
    envVars: reservation
```
    詳細は、 serverProperties パラメータを参照してください。
5. 基本ルールを'ONLY_WRITE_NEWに更新し、PATCH操作APIを呼び出して'inv_reserv_summaryテーブルへの書き込みを無効にする。更新された値を検証するには、GETオペレーションAPIを呼び出します。
```
PATCH https://<sip-domain>/inventory/operations/v1/configuration/settings/default

{
    "migration": {
		"reserveSummaryMigrationMode": "ONLY_WRITE_NEW",		
	}
}
```
productAvailability.v2とproductAvailabilitySnapshot.v2イベントのパブリッシャーを削除します
1. productAvailability.v2イベントのパブリッシャーIDを取得
```
GET : https://<sip-domain>/{tenantId}/v1/configuration/events/productAvailability.v2/publishers
```
2. イベントのパブリッシャーを削除するためにdelete APIを呼び出します。ステップ1で取得したパブリッシャーIDを取得します。
```
DELETE : https:///<sip-domain>/inventory/default/v1/configuration/events/productAvailability.v2/publishers/<publishers_id>
```
3. productAvailabilitySnapshot.v2イベントに対して、ステップ1と2を繰り返します。
4. パブリッシャーを削除した後、これら2つのイベントのサブスクライバーがいないことを確認してください。
  詳しくは、API の資料を参照してください。
{topicPrefix}-{environment}-prm-iv-breakup-sink-streamトピックを削除する。
Inventory Visibilityと Rules サービス間のルールの同期を効果的に行うための手順。以下の手順は、'Sterling Intelligent Promisingがプロダクションモードまたはフレキシブルモードでデプロイされている場合にのみ適用されます。したがって、開発モードでは何もする必要はない。
1. SIPEnvironmentカスタムリソースの'serverPropertiesに'RULES_TRIGGER_TOPIC環境変数を追加する。この環境変数の値は、既存のconfigMapから読み込まれる。したがって、以下の例に示すように、既存のconfigMapで使用されているのと同じconfigMap値を使用する。
```
  serverProperties:
    envVars:
      - groupName: ruletriggertopic
        propertyRef:
          - name: RULES_TRIGGER_TOPIC
            valueFrom:
              configMapKeyRef:
                key: rules-trigger-topic
                name: iv-kafka-configs
```
2. ステップ1で設定した変更を保存します。
3. IVServiceGroupの'property下に'ruletriggertopic'groupNameを設定し、カスタムリソースを保存する。このステップは、RulesTriggerConsumerバックエンドサーバーが'RULES_TRIGGER_TOPIC環境変数を使用することを確認するのに役立つ。
```
- active: true
  names:
    - 'RulesTriggerConsumer:5'
  property:
    envVars: ruletriggertopic
```
  RulesTriggerConsumerポッドが再起動しました。
4. RulesTriggerConsumerポッドにエラーがないことを確認して、先に進みます。