アクション ハブを介したデータ共有

Looker に組み込まれている配信先にコンテンツを配信する以外にも、アクション（統合とも呼ばれる）を使用して、アクション ハブ サーバーを介して Looker と統合されているサードパーティのサービスにコンテンツを配信することができます。

アクション ハブ サーバーを介して提供されるアクションは、action LookML パラメータで定義されるデータ アクションとは異なります。

このページでは、Looker Action Hub への追加または独自のプライベート アクション ハブ サーバーへの追加をリクエストできるカスタム アクションを作成するためのオプションについて説明します。また、ローカル アクション ハブ サーバーを起動して、カスタム アクションのテストやプライベート アクション ハブ サーバーの実行を行う方法についても説明します。

次のいずれかの手順で、アクションの使用を開始できます。

アクションがアクション ハブに追加されたら、Looker 管理者はそのアクションを有効にして、各種サービスへの Looker コンテンツの配信で使用できるようにします。

Looker Action Hub を介して Looker の統合を使用し、独自のプライベート アクションまたはカスタム アクションをホストする場合にも、複数のアクション ハブを設定できます。各アクション ハブのアクションは、[Admin] パネルの [Actions] ページに表示されます。

Looker Action Hub

Looker は、Looker の Action API を実装し、一般的なアクションを公開するステートレス サーバーである Looker Action Hub をホストおよび提供します。アクションを使用してユーザーが送信するデータは、Looker インスタンスではなく Looker Action Hub サーバーで一時的に処理されます。

Looker はすでに複数のサービスと統合されています。このような既存のサービスを有効にする方法については、管理者の設定 - アクションに関するドキュメント ページをご覧ください。

Looker Action Hub の要件

Looker 統合を使用するには、Looker Action Hub が Looker インスタンスと通信でき、これらの要件を満たしている必要があります。セルフホスト型インスタンスの管理者は、Looker Action Hub から Looker 統合を有効にする選択を行う際に、追加の要因を考慮しなければならない場合があります。ストリーミングされた結果をサポートする統合や、OAuth を使用する統合を有効にする場合は、特に当てはまります。

Looker Action Hub は、次の API リクエストを送受信できる必要があります。

Looker のデプロイでこうしたリクエストに対応できない場合や、IP 許可リスト機能が Looker インスタンスで有効になっている場合は、ローカル アクション ハブ サーバーを設定して、プライベートの Looker 統合またはカスタム アクションを行うことを検討してください。セルフホスト型インスタンスの管理者は、OAuth とストリーミング アクション専用のローカル アクション サーバーをデプロイすることもできます。

Looker インスタンスから Looker Action Hub ネットワークへのリクエスト

actions.looker.com へのリクエストは、動的 IP アドレスに解決されます。Looker インスタンスからの送信リクエストは以下のエンドポイントに到達できる必要があります。

actions.looker.com/
actions.looker.com/actions/<name>/execute
actions.looker.com/actions/<name>/form

name はアクションのプログラム名です。

Looker ユーザーのブラウザから Looker Action Hub ネットワークへのリクエスト

Looker ユーザーのブラウザから以下の Looker Action Hub エンドポイント（OAuth 用）にリクエストを実行できる必要があります。

actions.looker.com/actions/<name>/oauth

name はアクションのプログラム名です。

Looker Action Hub ネットワークから Looker インスタンスへのリクエスト

Looker Action Hub では、ストリーミングされた結果をサポートするアクションや OAuth を使用するアクションのために、Looker インスタンスに対するリクエストを実行する必要があります。

ストリーミング アクションにより、すべての結果を返すクエリをアクションで使用できるようになります。OAuth 対応のアクションでは、OAuth 2.0 フローによるユーザーごとの認証を使用します。Looker Action Hub はステートレスかつマルチテナントであり、ユーザー固有の認証情報はどのような種類であっても格納されないため、OAuth アクションはソースの Looker インスタンスにユーザー認証情報を保存する必要があります。

Looker Action Hub から Looker インスタンスへのリクエストの形式は次のとおりです。

GET <host_looker_url>/downloads/<random_40_char_token>
POST <host_looker_url>/action_hub_state/<random_40_char_token>

これらの URL は、Looker Action Hub に送信される前に Looker インスタンスのスポットで生成されます。したがって Looker Action Hub は、<host_looker_url> を IP アドレスに解決でき、かつ、Looker インスタンスが存在するネットワークにリクエストを送信できる必要があります。

Looker Action Hub には、常にリクエストの送信元となる静的下り（外向き）IP アドレス（35.153.89.114、104.196.138.163、35.169.42.87）があります。IP 許可リストが有効になっている Looker ホスト型インスタンスの管理者は、ストリーミングされた結果をサポートするアクションや OAuth を使用するアクションを実行するために、これらの IP アドレスを追加する必要があります。

セルフホスト型インスタンスに関する考慮事項

Looker 統合を使用するには、Looker Action Hub が Looker インスタンスと通信でき、これらの要件を満たしている必要があります。セルフホスト型 Looker インスタンスの場合、さまざまな理由によりこれは常に可能とは限りません。Looker Action Hub と Looker インスタンスの間で双方向通信ができない場合、Looker Action Hub は、予期しない動作や望ましくない動作（クエリがハングする、アクションが使用できないなど）を引き起こすことがあります。、

Looker Action Hub が Looker インスタンスと通信できないという潜在的な問題に対処するために、Looker 管理者は以下のソリューションのいずれかを実装できます。適切なソリューションまたはソリューションの組み合わせは、Looker インスタンスのアーキテクチャによって異なります。

  • セルフホスト型インスタンスがLooker Action Hub によって解決できない場合（つまり、Looker Action Hub　が Looker インスタンスからリクエストを受信できない場合）、Looker 管理者はGoogle Cloud セールス スペシャリストにお問い合わせをしてpublic_host_urlライセンス機能を有効にできます。このライセンス機能により --public-host-url 起動オプションが提供されます。このオプションを使用すると、管理者はインスタンス <host_looker_url> とは異なる、解決可能な <public_host_url> ホスト名を指定できます。public_host_url は、特定の Looker Action Hub コールバック URL のホスト名をオーバーライドし、public_host_url という一般公開で解決可能な名前を持つリバース プロキシ経由でこれらのコールバック URL をルーティングします。このリバース プロキシは、Looker Action Hub の静的下り（外向き）IP アドレスからのリクエストのみを受け入れます。このメソッドを使用する Looker 管理者は、Looker Action Hub から Looker インスタンスへのリクエストの送信元となる（外向き）IP アドレス（35.153.89.114、104.196.138.163、35.169.42.87）を許可リストに追加する必要があります。

  • セルフホスト型インスタンス URL が Looker インスタンスによって解決できるものの、Looker Action Hub が Looker インスタンスにリクエストを送信できない場合、ユーザーは、ストリーミングされた結果をサポートするアクションや OAuth を使用するアクションを構成または使用できないことがあります。Looker 管理者はこの問題を解決するために、Looker Action Hub から Looker インスタンスへのリクエストの送信元となる下り（外向き）IP アドレス（35.153.89.114、104.196.138.163、35.169.42.87）を許可リストに追加する必要があります。

  • 前述のソリューションがいずれも Looker インスタンス アーキテクチャに適していない場合、Looker 管理者はすべてのアクションに対して、またはストリーミングされた結果をサポートするアクションまたは OAuth を使用するアクションに対してのみ、セルフホスト型アクション ハブをデプロイできます。

  • セルフホスト型アクション ハブをデプロイするには、Looker Action Hub が JAR ファイルと通信できるように、JAR ファイルがパブリック サーバーでホストされている必要があります。ただし、Looker ではこのソリューションは推奨されません。

セルフホスト型 Looker インスタンスで OAuth とストリーミングのアクションを使用できないもう 1 つの理由として、このルート証明書のリストにない認証局（CA）によって発行された SSL 証明書がインスタンスで使用されている場合が挙げられます。

カスタム アクションを作成する

このセクションでは、Looker Action Hub のソースコードを使用してカスタム アクションを記述、テストする手順について説明します。関数コードの例については、GitHub の looker-open-source/actions リポジトリで既存のアクションを確認してください。

カスタム アクションは次の方法で作成できます。

  1. 開発リポジトリを設定する
  2. アクションを記述する
  3. アクションをテストする
  4. Looker Action Hub または独自のプライベート アクション ハブ サーバーでアクションを公開して有効にする

他のアクションと同様に、アクションを使用してデータを配信する前に、特定のパラメータを使用した LookML モデルの構成が必要になる場合があります。

開発リポジトリを設定する

Looker Action Hub は、TypeScript で記述された Node.js サーバーです。最新の JavaScript を基盤とする小さなレイヤで、プログラミング エラーの検出に役立つ型情報が追加されます。JavaScript に精通している場合は、TypeScript 言語のほとんどに馴染みがあるはずです。

Looker Action Hub を実行するには、次のソフトウェアが必要です。

  • Node.js
  • Node Version Manager（NVM - 適切な Node.js バージョンを選択）
  • Yarn（依存関係を管理するため）

必要なソフトウェアをインストールしたら、開発環境をセットアップできます。以下の例では Git を使用しています。

  1. looker-open-source/actions リポジトリのクローンをローカルに作成します。

    git clone git@github.com:looker-open-source/actions.git

  2. アクションの名前が付いたディレクトリを actions/src/actions ディレクトリに作成します。次に例を示します。

    mkdir actions/src/actions/my_action

  3. アクションの実行に必要なファイルで、ディレクトリへの入力を開始します。ファイル構造の例については、actions GitHub リポジトリをご覧ください。

Looker では、以下も追加することをおすすめします。

  • アクションの認証の目的と手段を説明する README
  • Looker Action Hub（または Looker インスタンスのプライベート アクション ハブ）と Looker データ配信ウィンドウに表示される PNG アイコン
  • アクション コードで実行するテスト用のファイル。これはアクションのテストとは異なります。

アクションの記述

Looker Action Hub サーバーの設計要件は、完全にステートレスであることです。アクションのアプリケーションやサービスに情報を保存することはできません。アクションの実行に必要な情報は、アクション ファイルのリクエスト呼び出し内で提供する必要があります。

アクション ファイルの正確な内容は、サービス、アクションが動作するタイプやレベル、指定する必要があるデータ形式やビジュアリゼーション形式によって異なります。アクションは OAuth 2.0 承認フロー用に構成することもできます。

アクション ファイルは /execute API メソッドに基づいています。ユーザーが Looker 内でアクションを実行するたびに、Looker API リクエストに DataActionRequest が渡されます。DataActionRequest には、アクションの実行に必要なすべてのデータとメタデータが含まれています。また、アクションを実行する前にユーザーから追加の情報を収集するために使用できる /form メソッドもあります。/form で指定したフィールドは、ユーザーがデータの配信先としてアクションを選択すると、[Send] または [Schedule] ポップアップに表示されます。

Looker Action API を使用している場合、これらのパラメータの形式が異なる場合があります。

アクション ファイルを記述する際、アクション定義には少なくとも以下の「必須」パラメータを含めてください。

パラメータ 必須 説明 データ型
name ○ アクションの一意の名前。これは、Looker Action Hub のすべてのアクションで一意である必要があります。 文字列
url ○ このアクションの /execute エンドポイントの絶対 URL。 文字列
label ○ 人が読める形式のアクションのラベル。 文字列
supportedActionTypes ○ アクションでサポートされるアクション タイプのリスト。有効な値は "cell"、"query"、"dashboard" です。 文字列
formURL × このアクションの /form エンドポイントの絶対 URL。 文字列
description × アクションの説明。 文字列
params × アクションの parameters の配列。各パラメータの名前、ラベル、説明を文字列形式で指定します。以下は、[管理者] パネルのアクションの有効化ページに表示されるフィールドです。ユーザーがアクションの対象にデータを配信する方法を管理するには、ユーザーに値を定義する必要があるユーザー属性を指定します。 parameters
supportedFormats × アクションでサポートされるデータ形式のリスト。有効な値は "txt"、"csv"、"inline_json"、"json"、"json_detail", "json_detail_lite_stream", "xlsx", "html", "wysiwyg_pdf", "assembled_pdf", and "wysiwyg_png". です。 文字列
supportedFormattings × アクションでサポートされる書式設定オプションのリスト。有効な値は "formatted" と "unformatted" です。 文字列
supportedVisualizationFormattings × アクションでサポートされるビジュアリゼーション書式設定オプションのリスト。有効な値は "apply" と "noapply" です。 文字列
iconName × アクションのアイコン画像を表すデータ URI。 文字列
requiredFields × アクションと互換性のある必須フィールドの説明のリスト。このリストに複数のエントリがある場合、アクションには複数のフィールドが必要です。 RequiredField
supportedDownloadSettings × データを無制限にストリーミングできるように、1 回限りのダウンロード URL をアクションに送信するかどうかを決定するブール値。このパラメータは、usesStreaming パラメータ（true/false のブール値）によって設定されます。usesStreaming = true の場合は supportedDownloadSettings = url、usesStreaming = false の場合は supportedDownloadSettings = push です。 ブール値
usesOAuth × アクションが OAuth アクションかどうかを決定するブール値。これにより、このアクションの特定のユーザーに対して state を設定するための 1 回限りのリンクをアクションに送信するかどうかを指定できます。 ブール値
usesStreaming × アクションでストリーミングされたクエリ結果をサポートするかどうかを決定するブール値。統合サービスのリストの [Can Stream Results Yes/No] 列を確認してください。結果をストリーミングするアクションでは、ローカル アクション ハブ サーバーの構成が必要になる場合があります。詳細については、OAuth またはストリーミングを使用するアクションのローカル アクション ハブの設定のベスト プラクティス ページをご覧ください。 ブール値
minimumSupportedVersion × [Admin] パネルのアクション ハブ リストにアクションが表示される最小の Looker バージョン。 文字列

Looker Action Hub アクションの例については、GitHub をご覧ください。

サポートされているアクションのタイプ

Looker では、アクションの supportedActionTypes パラメータで指定する 3 種類のアクション（query、cell、dashboard）がサポートされています。

  • クエリレベルのアクション: クエリ全体を送信するアクションです。たとえば、セグメント アクションはクエリレベルのアクションです。
  • セルレベルのアクション: セルレベルのアクションは、データテーブル内の単一の特定セルの値を送信します。このアクション タイプは、action パラメータを使用してディメンションまたは measure に定義できるデータ アクションとは異なります。テーブル内の特定のセルから情報を送信するには、Looker でタグを使用して対応するセルにアクションをマッピングします。アクションでは、サポートするタグを requiredFields で指定する必要があります。アクションとフィールドをマッピングするには、LookML のフィールドに対して、LookML の tags パラメータでマッピング先のタグを指定する必要があります。 たとえば、Twilio メッセージ アクションでは phone タグが使用されるため、LookML 開発者は Twilio アクションを表示する電話番号フィールドを制御できます。
  • ダッシュボード レベルのアクション: ダッシュボード レベルのアクションでは、ダッシュボードの画像の送信がサポートされています。たとえば、SendGrid アクションはダッシュボードの画像をメールで送信します。

カスタム アクションへのユーザー属性の追加

カスタム アクションの場合は、アクション ファイルの params パラメータにユーザー属性を追加できます。このパラメータが必須の場合、ユーザーごとにこの属性の値がユーザー アカウントで定義されているか、所属しているユーザー グループに対して定義されている必要があります。また、コンテンツを送信またはスケジュール設定する際に送信先オプションとしてアクションが表示されるように send_to_integration 権限も必要です。

アクションにユーザー属性を追加するには:

  1. Looker 管理者は、user_attribute_param に対応するユーザー属性を作成する必要があります（まだ存在しない場合）。
  2. アクションの対象にコンテンツを配信する必要があるユーザーまたはユーザー グループのユーザー属性に有効な値を定義します（これらのユーザーには send_to_integration 権限も必要です）。
  3. params パラメータは、Looker 管理者が [Admin] パネルの [Actions] リストにあるアクションの有効化ページで構成する必要があるフォーム フィールドを表します。アクション ファイルの params パラメータに以下を含めます。
  params = [{
    description: "A description of the param.",
    label: "A label for the param.",
    name: "action_param_name",
    user_attribute_name: "user_attribute_name",
    required: true,
    sensitive: true,
  }]

ここで、user_attribute_name は、[Admin] パネルの [Users] セクションの [User Attributes] ページにある [Name] フィールドで定義されているユーザー属性です。required: true は、データ配信時にアクションを表示するために、そのユーザー属性に対して null 以外の有効な値が定義されている必要があることを表します。sensitive: true は、ユーザー属性の値を一度入力すると暗号化され、Looker UI に表示されないことを表します。複数のユーザー属性サブパラメータを指定できます。

  1. アクション ハブサーバーに更新をデプロイします。
    • 新しいアクションを追加する場合は、Looker 管理者がそのアクションを有効にする必要があります。有効にするには、[Admin] パネルの [Actions] ページで、そのアクションの横にある [Enable] ボタンをクリックします。
    • 既存のアクションを更新する場合は、[Refresh] ボタンをクリックして、アクションのリストを更新します。次に、[Settings] ボタンをクリックします。
  2. Looker 管理者はアクションの設定 / 有効化ページで、ユーザー属性の情報が入力されるようにアクションのフォーム フィールドを構成する必要があります。それには、該当するフィールドの右側にあるユーザー属性アイコン をクリックし、目的のユーザー属性を選択します。

セルレベルのアクションの requiredField パラメータ

セルレベルのアクションの場合、そのアクションの対象にデータを配信するようにモデルの LookML フィールドを構成できます。それには、アクションでサポートするタグをアクション ファイルの requiredFields パラメータで指定します。

パラメータ 必須 説明 データ型
tag × 指定した場合、このタグを持つフィールドと照合されます。 文字列
any_tag × 指定した場合、tag よりも優先され、指定したタグのいずれかを持つフィールドと照合されます。 文字列
all_tags × 指定した場合、tag よりも優先され、指定したすべてのタグを持つフィールドと照合されます。 文字列

サポートされているデータ形式

DataActionRequest クラスは、アクションで処理できるデータ配信形式を定義します。クエリレベルのアクションの場合、リクエストには複数の形式の添付ファイルが含まれます。アクションでは、1 つ以上の supportedFormats を指定することも、使用可能なすべての形式を指定してユーザーが形式を選択できるようにすることもできます。セルレベルのアクションの場合、セルの値は DataActionRequest に存在します。

OAuth 用アクションの構成

IP 許可リスト機能が有効になっている Looker インスタンスや、Looker Action Hub 要件に対応できない Looker インスタンスの場合、Looker Action Hub から OAuth 対応のアクションを構成することはできません。OAuth 用のアクションの構成方法については、OAuth またはストリーミングを使用するアクションのローカル アクション ハブの設定ページをご覧ください。

ユーザーが OAuth でアクションに対して認証できるように、アクションを構成できます。Looker Action Hub はステートレスのままにする必要がありますが、Looker Action API のフォーム リクエストを使用して状態を適用できます。

Looker アクションの OAuth フロー

Looker Action Hub のアクションでは、Hub.Action ではなく OAuthAction を拡張して、ユーザーをアクションに対して認証するために必要な OAuth メソッドを示すブール値を設定できます。Looker では、OAuth 対応または状態対応のすべてのアクションについて、ユーザーごとおよびアクションごとに状態が保存されるため、アクションとユーザーの各組み合わせには独立した OAuth イベントがあります。

アクションを作成するフローには通常、/form リクエストに続いて /execute リクエストが含まれます。OAuth の場合、/form リクエストには、ユーザーがターゲット サービス内で認証されているかどうかを判別するためのメソッドが必要です。ユーザーがすでに認証されている場合、/execute リクエストの要件に従って、アクションで通常の /form が返されます。ユーザーが認証されていない場合は、OAuth フローを初期化するリンクが返されます。

OAuth URL を使用した状態の保存

Looker は、本文が空の HTTP POST リクエストを ActionList エンドポイントに送信します。アクションの定義で uses_oauth: true が返された場合、そのアクションには Looker からの /form リクエストごとに 1 回限りの state_url が送信されます。state_url は、特定のアクションに対するユーザーの状態を設定する、1 回限りの特別な URL です。

ユーザーがエンドポイントで認証されていない場合、返される /form には、アクションの /oauth エンドポイントに渡される oauth_link 型の form_field が含まれます。state_url は暗号化され、返される oauth_url に state パラメータとして保存されます。次に例を示します。

{
        "name": "login",
        "type": "oauth_link",
        "label": "Log in",
        "description": "OAuth Link",
        "oauth_url": "ACTIONHUB_URL/actions/my_action/oauth?state=encrypted_state_url"
}

この例では、/oauth エンドポイントがユーザーを認証サーバーにリダイレクトします。Dropbox OauthUrl に示すように、/oauth エンドポイントは OAuth アクションの oauthUrl(...) メソッドでリダイレクトを作成します。

この暗号化された state_url を含む state パラメータを Looker Action Hub に渡す必要があります。

アクション ハブのリダイレクト URI を使用した状態の保存

/oauth エンドポイントでは、アクション ハブの redirect_uri も作成され、アクションの oauthUrl(...) メソッドに渡されます。この redirect_uri は /actions/src/actions/my_maction/oauth_redirect の形式であり、認証が結果を返すときに使用されるエンドポイントです。

このエンドポイントは oauthFetchInfo(...) メソッドを呼び出します。このメソッドは OauthAction メソッドで実装する必要があり、これによって必要な情報が抽出され、認証サーバーから受信した状態や auth の受信または保存が試行されます。

state は暗号化された state_url を復号し、それを使用して Looker に state を POST で返します。ユーザーが次回そのアクションをリクエストしたときに、新しく保存された状態が Looker Action Hub に送信されます。

Looker Action Hub リポジトリへのアクション ファイルの追加

アクション ファイルを記述したら、Looker Action Hub リポジトリで以下を実行します。

  1. アクション ファイル（my_action.ts など）を actions/src/actions/index.ts に追加します。

    import "./my_action/my_action.ts"

  2. アクションを記述する際に使用した Node.js パッケージ要件を追加します。次に例を示します。

    yarn add aws-sdk
yarn add express

  3. Looker Action Hub サーバーの Node.js 依存関係をインストールします。

    yarn install

  4. 作成したテストを実行します。

yarn test

アクションのテスト

完全なテストを行うために、プライベート アクション ハブ サーバーをホストして、Looker インスタンスに対するアクションを試すことができます。このサーバーは、有効な SSL 証明書を持つ公共のインターネット上にあり、Looker との接続または HTTPS リクエストを開始および受信できる必要があります。この場合、次の例に示すように、Heroku などのクラウドベースのプラットフォーム、または前述の要件を満たすプラットフォームを使用できます。

ローカル アクション ハブ サーバーの設定

この例では、looker-open-source/actions/src/actions GitHub リポジトリで開発したアクションを実行し、新しい Git ブランチにコードを commit します。コードを簡単に追跡し、必要に応じて Looker で PR を簡単に作成できるように、ブランチを使用して機能を操作することをおすすめします。

  1. まずブランチを作成し、ステージングして作業を commit します。次に例を示します。

    git checkout -b my-branch-name
git add file-names
git commit -m commit-message

  2. この例では、Heroku にブランチを push するために、コマンドラインで Heroku をリモート オプションとして設定して Git リポジトリを構成します。

    heroku login
heroku create
git push heroku

  3. Heroku は、使用するアクション ハブをホストする公開 URL を返します。URL にアクセスするか、heroku logs を実行して、アクション ハブが実行中であることを確認します。公開 URL を忘れた場合は、コマンドラインで次のコマンドを実行します。

    heroku info -s | grep web_url

    Heroku から公開 URL が返されます。例: https://my-heroku-action-server-1234.herokuapp.com

  4. コマンドラインでアクション ハブのベース URL を設定します。

    heroku config:set ACTION_HUB_BASE_URL="https://my-heroku-action-server-1234.herokuapp.com"

  5. アクション ハブのラベルを設定します。

    heroku config:set ACTION_HUB_LABEL="Your Action Hub"

  6. Looker では認証トークンを使用してアクション ハブに接続します。コマンドラインでトークンを生成します。

    heroku run yarn generate-api-key

    この例のように Heroku を使用しない場合は、代わりに次を使用します。

    yarn generate-api-key

    Heroku から認証トークンが返されます。例: Authorization: Token token="abcdefg123456789"

  7. 秘密鍵を使用してアクション ハブのシークレットを設定します。

    heroku config:set ACTION_HUB_SECRET="abcdefg123456789"

    セルフホスト型のデプロイでは、ここに記載されていない追加の環境変数を構成する必要があります。

  8. [管理者] > [アクション] に移動して、ローカルの Looker インスタンスにアクションを追加します。

    • アクション リストの下部にある [Add Action Hub] をクリックします。
    • [Action Hub URL] にアクション ハブの URL を入力し、必要に応じて [Secret Key] に秘密鍵を入力します。
    • アクションは、Looker の [管理者] メニューの [アクション] リストで確認できます。
    • [Enable] をクリックします。

アクションで、Looker から特定の種類のデータを渡す必要がある場合は、適切な tags パラメータを含めるようにモデルを構成してください。

これで、アクションをテストする準備が整いました。

ダッシュボード レベルとクエリレベルのアクションのテスト

Looker インスタンスで、必要に応じてタグを使用して LookML モデルを構成します。Look を作成して保存します。保存した Look の右上にあるメニューで、アクションを送信先に設定して [Send] を選択します。配信フォームがある場合は、[Sent] ウィンドウに表示されます。

[Send Test] をクリックしてデータを配信します。アクションのステータスは、[Admin] パネルの [Scheduler History] に表示されます。アクションでエラーが発生した場合は [Admin] パネルに表示され、アクションを送信したユーザーにエラー メッセージが記載されたメールが送信されます。

セルレベルのアクションのテスト

アクションに適したタグを使用して LookML フィールドを設定します。Looker インスタンスで、そのフィールドを含むクエリを実行します。データテーブルでフィールドを検索します。セル内の […] をクリックし、プルダウン メニューから [Send] を選択します。エラーが表示された場合は、エラーに対処した後にデータテーブルを完全に更新する必要があります。

カスタム アクションの公開と有効化

カスタム アクションの公開には、次の 2 つの方法があります。

アクションが公開されたら、[Admin] パネルの [Actions] ページでアクションを有効化できます。

Looker Action Hub への公開

このアプローチは最も簡単で、Looker のすべてのユーザーがアクションを利用できるようにする場合に適しています。

アクションをテストしたら、GitHub の looker-open-source/actions リポジトリに PR を送信できます。

  1. 次のコマンドを入力します。

    git push <your fork> <your development branch>

  2. looker-open-source/actions リポジトリをターゲットに指定して pull リクエストを作成します。

  3. Looker Marketplace とアクション ハブの送信フォームに記入します。フォームの要件について詳しくは、Looker Marketplace へのコンテンツの送信をご覧ください。

    Looker によってアクション コードが確認されます。Looker は PR を拒否する権限を有しますが、問題があればサポートし、改善策を提案します。その後、コードが looker-open-source/actions リポジトリにマージされ、actions.looker.com にデプロイされます。デプロイが完了すると、Looker のすべてのお客様がコードを利用できるようになります。

  4. Looker インスタンスでアクションを有効化し、データ配信のオプションとして表示されるようにします。

プライベート アクション ハブ サーバーへの公開

会社またはユースケースに限定したカスタム アクションがある場合は、そのアクションを looker-open-source/actions リポジトリに追加しないでください。代わりに、アクションのテストに使用したのと同じ Node.js フレームワークを使用して、プライベート アクション ハブを作成します。

社内アクション ハブ サーバーは、独自のインフラストラクチャ上に設定するか、クラウドベースのアプリケーション プラットフォーム（この例では Heroku を使用）を使用して設定できます。デプロイの前に、必ず Looker Action Hub をプライベート アクション ハブ サーバーにフォークしてください。

アクションで使用する LookML モデルの構成

カスタム アクションと Looker Action Hub で利用可能なアクションの両方に関して、LookML モデルの tags パラメータを使用して関連データ フィールドを特定する必要があります。

[Admin] パネルの [Actions] ページに、サービスに必要なタグに関する情報が表示されます（存在する場合）。

たとえば、Zapier 統合では、どのクエリでも機能することが示されます。LookML モデルのフィールドに tags パラメータを追加する必要はありません。

ただし、Twilio メッセージ送信 サービスでは、電話番号のリストにメッセージを送信します。このサービスでは電話番号フィールドを含むクエリが必要で、tags パラメータを使用してクエリ内のどのフィールドに電話番号が含まれているのかを識別します。LookML で電話番号フィールドを識別するには、そのフィールドに tags: ["phone"] を指定します。LookML では、電話番号フィールドは次のようになります。

dimension: phone {
  tags: ["phone"]
  type: string
  sql: ${TABLE}.phone ;;
}

ユーザーがサービスを使用してデータを送信できるように、LookML モデルの必須フィールドは必ず tags パラメータを使用して識別してください。

次のステップ

統合サービスに Look または Explore のコンテンツまたはダッシュボードのコンテンツを配信する方法を学びます。