magic-etl-cli

Name: magic-etl-cli
Author: stahura

github.com/stahuraデータ・データベース24167 回インストール26 週間前に更新

magic-etl-cli について

magic-etl-cli は、community-domo-cli で Domo Magic ETL のデータフローを定義・操作するためのスキルです。JSON DAG の構造、対応するアクション、キャンバスの整理方法と、作成・更新・実行・確認のコマンドを説明します。

主な機能

01CLI によるデータフローの作成と更新
02JSON DAG によるデータフロー定義
03アクション種別と依存関係の説明
04セクションとタイルによるキャンバス整理
05フロー実行と実行履歴の確認

活用シーン

01データセットから Magic ETL フローを構築
02既存データフロー定義の変更
03フロー実行とステータスの確認
04キャンバス上の分岐と処理段階の整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/stahura/domo-ai-vibe-rules --skill magic-etl-cli

インストール後、Claude Code で/magic-etl-cliを入力して読み込まれたか確認します。

詳細

Domo で Magic ETL データフローをプログラムから作成する

概要

Domo の Magic ETL データフローは、community-domo-cli を使用して作成、更新、実行できます。データフローは、アクション（入力ノード、変換、出力ノード）の有向非巡回グラフ（DAG）を記述した JSON ドキュメントとして定義します。

すべてのデータフロー操作には community-domo-cli を使用してください。

操作	CLI コマンド
データフローの一覧表示	`community-domo-cli dataflows list`
データフロー定義全体の取得	`community-domo-cli dataflows get-definition <ID>`
データフローの実行	`community-domo-cli -y dataflows run <ID>`
実行ステータスの確認	`community-domo-cli dataflows executions <ID> --limit 1`
データフローの作成	`community-domo-cli -y dataflows create --body-file <FILE>`
データフローの更新	`community-domo-cli -y dataflows update <ID> --body-file <FILE>`
名前変更／有効化	`community-domo-cli -y dataflows update <ID> --body-file <FILE>`

**重要：**すべての操作には community-domo-cli を使用します。認証は自動的に処理されます。作成されたデータフローは DRAFT 状態ではないため、UI で保存しなくてもすぐに実行できます。

**変更を伴うコマンドには -y（または --yes）が必要です。**作成、更新、実行では Execute mutating action? [y/N] という確認が表示されます。-y を指定せず、stdin が TTY でない場合（スクリプト、Python の subprocess、CI など）、CLI は中止します。自動化では必ず -y を指定してください。

ユーザー ID を検索しないでください。responsibleUserId は省略可能なため、項目自体を含めないでください。データフロー作成用のユーザー ID を探すために、community-domo-cli users list やユーザー関連のエンドポイントを呼び出してはいけません。

データフロー用 CLI コマンド

すべての Magic ETL データフローを一覧表示する

community-domo-cli dataflows list

データフロー定義を取得する

community-domo-cli dataflows get-definition <DATAFLOW_ID>

GET /dataprocessing/v1/dataflows/{id} を介して、すべてのアクション、入力、出力、GUI の位置を含む JSON 定義全体を返します。JSON の構造を把握するには、既存のデータフローを取得して調べるのが最適です。更新を行う前には、必ずこのコマンドを使用してください。

データフローを実行する

community-domo-cli -y dataflows run <DATAFLOW_ID>

データフローの実行一覧を表示する

community-domo-cli dataflows executions <DATAFLOW_ID> --limit <LIMIT>

特定の実行を確認する

community-domo-cli dataflows execution-get <DATAFLOW_ID> <EXECUTION_ID>

実行状態（SUCCESS、FAILED_DATA_FLOW、CREATED、RUNNING）、行数、エラーなどを返します。

CLI でデータフローを作成する

作成

community-domo-cli -y dataflows create --body-file <FILE>

本文には必ず "databaseType": "MAGIC" を含めてください。作成したデータフローはすぐに実行できます。詳細は注意点 #7 と #11 を参照してください。

既存のデータフローを更新する

community-domo-cli -y dataflows update <DATAFLOW_ID> --body-file <FILE>

最初に必ず get-definition で定義全体を取得し、変更してから --body-file で渡してください。定義全体を含めてください。PUT はデータフロー全体を置き換えます。

データフロー JSON の構造

トップレベルのフィールド

{
  "name": "My Magic ETL",
  "databaseType": "MAGIC",
  "responsibleUserId": 149955692,
  "draft": false,
  "enabled": true,
  "runState": "ENABLED",
  "engineProperties": {
    "kettle.mode": "STRICT"
  },
  "inputs": [ ... ],
  "outputs": [ ... ],
  "actions": [ ... ]
}

フィールド	説明
`name`	データフローの表示名
`databaseType`	Magic ETL では `"MAGIC"` を指定する必要があります
`responsibleUserId`	所有者の数値のユーザー ID
`draft`	公開済みデータフローでは `false`
`enabled`	実行を許可するには `true`
`runState`	スケジュール実行を許可するには `"ENABLED"`
`engineProperties`	`{"kettle.mode": "STRICT"}` が標準です
`inputs`	入力データセット参照の配列
`outputs`	出力データセット参照の配列
`actions`	アクションノード（DAG）の配列

ユーザー ID を検索しないでください。responsibleUserId は省略可能なため、項目自体を含めないでください。データフロー作成用のユーザー ID を探すために、community-domo-cli users list やユーザー関連のエンドポイントを呼び出してはいけません。

トップレベルの `gui` フィールド（キャンバスのレイアウトとセクション）

gui フィールドは、関連するタイルをグループ化する色付きのセクションゾーンを含め、キャンバスの視覚的なレイアウトを制御します。useGraphUI: true の場合、キャンバスの elements 配列がタイルの位置を制御します（アクションレベルの gui.x／gui.y より優先されます）。

{
  "gui": {
    "version": "1.0",
    "canvases": {
      "default": {
        "canvasSettings": {
          "coarserGrid": false,
          "hideCoarserGridPopUp": false,
          "backgroundVariant": "None"
        },
        "elements": [
          { "type": "Section", ... },
          { "type": "Tile", ... }
        ],
        "disabledActions": []
      }
    },
    "useGraphUI": true
  }
}

セクション要素（色付きの背景ゾーン）

セクションは、キャンバス上で関連するタイルを視覚的にグループ化する、色付きの長方形のゾーンです。

{
  "id": "a-unique-uuid",
  "type": "Section",
  "x": 56,
  "y": 72,
  "width": 1320,
  "height": 288,
  "name": "Work Orders Denormalization",
  "backgroundColor": "var(--colorChartBlue6)"
}

フィールド	説明
`id`	セクションの一意な UUID
`type`	`"Section"` である必要があります
`x`、`y`	キャンバス上の絶対位置（左上隅）
`width`、`height`	色付きゾーンのピクセル単位のサイズ
`name`	セクションのヘッダーに表示されるラベル
`backgroundColor`	ゾーンの色を指定する CSS 変数（下の表を参照）

使用可能なセクションの背景色

CSS 変数	色	推奨される用途
`var(--colorChartBlue6)`	ライトブルー	入力／ステージングパイプライン
`var(--colorChartGreen6)`	ライトグリーン	品質／検証パイプライン
`var(--colorChartPurple6)`	ライトパープル	出力／公開パイプライン
`var(--colorChartOrange6)`	ライトオレンジ	変換／エンリッチメントパイプライン
`var(--colorChartRed6)`	ライトレッド	フィルター／除外パイプライン
`var(--colorChartYellow6)`	ライトイエロー	共有／ディメンションテーブル

接尾辞の 6 は最も明るい色合いを示します。タイルのラベルを読みやすく保てるため、セクションの背景に最適です。

タイル要素（アクションの位置）

各アクションノードには、キャンバス上に対応する Tile 要素があります。タイルはセクション内に親子関係を設定できます。この場合、x／y はセクションの位置を基準とした相対座標になります。

{
  "id": "LoadFromVault-work_orders",
  "type": "Tile",
  "x": 72,
  "y": 56,
  "parentId": "section-uuid-here",
  "color": null,
  "colorSource": null
}

フィールド	説明
`id`	アクションの `id` フィールドと一致する必要があります
`type`	`"Tile"` である必要があります
`x`、`y`	位置。`parentId` がない場合は絶対座標、`parentId` が設定されている場合は親セクションを基準とした相対座標です
`parentId`	親セクション要素の UUID（親を持たないタイルでは省略）
`color`	タイルアイコンの色を指定する任意の整数コード

親子関係の設定変更に関する計算式： タイルをセクション内に移動する場合は、絶対座標を相対座標に変換します。

relativeX = absoluteX - section.x
relativeY = absoluteY - section.y

parentId のないタイルは、キャンバスの絶対座標に配置され、どのセクションにも含まれません。

データフローの作成時には必ずセクションを追加する

複数の論理分岐や処理ステージを持つデータフローを構築する場合、視覚的なレイアウトを整理するために必ずセクション要素を追加してください。これは、データフローをすぐに理解できるようにするベストプラクティスです。タイルは次の単位でグループ化します。

パイプラインの分岐（例：各ファクトテーブルの結合チェーンに専用のセクションを設定）
処理ステージ（例：「入力／ステージング」、「変換」、「出力」）
共有リソース（例：複数の分岐で使用されるディメンションテーブル）

視覚的に区別できるよう、各セクションに異なる色を割り当てます。

Inputs 配列

各入力は、データフローにデータを供給する Domo データセットを参照します。

"inputs": [
  {
    "dataSourceId": "422efbf4-6c96-4576-907b-eacae8379d5d",
    "executeFlowWhenUpdated": false,
    "dataSourceName": "RAW | SFDC | Accounts",
    "onlyLoadNewVersions": false,
    "recentVersionCutoffMs": 0
  }
]

フィールド	説明
`dataSourceId`	入力データセットの UUID
`dataSourceName`	表示名（読みやすさのため）
`executeFlowWhenUpdated`	この入力が更新されたときにデータフローを自動的に実行するには `true` を指定します
`onlyLoadNewVersions`	新しいデータバージョンのみを処理するには `true` を指定します

Outputs 配列

出力データセットがまだ存在しない新規データフローの場合：

"outputs": [
  {
    "dataSourceId": null,
    "dataSourceName": "SFDC | Account Summary",
    "versionChainType": "REPLACE"
  }
]

dataSourceId を null に設定すると、初回実行時に Domo が新しいデータセットを作成します。初回実行が成功すると、Domo が UUID を割り当てます。

既存の出力データセットの場合：

"outputs": [
  {
    "dataSourceId": "8fe448eb-231d-4ff5-95f1-86db64336e96",
    "dataSourceName": "SFDC | Account Opportunity Summary",
    "versionChainType": "REPLACE"
  }
]

versionChainType に "REPLACE" を指定すると、実行のたびにすべてのデータが置き換えられます。ほかの選択肢には "APPEND" があります。

アクションの種類

アクションは DAG 内のノードです。各アクションには一意な id と type があり、dependsOn を使って上流の依存関係を参照します。

有効な種類：LoadFromVault、PublishToVault、MergeJoin、GroupBy、WindowAction、Filter、ExpressionEvaluator、SQL

無効な種類（DP-0069 で失敗します）：SaveToVault、SelectValues、RenameColumns

共通のアクションフィールド

すべてのアクションには、次のフィールドがあります。

{
  "type": "ActionType",
  "id": "unique-action-id",
  "name": "Human-readable name",
  "dependsOn": ["upstream-action-id-1", "upstream-action-id-2"],
  "settings": {
    "preferredDatabaseEntityType": "TEMP_VIEW"
  },
  "gui": {
    "x": 128,
    "y": 128,
    "color": null,
    "colorSource": null,
    "sampleJson": null
  },
  "tables": [{}]
}

フィールド	説明
`id`	このアクションノードの一意の識別子です。任意の文字列を指定できますが、`TypeName-uuid` が慣例です
`dependsOn`	このアクションの実行前に完了している必要があるアクション ID の配列です
`gui.x` / `gui.y`	ビジュアルキャンバス上の位置です。`useGraphUI: true` の場合は、トップレベルの `gui.canvases.default.elements` 配列が優先されます。一貫性を保つため、両方に設定してください
`settings.preferredDatabaseEntityType`	常に `"TEMP_VIEW"` です
`tables`	常に `[{}]` です

LoadFromVault（入力ノード）

Domo のデータセットからデータフローにデータを読み込みます。

{
  "type": "LoadFromVault",
  "id": "LoadFromVault-accounts",
  "name": "RAW | SFDC | Accounts",
  "settings": {"preferredDatabaseEntityType": "TEMP_VIEW"},
  "gui": {"x": 128, "y": 128, "color": null, "colorSource": null, "sampleJson": null},
  "previewRowLimit": 10000,
  "propagateAi": false,
  "filterPolicy": "LEGACY",
  "dataSourceId": "422efbf4-6c96-4576-907b-eacae8379d5d",
  "sourceType": "AUTO",
  "executeFlowWhenUpdated": false,
  "pseudoDataSource": false,
  "truncateTextColumns": false,
  "truncateRows": false,
  "onlyLoadNewVersions": false,
  "recentVersionCutoffMs": 0,
  "tables": [{}]
}

主なフィールド：

dataSourceId：読み込むデータセットの UUID
name：わかりやすいように、データセット名と一致させてください
dependsOn はありません。このノードはルートノードです

MergeJoin（結合）

指定したキーを使って、2 つの上流アクションを結合します。

{
  "type": "MergeJoin",
  "id": "MergeJoin-accounts-opps",
  "name": "Join Accounts & Opp Summary",
  "dependsOn": ["LoadFromVault-accounts", "GroupBy-opp-summary"],
  "disabled": false,
  "removeByDefault": false,
  "notes": [],
  "settings": {"preferredDatabaseEntityType": "TEMP_VIEW"},
  "gui": {"x": 576, "y": 320, "color": null, "colorSource": null, "sampleJson": null},
  "previewRowLimit": null,
  "joinType": "LEFT OUTER",
  "relationshipType": "MTM",
  "step1": "LoadFromVault-accounts",
  "step2": "GroupBy-opp-summary",
  "keys1": ["Id"],
  "keys2": ["AccountId"],
  "on": null,
  "schemaModification1": [],
  "schemaModification2": [
    {"name": "AccountId", "rename": "Opp_AccountId", "remove": true}
  ]
}

フィールド	説明
`joinType`	`"LEFT OUTER"`、`"INNER"`、`"RIGHT OUTER"`、`"FULL OUTER"`
`relationshipType`	`"MTM"` — この略語を使用してください。`"MANY_TO_MANY"` は使用しないでください（検証エラーが発生します）
`step1`	結合の左側のアクション ID
`step2`	結合の右側のアクション ID
`keys1`	結合に使用する step1 の列名の配列
`keys2`	結合に使用する step2 の列名の配列（keys1 と位置で対応します）
`schemaModification1`	step1（左側）の列の名前変更または削除
`schemaModification2`	名前の衝突を避けるため、step2（右側）の列の名前を変更または削除します
`dependsOn`	`step1` と `step2` の両方のアクション ID を含める必要があります

注：キーは非対称でもかまいません。例：keys1: ["fldWorkCodeID"] / keys2: ["ID"]。Domo は列名ではなく、配列内の位置で対応付けます。

schemaModification1 / schemaModification2

2 つのデータセットで同じ列名（たとえば、両方に Id、Name、Description がある）が使われている場合は、schemaModification2 を使用して、右側（step2）のデータセットにある競合する列の名前を変更するか、削除してください。

"schemaModification2": [
  {"name": "Description", "rename": "Opportunities.Description", "remove": false},
  {"name": "Id", "rename": "Opportunities.Id", "remove": false},
  {"name": "Name", "rename": "Opportunities.Name", "remove": false},
  {"name": "AccountId", "rename": "Opp_AccountId", "remove": true}
]

remove: true — 出力から列を完全に削除します
remove: false — 列を保持し、rename の値に名前を変更します

GroupBy（集計）

列でグループ化し、集計関数を適用してデータを集計します。

{
  "type": "GroupBy",
  "id": "GroupBy-opp-summary",
  "name": "Summarize Opportunities per Account",
  "dependsOn": ["LoadFromVault-opportunities"],
  "settings": {"preferredDatabaseEntityType": "TEMP_VIEW"},
  "gui": {"x": 352, "y": 512, "color": null, "colorSource": null, "sampleJson": null},
  "input": "LoadFromVault-opportunities",
  "addLineNumber": false,
  "giveBackRow": false,
  "allRows": false,
  "groups": [
    {"name": "AccountId"}
  ],
  "fields": [
    {"name": "Opportunity Count", "source": "Id", "type": "COUNT_ALL", "valuefield": null, "expression": null, "settings": null},
    {"name": "Total Amount", "source": "Amount", "type": "SUM", "valuefield": null, "expression": null, "settings": null},
    {"name": "Avg Amount", "source": "Amount", "type": "AVERAGE", "valuefield": null, "expression": null, "settings": null},
    {"name": "Total Expected Revenue", "source": "ExpectedRevenue", "type": "SUM", "valuefield": null, "expression": null, "settings": null},
    {"name": "Avg Probability", "source": "Probability", "type": "AVERAGE", "valuefield": null, "expression": null, "settings": null}
  ],
  "tables": [{}]
}

フィールド	説明
`input`	上流データのアクション ID
`groups`	グループ化する列の配列です。各項目は `{"name": "ColumnName"}` です
`fields`	集計定義の配列です

集計フィールドの定義

{
  "name": "Total Amount",
  "source": "Amount",
  "type": "SUM",
  "valuefield": null,
  "expression": null,
  "settings": null
}

フィールド	説明
`name`	集計値の出力列名
`source`	集計する元の列名
`type`	集計関数（下記を参照）

集計タイプ

タイプ	説明	確認済み
`SUM`	値の合計	はい
`AVERAGE`	値の平均	はい
`COUNT_ALL`	すべての行（null を含む）の件数	はい
`COUNT_DISTINCT`	個別の値の件数
`MIN`	最小値	はい
`MAX`	最大値
`FIRST`	グループ内の最初の値
`LAST`	グループ内の最後の値
`CONCAT_COMMA`	カンマ区切りで値を連結

重要： API で使用するのは MINIMUM や MAXIMUM ではなく、MIN と MAX です。MINIMUM を使用すると、"The value is invalid for expected type... AggregateType" という検証エラーが返されます。これはテストを通じて確認されました。

式ベースの集計（上級）

source と type を使う代わりに、完全な SQL 集計式を使用できます。source、type、valuefield を null に設定し、完全な式を expression に指定します。

{
  "name": "Total Hours",
  "source": null,
  "type": null,
  "valuefield": null,
  "expression": "SUM(IFNULL(`Hours`,0))",
  "settings": null
}

重要： expression には、関数名だけではなく、完全な SQL 集計式を指定する必要があります。

"expression": "SUM(IFNULL(\Hours`,0))"と"source": null` — 正しい
"expression": "SUM" と "valuefield": "Hours" — 誤り（「SUM」を列名として扱います）

これにより、GroupBy の前に ExpressionEvaluator を挟まなくても、CASE WHEN などの複雑なロジックを GroupBy に直接埋め込めます。

{
  "name": "LTM_Revenue",
  "source": null, "type": null, "valuefield": null,
  "expression": "SUM(CASE WHEN `Date` >= DATE_SUB(CURRENT_TIMESTAMP(), INTERVAL 12 MONTH) THEN IFNULL(`Revenue`,0) ELSE 0 END)",
  "settings": null
}

WindowAction（ランクとウィンドウ）

グループ列でパーティション分割し、ソート列で順序付けを行って、ランキング、行番号、LAG／LEAD オフセットなどのウィンドウ関数を適用します。これは、Magic ETL の UI にある「ランクとウィンドウ」タイルに相当するプログラム上の処理です。

{
  "type": "WindowAction",
  "id": "WindowAction-first-order",
  "name": "First Order Date per Customer",
  "dependsOn": ["LoadFromVault-finance"],
  "settings": {"preferredDatabaseEntityType": "TEMP_VIEW"},
  "gui": {"x": 352, "y": 128, "color": null, "colorSource": null, "sampleJson": null},
  "input": "LoadFromVault-finance",
  "groupRules": [
    {"column": "customer", "caseSensitive": false}
  ],
  "orderRules": [
    {"column": "date_ymd", "caseSensitive": false, "ascending": true}
  ],
  "additions": [
    {
      "name": "Customer Order Rank",
      "operation": {
        "type": "RANKING",
        "operationType": "ROW_NUMBER",
        "column": null,
        "defaultValue": null,
        "amount": null
      }
    }
  ],
  "tables": [{}]
}

フィールド	説明
`input`	上流データのアクション ID
`groupRules`	パーティション列。ウィンドウ関数は各グループ内で適用されます
`orderRules`	各パーティション内のソート順
`additions`	新しい列として追加するウィンドウ関数定義の配列

groupRules

PARTITION BY 列を定義します。

"groupRules": [
  {"column": "customer", "caseSensitive": false},
  {"column": "region", "caseSensitive": false}
]

各エントリは、その列でデータをパーティション分割します。複数のエントリを指定すると、複合パーティションキーが作成されます。

orderRules

各パーティション内の ORDER BY を定義します。

"orderRules": [
  {"column": "date_ymd", "caseSensitive": false, "ascending": true}
]

フィールド	説明
`column`	ソート対象の列
`caseSensitive`	文字列のソートで大文字と小文字を区別するかどうか
`ascending`	`true` は昇順、`false` は降順

複数の orderRules を指定すると、複合ソートキーが作成されます。

additions（ウィンドウ関数定義）

各 addition は、ウィンドウ関数の結果を格納した新しい列を作成します。

{
  "name": "Output Column Name",
  "operation": {
    "type": "RANKING",
    "operationType": "ROW_NUMBER",
    "column": null,
    "defaultValue": null,
    "amount": null
  }
}

ウィンドウ操作の種類

ランキング操作（type: "RANKING"）：

operationType	説明	column	amount
`ROW_NUMBER`	パーティション内の連続した番号（1、2、3...）	`null`	`null`
`RANK`	同順位がある場合に順位を飛ばすランキング（1、2、2、4...）	`null`	`null`
`DENSE_RANK`	同順位がある場合も順位を飛ばさないランキング（1、2、2、3...）	`null`	`null`

オフセット操作（type: "OFFSET"）：

operationType	説明	column	amount
`LAG`	パーティション内で N 行前の値	ソース列名	遡る行数
`LEAD`	パーティション内で N 行後の値	ソース列名	先に進む行数

例 — LAG を使用して前日の売上を取得する場合：

{
  "name": "Previous Day Revenue",
  "operation": {
    "type": "OFFSET",
    "operationType": "LAG",
    "column": "revenue",
    "defaultValue": null,
    "amount": 1
  }
}

例 — ROW_NUMBER を使用して顧客ごとに注文をランク付けする場合：

{
  "name": "Customer Order Rank",
  "operation": {
    "type": "RANKING",
    "operationType": "ROW_NUMBER",
    "column": null,
    "defaultValue": null,
    "amount": null
  }
}

WindowAction と GroupBy の組み合わせ

よく使われるパターンは、WindowAction で行レベルのランキングを行い、その後 GroupBy で集計する方法です。たとえば、顧客ごとの最初の注文日を調べるには、次のようにします。

WindowAction：customer でパーティション分割し、date_ymd の昇順で並べ替えて、ROW_NUMBER を追加します
GroupBy：customer でグループ化し、date_ymd に MIN を適用して最初の注文日を取得し、数値列に SUM／AVERAGE を適用します

WindowAction は、元のすべての列と新たに追加した列を引き継ぐため、後続のアクションからすべての列にアクセスできます。

Filter（行のフィルタリング）

列の条件に基づいて行をフィルタリングします。これは、Magic ETL の UI にある「行のフィルタリング」タイルに相当するプログラム上の処理です。

{
  "type": "Filter",
  "id": "Filter-exclude-florida",
  "name": "Exclude Florida",
  "dependsOn": ["LoadFromVault-sales"],
  "settings": {"preferredDatabaseEntityType": "TEMP_VIEW"},
  "gui": {"x": 352, "y": 256, "color": null, "colorSource": null, "sampleJson": null},
  "input": "LoadFromVault-sales",
  "filterList": [
    {
      "leftField": "state",
      "rightField": null,
      "rightValue": {"value": "Florida", "type": "STRING"},
      "rightExpr": "'Florida'",
      "operator": "NE",
      "expression": null,
      "andFilterList": []
    }
  ],
  "tables": [{}]
}

フィールド	説明
`input`	上流データのアクション ID
`filterList`	フィルター条件の配列（OR ロジックで結合）
`andFilterList`	フィルター内のネストされた配列（AND ロジック用）

フィルター条件のフィールド

フィールド	説明
`leftField`	フィルター対象の列名
`operator`	比較演算子（下の表を参照）
`rightValue`	型付き値オブジェクト：`{"value": "Florida", "type": "STRING"}`
`rightExpr`	値を表す文字列式。文字列の場合は単一引用符で囲みます：`"'Florida'"`
`rightField`	比較対象の列名（列同士を比較する場合。それ以外は `null`）

重要： 文字列を比較する場合、rightValue は value フィールドと type フィールドを持つ型付きオブジェクトにする必要があり、rightExpr では値を単一引用符で囲む必要があります。rightValue に通常の文字列を指定すると、VALIDATION-DE エラーが返されます。

式ベースのフィルター（代替方法）

leftField／operator／rightValue の代わりに、複雑な条件には SQL の expression を直接使用できます。

{
  "leftField": null,
  "rightField": null,
  "rightValue": null,
  "rightExpr": null,
  "operator": null,
  "expression": "IFNULL(TRIM(`column_name`),'') <> ''",
  "andFilterList": []
}

複数条件のフィルターや関数呼び出しを含むフィルターに便利です。expression は SQL の WHERE 句の断片です。

フィルター演算子

演算子	説明	確認済み
`NE`	等しくない	はい
`EQ`	等しい
`LT`	より小さい
`GT`	より大きい
`LE`	以下
`GE`	以上
`NN`	NULL ではない	はい（既存のデータフローで確認）
`NL`	NULL である
`NIN`	リストに含まれない
`IN`	リストに含まれる

rightValue の型の値

型	用途
`STRING`	テキストの比較
`NUMERIC`	数値の比較
`DATE`	日付の比較

ExpressionEvaluator（数式を追加）

Domo の式言語を使用して、計算列を追加します。これは Magic ETL UI の「数式を追加」タイルに相当するプログラム上の機能です。

{
  "type": "ExpressionEvaluator",
  "id": "ExpressionEvaluator-month-trunc",
  "name": "Add Month Column",
  "dependsOn": ["Filter-exclude-florida"],
  "settings": {"preferredDatabaseEntityType": "TEMP_VIEW"},
  "gui": {"x": 480, "y": 256, "color": null, "colorSource": null, "sampleJson": null},
  "input": "Filter-exclude-florida",
  "expressions": [
    {
      "expression": "concat(year(`date_ymd`),MONTHNAME(`date_ymd`))",
      "fieldName": "Year_Month",
      "settings": {}
    }
  ],
  "tables": [{}]
}

フィールド	説明
`input`	上流データのアクション ID
`expressions`	数式定義の配列

式の定義

{
  "expression": "concat(year(`date_ymd`),MONTHNAME(`date_ymd`))",
  "fieldName": "Year_Month",
  "settings": {}
}

フィールド	説明
`expression`	Domo の数式式です。列名はバッククォートで囲む必要があります。
`fieldName`	新しい出力列の名前
`settings`	空のオブジェクト `{}`

動作確認済みの関数

関数	説明	例
`year()`	日付から年を抽出	`year(\`date_ymd`)`
`MONTH()`	月の数値（1～12）を抽出	`MONTH(\`date_ymd`)`
`MONTHNAME()`	日付から月名を抽出	`MONTHNAME(\`date_ymd`)`
`concat()`	文字列を連結	`concat(year(\`date_ymd`), MONTHNAME(`date_ymd`))`
`DATE()`	日付型に変換	`DATE(\`date_ymd`)`
`DATE_FORMAT()`	日付を文字列としてフォーマット	`DATE_FORMAT(\`date_ymd`, 'yyyy-MM-dd')`
`LEFT()`	左側の部分文字列	「2025-01-15」から年月を取得する場合は `LEFT(\`Date`, 7)`
`LPAD()`	文字列の左側を埋める	`LPAD(MONTH(\`date`), 2, '0')`
`IFNULL()`	NULL の置換（引数は 2 つのみ）	`IFNULL(\`col`, 0)`
`COALESCE()`	NULL の置換（複数引数）	`COALESCE(\`a`, `b`, 'default')`
`TRIM()`	空白を削除	`TRIM(\`col`)`
`CAST()`	型変換	`CAST(NULL AS DATETIME)`
`LAST_DAY()`	月の最終日	`LAST_DAY(\`date`)`
`DATE_SUB()`	期間を減算	`DATE_SUB(\`date`, INTERVAL 12 MONTH)`
`CONVERT_TZ()`	タイムゾーン変換	`CONVERT_TZ(CURRENT_TIMESTAMP(),'UTC','US/Eastern')`
`CURRENT_TIMESTAMP()`	現在の日時	`CURRENT_TIMESTAMP()`

重要： TRUNC_MONTH() は有効な関数ではなく、"Unknown function: TRUNC_MONTH" が返されます。日付を月単位に切り詰めるには、concat(year(...), MONTHNAME(...)) などの文字列ベースの方法を使用してください。

式の動作ルール

式は順番に処理されます。同じタイル内で、後の式から先に計算されたフィールドを参照できます
既存の列と同じ fieldName の式を追加すると、その列の値が置き換えられます（型変換や再フォーマットに便利です）
IFNULL() の引数は 2 つです。複数引数で NULL を処理する場合は COALESCE(a, b, c) を使用してください
CAST(NULL AS DATETIME) は、型付きの NULL 列を作成する場合に使用できます

1 つの ExpressionEvaluator アクションに複数の式を追加できます。それぞれが新しい列を作成するか、既存の列を置き換えます。元の列はすべて引き継がれます。

Unique（重複排除）

指定したキー列に基づいて重複行を削除します。これは「重複を削除」タイルに相当するプログラム上の機能です。

{
  "type": "Unique",
  "id": "Unique-dedup",
  "name": "Deduplicate",
  "dependsOn": ["SelectValues-final"],
  "settings": {"preferredDatabaseEntityType": "TEMP_VIEW"},
  "gui": {"x": 800, "y": 256, "color": null, "colorSource": null, "sampleJson": null},
  "input": "SelectValues-final",
  "countRows": false,
  "fields": [
    {"name": "ColA", "caseInsensitive": false},
    {"name": "ColB", "caseInsensitive": false}
  ],
  "tables": [{}]
}

フィールド	説明
`input`	上流データのアクション ID
`countRows`	重複が何件見つかったかを示すカウント列を追加する場合は `true`
`fields`	一意性を定義する列の配列。リストされたすべての列で値が同一の行は重複排除されます
`fields[].caseInsensitive`	大文字と小文字を区別せずに文字列を照合する場合は `true`

ヒント： 行数が増える可能性のある結合（例：多対多結合）の後に Unique タイルを追加してください。

SelectValues（レガシー／新しいフローでは無効）

特定の列を選択し、必要に応じて名前を変更します。

{
  "type": "SelectValues",
  "id": "SelectValues-final",
  "name": "Select Final Columns",
  "dependsOn": ["MergeJoin-final"],
  "settings": {"preferredDatabaseEntityType": "TEMP_VIEW"},
  "gui": {"x": 1024, "y": 320, "color": null, "colorSource": null, "sampleJson": null},
  "input": "MergeJoin-final",
  "select": [
    {"name": "Id", "rename": "Account ID"},
    {"name": "Name", "rename": "Account Name"},
    {"name": "Industry"},
    {"name": "Contact Count"},
    {"name": "Total Amount"}
  ],
  "tables": [{}]
}

select に記載された列のみが引き継がれ、それ以外の列は削除されます
元の列名を維持するには、rename を省略します

代替形式 — select の代わりに fields を使用します。保持する列のみを指定してください（必要に応じて名前を変更できます）。指定されていない列は削除されます。remove: true のエントリは追加しないでください。追加すると、検証エラー DP-0003 が発生します。

保持する列のみを指定してください（必要に応じて名前を変更できます）。指定されていない列は削除されます。remove: true のエントリは追加しないでください。追加すると、検証エラー DP-0003 が発生します。

"fields": [
  {"name": "ID", "rename": "Dataflow ID"},
  {"name": "Display Name", "rename": "Dataflow Name"},
  {"name": "Link", "rename": "Dataflow Link"}
]

最小限のフィールドエントリは、{"name": "...", "rename": "..."} だけです。type、dateFormat、settings、remove は含めないでください。fields 形式では、これらを含めると DP-0003 Action is improperly configured エラーが発生します。

PublishToVault（出力ノード）

最終データを Domo データセットに書き込みます。

{
  "type": "PublishToVault",
  "id": "PublishToVault-my-output",
  "name": "Output Dataset Name",
  "dependsOn": ["last-action-id"],
  "settings": {"preferredDatabaseEntityType": "DYNAMIC_TABLE"},
  "inputs": ["last-action-id"],
  "dataSource": {
    "guid": null,
    "type": "DataFlow",
    "name": "Output Dataset Name",
    "description": "",
    "cloudId": null
  },
  "versionChainType": "REPLACE",
  "schemaSource": "DATAFLOW",
  "partitioned": false,
  "tables": [{}]
}

フィールド	説明
`dependsOn`	最終変換アクション ID を含む配列
`inputs`	同じ最終変換アクション ID を含める必要があります
`dataSource.type`	`"DataFlow"`
`dataSource.name`	出力データセットの名前
`dataSource.guid`	新しい出力の場合は `null`、既存の出力データセットの場合は既存の UUID
`dataSource.cloudId`	標準のデータフロー管理出力の場合は `null`
`versionChainType`	`"REPLACE"`（全置換）または `"APPEND"`
`schemaSource`	`"DATAFLOW"`
`partitioned`	`false`
`tables`	`[{}]`

新しいデータフローでは、guid を省略してください。最初の実行が正常に完了すると、Domo によって実際の出力データセット UUID が割り当てられます。

完全な例：アカウント概要 ETL

この例では、次の処理を行うデータフローを作成します。

Salesforce データセットを 3 つ読み込みます（Accounts、Contacts、Opportunities）
アカウントごとに連絡先を集計します（件数）
アカウントごとに商談を集計します（件数、合計金額、平均金額、期待収益、平均確度）
2 つの集計結果を Accounts テーブルに左結合します
すべての概要指標を含む、アカウントごとに 1 行のデータを出力します

パイプライン図

LoadFromVault(Accounts) ─────────────────────┐
                                              ├─ MergeJoin(LEFT) ──┐
LoadFromVault(Opportunities)                  │   on Id=AccountId   │
  └─ GroupBy(AccountId) ─────────────────────┘                     │
       COUNT(Id) → Opportunity Count                               ├─ MergeJoin(LEFT) ─── PublishToVault
       SUM(Amount) → Total Amount                                  │   on Id=AccountId
       AVG(Amount) → Avg Amount                                    │
       SUM(ExpectedRevenue) → Total Expected Revenue               │
       AVG(Probability) → Avg Probability                          │
                                                                   │
LoadFromVault(Contacts)                                            │
  └─ GroupBy(AccountId) ──────────────────────────────────────────┘
       COUNT(Id) → Contact Count

作成コマンド

community-domo-cli -y dataflows create --body-file sfdc_account_summary_etl.json

実行

community-domo-cli -y dataflows run <DATAFLOW_ID>

完全な例：順位とウィンドウ関数を含む顧客概要

この例では、次の処理を行うデータフローを作成します。

財務データセットを読み込みます（顧客、日付、売上、収益、売上原価を含む 329,460 行）
WindowAction を使用し、日付順に顧客ごとの注文に順位を付けます（ROW_NUMBER）
顧客ごとに集計します：初回注文日（MIN）、売上／収益／売上原価の SUM と AVERAGE、注文数

パイプライン図

LoadFromVault(Mododata | Finance)  329,460 rows
  └── WindowAction: ROW_NUMBER partitioned by customer, ordered by date_ymd ASC
       └── GroupBy(customer):
            MIN(date_ymd)  → First Order Date
            SUM(sales)     → Total Sales
            AVG(sales)     → Avg Sales
            SUM(revenue)   → Total Revenue
            AVG(revenue)   → Avg Revenue
            SUM(cogs)      → Total COGS
            AVG(cogs)      → Avg COGS
            COUNT(date_ymd)→ Order Count
              └── PublishToVault  →  104 customer rows

主な JSON スニペット

WindowAction（順位とウィンドウタイル）：

{
  "type": "WindowAction",
  "id": "WindowAction-first-order",
  "name": "First Order Date per Customer",
  "dependsOn": ["LoadFromVault-finance"],
  "input": "LoadFromVault-finance",
  "groupRules": [
    {"column": "customer", "caseSensitive": false}
  ],
  "orderRules": [
    {"column": "date_ymd", "caseSensitive": false, "ascending": true}
  ],
  "additions": [
    {
      "name": "Customer Order Rank",
      "operation": {
        "type": "RANKING",
        "operationType": "ROW_NUMBER",
        "column": null,
        "defaultValue": null,
        "amount": null
      }
    }
  ]
}

初回注文日に MIN を使用する GroupBy：

{
  "type": "GroupBy",
  "id": "GroupBy-customer-summary",
  "name": "Customer Aggregations",
  "dependsOn": ["WindowAction-first-order"],
  "input": "WindowAction-first-order",
  "groups": [{"name": "customer"}],
  "fields": [
    {"name": "First Order Date", "source": "date_ymd", "type": "MIN"},
    {"name": "Total Sales", "source": "sales", "type": "SUM"},
    {"name": "Avg Sales", "source": "sales", "type": "AVERAGE"},
    {"name": "Total Revenue", "source": "revenue", "type": "SUM"},
    {"name": "Avg Revenue", "source": "revenue", "type": "AVERAGE"},
    {"name": "Total COGS", "source": "cogs", "type": "SUM"},
    {"name": "Avg COGS", "source": "cogs", "type": "AVERAGE"},
    {"name": "Order Count", "source": "date_ymd", "type": "COUNT_ALL"}
  ]
}

結果

出力データセット：104 行（顧客ごとに 1 行）。列：customer、First Order Date、Total Sales、Avg Sales、Total Revenue、Avg Revenue、Total COGS、Avg COGS、Order Count。

完全な例：フィルターと数式を使った月別部門指標

この例では、次の処理を行うデータフローを作成します。

売上データセットを読み込みます（481,643 行）
state = 'Florida' の行を除外します
concat(year(), MONTHNAME()) を使用して Year_Month 列を追加します
Year_Month + department + metric_name ごとに集計します：revenue、store_revenue、web_revenue、mobile_revenue、total_costs、visits の SUM と AVERAGE

パイプライン図

LoadFromVault(Mododata | Sales)  481,643 rows
  └── Filter: state != 'Florida'
       └── ExpressionEvaluator: Year_Month = concat(year(date_ymd), MONTHNAME(date_ymd))
            └── GroupBy(Year_Month, department, metric_name):
                 SUM/AVG for revenue, store_revenue, web_revenue,
                 mobile_revenue, total_costs, visits
                   └── PublishToVault  →  14,057 rows

主な JSON スニペット

フィルター（特定の値を除外）：

{
  "type": "Filter",
  "id": "Filter-exclude-florida",
  "name": "Exclude Florida",
  "dependsOn": ["LoadFromVault-sales"],
  "input": "LoadFromVault-sales",
  "filterList": [
    {
      "leftField": "state",
      "rightField": null,
      "rightValue": {"value": "Florida", "type": "STRING"},
      "rightExpr": "'Florida'",
      "operator": "NE",
      "expression": null,
      "andFilterList": []
    }
  ]
}

ExpressionEvaluator（日付を年月文字列に変換）：

{
  "type": "ExpressionEvaluator",
  "id": "ExpressionEvaluator-month-trunc",
  "name": "Add Month Column",
  "dependsOn": ["Filter-exclude-florida"],
  "input": "Filter-exclude-florida",
  "expressions": [
    {
      "expression": "concat(year(`date_ymd`),MONTHNAME(`date_ymd`))",
      "fieldName": "Year_Month",
      "settings": {}
    }
  ]
}

結果

出力：14,057 行（Florida を除く、月 × 部門 × metric_name ごとに 1 行）。粒度は日次の 481K 行から、月次集計された 14K 行に縮小されます。

ETL エラーコードのリファレンス

データフローの実行が失敗すると、lastExecution.errors[] のエラーオブジェクトに code フィールドが含まれます。診断には、次の表を使用してください。

コード	カテゴリ	意味	一般的な修正方法
`DP-DSNF`	入力の欠落	必須のデータセットが存在しません	データセットを再作成するか、LoadFromVault タイルを削除します
`DP-61100`	入力の欠落	DP-DSNF と同じ（別のコード）	上記と同じです
`DP-0001`	スキーマの不一致	参照されている列が見つかりません	上流のスキーマが変更されています。列の参照を更新してください
`DP-0059`	数式エラー	式の構文エラーです	数式を修正してください（例：CASE 文の `END` が不足している）
`DP-0118`	コード／モデルのクラッシュ	変換ジョブの失敗です	Python スクリプトまたは AI モデルタイルを確認してください
`DP-TGTFR`	データ量	Batch Text Generation には 100 行以上が必要です	入力に十分な行数があることを確認してください
`MYSQL-601072`	結合キーの欠落	キー列がテーブルに存在しません	結合キーの列名を更新してください
`DP-0000`	不明	API レベルの詳細がありません	Domo UI で調べてください

エラーを特定のタイルまで追跡する

エラーオブジェクトには _actionId（失敗したタイルの UUID）を含む parameters マップがあります。データフロー内の actions[].id と照合してください。

errors = dataflow.get("lastExecution", {}).get("errors", [])
actions_by_id = {a["id"]: a for a in dataflow.get("actions", [])}
for e in errors:
    action_id = e.get("parameters", {}).get("_actionId", "")
    tile = actions_by_id.get(action_id, {})
    print(f'Error: [{e["code"]}] {e["localizedMessage"]}')
    print(f'Tile: "{tile.get("name", "?")}" (type: {tile.get("type", "?")})')
    print(f'Property: {e.get("parameters", {}).get("_propertyPath", "")}')

`_actionId` のタイルタイプ	確認する内容
`ExpressionEvaluator`	`expressions[].expression` — 数式テキスト
`LoadFromVault`	`dataSourceId` — 入力データセットの UUID
`MergeJoin`	`keys1` / `keys2` — 結合キーの列名
`SelectValues`	`fields[].name` — 選択されている列名
`Filter`	`filterList[].leftField` — フィルター列
`PublishToVault`	`dataSource.guid` — 出力データセットの UUID

よくある落とし穴

1. `DP-DSCF`／`DP-0069` の失敗 — アクションタイプが誤っている、または PublishToVault の構造が不正

DP-0069 は、不正なアクションタイプが使用されたことを意味します（例：SaveToVault、SelectValues、RenameColumns）。DP-DSCF は出力のコミット失敗を示し、多くの場合、形式が不正な PublishToVault ペイロードに関連しています。

根本原因： サポートされていないアクションタイプ、または不完全／不正な PublishToVault の構造です。

修正方法： サポートされているアクションタイプを使用し、次の PublishToVault の構造を使用してください。

{
  "type": "PublishToVault",
  "id": "PublishToVault-my-output",
  "name": "Output Dataset Name",
  "dependsOn": ["last-action-id"],
  "settings": {"preferredDatabaseEntityType": "DYNAMIC_TABLE"},
  "inputs": ["last-action-id"],
  "dataSource": {"guid": null, "type": "DataFlow", "name": "Output Dataset Name", "description": "", "cloudId": null},
  "versionChainType": "REPLACE",
  "schemaSource": "DATAFLOW",
  "partitioned": false,
  "tables": [{}]
}

2. SelectValues — 従来の失敗パターン（使用しないでください）

SelectValues は失敗の原因となることが繰り返し確認されているため、このスキルで新たに自動化を行う際はサポート対象外として扱ってください。

推奨事項： SelectValues は完全に省略してください。PublishToVault.dependsOn を最終変換ノード（通常は MergeJoin）に直接設定し、その出力スキーマをそのまま引き継いでください。

従来のリファレンス（診断専用）：以前のペイロードでは、保持する列のみを fields に指定していました（"remove": true や、追加の type / dateFormat / settings はありません）。

"fields": [
  {"name": "ID", "rename": "Dataset ID"},
  {"name": "Name", "rename": "Dataset Name"}
]

一覧にない列は削除されます。削除エントリは追加しないでください。

3. 結合時の列名の競合

列名（例：Id、Name、Description）が重複する 2 つのデータセットを結合する場合は、MergeJoin の schemaModification2 を使用して、右側のデータセットにある競合列の名前を変更するか削除する必要があります。これを行わないと、後続処理で列名が曖昧になります。

4. アクション ID は一意でなければなりません

actions 配列内のすべてのアクションには、一意の id 文字列が必要です。慣例では TypeName-uuid を使用します（例："LoadFromVault-b71d89d7-6c08-44ad-a503-ebed046377e0"）が、一意な文字列であればどのようなものでも使用できます（例："LoadFromVault-accounts"）。

5. dependsOn は step1／step2／input と一致させる必要があります

MergeJoin の場合、dependsOn 配列には step1 と step2 の両方のアクション ID を含める必要があります。GroupBy の場合、dependsOn には input のアクション ID を含める必要があります。一致しないと、データフローは失敗します。

6. GUI の位置はビジュアルキャンバスに影響します

gui.x と gui.y の値によって、Domo Magic ETL のビジュアルエディターでノードが表示される位置が決まります。見やすいレイアウトにするには、水平方向に約 224px、垂直方向に約 192px の間隔を空けてノードを配置してください。入力ノードは通常 x: 128 から始まります。

useGraphUI: true が設定されている場合（モダンキャンバスモード）、タイルの位置はアクションレベルの gui フィールドではなく、トップレベルの gui.canvases.default.elements 配列で制御されます。一貫性を保つため、常に両方を設定してください。Section 要素と Tile 要素の完全なスキーマについては、「トップレベルの gui フィールド」セクションを参照してください。

7. データフローの作成 — 認証と実行（2026 年 4 月更新）

認証： community-domo-cli が認証を自動的に処理します。基盤となる POST /dataprocessing/v1/dataflows 呼び出しは、CLI で設定されたセッションで動作します。リクエスト本文には "databaseType": "MAGIC" を必ず含めてください。作成されたデータフローは DRAFT 状態ではないため、すぐに実行できます。UI で保存する必要はありません。

出力： リクエスト本文に "outputs": [{"dataSourceId": null, "dataSourceName": "...", "versionChainType": "REPLACE"}] が含まれている場合、Domo は実際の出力データセット UUID をすぐに割り当てます。最初の実行が成功すると、実際のデータセットが作成されます。

8. 集計タイプ名は想像とは異なります

GroupBy の type フィールドでは MIN と MAX を使用します。MINIMUM や MAXIMUM ではありません。MINIMUM を使用すると、検証エラーが返されます。

{"code":"VALIDATION-DIV","message":"The value is invalid for expected type.","path":"actions[2].fields[0].type","parameters":{"field":"type","type":"AggregateType","rejected":"MINIMUM"}}

動作確認済みのタイプ：SUM、AVERAGE、COUNT_ALL、MIN。これらの文字列をそのまま使用してください。

9. Filter の rightValue は型付きオブジェクトである必要があります

Filter アクションの rightValue に、単なる文字列は指定できません。型付きオブジェクトである必要があります。

// WRONG — returns VALIDATION-DE error
"rightValue": "Florida"

// CORRECT
"rightValue": {"value": "Florida", "type": "STRING"}

さらに、rightExpr では文字列値を一重引用符で囲む必要があります："'Florida'"。rightValue と rightExpr は両方とも設定してください。

10. TRUNC_MONTH などの日付関数は存在しません

ExpressionEvaluator は TRUNC_MONTH()、DATE_TRUNC() などの日付切り捨て関数をサポートしていません。年月の値を取得するには、文字列連結を使用してください。

concat(year(`date_ymd`), MONTHNAME(`date_ymd`))

動作確認済みの関数：year()、MONTHNAME()、concat()、DATE()。

11. CLI で作成したデータフローはすぐに実行できます（2026 年 4 月更新）

community-domo-cli -y dataflows create で作成したデータフローは DRAFT 状態ではないため、community-domo-cli -y dataflows run <ID> ですぐに実行できます。dataSourceId: null を指定すると、作成時に outputs 配列が設定されます。UI で保存する必要はありません。実行すると有効な実行 ID が返され、完了まで実行されます。

12. Java CLI ではなく `dataflows run` を使用してください

従来の Java CLI の dataflow-run-now は、新しく作成したデータフローに対して 500 エラーを返すことがあります。必ず community-domo-cli -y dataflows run <ID> を使用してください。これは /dataprocessing/v1/dataflows/{id}/executions に直接 POST するため、安定して動作します。

13. responsibleUserId は省略可能です

POST 本文で responsibleUserId を指定する必要はありません。認証済みユーザーがデフォルトで設定されます。

14. LoadFromVault ノードは複数の分岐に接続できます

1 つの LoadFromVault ノードを複数の下流分岐に接続できます。複数の dependsOn 配列でその ID を参照するだけです。これにより、同じデータセットを二重に読み込まずに済みます。

15. PublishToVault — `inputs` ではなく `dependsOn` のみを使用してください

PublishToVault アクションでは、上流のアクションを参照するために dependsOn を使用します。inputs 配列は含めないでください。これは動作する形式の一部ではなく、DP-DSCF のコミット失敗の原因になります。作成後に numOutputs = 0 となる場合、アクションに dataSource オブジェクトが含まれていない可能性があります。定義を修正するには、修正した定義を PUT してください。

16. 認証

community-domo-cli は domo login で設定されたセッションを使用して、認証を自動的に処理します。手動でトークンヘッダーを設定したり、OAuth でトークンを交換したりする必要はありません。

19. `LoadFromVault` 以外のすべてのアクションに `disabled`、`removeByDefault`、`notes` が必要です

LoadFromVault 以外のすべてのアクションには、次のフィールドを含める必要があります。含めない場合、UI でデータフローが予期せず動作することがあります。

"disabled": false,
"removeByDefault": false,
"notes": [],
"previewRowLimit": null

MergeJoin には、さらに "on": null と、明示的な "schemaModification1": [] および "schemaModification2": []（空の場合でも）が必要です。

LoadFromVault では "previewRowLimit": 10000 を使用します（null ではありません）。

20. `relationshipType` は `"MANY_TO_MANY"` ではなく `"MTM"` にする必要があります

MergeJoin のフィールド relationshipType には、省略形の "MTM" を指定する必要があります。"MANY_TO_MANY" を使用すると、検証エラーが発生します。そのほかの有効な値は "OTO"、"OTM"、"MTO" です。

21. 系譜 ETL を構築する前に、必ずマスターデータセットのアンカーについて確認してください

データセットの系譜 ETL を構築する前に、次のように確認してください。「すべての出力行を関連付ける必要がある、マスターの『My Datasets』などのリストデータセットはありますか？」 このアンカーデータセット（通常は Dataset ID、Name、Link、Owner などを含みます）は、最終結合の LEFT 側に読み込む必要があります。これにより、カードや ETL との関連付けがないデータセット（単独のデータセット）も含め、すべてのデータセットが出力に含まれます。このアンカーがないと、ほかのメタデータテーブルに存在するデータセットしか出力されず、単独のデータセットが欠落します。

17. アクション配列全体が必要な場合は、`get` ではなく `get-definition` を使用してください

community-domo-cli dataflows get は v2 エンドポイントにアクセスするため、完全な actions[] 配列を返さない場合があります。community-domo-cli dataflows get-definition は GET /dataprocessing/v1/dataflows/{id} にアクセスします（?hydrate=full は付けません。これを付けると 400 が返されます）。更新を実行する前には、必ず get-definition を使用してください。

18. `dataflows update` はデータフロー定義全体を置き換えます

community-domo-cli -y dataflows update <ID> --body-file <FILE> を使用して更新する場合：

データフローオブジェクト全体を送信してください — 必ず最新の get-definition の結果を基に変更し、--body-file で渡します。
更新で保存されるだけです — データフローは実行されません。実行するには、別途 community-domo-cli -y dataflows run <ID> を呼び出してください。
バージョン管理 — 更新が成功するたびに onboardFlowVersion.versionNumber が増加します。実行レスポンスに含まれる dataFlowVersion で、どのバージョンが実行されたかを確認できます。

既知のアクションタイプ

インスタンス内の既存データフロー全体から検出されたアクションタイプ：

アクションタイプ	説明	動作確認済み
`LoadFromVault`	入力ノード — Domo データセットを読み込みます	はい
`PublishToVault`	出力ノード — Domo データセットに書き込みます	はい
`MergeJoin`	キーを使って 2 つの上流アクションを結合します	はい
`GroupBy`	SUM、AVERAGE、MIN、COUNT_ALL などで集計します	はい
`WindowAction`	ランクとウィンドウ — ROW_NUMBER、RANK、LAG、LEAD	はい
`SelectValues`	旧式の選択／名前変更ノード	このスキルでの新しいフロー作成には無効です。サポート対象の変換チェーンと `PublishToVault` を使用してください
`Filter`	条件（NE、EQ、NN など）に基づいて行をフィルタリングします	はい
`ExpressionEvaluator`	計算列／数式（concat、year、MONTHNAME、DATE）を追加します	はい
`Unique`	キー列で行の重複を排除します	ドキュメントに記載（パターンガイドより）
`Metadata`	列の型またはメタデータを変更します	既存のデータフローで確認
`SplitColumnAction`	列を複数の列に分割します	既存のデータフローで確認
`FixedInput`	ハードコードされた／定数の入力データ	既存のデータフローで確認

ワークフロー：新しい Magic ETL の作成

事前確認事項（構築前に確認してください）

すべての入力データセット ID と列スキーマは何ですか？（各データセットを community-domo-cli datasets sql <UUID> --body '{"sql":"SELECT * FROM table LIMIT 2"}' でクエリしてください）
すべての出力行を関連付ける必要があるマスター／アンカーデータセット（例：「My Datasets」）はありますか？ある場合は、その UUID を取得してください。最終結合の LEFT 側になります。
必要な出力列名と、それぞれに対応する入力フィールドは何ですか？

ビルド手順

入力データセットのスキーマを取得する — 各入力データセットで community-domo-cli datasets sql <UUID> --body '{"sql":"SELECT * FROM table LIMIT 2"}' を実行します
JSON 定義を作成する — このスキルのドキュメントで確認済みの、動作するアクション構造を使用します
色付きのセクションゾーンを追加する — 関連するタイルを gui.canvases.default.elements 内のセクション要素にグループ化します。各論理分岐または処理ステージにそれぞれ異なる色を割り当てます。parentId と相対座標を使って、タイル要素をセクション内に再配置します。この手順は、分岐またはステージが 2 つ以上あるすべてのデータフローで必須です。
作成する — community-domo-cli -y dataflows create --body-file <FILE> を実行します。UI で保存しなくても、すぐに動作します
実行する — community-domo-cli -y dataflows run <DATAFLOW_ID> を実行します
ステータスを確認する — community-domo-cli dataflows execution-get <DATAFLOW_ID> <EXEC_ID> を実行し、state が SUCCESS または FAILED_DATA_FLOW になるまでポーリングします
失敗した場合 — 実行レスポンスの errors[] 配列で actionId と localizedMessage を確認し、該当するアクションを修正して、community-domo-cli -y dataflows update <ID> --body-file <FILE> を実行した後、再実行します
デバッグ用にエクスポートする — community-domo-cli dataflows get-definition <DATAFLOW_ID> を実行すると、サーバーによって割り当てられた GUID を含む、保存済みの定義全体が返されます

Markdown 対応

ログインしてコメント

基本情報

作者: stahura
リポジトリ: stahura/domo-ai-vibe-rules
カテゴリ: データ・データベース
インストール数: 167
GitHub スター: 24

問題を報告

magic-etl-cli

magic-etl-cli について

主な機能

活用シーン

インストール

詳細

Domo で Magic ETL データフローをプログラムから作成する

概要

データフロー用 CLI コマンド

すべての Magic ETL データフローを一覧表示する

データフロー定義を取得する

データフローを実行する

データフローの実行一覧を表示する

特定の実行を確認する

CLI でデータフローを作成する

作成

既存のデータフローを更新する

データフロー JSON の構造

トップレベルのフィールド

トップレベルの gui フィールド（キャンバスのレイアウトとセクション）

セクション要素（色付きの背景ゾーン）

使用可能なセクションの背景色

タイル要素（アクションの位置）

データフローの作成時には必ずセクションを追加する

Inputs 配列

Outputs 配列

アクションの種類

共通のアクションフィールド

LoadFromVault（入力ノード）

MergeJoin（結合）

schemaModification1 / schemaModification2

GroupBy（集計）

集計フィールドの定義

集計タイプ

式ベースの集計（上級）

WindowAction（ランクとウィンドウ）

groupRules

orderRules

additions（ウィンドウ関数定義）

ウィンドウ操作の種類

WindowAction と GroupBy の組み合わせ

Filter（行のフィルタリング）

フィルター条件のフィールド

式ベースのフィルター（代替方法）

フィルター演算子

rightValue の型の値

ExpressionEvaluator（数式を追加）

式の定義

動作確認済みの関数

式の動作ルール

Unique（重複排除）

SelectValues（レガシー／新しいフローでは無効）

PublishToVault（出力ノード）

完全な例：アカウント概要 ETL

パイプライン図

作成コマンド

実行

完全な例：順位とウィンドウ関数を含む顧客概要

パイプライン図

主な JSON スニペット

結果

完全な例：フィルターと数式を使った月別部門指標

パイプライン図

主な JSON スニペット

結果

ETL エラーコードのリファレンス

エラーを特定のタイルまで追跡する

よくある落とし穴

1. DP-DSCF／DP-0069 の失敗 — アクションタイプが誤っている、または PublishToVault の構造が不正

2. SelectValues — 従来の失敗パターン（使用しないでください）

3. 結合時の列名の競合

4. アクション ID は一意でなければなりません

5. dependsOn は step1／step2／input と一致させる必要があります

6. GUI の位置はビジュアルキャンバスに影響します

7. データフローの作成 — 認証と実行（2026 年 4 月更新）

8. 集計タイプ名は想像とは異なります

9. Filter の rightValue は型付きオブジェクトである必要があります

10. TRUNC_MONTH などの日付関数は存在しません

11. CLI で作成したデータフローはすぐに実行できます（2026 年 4 月更新）

12. Java CLI ではなく dataflows run を使用してください

トップレベルの `gui` フィールド（キャンバスのレイアウトとセクション）

1. `DP-DSCF`／`DP-0069` の失敗 — アクションタイプが誤っている、または PublishToVault の構造が不正

12. Java CLI ではなく `dataflows run` を使用してください

15. PublishToVault — `inputs` ではなく `dependsOn` のみを使用してください

19. `LoadFromVault` 以外のすべてのアクションに `disabled`、`removeByDefault`、`notes` が必要です

20. `relationshipType` は `"MANY_TO_MANY"` ではなく `"MTM"` にする必要があります

17. アクション配列全体が必要な場合は、`get` ではなく `get-definition` を使用してください

18. `dataflows update` はデータフロー定義全体を置き換えます