ユニークキーのルール
工程の依頼ごとに親キーを発行し、その末尾にシリアル・確認項目の管理番号を付けます。同じレコードの値を修正しても、キーは変わりません。
| 対象 | 形式 |
|---|---|
| 工程 | iw_pro_本体22文字 |
| シリアル | 工程キー_001 |
| 確認結果 | 工程キー_001_001 |
proはprocess（工程）の略です。本体は依頼UUIDの16バイトをBase64urlにした22文字で、工程キー全体は29文字です。英大文字・小文字・数字・アンダースコア・ハイフンのみを使い、大文字と小文字を区別します。
{ "process_record_id": "iw_pro_lwsiSpHpTVWXr-JkEAuoWg", "serials": [ { "works_data_id": 1, "serial_record_id": "iw_pro_lwsiSpHpTVWXr-JkEAuoWg_001", "checks": [ { "field_key": "appearance", "check_record_id": "iw_pro_lwsiSpHpTVWXr-JkEAuoWg_001_001" }, { "field_key": "voltage", "check_record_id": "iw_pro_lwsiSpHpTVWXr-JkEAuoWg_001_002" } ] } ]}番号は固定の管理番号
1から採番し、最低3桁でゼロ埋めします。999を超えたら1000、1001と桁を増やします。表示順を変えても振り直さず、削除番号は再利用しません。番号で並べ替える場合は数値として比較します。
現在のAPIは発行時のシリアル・項目構成を固定保存するため、その順序を採番根拠にできます。回答の取得順や画面の表示順から番号を計算し直しません。発行後に行・項目を追加削除する機能を実装する場合は、採番済み対応と過去最大番号を永続化して維持します。
APIと連携するとき
送信JSONの idempotency_key は従来どおりUUIDです。業務IDや form.fields[].key をこのユニークキーに置き換えないでください。工程キーは発行レスポンスの process_record_id、子キーは結果APIの serial_record_id と checks[].check_record_id で取得します。未入力セルにもキーが付き、値はnullになります。
同じ依頼の再送・下書き保存・完了でキーは維持されます。別依頼として発行すると別キーです。企業をまたいで共有する製品の生涯IDや、認証用のAPIキーではありません。
保存・解析の注意
本体にもアンダースコアを含むため、単純な区切り文字分割は避け、先頭29文字と後続の番号を分けて読みます。保存側は大文字小文字を区別した一意制約を設け、revisionで更新順を確認してください。
本社向け拡張出力の iw_exp_ は出力ファイル、iw_fld_ は項目定義のキーです。この2種は拡張サンプルの属性で、現在の結果APIには含めません。