表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

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

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

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

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

Looker Action Hub から入手できる Looker の既存のアクションを使用する。
一般公開で使用できるようにカスタムアクションを作成し、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 Action Hub は、次の API リクエストを送受信できる必要があります。

Looker インスタンスから Looker Action Hub ネットワークへ
Looker ユーザーのブラウザから Looker Action Hub ネットワークへ
Looker Action Hub ネットワークから Looker インスタンスへ

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 Action Hub の要件を満たす必要があります。セルフホスト型 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 ファイルがパブリックサーバーでホストされている必要があります。ただし、このソリューションはおすすめしません。

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

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

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

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

開発リポジトリを設定する
アクションを記述する
アクションをテストする
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 を使用します。

looker-open-source/actions リポジトリのクローンをローカルに作成します。
```
git clone git@github.com:looker-open-source/actions.git
```
アクションの名前が付いたディレクトリを actions/src/actions ディレクトリに作成します。次に例を示します。
```
mkdir actions/src/actions/my_action
```
アクションの実行に必要なファイルのディレクトリへの入力を開始します。ファイル構造の例については、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] ポップアップに表示されます。

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

パラメータ	必須	説明	データ型
`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`	×	アクションでストリーミングされたクエリ結果をサポートするかどうかを決定するブール値。統合サービスのリストの [Uses data streaming (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 権限も必要です。

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

Looker 管理者は、user_attribute_param に対応するユーザー属性を作成する必要があります（まだ存在しない場合）。
アクションの対象にコンテンツを配信する必要があるユーザーまたはユーザーグループのユーザー属性に有効な値を定義します（これらのユーザーには send_to_integration 権限も必要です）。
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 に表示されないことを表します。複数のユーザー属性サブパラメータを指定できます。

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

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

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

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

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

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

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 リポジトリで以下を実行します。

アクションファイル（my_action.ts など）を actions/src/actions/index.ts に追加します。
```
import "./my_action/my_action.ts"
```
アクションを記述する際に使用した Node.js パッケージ要件を追加します。次に例を示します。
```
yarn add aws-sdk
yarn add express
```
Looker Action Hub サーバーの Node.js 依存関係をインストールします。
```
yarn install
```
作成したテストを実行します。

yarn test

アクションのテスト

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

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

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

まずブランチを作成し、ステージングして作業を commit します。次に例を示します。
```
git checkout -b my-branch-name
git add file-names
git commit -m commit-message
```
この例では、Heroku にブランチを push するために、コマンドラインで Heroku をリモートオプションとして設定して Git リポジトリを構成します。
```
heroku login
heroku create
git push heroku
```
Heroku は、使用するアクションハブをホストする公開 URL を返します。URL にアクセスするか、heroku logs を実行して、アクションハブが実行中であることを確認します。公開 URL を忘れた場合は、コマンドラインで次のコマンドを実行します。
```
heroku info -s | grep web_url
```
Heroku から公開 URL が返されます。例: https://my-heroku-action-server-1234.herokuapp.com

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

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

アクションハブのラベルを設定します。
```
heroku config:set ACTION_HUB_LABEL="Your Action Hub"
```
Looker では認証トークンを使用してアクションハブに接続します。コマンドラインでトークンを生成します。
```
heroku run yarn generate-api-key
```
この例のように Heroku を使用しない場合は、代わりに次を使用します。
```
yarn generate-api-key
```
Heroku から認証トークンが返されます。例: Authorization: Token token="abcdefg123456789"
秘密鍵を使用してアクションハブのシークレットを設定します。
```
heroku config:set ACTION_HUB_SECRET="abcdefg123456789"
```
セルフホスト型のデプロイでは、ここに記載されていない追加の環境変数を構成する必要があります。
[管理者] > [アクション] に移動して、ローカルの Looker インスタンスにアクションを追加します。
- アクションリストの下部にある [Add Action Hub] をクリックします。
- [Action Hub URL] にアクションハブの URL を入力し、必要に応じて [Secret Key] に秘密鍵を入力します。
- アクションは、Looker の [管理者] メニューの [アクション] リストで確認できます。
- [有効にする] をクリックします。

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

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

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

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

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

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

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

アクションがエラーなく配信された場合は、アクションを公開できます。
アクションを限定公開でホストする場合は、プライベートアクションハブに公開します。
すべての Looker ユーザーが使用できるようにアクションを公開する場合は、Looker Action Hub への公開セクションをご覧ください。

カスタムアクションを公開して有効にする

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

Looker Action Hub に公開: Looker を使用するすべてのユーザーがアクションを利用できるようになります。
プライベートアクションハブサーバーに公開: アクションが Looker インスタンスでのみ利用可能になります。

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

Looker Action Hub への公開

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

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

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

git push <your fork> <your development branch>

looker-open-source/actions リポジトリをターゲットに指定して pull リクエストを作成します。
Looker Marketplace とアクションハブの送信フォームに記入します。フォーム要件の詳細については、Looker Marketplace にコンテンツを送信するをご覧ください。

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

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

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

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

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

カスタムアクションと Looker Action Hub で利用可能なアクションの両方に関して、LookML モデルの tags パラメータを使用して関連データフィールドを特定する必要があります。[Admin] パネルの [Actions] ページに、サービスに必要なタグに関する情報が表示されます（存在する場合）。

たとえば、[Twilio Send Message] の統合の場合、電話番号のリストにメッセージを送信します。[Admin] パネルの [Actions] ページに、統合に「phone タグのあるフィールドを持つクエリでアクションを使用できます」というサブテキストが表示されます。

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

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

タグを必要としない統合では、[Admin] パネルの [Actions] ページに「Action can be used with any query」というサブテキストが表示されます。

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

次のステップ

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