アップグレードノート
バージョンを上げる際に連携側で修正が必要な事項と、初回起動時に発生する処理をバージョン別に記載します。 更新手順（インストールワンライナーの再実行）は アップグレード を参照してください。 最新バージョンが上に表示されます。
2026.11 — アップグレード前の準備と名称変更
サポート範囲は 2026.11 以降のバージョンのうち、最新の3バージョンまでです。2026.10 以前のバージョンからはアップグレードできないため、再インストールしてください（試みた場合、アップグレードは失敗し、自動的に元のバージョンにロールバックされます）。 アップグレード を参照してください。以下の名称変更および連携変更は、再インストールする場合にも同様に適用されます。
以下の順序で準備してください。Cassandra は一度アップグレードすると元に戻せず、変更後の名称に互換性はありません — 旧パス、旧カラム、旧ツール名はアップグレードの瞬間に消滅するため、連携をサーバーと同時に更新してください。現場アプリ も同じバージョンに更新します。ワークオーダーの数量・名称変更については 次項 を参照してください。
1. バックアップ — Cassandra r4 はロールバック不可
このバージョンの Cassandra 本体は Aster TSDB v6.0.0-r4 です。
クラスターメタデータのスナップショット形式が変更され、旧本体では読み込めなくなります。切り戻し手段を確保したい場合は、必ずアップグレード前にバックアップを行ってください。
- PostgreSQL の全バックアップ —
./backup.sh --postgres full - Aster TSDB の全バックアップ —
./backup.sh --cassandra full(バックアップとリカバリ) - ノードごとに Cassandra データディレクトリの
system_cluster_metadataをコピーして保存 - その後、新バージョンを適用します
2. マイグレーション V121~ — 初回起動に時間がかかる場合があります
初回起動時に Flyway が V121~V152 を一括適用します。アラーム表の整理(V121V124)、5層設備ツリー(V137V139)、記録表のキーと整備名称(V140)、外部キー(V127~V133)など、構造を大幅に変更するステップが含まれます。特に V123 は mm_alarm の全行を更新するため、所要時間はアラームの行数に応じて増加します。 その間、サーバーは応答せず、ヘルスチェックが先に unhealthy を出す可能性があります — コンテナを再起動せず、ログの Flyway migration completed. を待機してください。
条件に合わないデータがある場合、マイグレーションが停止し、サーバーが起動しません。 停止したステップの変更はロールバックされ、それ以前のステップは保持されます。ログの Platform version update failed に続く指示に従ってデータを修正後、再起動するとそのステップから再開されます。以下はアップグレード前に DB で確認可能です。
-- V121: 0 행이어야 합니다 — 숨겨진 채 켜져 있는 알람
SELECT alarm_seq FROM pp.mm_alarm WHERE shelved AND is_on;
-- V121: 0 이어야 합니다 — 숨겨진 알람에 확인 · 라벨이 붙은 행
SELECT count(*) FROM pp.mm_alarm
WHERE shelved AND (is_read IS TRUE OR read_user_id IS NOT NULL OR disposition IS NOT NULL
OR cause_note IS NOT NULL OR labeled_by IS NOT NULL OR labeled_at IS NOT NULL
OR failure_record_id IS NOT NULL);
-- V128: 0 이어야 합니다 — 고장 기록을 가리키지 못하는 알람 연결
SELECT count(*) FROM pp.mm_alarm a
WHERE a.failure_record_id IS NOT NULL
AND (a.failure_record_id !~ '^[0-9]{1,18}$'
OR NOT EXISTS (SELECT 1 FROM pp.mm_ram_failure f WHERE f.failure_id = a.failure_record_id::bigint));
-- V137: 1 행이어야 합니다 — 설치당 기업은 하나
SELECT enterprise_id FROM pp.mm_enterprise;
3. 名称変更 — 旧名称との互換性はありません
旧名称は受信も応答もしません。旧 V5 パスは 404 となります。
整備 «記録» は 整備 «オーダー» となります。
| 場所 | 旧 | 新 |
|---|---|---|
| V5 パス | /api/v5/maintenance-records… | /api/v5/maintenance-orders… |
| V5 パス | /api/v5/asset/{asset_id}/maintenance-records | /api/v5/asset/{asset_id}/maintenance-orders |
| MCP ツール | list_maintenance_records | list_maintenance_orders |
| カラム・クエリ | record_id | maintenance_order_id — 数値 → 文字列 |
| カラム・クエリ | kind · status · cancel_reason | maintenance_kind_code · status_code · cancel_reason_code |
| カラム | failure_id | failure_record_seq |
| カラム | plan_id · plan_name | maintenance_plan_id(数値 → 文字列) · maintenance_plan_name |
| カラム・クエリ | failure_mode · failure_mechanism · failure_cause · maintainable_item | 後方に _code. 表示名称 *_name と cause_code は維持 |
| カラム | checklist_results[].attachment_id | checklist_results[].maintenance_attachment_seq |
| 添付応答 | attachment_id · record_id | maintenance_attachment_seq · maintenance_order_id |
リスト sort 値 | status · kind | status_code · maintenance_kind_code |
| 整備計画カレンダー | record_id · record_status · open_record_id · open_status · record_ids | maintenance_order_id · maintenance_order_status_code · open_maintenance_order_id · open_status_code · maintenance_order_ids |
| DB 表 | mm_maintenance_record · mm_ram_failure | mm_maintenance_order · mm_failure_record |
maintenance_order_id · maintenance_plan_id を数値として読み込んだり比較しないでください。旧行は番号を維持した文字列("12")であり、新行は MAINTENANCE_ORDER_000013 形式です。
CMMS ウェブフックのキー (PP_MAINTENANCE_WEBHOOK_URL) — 受信側を先に修正してください。
| 旧キー | 新キー | 値 |
|---|---|---|
record_id | maintenance_order_id | 文字列 |
kind | maintenance_kind_code | 同一 |
status | status_code | 同一 |
failure_mode | failure_mode_code | 同一 |
cancel_reason | cancel_reason_code | 同一 |
plan_id | maintenance_plan_id | 文字列 |
checklist_results[].attachment_id | checklist_results[].maintenance_attachment_seq | 同一 |
text · event · asset_id · asset_name · description · requested_by · accepted_by · assignee_employee_id · external_system · external_id · owner · anomaly_found · plan_due_at · at · version は変更ありません — CMMS ウェブフック.
その他の記録キーと ID カラム
| 場所 | 旧 | 新 |
|---|---|---|
/ram/failures… | failure_id · asset_class · equipment_class · code_status | failure_record_seq · asset_class_code · equipment_class_code · raw_code_status_code |
/ram/failures… | failure_mode · mechanism · iso_cause · maintainable_item | failure_mode_code · failure_mechanism_code · failure_cause_code · maintainable_item_code |
| 故障・整備コードマッピング | map_id(数値) | fault_code_map_id · maintenance_code_map_id(文字列) |
/defects… | defect_id | defect_record_seq |
/order/{id}/notes · /progress | note_id · progress_id | order_note_seq · order_progress_seq |
/alarm/config/{id}/revisions | revision_id | alarm_config_revision_seq |
| 勤務計画区間 | generation_id | asset_plan_generation_seq |
アラーム label | failure_id | failure_record_seq |
設備 · サイト
| 旧 | 新 | 備考 |
|---|---|---|
table_type | asset_class_code | 画面表示は «設備分類». 表 mm_asset_class のコードカラムは code |
サイト status | operational_status_code | ACTIVE → IN_OPERATION, INACTIVE → OUT_OF_SERVICE, CLOSED → DECOMMISSIONED. 全階層の共通カラムです |
| ツリーに区画・ライン・設備のみ | 企業 → サイト → 区画 → ライン → 設備 | asset_type に E · S が新設されます。設備数をカウントする際は除外してください |
ID 形式。新しく生成される ID は「ドメインフルネーム + 6桁番号」となります。既存の ID は引き続き有効であり、変更されません。ID 接頭辞で階層や種類を判別せず、asset_type を参照してください。
| ドメイン | 旧形式(引き続き有効) | 新形式 |
|---|---|---|
| 区画 · ライン · 設備 | ASSET_… | AREA_000001 · LINE_000001 · EQUIPMENT_000001 |
| ワークオーダー | ORD_… | ORDER_000001 |
| カレンダー · シフト例外 | CAL_… · OV_… | CALENDAR_000001 · SHIFT_OVERRIDE_000001 |
| 設備関係 · 工程セグメント | REL_… · SEG_… | ASSET_RELATION_000001 · PROCESS_SEGMENT_000001 |
| 命令領域 · 設備命令 | CMDAREA_… · CMD_… | COMMAND_AREA_000001 · ASSET_COMMAND_000001 |
| 画像 | IMG_… | IMAGE_000001 |
| 社員 | EMP_… | EMPLOYEE_… |
| アラーム設定 | ALARM_CONFIG_00375 · ALARM_CONFIG_<태그 ID> | ALARM_CONFIG_000376 |
番号は欠番する可能性があり、999999 を超えると桁数が増加します。詳細は ドメイン ID ルール を参照してください。
アラーム設定
POST /alarm/configに任意に定義した ID を指定すると 422alarm.invalid.alarm_config_idとなります。新しい ID はGET /alarm/config/new-idで取得します。旧形式の ID は修正のみ可能です。- 帯域（バンド）アラーム設定はタグあたり1つまでです。2つ目を設定しようとすると 409 となります。EQL アラーム設定は数に制限はありません。
- 帯域アラーム設定 ID を
ALARM_CONFIG_<태그 ID>で定義して検索しないでください。新設定ではその名称は存在しません。GET /alarm/config/list/by-tag?tag_id=…でalarm_config_priorityがBANDであるものを検索してください。
ステートメント必須カラム
保存時、種類別の必須出力カラムを検証します。不足している場合は 422 asset_statement.eql.missing_columns で拒否され、不足カラムが通知されます。
| 種類 | 必須カラム |
|---|---|
EVENT | timestamp · plugin · name · color · from_timestamp · to_timestamp · value |
CONTEXT · AGGREGATION · COMMAND | timestamp · plugin · key · value |
既に保存済みの文はアップグレードによって消去または停止しません。 起動時にそのまま展開されます。ただし、必須カラムがない文は以前から結果が記録されず、現在も同様です — イベントごとに失敗として残り、診断 diagnostic.asset.statement_failing が点灯します。そのような文は修正して保存する際に上記の検証に抵触するため、カラムを埋める必要があります。適用後、診断画面でこのコードを探して修正してください。
4. 診断 — CEP デッドレターの保持期限は 24時間 · 256 MiB
CEP が処理できなかったイベントを保持するデッドレター(PP:CEP-DEAD-LETTER)の上限が、時間とバイト数で定義されました。24時間が経過するか、合計 256 MiB を超えると、古いものから消去されます。3回の配信後も処理できなかったイベントのみが格納されます。失敗イベントを調査する場合は、その期間内に確認してください — データ保存.
5. CEP — Esper バックエンドと文別 CPU 指標の廃止
cep.backend の値は aster · flink の2種類であり、設定しない場合は aster となります。標準デプロイテンプレートは cep.backend=aster であるため、手動で変更していないインストール環境では対応不要です。
cep.backend=esper のままでは CEP が起動しませんタイポ等で不正な値がある場合、ブート時に停止します。適用前に plantpulse-cep.properties の該当行を aster に変更するか削除してください。
- Esper を利用していた環境は、適用前に
GET /api/v1/eql/portabilityを使用して Aster CEP で受信できない文を確認してください。受信できなかった文は消去されずREJECTEDとして残ります — 限界と拒否トークン. GET /api/v1/eql/{name}/metricsが廃止されました。文別の CPU 時間、壁時計時間（Wall-clock time）のゲージ、REST、コンソールパネル、保存機能はすべて提供されません。文指標はGET /api/v1/eql/metrics/snapshotの一致率・出力率を使用します。PlantPulse Dashboard のEQL_CPU_TIMEパネルには値が入らなくなります。- 読み込みコードが廃止された設定:
cep.ha.*·cep.monitor.statement_metrics_enabled·cep.monitor.cpu_estimate_max_error·cep.performance.cpu_warn_threshold_ns·cep.performance.wall_warn_threshold_ns·cep.storage.max_inflight_writes. ルール状態の保持はcep.aster.state.*となります — プロパティ参照.
6. 適用後の手順
- 設定画面に
PP_UI_CONSOLE_URLを入力してください。空欄の場合、アラームメールにリンクが表示されず、QR ラベル を作成できません。現場アプリを使用する場合はPP_UI_FRONTLINE_URLも入力してください。 - QR 公開ページは、すべてのサイトでオフの状態で開始されます。
- 設定画面の
MAIL_SMTP_*の値が送信に適用されなかった不具合と、STARTTLS が «No appropriate protocol» で失敗していた不具合が修正されました。メールが実際に送信され始める可能性があるため、設定を確認してください — メール設定.
2026-11-05 より前の 2026.11 版で適用したプラグイン — RAM_FAILURE_CODE_TAG と OEE_PRODUCT_BAD_COUNT_CODED は古い文が残り、存在しないタグ(<タグ>_CODE、<タグ>_CAUSE)を監視しています。再適用だけでは「すでにあり(スキップ)」となり文は変わりません。その文を削除してから(DELETE /api/v5/asset/{asset_id}/statement/{statement_name})プラグインを再適用し、コードタグと不良原因タグを選択してください。他の文はそのままにします。再適用前に発生した故障はコードなしのまま残ります。コードタグが実際に <故障タグ ID>_CODE として存在し正常に動いていた環境では対応は不要です。
2026.11 — ワークオーダー数量と名称を ISA-95 / B2MML に
ワークオーダーの数量が «単一の数値» から 値 + 単位オブジェクト(ISA-95 / B2MML QuantityValueType) に変更されました。
カラム名も ISO 22400 用語に変更され、不良が廃棄と再作業に分かれました。同一バージョンにおいて、ワークオーダー・カレンダー・顧客・製品のカラム名も ISA-95 / B2MML 名称に変更されました(title → order_name, fix_start_timestamp → planned_start_timestamp …, 以下 名称変更 参照)。
互換カラム、互換パス、エイリアスは提供されません — 旧名称で読み書きを行う連携は、アップグレードと同時に修正する必要があります。
基準: V5 API 5.0 · 数量契約 2026-10-30 · 名称ウェーブ 2026-10-31 · server-web 974891b4(数量ウェーブは 30b7d9af から) · Flyway V99·V100·V103 · core マイグレーション V12V16·V21V23 · イベントスキーマ plantpulse.order.*·plantpulse.calendar.* major 2, plantpulse.kpi.oee.finalized major 1.
変更内容
| 領域 | 変更点 | 詳細 |
|---|---|---|
| V5 数量カラム | target_units+unit → planned_quantity, total_good_count → good_quantity, total_bad_count → scrap_quantity, total_production_count → produced_quantity など。値は {quantity_string, data_type, unit_of_measure} オブジェクト | Order サービス — 数量 |
| 廃棄 · 再作業 | scrap_quantity は廃棄のみ(ISO 22400 SQ)、再作業は新カラム rework_quantity(RQ)。旧 total_bad_count は不良の合計であったため、合計が必要な場合は両方を加算する。画面上も廃棄のみの箇所は «廃棄」、合計の箇所は «不良» と表示 | Order サービス — 廃棄と再作業 |
| 単位 | UN/ECE Rec 20 許可リスト 13種(EA·H87·C62·BX·SET·KGM·GRM·TNE·LTR·MLT·MTQ·MTR·MTK)。実績はワークオーダー単位でのみ受信(換算なし)。拒否時は 422 E1002 + reason(quantity.unit_mismatch·quantity.not_integer …) | Order サービス — 要求ルールと拒否 |
| 製品基本単位 | 製品の unit_of_measure が新しいワークオーダーの基本単位となる。旧値はコードに移行(BOX→BX, KG→KGM, PCS·개→EA …)、不明な値は «単位なし»(その製品の新ワークオーダーは EA) | 生産管理 — 数量と単位 |
| 優先度 | priority が B2MML Priority 整数へ(1 緊急・2 高・3 中・4 低、数値が小さいほど優先度が高い)。旧 URGENT·HIGH·NORMAL·LOW は 1~4 に移行される | |
| 期間 KPI | 単位が単一の場合は数値そのまま + unit_of_measure、混在する場合は合算せず quantities_by_unit | 同左 |
| EMS 単位あたり値 | energy_per_unit_kwh·co2_per_unit_kg の横に分母単位 unit_of_measure | 同左 |
| 名称 (ワークオーダー・カレンダー・顧客・製品) | title → order_name, fix_start_timestamp/fix_end_timestamp → ワークオーダーは planned_start_timestamp/planned_end_timestamp, カレンダーは start_timestamp/end_timestamp, external_order_id → external_id, external_po_id → customer_po_id, 顧客・製品の external_customer_id/external_product_id → external_id(+ external_system). V5·SDK·イベント·MCP·フローノード·DB カラムすべて。エイリアスなし | 名称変更 |
| 外部ワークオーダー識別 | (external_system, external_id) ペア。V5 POST·PUT·PATCH /order が両方受信し、応答・実績ドキュメントが両方を掲載。GET /order/performance/by-external/{external_order_id} は削除し …/by-external/{external_system}/{external_id} へ。ワークオーダー1件につき GET /order/by-external/{system}/{external_id} | MES 連携 |
| イベント | plantpulse.order.* に planned_quantity_unit_of_measure·external_system, plantpulse.kpi.oee.finalized に *_quantity + unit_of_measure(正本)と再作業 rq·rq_quantity。タイプ変更なしで末尾に追加。名称変更により plantpulse.order.*·plantpulse.calendar.* はスキーマ major 2(dataschema 末尾が :2) | Order サービス — 数量 |
| フロー | OEE_EVENT の数量が Quantity オブジェクト(rework_quantity 追加)。flow_create_work_order は単位値が必須(パス unit_of_measure_field, デフォルト data.unit_of_measure)。このノードのパス設定名称も変更された(title_field → order_name_field …) | フロー |
| 画面 | 数量ごとに単位記号が付与される(言語不問 — EA, kg, L, m² …)。ワークオーダー様式に単位カラムを追加 | 生産管理 — 数量と単位 |
数値自体は変更されません。アップグレード前のワークオーダーはすべて EA へ移行され、整数個数は維持されるため、OEE・稼働率・性能・品質および数量合計は適用前後で一致します。再作業は既存の REWORK 不良記録の合計で埋められ（ない場合は 0）、その分だけ scrap_quantity が旧 total_bad_count より小さくなります。
名称変更 — 旧名称と新名称
ワークオーダー・カレンダーのカラム名を ISA-95 / B2MML 名称に統一しました。ワイヤ・SDK・イベント・DB カラムのすべてが同一の新名称となり、旧名称のエイリアス・互換ビュー・二重書き込みは提供されません(server-web 974891b4, Flyway V103 order_calendar_names_isa95)。
| 旧名称 | 新名称 | 変更箇所 |
|---|---|---|
title | order_name | ワークオーダー — V5 要求・応答・/order/query 行, SDK setOrder_name, イベント plantpulse.order.*(全種類に付帯, deleted 含む), MCP list_work_orders·get_work_order_kpi, DB mm_order·mm_order_revision, Cassandra tm_asset_order |
fix_start_timestamp / fix_end_timestamp | planned_start_timestamp / planned_end_timestamp | ワークオーダー — 上記と同様。MCP の fix_start_at/fix_end_at は planned_start_at/planned_end_at |
fix_start_timestamp / fix_end_timestamp | start_timestamp / end_timestamp | カレンダー — V5 要求・応答・改定履歴, SDK setStart_timestamp/setEnd_timestamp, イベント plantpulse.calendar.created·updated·entry.*, DB mm_calendar·mm_calendar_revision·mm_shift |
target_units | planned_quantity | DB カラム mm_order·mm_order_revision·mm_order_oee. V5·SDK·イベントは既に planned_quantity であった |
external_order_id | external_id | ワークオーダー — V5 要求・応答・実績ドキュメント・/order/query フィルタ, SDK setExternal_id·OrderQuery.externalId(..), イベント, MCP get_work_order_kpi, DB |
external_po_id | customer_po_id | ワークオーダー — V5 要求・応答・実績ドキュメント, SDK setCustomer_po_id, 遷移イベント(started~aborted), MCP, DB |
external_customer_id / external_product_id | external_id + 新カラム external_system | 顧客・製品 — V5 要求・応答, SDK, DB. ペア検索 GET /customer/by-external/{system}/{external_id}·/product/by-external/… が新設された |
baseline_fix_start / baseline_fix_end | baseline_planned_start_timestamp / baseline_planned_end_timestamp | ワークオーダー deviation オブジェクト(V5·SDK·MCP) |
ソート fix_start_desc / fix_start_asc | planned_start_desc / planned_start_asc | /order/query の sort |
フロー title_field · target_units_field · external_order_id_field · external_po_id_field | order_name_field · planned_quantity_field · external_id_field · customer_po_id_field | flow_create_work_order ノード設定。デフォルトパスも data.order_name · data.planned_quantity · data.planned_start_timestamp · data.planned_end_timestamp · data.external_id · data.customer_po_id へ |
旧名称は受信しません — 静かに無視される箇所があるため、連携を先に修正してください。
POST·PUT /orderに旧名称を送信すると、そのカラムは読み込まれません。order_nameが空になるため検証エラーで拒否され(order_nameは必須、空白不可 —order.name.required)、計画時刻も空値となります。新名称と旧名称を混在させて送信した場合、保存はされますが、PUTは要求カラム全体を置き換えるため、旧名称で送信したexternal_order_id·external_po_idは消去されます。PATCH /orderに旧名称を送信すると 422 «not patchable» となります。/order/query?external_order_id=…は無視せず 422 で拒否します —external_idとexternal_systemを使用してください。- イベントは major 2 でのみ送信されます。major 1 スキーマファイルは再生用として残りますが、新しく送信されるイベントは新名称を搭載します。
/kpi/*応答とplantpulse.kpi.oee.finalizedのカラム名称は今回の変更対象外です(維持)。
アップグレード前に — 外部識別ペアの重複確認
新バージョンでは、外部識別ペアがともに空でないワークオーダー間で一意となるようインデックスを付与します(Flyway V100, ux_mm_order_external_pair)。
同一のペアを持つワークオーダーが2件以上存在する場合、そのステップで失敗するため、適用前に確認してください。
以下の SQL は適用前の DB で実行するため、旧カラム名 external_order_id を使用します(V103 で後に external_id に変更されます)。
SELECT external_system, external_order_id, count(*)
FROM pp.mm_order
WHERE external_system <> '' AND external_order_id <> ''
GROUP BY 1, 2
HAVING count(*) > 1;
0行である必要があります。行が表示された場合は、どちらかの external_system または external_order_id を修正してから適用してください。
external_order_id のみ存在し external_system が空であるワークオーダーはペアではないため、対象外となります(そのまま保持されます)。
初回起動時に発生する処理
| リポジトリ | タイミング | 処理内容 |
|---|---|---|
| PostgreSQL | server-web 起動(Flyway V99 order_quantity_isa95 · V100 order_external_id_pair_unique) | 数量カラムを numeric(18,4) に変更し、ワークオーダーごとに unit_of_measure を 'EA' で埋める。mm_order_oee.total_rework_count を加え REWORK 不良記録合計で埋める。製品単位をコードに移行し priority を整数に変更 |
| PostgreSQL | 続いて Flyway V103 order_calendar_names_isa95 | 上記 名称変更 表の DB カラムを RENAME COLUMN に変更 — データ・インデックス・制約・ビューは継承される。顧客・製品に external_system カラムとペア一意インデックスを追加(既存行のシステムは空のまま)、ワークオーダー status が WAIT·START·PAUSED·END·ABORTED 外であれば停止する。状態変更は改定行と同時にのみ行われるようトリガーを設定 |
| Cassandra · 保存 EQL | プラットフォーム初回起動(core V21~V23) | tm_asset_order に order_name·planned_start_timestamp·planned_end_timestamp を追加し、旧カラム値を移行(V21·V22, 数秒間, 旧カラムは削除しない)。保存済み設備ステートメント(EQL)の旧属性名を新名称に置換して書き込む(V23, SYSTEM 改定) — 修正できなかった文は診断 diagnostic.asset.statement_not_renamed として残る |
| Cassandra | プラットフォーム初回起動 | バージョンマイグレーションにより小規模表(OEE·EMS の current·order, tm_asset_order)に新 decimal 数量カラムと unit_of_measure を追加し、既存行を埋める('EA') — 数秒間。大規模表(OEE·EMS の rolling·rollup·history, tm_kpi_oee_count)は起動後のバックグラウンドで移行される。起動自体の所要時間は通常通り |
- 大規模表の移行中、履歴 KPI は旧カラムから同一の値で読み込まれます。表ごとの移行が完了すると、自動的に新カラムのみを読み込みます。進行状況は server-web 起動ログに «Cassandra migration» で始まる行として出力されます(
docker logs plantpulse-server-web | grep 'Cassandra migration')。 - 旧整数カラム(
target_units·total_production_count·total_good_count·total_bad_count)は移行完了後、読み書きされません。カラムの削除はこのバージョンではなく、以降のバージョンで行われます。新規インストールされたクラスターには最初から存在しません。
連携側の修正事項 — チェックリスト
- SDK —
plantpulse-apiを新バージョンに更新。setTarget_units(…)/setUnit(…)は廃止 →setPlanned_quantity(Quantity.of("500", "EA"))。 - V5 応答を読み込むコード — 旧カラム名(
target_units,total_good_count,total_bad_count,total_production_count,good_count/bad_count(数量記録),out_of_plan_*_count…)を新名称に変更。値は数値ではなくquantity_string文字列である — double に変換せず 10進形式で読み込む。 - 不良合計を使用していた箇所 — 旧
total_bad_countをscrap_quantityに変更するだけでは再作業分が除外される。不良合計が必要な場合はscrap_quantity+rework_quantityとする。 - 拒否処理 — 数量拒否は 422
E1002、分岐は応答のreason(quantity.*)を参照。数量カラムに数値を直接入力すると 400E1000。 - 実績・補正入力 — ワークオーダーの単位で送信する。個数単位(
EA·H87·C62·BX·SET)に小数を送信すると 422quantity.not_integer。 - 期間 KPI を合算する画面・レポート —
good_count等が null の場合はquantities_by_unitを参照。単位が異なる数量は合算しない。 - 名称変更 — V5 要求・応答を扱うコードにて
title·fix_start_timestamp·fix_end_timestamp·external_order_id·external_po_id(ワークオーダー),fix_start_timestamp·fix_end_timestamp(カレンダー),external_customer_id·external_product_id(顧客・製品)を新名称に変更。エイリアスがないためサーバーと同時に更新する。 - SDK セッター名称 —
setTitle→setOrder_name,setFix_start_timestamp→setPlanned_start_timestamp(カレンダーはsetStart_timestamp),setExternal_order_id→setExternal_id,setExternal_po_id→setCustomer_po_id,OrderQuery.externalOrderId(..)→externalId(..). - MES 実績収集 — 外部番号で検索していた呼び出しを
by-external/{external_system}/{external_id}へ。ワークオーダー作成時にexternal_systemも付与する。 - PostgreSQL を直接参照する SQL — 計画数量は
mm_order.planned_quantity(旧target_units)であり、文字列中でnumericとなる(文字列で読み込むと'1200.0000'形式)。mm_order_oeeの数量カラムもbigintからnumeric(18,4)へ。単位は新カラムunit_of_measure。その他、上記 名称変更 表の DB カラム名も変更される。 - フロー —
OEE_EVENTを読み込むスクリプトをdata.payload.good_quantity.quantity_stringへ。flow_create_work_orderノードに単位パスを設定する。このノードにtitle_field·target_units_field·external_order_id_field·external_po_id_fieldを直接記述したフローは設定が読み込まれず、新デフォルトパス(data.order_name…)が使用されるため、新設定名称で再記述する。ワークオーダー・カレンダーイベントの旧キーを読み込むスクリプトも新名称に変更する。 - 設備ステートメント(EQL) — アップグレード後、診断画面に
diagnostic.asset.statement_not_renamedがある場合は、その文の旧名称(fix_start_timestamp·title·external_order_id…)を手動で修正する。 - イベントコンシューマー —
plantpulse.order.*·plantpulse.calendar.*は major 2 の新キー(planned_start_timestamp·external_id·order_name…, カレンダーはstart_timestamp·end_timestamp)を読み込む。plantpulse.kpi.oee.finalizedは*_quantityカラムを読み込む。sqは廃棄のみであり、再作業はrq. 整数gq·sq·rq·pqは小数単位では搭載されず、次回の major で廃止される。