メインコンテンツまでスキップ

連携ノード

このページでは、外部システムと連携するワークフローノード — API ノード、GitHub 系ノード、Forge Function ノード — の設定について説明します。利用可能なノードの一覧については、ワークフローノードを参照してください。

API ノード — Auto Retry​

API ノード には Auto Retry セクションがあります。有効にすると、失敗したリクエストは即座に失敗として処理されるのではなく自動的に再試行され、再試行のタイミングはランダム化された減衰型の遅延によって時間的に分散されます。再試行が尽きると、設定済みの Failure Routes に処理が引き継がれます。

API Node Auto Retry settings

API ノード — Auto Retry の設定

設定説明
Enable auto retryこのノードの自動リトライ動作を有効にします。
Retry onどの失敗タイプで再試行をトリガーするか: Timeout、HTTP error status、Null / empty response、Other errors。
Max retries最大の再試行回数です。
First retry delay最初の再試行までの待機時間です。再試行は5分単位のスケジュールで確認されるため、遅延は5分刻みで選択され、最初の再試行は選択した遅延が経過した後の次回チェック時に行われます。
Delay decay factor連続する再試行の間の遅延に適用される乗数です。
Max delay再試行間の遅延の上限です。
Jitter (0–1)遅延をどの程度ランダム化するかです。1 にすると、同時に失敗した項目が同じタイミングで一斉に再試行されないよう、再試行がウィンドウ全体に完全に分散されます。0 にすると固定の遅延が使われます。

API ノード — Concurrency & burst control​

API ノード には Concurrency & burst control セクションもあり、速度が遅い、またはレート制限のあるエンドポイントに対してこのノードが送信するリクエスト数を制限します。上限に達すると、実行は失敗する代わりにキューに入れられ、自動的に再試行されます。

API Node Concurrency and burst control settings

API ノード — Concurrency & burst control の設定

設定説明
Limit concurrent requestsこのノードの同時実行数・バースト制限を有効にします。デフォルトでは無効です。
Group requests by以下の上限を適用する際に何を「同じエンドポイント」とみなすかです。デフォルトは URL (host and path) で、各エンドポイントに個別の上限が割り当てられます。他のオプションとして、ホスト全体で1つの上限を共有する（Server）、または宛先を問わずノード全体で共有する（This node）もあります。
Requests at the same time同時に実行できるリクエストの数です。それ以上のリクエストは、いずれかの応答が返るまで待機します。
Requests per time window重複の有無を問わず、各ウィンドウ内で許可されるリクエストの総数です。0 のままにすると、この時間ベースの上限は無効になり、同時実行数の上限のみが適用されます。
Wait for a free slot (seconds)待機中のリクエストが、キューに入れられて次のスイープに回される前にスロットの空きを待つ時間です。混雑のほとんどは数秒で解消するため、短い待機時間でもリクエストがすぐに送信されることが多いです。すぐにキューへ入れたい場合は 0 に設定します。

これらのフィールドの上には、設定した上限を平易な文章で言い換えたライブサマリーが表示されます（例: 「各 URL (host and path) に対して同時に最大2件のリクエスト。待機中のリクエストは最大30秒待ち、その後次のスイープでキューに入ります。」）。キューに入った実行は、およそ5分ごとの次のスイープで再試行され、失敗としてではなく Inbox 上で Queued として表示されます。解消されないキューは、ノードの Failure Routes 設定にある Queue limit reached オプションでルーティングできます。

GitHub Commit ノード​

GitHub Commit ノード は、1つ以上のドキュメントを接続済みの GitHub リポジトリにコミットします。コネクタの contents_write 機能が有効になっている必要があり（.github/workflows 配下にコミットする場合は workflow_files も必要）、そうでない場合は実行が拒否されます。

GitHub Commit Node settings

GitHub Commit ノード — リポジトリとブランチの設定

設定説明
Repositoryコミット先となる、接続済みの GitHub リポジトリです。
Branchコミット先のブランチです。ソースドキュメントに対する Jinja テンプレートに対応しています。
Base branch（任意）ブランチがまだ存在しない場合に、そこからフォークする元のブランチです。空欄の場合はリポジトリのデフォルトブランチが使用されます。
Create branch if missingブランチが存在しない場合に作成します。無効で、かつブランチが見つからない場合、ノードは失敗します。
Delete branch on completion後続の GitHub Action の実行が完了した時点でブランチを削除します。使い捨てのブランチを片付ける際に便利です。このノードの後に poll モードまたは webhook モードの GitHub Action ノード が必要です。
What to commitこのノードがコミットするドキュメントを選択します（詳細は下記）。
Repository path（任意）ファイルを配置するリポジトリ内のサブフォルダーです。空欄の場合、各ドキュメントの元のファイル名でリポジトリのルートにコミットされます。
Commit message（任意）デフォルトのコミットメッセージを上書きします。Jinja テンプレートに対応しています。

What to commit には3つのオプションがあります。

What to commit selector options

What to commit — 選択オプション

オプション説明
Workflow documentこのワークフローの開始元となったアイテムです。
Node input前のノードで生成されたドキュメントです。
Specific document IDsコミットするドキュメント ID をカンマ区切りで指定したリストです。

GitHub Action ノード — Run Tracking​

GitHub Action ノード は GitHub Actions のワークフロー実行をディスパッチし、選択した Run Tracking Mode に応じて、処理を進める前にその実行が完了するのを待つことができます。コネクタの actions 機能が有効になっている必要があり、そうでない場合は実行が拒否されます。

設定説明
Repository接続済みの GitHub リポジトリです。
Workflow File選択した ref 上の、.github/workflows 内にあるワークフローファイル名です。workflow_dispatch トリガーと docwize_run_id の入力を宣言し、run-name を通じてそれをエコーする必要があります。これにより Docwize がその実行を識別できるようになります。
Ref（ブランチまたはタグ）ディスパッチ先となるブランチまたはタグです。Jinja テンプレートに対応しています。
Workflow Inputs実行に渡す、追加の workflow_dispatch 入力です。値は Jinja テンプレートに対応しており、ディスパッチ時に展開されます。docwize_run_id の関連付けトークンは自動的に追加されます。
Run Tracking ModeFire and forget（ディスパッチ後、即座に処理を継続）、Poll for completion（一時停止し、実行が完了するまで Actions API をポーリング）、Await webhook（一時停止し、GitHub が workflow_run の完了 webhook を配信した時点で再開。取り逃した配信はウォッチドッグによるポーリングで回収されます）。

対象のワークフローファイルが実行の関連付けに対応していない可能性がある場合、ダイアログに事前警告が表示されます。

Run tracking may not work for this workflow warning

事前警告: このワークフローでは実行トラッキングが機能しない可能性があります

実行をポーリングまたは待機するには、ワークフローファイルで workflow_dispatch トリガーと docwize_run_id 入力を宣言し、それをトップレベルの run-name にエコーする必要があります（例: run-name: "${{ inputs.docwize_run_id }}"）。run-name へのエコーがない場合、Docwize は実行を関連付けられず、ノードはタイムアウトするまで停止したままになります。Fire and forget モードはこの影響を受けません。

このノードは3つのアウトプットのいずれかにルーティングされます: On success（実行が成功して完了）、On failure（実行は完了したが失敗した）、On infrastructure error（GitHub Actions の実行自体の失敗とは異なり、コネクタや API の問題などにより、Docwize が実行をディスパッチまたはトラッキングできなかった）。

Forge Function ノード​

Forge Function ノードは、対応するアップロード済みのファンクションをワークフローのドキュメントとそのファイルに対して実行します。アウトプット側は固定のポート数ではなく、そのファンクションのマニフェストで宣言されたアウトプットルートごとに1つのポートを持ちます。たとえば、あるファンクションが Appended、No PDF、Error のルートを公開し、それぞれが異なる次のステップに接続される場合があります。

関連する設定​