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 を実行するには、次のソフトウェアが必要です。
必要なソフトウェアをインストールしたら、開発環境の設定を開始できます。次の例では 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" です。 |
文字列 |
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-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 のコンテンツまたはダッシュボードのコンテンツを配信する方法を学びます。