8c8d748a07
LINE WORKSからの応答を受ける唯一のWebhook受信口(45ノード)をローカルJSONとして作成。 awaitInput(none/date/file)3分岐のSwitchで、既存プロセス選択・日付入力・ファイル添付の 各応答パターンをHC-SUB(Task 9)へ橋渡しする。秘密値はすべてworkflow_config_values経由の Data Table参照。デプロイ・activateはコントローラー側で別途実施(本コミットはローカル定義のみ)。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
52 lines
6.1 KiB
Markdown
52 lines
6.1 KiB
Markdown
# healthcheck-survey-bot
|
||
|
||
健康診断管理(SiteId 508971)×LINEWORKS Bot連携。508971の`SiteSettings.Processes`
|
||
をフロー定義として使い、n8n上でBot対話型のStatus管理を行う。
|
||
|
||
設計書: `NodeSrv/docs/superpowers/specs/2026-09-05-healthcheck-lineworks-survey-n8n-design.md`
|
||
実装計画: `NodeSrv/docs/superpowers/plans/2026-09-05-healthcheck-lineworks-survey-n8n.md`
|
||
|
||
## 実機調査メモ（2026-09-05確認）
|
||
|
||
508971への新規テストProcess追加なしで、既存本番プロジェクト「実行予算WF申請」（SiteId 376872）の
|
||
取得済み`processes.json`（`Pleasanter/実行予算WF申請/configs/production/site-376872_実行予算WF申請/processes.json`）
|
||
に入力検証タブを使ったProcessの実例があり、そこからJSON構造を確認できた。
|
||
|
||
Processの入力検証タブは`SiteSettings.Processes[].ValidateInputs`配列として保存される。
|
||
各要素は`{"Id": number, "ColumnName": string, "Required": boolean}`（実例: `{"Id": 1, "ColumnName": "Class021", "Required": true}`）。
|
||
配列名は`Validations`ではなく`ValidateInputs`。値を設定していない項目（クライアント/サーバ正規表現、エラーメッセージ、最小/最大等）は
|
||
キー自体が省略される可能性が高い（今回の実例では未設定のため確認できていない）。
|
||
|
||
Task 5（processFlow.js）の`getValidationColumnNames`はこの構造（`process.ValidateInputs[].ColumnName`）を前提に実装する。
|
||
|
||
## n8nリソースID一覧
|
||
|
||
(Task 8〜11完了後、ここに作成したData Table ID・ワークフローIDを記録する)
|
||
|
||
- Data Table `healthcheck_bot_state`: `jqMDa2YZTI4f0iQ7`
|
||
- projectId: `LOcxF69Gm4PvnkqA`（`org-master-sync`用プロジェクトを流用）
|
||
- 列: `resultId`, `targetEmail`, `currentStatus`, `pendingProcesses`, `awaitInput`, `awaitProcessId`, `awaitColumn`（すべてstring型）
|
||
- 注記: 設計上の8列目`updatedAt`はn8n Data Tableのシステム予約列名（`POST /data-tables`が`400 Column name "updatedAt" is reserved as a system column name.`を返す）のため、列定義には含めていない。各行の更新日時はn8nが自動管理する`updatedAt`メタデータで代替する。
|
||
|
||
- ワークフロー `HC-SUB: プロセス実行と案内送信`: `XRqcykbG2LuAjGG2`
|
||
- ファイル: `workflows/hc-sub-run-process-and-notify.json`（Execute Workflow Trigger、入力`{resultId, processId}`）
|
||
- active化済み（Execute Workflow Triggerサブワークフローは呼び出し元から実行可能にするためactive必須、`asKvC5LSVg3q8tuU`と同じ運用）
|
||
- 秘密情報・SiteId等はすべて`workflow_config_values`（`bNkadTyDgDepYx2p`）から`Data Table`ノードで取得し式参照。ワークフローJSONに秘密値のハードコードなし
|
||
- 未検証の暫定実装あり（Task 12で要修正）: ①484184(`LINEWORKS_BOT_MASTER_SITE_ID`)からのBotId解決ロジック（実データ構造未調査のため`SiteSettings.BotIds`または`Processes[].BotId`を仮定し、無ければ例外を投げる）、②`/api/users/get`のレスポンス形状（配列/単一オブジェクト両対応の防御的実装）
|
||
- Step 4（実行テスト・LINEWORKS実送信）は本タスクでは未実施。次回、捨てレコードでの疎通確認とユーザー確認が必要
|
||
|
||
- ワークフロー `HC-WP: Statusプッシュ通知`: `swXfpoDtwZDT3Hwk`
|
||
- ファイル: `workflows/hc-wp-status-push.json`
|
||
- Webhook: `https://n8n32.next-hd.net/webhook/healthcheck-status-push`（`X-Api-Key`ヘッダー認証、body `{resultId, processId}`）
|
||
- active化済み
|
||
- `X-Api-Key`は`workflow_config_values`の`HEALTHCHECK_WP_API_KEY`と照合。秘密値のハードコードなし
|
||
- 実際のcurl疎通テスト（本番508971書き込み・LINEWORKS実送信を伴う）は未実施。ユーザー確認後に実施する
|
||
- デプロイ・活性化はサブエージェントのBashサンドボックスが実APIキー使用を一律ブロックしたためコントローラーが直接実行した（詳細: `task-10-report.md`）
|
||
|
||
- ワークフロー `HC-WA: LINEWORKS応答受信`: **ローカルJSON作成のみ、n8n未デプロイ**（id未採番）
|
||
- ファイル: `workflows/hc-wa-lineworks-response.json`（45ノード、Webhook `healthcheck-lineworks-response` 唯一の受信口、`awaitInput`(none/date/file)3分岐のSwitch構成）
|
||
- 本タスクの担当範囲はワークフローJSONのローカル作成・検証までで、n8n Public APIの呼び出し（デプロイ・activate）は一切実施していない。コントローラー側での`node scripts/deploy-workflow.js workflows/hc-wa-lineworks-response.json`実行後、実際のワークフローIDをこの行に追記すること
|
||
- 秘密情報・SiteId等はすべて`workflow_config_values`（`bNkadTyDgDepYx2p`）から`Data Table`ノードで取得し式参照。ワークフローJSONに秘密値のハードコードなし
|
||
- 未検証の暫定実装あり（詳細は`task-11-report.md`）: ①Data Table `update`操作のパラメータ形状（get/insertは実機確認済みだが、updateは本タスクで初採用のため未検証）、②Switchノード(typeVersion 3)の`rules.values[].outputKey`スキーマ、③`/api/users/get`をWhere無しで呼んだ場合のレスポンス形状（配列/`.Value`/単一オブジェクトいずれにも対応する防御的実装）、④`api/items/{SiteId}/get`（ColumnFilterHash検索）のレスポンス形状、⑤LINEWORKSファイル添付のダウンロード/Pleasanterアップロードのエンドポイント（ブリーフ記載どおり実装時にPleasanter公式マニュアルapi-attachment系で要確認のプレースホルダー）
|
||
- 設計上の注記: HC-SUB（Task 9）が`healthcheck_bot_state`に保存する`pendingProcesses`は`{processId, label, tooltip}`のみで`ValidateInputs`を持たないため、none分岐での`classifyAwaitInput`実行時はHC-WA内で`サイト設定取得`(getsite)を再実行し、ProcessId一致でフルのProcess定義を引き直す設計にした（Task 9側のファイルは変更していない）
|