Notez que vous consultez la documentation de Looker. Pour accéder à la documentation Looker Studio, consultez https://support.google.com/looker-studio.

Cette page a été traduite par l'API Cloud Translation.

Partager des données via un hub d'actions

En plus de diffuser du contenu vers les destinations intégrées de Looker, vous pouvez utiliser des actions (également appelées intégrations) pour diffuser du contenu vers des services tiers intégrés à Looker via un serveur Action Hub.

Cette page vous explique comment créer des actions personnalisées que vous pouvez demander à ajouter à Looker Action Hub ou à votre propre serveur Action Hub privé. Cette page explique également comment démarrer un serveur de hub d'actions local pour tester vos actions personnalisées ou exécuter un serveur de hub d'actions privé.

Pour commencer à utiliser des actions, vous pouvez:

Utilisez les actions existantes de Looker disponibles dans l'Action Hub de Looker.
Créez et publiez une action personnalisée dans l'Action Hub de Looker pour une utilisation publique.
Créez et publiez une action personnalisée sur un serveur de hub d'actions privé pour un usage privé.

Une fois l'action ajoutée à l'Action Hub, un administrateur Looker peut l'activer pour l'utiliser afin de diffuser du contenu Looker vers ces services.

Vous pouvez également configurer plusieurs hubs d'actions si vous souhaitez utiliser les intégrations de Looker via le hub d'actions Looker et héberger vos propres actions privées ou personnalisées. Les actions de chaque hub d'actions s'affichent sur la page Actions du panneau Administration.

Action Hub Looker

Looker héberge et fournit Looker Action Hub, un serveur sans état qui implémente l'API Action de Looker et expose les actions courantes. Toutes les données envoyées par vos utilisateurs à l'aide d'une action sont provisoirement traitées sur le serveur Looker Action Hub, et non dans votre instance Looker.

Looker est déjà intégré à plusieurs services. Consultez la page de documentation Paramètres d'administration - Actions pour savoir comment activer ces services existants.

Exigences concernant Action Hub Looker

Looker Action Hub doit pouvoir envoyer et recevoir des requêtes API de la manière suivante:

De l'instance Looker au réseau Looker Action Hub
Du navigateur de l'utilisateur Looker au réseau Looker Action Hub
Depuis le réseau Action Hub de Looker vers l'instance Looker

Si votre déploiement Looker ne peut pas répondre à ces requêtes ou si la fonctionnalité Liste d'autorisation d'adresses IP est activée sur votre instance Looker, envisagez de configurer un serveur de hub d'actions local pour diffuser des intégrations Looker ou des actions personnalisées privées. Les administrateurs des instances hébergées par le client peuvent également déployer un serveur d'actions local spécifiquement pour les actions OAuth et de streaming.

Requêtes de l'instance Looker vers le réseau Looker Action Hub

Les requêtes envoyées à actions.looker.com sont converties en une adresse IP dynamique. Les requêtes sortantes de l'instance Looker doivent pouvoir atteindre les points de terminaison suivants:

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

où name est le nom programmatique de l'action.

Requêtes du navigateur de l'utilisateur Looker au réseau de l'Action Hub de Looker

Le navigateur de l'utilisateur Looker doit pouvoir envoyer des requêtes aux points de terminaison Looker Action Hub suivants (pour OAuth):

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

où name est le nom programmatique de l'action.

Requêtes du réseau Looker Action Hub vers l'instance Looker

L'Action Hub de Looker doit envoyer des requêtes à l'instance Looker pour les actions qui acceptent les résultats diffusés ou qui utilisent OAuth.

Une action en streaming permet à l'action de consommer des requêtes qui renvoient Tous les résultats. Les actions compatibles avec OAuth utilisent une authentification par utilisateur via des flux OAuth 2.0. Les actions OAuth doivent stocker les identifiants utilisateur dans leur instance Looker source, car le hub d'actions Looker est sans état et multi-tenant, et ne stocke aucun identifiant spécifique à l'utilisateur.

Les requêtes de l'Action Hub de Looker vers une instance Looker se présentent sous les formes suivantes:

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

Ces URL sont générées sur place dans l'instance Looker avant d'être envoyées à Looker Action Hub. Pour cette raison, le hub d'actions Looker doit pouvoir résoudre le <host_looker_url> en adresse IP et envoyer des requêtes sur le réseau sur lequel se trouve votre instance Looker.

Le hub d'actions Looker dispose d'adresses IP de sortie statiques à partir desquelles les requêtes proviennent toujours: 35.153.89.114, 104.196.138.163 et 35.169.42.87. Les administrateurs des instances hébergées par Looker qui ont activé la liste d'autorisation d'adresses IP doivent ajouter ces adresses IP pour utiliser les actions qui acceptent les résultats en streaming ou qui utilisent OAuth.

Considérations concernant les instances hébergées par le client

Pour utiliser les intégrations Looker, Looker Action Hub doit pouvoir communiquer avec l'instance Looker et répondre aux conditions requises pour Looker Action Hub. Ce n'est pas toujours possible avec les instances Looker hébergées par le client, pour diverses raisons. Si la communication bidirectionnelle entre Looker Action Hub et l'instance Looker n'est pas possible, Looker Action Hub peut présenter un comportement inattendu ou indésirable, comme des requêtes en attente ou des actions indisponibles.

Pour résoudre le problème potentiel d'impossibilité de communication entre Action Hub et l'instance Looker, les administrateurs Looker peuvent implémenter l'une des solutions présentées plus loin sur cette page. La solution ou la combinaison de solutions appropriées dépend de l'architecture de l'instance Looker:

Si l'instance hébergée par le client n'est pas résolue par Looker Action Hub (c'est-à-dire que Looker Action Hub ne peut pas recevoir de requêtes de l'instance Looker), les administrateurs Looker peuvent contacter un spécialiste commercial Google Cloud pour activer la fonctionnalité de licence public_host_url. Cette fonctionnalité de licence révèle l'option de démarrage --public-host-url, qui permet aux administrateurs de spécifier un nom d'hôte <public_host_url> résoluble qui est différent de l'instance <host_looker_url>. public_host_url remplace le nom d'hôte pour certaines URL de rappel Looker Action Hub spécifiques et redirige ces URL de rappel via un proxy inverse dont public_host_url est le nom publiquement résoluble. Ce proxy inverse n'accepte les requêtes que provenant des adresses IP de sortie statiques de l'Action Hub de Looker. Les administrateurs Looker qui utilisent cette méthode doivent ajouter à la liste d'autorisation les adresses IP de sortie à partir desquelles l'Action Hub de Looker envoie des requêtes à l'instance Looker: 35.153.89.114, 104.196.138.163 et 35.169.42.87.
Si l'URL de l'instance hébergée par le client est résolue par l'instance Looker, mais que Looker Action Hub ne peut pas envoyer de requêtes à l'instance Looker, les utilisateurs ne pourront peut-être pas configurer ni utiliser les actions qui acceptent les résultats en streaming ou qui utilisent OAuth. Pour résoudre ce problème, les administrateurs Looker doivent ajouter à la liste d'autorisation les adresses IP de sortie à partir desquelles le hub d'actions Looker envoie des requêtes à l'instance Looker: 35.153.89.114, 104.196.138.163 et 35.169.42.87.
Si aucune des solutions mentionnées ci-dessus n'est adaptée à l'architecture de l'instance Looker, les administrateurs Looker peuvent déployer un hub d'actions hébergé par le client pour toutes les actions ou uniquement pour celles qui acceptent les résultats en streaming ou qui utilisent OAuth.
Pour déployer un hub d'actions hébergé par le client, vous devez vous assurer que le fichier JAR est hébergé sur un serveur public afin qu'Action Hub de Looker puisse communiquer avec. Cette solution n'est toutefois pas recommandée.

De plus, les actions OAuth et de streaming peuvent ne pas être utilisables sur une instance Looker hébergée par le client si elle utilise un certificat SSL délivré par une autorité de certification (AC) qui ne figure pas sur cette liste de certificats racine.

Créer une action personnalisée

Cette section décrit les étapes à suivre pour écrire et tester une action personnalisée à l'aide du code source de Looker Action Hub. Pour voir des exemples de code fonctionnel, consultez les actions existantes dans le dépôt looker-open-source/actions sur GitHub.

Pour créer une action personnalisée, procédez comme suit:

Configurer un dépôt de développement
Écrire votre action
Tester votre action
Publier et activer votre action, soit dans Looker Action Hub, soit sur votre propre serveur Action Hub privé

Comme pour toute action, vous devrez peut-être configurer vos modèles LookML avec des paramètres spécifiques avant de pouvoir utiliser l'action pour transmettre vos données.

Configurer un dépôt de développement

Looker Action Hub est un serveur Node.js écrit en TypeScript, une petite couche sur le JavaScript moderne qui ajoute des informations de type pour aider à détecter les erreurs de programmation. Si vous connaissez JavaScript, la plupart du langage TypeScript devrait vous être familière.

L'exécution d'Action Hub Looker nécessite les logiciels suivants:

Node.js
Node Version Manager (NVM) pour sélectionner la version de Node.js appropriée
Yarn (pour gérer les dépendances)

Une fois le logiciel requis installé, vous pouvez configurer votre environnement de développement. L'exemple suivant utilise Git.

Clonez le dépôt looker-open-source/actions localement:

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

Créez un répertoire portant le nom de votre action dans le répertoire actions/src/actions. Exemple :
```
mkdir actions/src/actions/my_action
```
Commencez à remplir votre répertoire avec les fichiers dont vous avez besoin pour exécuter votre action. Pour obtenir un exemple de structure de fichiers, consultez le dépôt GitHub d'actions.

Looker vous recommande également d'ajouter les éléments suivants:

Un fichier README expliquant l'objectif et les moyens d'authentification de votre action
Une icône PNG à afficher dans Looker Action Hub (ou dans le hub d'actions privées de votre instance Looker) et dans les fenêtres de livraison de données Looker
Tous les fichiers de test que vous souhaitez exécuter sur votre code d'action (ce qui est différent du test de votre action)

Écrire une action

Le serveur Looker Action Hub doit rester complètement sans état. Il n'est donc pas autorisé à stocker des informations dans l'application ou le service d'action. Toutes les informations nécessaires à l'exécution de l'action doivent être fournies dans les appels de requête du fichier d'action.

Le contenu exact du fichier d'action varie en fonction du service, du type ou du niveau auquel l'action s'exécute, et des formats de données ou de visualisation à spécifier. L'action peut également être configurée pour les flux d'autorisation OAuth 2.0.

Les fichiers d'action sont basés sur la méthode de l'API /execute. Les requêtes de l'API Looker sont transmises à un DataActionRequest chaque fois qu'un utilisateur exécute l'action dans Looker. DataActionRequest contient toutes les données et métadonnées nécessaires à l'exécution de votre action. Une méthode /form est également disponible, qui peut être utilisée pour collecter des informations supplémentaires auprès de l'utilisateur avant qu'il n'exécute l'action. Les champs que vous spécifiez dans /form s'affichent dans le pop-up Envoyer ou Planifier lorsque les utilisateurs sélectionnent l'action comme destination pour la diffusion de leurs données.

Lorsque vous rédigez votre fichier d'action, incluez au moins les paramètres suivants marqués comme Obligatoires dans la définition de l'action:

Paramètre	Obligatoire	Description	Type de données
`name`	Oui	Nom unique de l'action. Il doit être unique pour toutes les actions du hub d'actions Looker.	chaîne
`url`	Oui	URL absolue du point de terminaison `/execute` pour cette action.	chaîne
`label`	Oui	Libellé lisible de l'action.	chaîne
`supportedActionTypes`	Oui	Liste des types d'actions compatibles avec l'action. Les valeurs valides sont `"cell"`, `"query"` et `"dashboard"`.	chaîne
`formURL`	Non	URL absolue du point de terminaison `/form` pour cette action.	chaîne
`description`	Non	Description de l'action.	chaîne
`params`	Non	Tableau `parameters` pour l'action. Incluez le nom, le libellé et la description au format de chaîne pour chaque paramètre. Il s'agit des champs qui s'affichent sur la page d'activation de l'action dans le panneau Administration. Pour gérer la manière dont les utilisateurs peuvent envoyer des données à une destination d'action, vous pouvez spécifier un attribut utilisateur pour lequel un utilisateur doit définir une valeur.	`parameters`
`supportedFormats`	Non	Liste des formats de données compatibles avec l'action. Les valeurs valides sont `"txt"`, `"csv"`, `"inline_json"`, `"json"` et `"json_detail", "json_detail_lite_stream", "xlsx", "html", "wysiwyg_pdf", "assembled_pdf", and "wysiwyg_png".`.	chaîne
`supportedFormattings`	Non	Liste des options de mise en forme compatibles avec l'action. Les valeurs valides sont `"formatted"` et `"unformatted"`.	chaîne
`supportedVisualizationFormattings`	Non	Liste des options de mise en forme de la visualisation compatibles avec l'action. Les valeurs valides sont `"apply"` et `"noapply"`.	chaîne
`iconName`	Non	URI de données représentant une image d'icône pour l'action.	chaîne
`requiredFields`	Non	Liste des descriptions des champs obligatoires compatibles avec cette action. Si cette liste contient plusieurs entrées, l'action nécessite plusieurs champs.	`RequiredField`
`supportedDownloadSettings`	Non	Valeur booléenne qui détermine si une URL de téléchargement à usage unique sera envoyée à l'action pour faciliter le streaming illimité de données. Le paramètre est défini par le paramètre `usesStreaming`, qui est une valeur booléenne `true/false`. Si `usesStreaming = true`, alors `supportedDownloadSettings = url`. Si `usesStreaming = false`, alors `supportedDownloadSettings = push`.	Booléen
`usesOAuth`	Non	Valeur booléenne qui détermine si l'action est une action OAuth. Cela déterminera si un lien à usage unique sera envoyé à l'action pour pouvoir définir `state` pour un utilisateur spécifique pour cette action.	Booléen
`usesStreaming`	Non	Valeur booléenne qui détermine si l'action est compatible avec les résultats de requête diffusés. Vérifiez la colonne Utilise le streaming de données (oui/non) dans la liste des services intégrés. Les actions qui diffusent des résultats peuvent nécessiter la configuration d'un serveur Action Hub local. Pour en savoir plus, consultez la page des bonnes pratiques Configurer un Action Hub local pour les actions qui utilisent OAuth ou la diffusion de données.	Booléen
`minimumSupportedVersion`	Non	Version minimale de Looker à partir de laquelle l'action s'affiche dans la liste du hub d'actions du panneau Administration.	chaîne

Des exemples d'actions du hub d'actions Looker sont disponibles sur GitHub à titre de référence.

Types d'actions compatibles

Looker accepte trois types d'actions, comme indiqué dans le paramètre supportedActionTypes de votre action: requête, cellule et tableau de bord.

Action au niveau de la requête:action qui envoie une requête complète. L'action de segmentation, par exemple, est une action au niveau de la requête.
Action au niveau de la cellule:une action au niveau de la cellule envoie la valeur d'une seule cellule spécifique dans un tableau de données. Ce type d'action est différent des actions de données, qui peuvent être définies pour les dimensions ou les mesures à l'aide du paramètre action. Pour envoyer des informations à partir d'une cellule spécifique d'un tableau, Looker utilise des balises pour mettre en correspondance des actions avec les cellules correspondantes. Les actions doivent spécifier les balises qu'elles acceptent dans requiredFields. Pour mapper des actions et des champs, les champs LookML doivent spécifier les balises auxquelles ils sont mappés à l'aide du paramètre tags LookML. Par exemple, l'action de message Twilio utilise une balise phone afin que les développeurs LookML puissent contrôler les champs de numéro de téléphone sur lesquels l'action Twilio s'affichera.
Action au niveau du tableau de bord:une action au niveau du tableau de bord permet d'envoyer une image d'un tableau de bord. Par exemple, l'action SendGrid envoie des images de tableau de bord par e-mail.

Ajouter des attributs utilisateur aux actions personnalisées

Pour les actions personnalisées, vous pouvez ajouter des attributs utilisateur dans le paramètre params de votre fichier d'action. Si le paramètre est obligatoire, chaque utilisateur doit avoir une valeur définie pour cet attribut dans son compte utilisateur ou pour un groupe d'utilisateurs auquel il appartient, en plus de l'autorisation send_to_integration, pour voir l'action en tant qu'option de destination lors de l'envoi ou de la planification de contenus.

Pour ajouter un attribut utilisateur à votre action:

Un administrateur Looker peut être amené à créer l'attribut utilisateur qui correspond à user_attribute_param s'il n'existe pas déjà.
Définissez une valeur valide pour l'attribut utilisateur des utilisateurs ou des groupes d'utilisateurs qui doivent diffuser du contenu vers la destination de votre action. (Ces utilisateurs doivent également disposer des autorisations send_to_integration.)
Le paramètre params représente les champs de formulaire qu'un administrateur Looker doit configurer sur la page d'activation de l'action à partir de la liste Actions du panneau Administration. Dans le paramètre params de votre fichier d'action, incluez les éléments suivants:

  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,
  }]

où user_attribute_name est l'attribut utilisateur défini dans le champ Nom de la page Attributs utilisateur, dans la section Utilisateurs du panneau Administration. required: true signifie qu'une valeur non nulle et valide doit être définie pour cet attribut utilisateur pour que l'action s'affiche lorsque les données sont transmises. sensitive: true signifie que l'attribut utilisateur est chiffré et qu'il n'est jamais affiché dans l'interface utilisateur de Looker une fois saisi. Vous pouvez spécifier plusieurs sous-paramètres d'attribut utilisateur.

Déployez vos mises à jour sur le serveur de l'Action Hub.
- Si vous ajoutez une action, un administrateur Looker devra l'activer en cliquant sur le bouton Activer à côté de l'action sur la page Actions du panneau Administration.
- Si vous modifiez une action existante, actualisez la liste des actions en cliquant sur le bouton Actualiser. Cliquez ensuite sur le bouton Paramètres.
Sur la page des paramètres/de l'activation de l'action, un administrateur Looker doit configurer les champs du formulaire de l'action pour extraire des informations de l'attribut utilisateur. Pour ce faire, il doit cliquer sur l'icône de l'attribut utilisateur à droite du champ approprié, puis sélectionner l'attribut utilisateur souhaité.

Paramètres `requiredField` dans les actions au niveau de la cellule

Pour les actions au niveau des cellules, vous pouvez configurer les champs LookML de votre modèle afin de transmettre des données à la destination de cette action en spécifiant les balises compatibles avec votre action dans le paramètre requiredFields de votre fichier d'action.

Paramètre	Obligatoire	Description	Type de données
`tag`	Non	Si elle est présente, correspond à un champ associé à cette balise.	chaîne
`any_tag`	Non	Si cette valeur est présente, elle remplace `tag` et correspond à un champ contenant l'une des balises fournies.	chaîne
`all_tags`	Non	Si cette valeur est présente, elle remplace `tag` et correspond à un champ contenant toutes les balises fournies.	chaîne

Formats de données compatibles

La classe DataActionRequest définit le format de diffusion des données disponible pour l'action. Pour les actions au niveau de la requête, la demande contient une pièce jointe qui peut être au format suivant : L'action peut spécifier un ou plusieurs supportedFormats, ou laisser l'utilisateur choisir le format en spécifiant tous les formats possibles. Pour les actions au niveau de la cellule, la valeur de la cellule est présente sur DataActionRequest.

Configurer une action pour OAuth

Vous pouvez configurer votre action afin que les utilisateurs puissent s'y authentifier avec OAuth. Même si Action Hub de Looker doit rester sans état, vous pouvez appliquer un état via une requête de formulaire de l'API Action de Looker.

Flux OAuth des actions Looker

Pour les actions du hub d'actions Looker, vous pouvez étendre un OAuthAction au lieu d'un Hub.Action afin de définir une valeur booléenne indiquant les méthodes OAuth requises pour authentifier un utilisateur dans une action. Pour chaque action activée par OAuth ou par état, Looker stocke un état par utilisateur et par action, de sorte que chaque combinaison d'action et d'utilisateur dispose d'un événement OAuth indépendant.

Le flux de création d'actions implique généralement une requête /form suivie d'une requête /execute. Pour OAuth, la requête /form doit comporter une méthode permettant de déterminer si l'utilisateur est authentifié dans le service cible. Si l'utilisateur est déjà authentifié, l'action doit renvoyer un /form normal, conformément à ce que la requête /execute exige. Si l'utilisateur n'est pas authentifié, l'action renvoie un lien qui initialise un flux OAuth.

Enregistrer l'état avec l'URL OAuth

Looker envoie une requête HTTP POST avec un corps vide au point de terminaison ActionList. Si l'action renvoie uses_oauth: true dans sa définition, un state_url à usage unique lui sera envoyé dans chaque requête /form de Looker. state_url est une URL spéciale à usage unique qui définit l'état d'un utilisateur pour une action donnée.

Si l'utilisateur n'est pas authentifié auprès du point de terminaison, le /form renvoyé doit contenir un form_field de type oauth_link qui accède au point de terminaison /oauth d'une action. Le state_url doit être chiffré et enregistré en tant que paramètre state dans le oauth_url renvoyé. Exemple :

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

Dans cet exemple, le point de terminaison /oauth redirige l'utilisateur vers le serveur d'authentification. Le point de terminaison /oauth crée la redirection dans la méthode oauthUrl(...) sur une action OAuth, comme indiqué dans Dropbox OauthUrl.

Le paramètre state contenant ce state_url chiffré doit être transmis au hub d'actions Looker.

Enregistrer l'état avec l'URI de redirection du hub d'actions

Dans le point de terminaison /oauth, un redirect_uri pour le hub d'actions est également créé et transmis à la méthode oauthUrl(...) de l'action. Ce redirect_uri est au format /actions/src/actions/my_maction/oauth_redirect et correspond au point de terminaison utilisé si l'authentification renvoie un résultat.

Ce point de terminaison appelle la méthode oauthFetchInfo(...), qui doit être implémentée par la méthode OauthAction pour extraire les informations nécessaires et tenter de recevoir ou d'enregistrer tout état ou auth reçu du serveur d'authentification.

Le state déchiffre le state_url chiffré et l'utilise pour renvoyer le state à Looker par POST. La prochaine fois qu'un utilisateur enverra une requête à cette action, l'état nouvellement enregistré sera envoyé à Looker Action Hub.

Ajouter vos fichiers d'action au dépôt Looker Action Hub

Une fois votre fichier d'action écrit, dans le dépôt Looker Action Hub:

Ajoutez le fichier d'action (par exemple, my_action.ts) à actions/src/actions/index.ts.
```
import "./my_action/my_action.ts"
```
Ajoutez toutes les exigences concernant les packages Node.js que vous avez utilisées pour rédiger votre action. Exemple :
```
yarn add aws-sdk
yarn add express
```
Installez les dépendances Node.js du serveur Looker Action Hub.
```
yarn install
```
Exécutez les tests que vous avez écrits.

yarn test

Tester une action

Pour effectuer des tests complets, vous pouvez tester votre action sur votre instance Looker en hébergeant un serveur de hub d'actions privé. Ce serveur doit être sur Internet public avec un certificat SSL valide et doit pouvoir établir et recevoir des connexions ou des requêtes HTTPS à destination et en provenance de Looker. Pour ce faire, vous pouvez utiliser une plate-forme cloud telle que Heroku, comme illustré dans l'exemple suivant. Vous pouvez également utiliser n'importe quelle plate-forme répondant aux exigences susmentionnées.

Configurer un serveur de hub d'actions local

Dans cet exemple, nous allons utiliser l'action que nous avons développée dans le dépôt GitHub looker-open-source/actions/src/actions et allons valider le code dans une nouvelle branche Git. Nous vous recommandons de travailler sur des fonctionnalités à l'aide de branches afin de pouvoir suivre facilement votre code et, si vous le souhaitez, créer facilement une demande de pull avec Looker.

Pour commencer, créez votre branche, puis mettez en scène et validez votre travail. Exemple :
```
git checkout -b my-branch-name
git add file-names
git commit -m commit-message
```
Pour cet exemple, pour transférer une branche vers Heroku, configurez votre dépôt Git avec Heroku en tant qu'option distante dans votre ligne de commande:
```
heroku login
heroku create
git push heroku
```
Heroku renvoie l'URL publique qui héberge désormais le hub d'actions à votre disposition. Accédez à l'URL ou exécutez heroku logs pour vérifier que le hub d'actions est en cours d'exécution. Si vous avez oublié l'URL publique, vous pouvez exécuter la commande suivante dans votre ligne de commande:
```
heroku info -s | grep web_url
```
Heroku renvoie votre URL publique. Par exemple : https://my-heroku-action-server-1234.herokuapp.com

Dans votre ligne de commande, définissez l'URL de base de votre hub d'actions:

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

Définissez le libellé de votre hub d'actions:

heroku config:set ACTION_HUB_LABEL="Your Action Hub"

Looker utilise un jeton d'autorisation pour se connecter à l'Action Hub. Générez le jeton dans votre ligne de commande:
```
heroku run yarn generate-api-key
```
Si vous n'utilisez pas Heroku, comme nous le faisons dans cet exemple, utilisez plutôt:
```
yarn generate-api-key
```
Heroku renvoie votre jeton d'autorisation. Par exemple : Authorization: Token token="abcdefg123456789"
Définissez le secret de votre hub d'actions à l'aide de la clé secrète:
```
heroku config:set ACTION_HUB_SECRET="abcdefg123456789"
```
Les déploiements hébergés par le client peuvent nécessiter la configuration de variables d'environnement supplémentaires non documentées ici.
Ajoutez votre action à votre instance Looker locale en accédant à Administration > Actions.
- En bas de la liste des actions, cliquez sur Ajouter un hub d'actions.
- Saisissez l'URL du hub d'actions et, éventuellement, une clé secrète.
- Recherchez votre action dans la liste Actions du menu Administration de Looker.
- Cliquez sur Activer.

Si votre action nécessite que des types de données spécifiques soient transmis à partir de Looker, veillez à configurer les modèles pour inclure le paramètre tags approprié.

Vous êtes maintenant prêt à tester votre action.

Tester les actions au niveau du tableau de bord et de la requête

Dans votre instance Looker, configurez votre modèle LookML avec des balises, si nécessaire. Créez et enregistrez un look. Dans la présentation enregistrée, cliquez sur le menu en haut à droite, puis sélectionnez Envoyer en définissant votre action comme destination. Si vous avez un formulaire à envoyer, Looker l'affiche dans la fenêtre Envoyé.

Cliquez sur Envoyer un test pour envoyer les données. L'état de l'action s'affiche dans l'onglet Historique du planificateur du panneau Administration. Si votre action rencontre une erreur, elle s'affiche dans le panneau Administration, et Looker envoie un e-mail contenant le message d'erreur à l'utilisateur qui a envoyé l'action.

Tester les actions au niveau de la cellule

Configurez un champ LookML avec les balises appropriées pour votre action. Dans votre instance Looker, exécutez une requête qui inclut ce champ. Recherchez le champ dans le tableau de données. Cliquez sur … dans la cellule, puis sélectionnez Envoyer dans le menu déroulant. Si des erreurs s'affichent, vous devrez effectuer une actualisation complète de la table de données après les avoir corrigées.

Si votre action est diffusée sans erreur, vous pouvez la publier.
Si vous souhaitez continuer à héberger votre action en privé, vous pouvez la publier dans votre hub d'actions privé.
Si vous souhaitez publier votre action pour qu'elle soit utilisée par tous les clients Looker, consultez la section Publier dans l'Action Hub de Looker.

Publier et activer une action personnalisée

Il existe deux options de publication pour les actions personnalisées:

Publier dans l'Action Hub de Looker: votre action sera disponible pour tous les utilisateurs de Looker.
Publier sur un serveur de hub d'actions privé: votre action n'est disponible que sur votre instance Looker.

Une fois votre action publiée, vous pouvez l'activer depuis la page Actions du panneau Administration.

Publier dans Looker Action Hub

Cette approche est la plus simple et fonctionne pour toute action que vous souhaitez mettre à la disposition de tous les utilisateurs de Looker.

Une fois votre action testée, vous pouvez envoyer une demande de pull au dépôt looker-open-source/actions sur GitHub.

Saisissez la commande suivante :

git push <your fork> <your development branch>

Créez votre demande d'extraction en utilisant le dépôt looker-open-source/actions comme cible.
Remplissez le formulaire d'envoi pour Looker Marketplace et Action Hub. Pour en savoir plus sur les exigences concernant le formulaire, consultez Envoyer du contenu sur la place de marché Looker Marketplace.

Looker examinera votre code d'action. Nous nous réservons le droit de refuser votre communiqué de presse, mais nous pouvons vous aider à résoudre les problèmes que vous rencontrez et vous suggérer des améliorations. Nous fusionnons ensuite le code dans le dépôt looker-open-source/actions et le déployons sur actions.looker.com. Une fois le code déployé, il sera disponible pour tous les clients Looker.
Activez l'action dans votre instance Looker afin qu'elle s'affiche comme option de diffusion des données.

Publier sur un serveur de hub d'actions privé

Si vous avez des actions personnalisées qui sont privées à votre entreprise ou à votre cas d'utilisation, vous ne devez pas les ajouter au dépôt looker-open-source/actions. Créez plutôt un hub d'actions privé à l'aide du même framework Node.js que celui que vous avez utilisé pour tester votre action.

Vous pouvez configurer votre serveur de hub d'actions interne sur votre propre infrastructure ou à l'aide d'une plate-forme d'applications cloud (nous avons utilisé Heroku dans notre exemple). N'oubliez pas de créer une fourchette de l'Action Hub Looker sur votre serveur Action Hub privé avant le déploiement.

Configurer un modèle LookML pour l'utiliser avec une action

Pour les actions personnalisées et les actions disponibles dans le hub d'actions Looker, vous devez identifier les champs de données pertinents à l'aide du paramètre tags dans votre modèle LookML. La page Actions du panneau Administration fournit des informations sur les balises éventuellement requises pour le service.

Par exemple, une intégration Twilio Send Message envoie un message à une liste de numéros de téléphone. Sur la page Actions du panneau Administration, l'intégration affiche le sous-texte "L'action peut être utilisée avec les requêtes dont un champ est tagué phone".

Cela signifie que le service Envoyer un message Twilio nécessite une requête incluant un champ de numéro de téléphone et qui utilise le paramètre tags pour identifier le champ de la requête qui contient les numéros de téléphone. Vous identifiez un champ de numéro de téléphone dans LookML en spécifiant tags: ["phone"] pour ce champ. Voici un exemple de code LookML correspondant à un champ de numéro de téléphone :

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

Si une intégration ne nécessite pas de tags, le sous-texte "L'action peut être utilisée avec n'importe quelle requête" s'affiche sur la page Actions du panneau Administration.

Veillez à identifier les champs obligatoires dans votre modèle LookML avec le paramètre tags, afin que vos utilisateurs puissent envoyer des données à l'aide du service.

Étape suivante

Découvrez comment diffuser le contenu d'une présentation ou d'une exploration ou d'un tableau de bord dans un service intégré.