iPaaS・フローエディタ連携の実現可能性
iPaaS（Integration Platform as a Service）は、複数のサービスをつないでデータの受け渡しや処理の自動化を行う基盤です。Node-RED のように、トリガー・処理・出力をノードとして画面に並べ、線でつないでフローを作る UI を持つものが多くあります。
このページは、そのような仕組みをプリザンターで実現できるかを整理した設計メモです。本体の標準機能ではありません。 前提にした現行実装は 1.5.8.1 のソースで確認しています。
現行の構成要素との対応
| iPaaS の要素 | プリザンターの現行機能 | 対応状況 |
|---|---|---|
| トリガー（レコード変更） | 通知の作成後・更新後・削除後など（Webhook 通知の改修案） | あり |
| トリガー（時刻） | バックグラウンドサーバースクリプト（毎時・毎日・毎週・毎月・1 回だけ）、リマインダー | あり |
| トリガー（外部からの受信） | 受信用の口が無い（外部 Webhook 受信の設計） | なし |
| アクション | サーバースクリプト（JavaScript） | 一部（1 本のスクリプトに書く） |
| コネクタ | サーバースクリプトの httpClient（汎用の HTTP） | 一部（サービス専用のコネクタは無い） |
| フロー定義 | 複数の処理をつなぐデータモデルが無い | なし |
| ビジュアルエディタ | 無い | なし |
| 実行エンジン | V8 と Quartz.NET のスケジューラはあるが、フローの実行には対応しない | 一部 |
| エラー処理 | SysLogs への記録はあるが、再試行や失敗キューは無い | 一部 |
バックグラウンドサーバースクリプトのスケジュール種別は hourly・daily・weekly・monthly・onlyonce です（BackgroundServerScriptUtilities.cs）。
図を読み込み中…
3 つのアプローチ
1. プリザンターに組み込む
フロー定義・実行エンジン・ビジュアルエディタ・受信口をすべて本体に追加します。
| 改修 | 規模 |
|---|---|
| Webhook 受信口 | 小 |
| 受信内容の変換 | 中 |
| フロー定義のデータモデル（ノード・エッジ・分岐） | 大 |
| フロー実行エンジン（順次・並列の実行） | 大 |
| ビジュアルエディタ | 大 |
| フローの保存・版管理・テナント分離 | 中 |
| 再試行・タイムアウト・失敗キュー | 中 |
| 実行履歴・ノードごとの結果の記録 | 中 |
認証・権限の仕組みやサイト設定の画面、サーバースクリプトをそのまま使えるのが利点ですが、改修が大きく、信頼性（再試行・冪等性・順序保証）の作り込みとバージョンアップへの追従が重い負担になります。
2. 外部の iPaaS / Node-RED に任せる（推奨）
フローの制御は Node-RED や n8n などに任せ、プリザンター側は受信口の追加など最小限の改修にとどめます。
図を読み込み中…
| 改修 | 規模 |
|---|---|
| Webhook 受信口 | 小 |
| 署名検証（HMAC-SHA256 など） | 小 |
| HttpClient 通知の再試行・ログ強化 | 小 |
| 受信をサーバースクリプトのトリガーにする | 中 |
成熟したフローエンジンと UI、コネクタ群、再試行などの仕組みをそのまま使えます。代わりに別サービスの運用が必要になり、プリザンターの権限モデルとの統合は API キーの範囲に限られます。
3. エディタだけプリザンターに載せる
フローエディタの画面はプリザンターに作り、実行は外部のエンジン（Node-RED や Temporal など）に任せる折衷案です。
図を読み込み中…
既存の拡張ポイント
| 拡張ポイント | 1.5.8.1 の状態 |
|---|---|
| 拡張ライブラリ（ExtendedPlugin） | プラグインの種類は Pdf だけ（ExtendedPlugin.cs）。読み込みの仕組みを広げれば受信やフローを載せられる可能性がある |
拡張 API（ExtendedController） | API コントローラの 1 つ。受信口を作るときの参考になる |
| バックグラウンド処理 | Quartz.NET のスケジューラ上で、リマインダー・LDAP 同期・各種の削除タイマー・バックグラウンドジョブなどが動いている（TimerBackground.cs）。フローの実行も同じ基盤に載せられる |
フローエディタの候補
| ライブラリ | 特徴 | ライセンス | 前提 |
|---|---|---|---|
| React Flow | React のノードエディタ。カスタムノードが柔軟 | MIT | React |
| Rete.js | フレームワーク非依存、プラグインで拡張 | MIT | なし |
| Flume | React。ノードの型定義が宣言的 | MIT | React |
| Drawflow | 軽量（約 11KB）、素の JavaScript、依存なし | MIT | なし |
| Node-RED のエディタ | Node-RED のエディタを埋め込む | Apache-2.0 | jQuery / D3 と Node-RED 本体 |
プリザンターの画面は jQuery が基盤で、サーバー側の HtmlBuilder が HTML を組み立てます。React 系を入れると部分的な導入になり、仮想 DOM との共存に気を使います。Drawflow は素の JavaScript で依存が無く、JS と CSS を 1 つずつ置くだけで使え、ノードを HTML 文字列で定義でき、export() / import() でフロー全体を JSON にできるため、最も合うと判断しました。
Drawflow を載せる手順
1.5.8.1 の wwwroot/Extensions/ には Mermaid（mermaid-11.9.0.min.js）や D3 などの外部ライブラリが置かれています。Drawflow も同じ場所に置きます。
| 手順 | 規模 | 内容 |
|---|---|---|
| 1 | 小 | Drawflow の JS / CSS を wwwroot/Extensions/ に置く |
| 2 | 小 | サイト設定画面でだけ読み込む（拡張スクリプト・拡張スタイルで注入するか、HtmlScripts.cs に条件付きで追加する） |
| 3 | 小 | サイト設定画面（SiteUtilities.cs）に「フロー」タブを追加する |
| 4 | 小 | SiteSettings にフロー定義（JSON）を持たせる |
| 5 | 中 | エディタの初期化・保存・読み込み |
| 6 | 中 | ノードの HTML テンプレートと入力チェック |
| 7 | 大 | フロー定義を解釈して実行するエンジン |
手順 2 は、拡張スクリプトなら本体を改修せずに済み、HtmlScripts.cs に書くほうが読み込みの管理はしやすくなります。
// フロータブを開いたときの初期化（例）
(function () {
var container = document.getElementById('FlowEditor');
if (!container) return;
var editor = new Drawflow(container);
editor.reroute = true;
editor.start();
var saved = $('#FlowDefinition').val();
if (saved) {
try {
editor.import(JSON.parse(saved));
} catch (e) {
console.warn('フロー定義の読み込みに失敗:', e);
}
}
// 保存時に hidden 項目へ書き出す
$('#FlowSettingsEditor').on('save', function () {
$('#FlowDefinition').val(JSON.stringify(editor.export()));
});
// トリガーノードへの入力接続を禁止する
editor.on('connectionCreated', function (c) {
var input = editor.getNodeFromId(c.input_id);
if (input.class.indexOf('trigger-node') !== -1) {
editor.removeSingleConnection(c.output_id, c.input_id, c.output_class, c.input_class);
}
});
})();ノードの種類
| ノード | 入力 | 出力 | パラメータ |
|---|---|---|---|
| Webhook 受信 | 0 | 1 | 受信口の ID、検証方式（HMAC / Bearer / なし） |
| スケジュール | 0 | 1 | Cron 式、タイムゾーン |
| レコード変更 | 0 | 1 | サイト ID、種類（作成・更新・削除） |
| API 呼び出し | 1 | 1 | URL、メソッド、ヘッダ、本文 |
| レコード操作 | 1 | 1 | サイト ID、操作（作成・更新・Upsert・削除）、項目の対応 |
| 通知 | 1 | 0 | 通知先、テンプレート |
| スクリプト実行 | 1 | 1 | サーバースクリプト |
| 条件分岐 | 1 | 2 以上 | 条件式 |
| ループ | 1 | 1 | 繰り返し条件 |
| 待機 | 1 | 1 | 秒数 |
フロー定義の保存先
| 保存先 | 利点 | 課題 |
|---|---|---|
SiteSettings のプロパティ | 既存の設定と同じ扱い（推奨） | JSON が大きくなる |
| 拡張テーブル（Extensions） | サイト設定と分けて管理できる | 読むたびに追加のクエリ |
| 専用テーブル | 実行履歴と結びつけやすい | CodeDefiner の定義追加 |
結論
| 項目 | 結論 |
|---|---|
| 送信 | 通知の HttpClient 種別とサーバースクリプトの httpClient で実現できている |
| 受信 | 専用の口は無い。API で代替するには中継での変換が要る |
| iPaaS の実現可能性 | 技術的には可能だが、フロー定義・実行エンジン・エディタの 3 つが大きな新規開発になる |
| 推奨 | 外部の Node-RED / n8n などに任せる案。プリザンター側は受信口の追加で足りる |
| エディタを作るなら | Drawflow が jQuery ベースの画面と競合せず導入しやすい |
| 送信側の改善 | 再試行・署名・送信ログ・本文テンプレートが iPaaS 連携で効く（Webhook 通知の改修案） |