Tieni presente che stai visualizzando la documentazione di Looker. Per la documentazione di Looker Studio, visita https://support.google.com/looker-studio.

Questa pagina è stata tradotta dall'API Cloud Translation.

Condivisione di dati tramite un hub azioni

Oltre a pubblicare contenuti nelle destinazioni integrate di Looker, puoi utilizzare le azioni, denominate anche integrazioni, per distribuire contenuti a servizi di terze parti integrati con Looker tramite un server hub azioni.

Questa pagina illustra le opzioni a tua disposizione per la creazione di azioni personalizzate che puoi richiedere di aggiungere all'hub azioni di Looker o aggiungere al tuo server hub azioni privato. In questa pagina viene inoltre descritto come avviare un server hub azioni locale per testare le azioni personalizzate o eseguire un server hub azioni privato.

Per iniziare a utilizzare le azioni, puoi:

Utilizza le azioni esistenti di Looker disponibili nell'hub azioni di Looker.
Crea e pubblica un'azione personalizzata nell'hub azioni Looker per uso pubblico.
Crea e pubblica un'azione personalizzata su un server hub azioni privato per uso privato.

Una volta che l'azione viene aggiunta all'hub delle azioni, un amministratore di Looker può enable l'azione per l'utilizzo per il caricamento dei contenuti di Looker nei servizi in questione.

Puoi anche configurare più hub azioni se vuoi utilizzare le integrazioni di Looker tramite l'hub azioni di Looker e ospitare anche le tue azioni private o personalizzate. Le azioni relative a ciascun hub azioni vengono visualizzate nella pagina Azioni del riquadro Amministrazione.

Hub azioni di Looker

Looker ospita e fornisce Looker Action Hub, un server stateless che implementa l'API Looker's Action e espone le azioni più comuni. Tutti i dati che gli utenti inviano utilizzando un'azione verranno elaborati temporaneamente sul server Action Hub di Looker invece che nell'istanza di Looker.

Looker è già integrato con diversi servizi. Per informazioni su come abilitare i servizi esistenti, consulta la pagina della documentazione Impostazioni amministratore - Azioni.

Requisiti di Looker Action Hub

Looker Action Hub deve essere in grado di inviare e ricevere le richieste API nei seguenti modi:

Dall'istanza di Looker alla rete di Looker Action Hub
Dal browser dell'utente di Looker alla rete di Looker Action Hub
Dalla rete Looker Action Hub all'istanza di Looker

Se il deployment di Looker non è in grado di soddisfare queste richieste o se sulla tua istanza Looker è abilitata la funzionalità Lista consentita IP, valuta la possibilità di configurare un server hub azioni locale per gestire le integrazioni di Looker o le azioni personalizzate private. Gli amministratori delle istanze ospitate dal cliente possono anche eseguire il deployment di un server di azioni locale specifico per OAuth e azioni di flusso.

Richieste dall'istanza di Looker alla rete di Looker Action Hub

Le richieste a actions.looker.com si risolvono in un indirizzo IP dinamico. Le richieste in uscita dall'istanza di Looker devono poter raggiungere i seguenti endpoint:

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

dove name è il nome programmatico dell'azione.

Richieste dal browser dell'utente Looker alla rete Looker Action Hub

Il browser dell'utente di Looker deve essere in grado di effettuare richieste ai seguenti endpoint di Looker Action Hub (per OAuth):

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

dove name è il nome programmatico dell'azione.

Richieste dalla rete di Looker Action Hub all'istanza di Looker

L'hub azioni di Looker deve effettuare richieste all'istanza di Looker per azioni che supportano la trasmissione dei risultati in modalità flusso o che utilizzano OAuth.

Un'azione di flusso consente all'azione di consumare query che restituiscono tutti i risultati. Le azioni abilitate per OAuth utilizzano l'autenticazione per utente tramite i flussi OAuth 2.0. Le azioni OAuth devono archiviare le credenziali utente nell'istanza Looker di origine perché l'hub azioni di Looker è stateless e multi-tenant e non archivierà credenziali specifiche dell'utente di alcun tipo.

Le richieste dall'hub azioni di Looker a un'istanza di Looker hanno le seguenti forme:

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

Questi URL vengono generati sul posto nell'istanza di Looker prima di essere inviati all'hub azioni di Looker. Per questo motivo, l'hub azioni di Looker deve essere in grado di risolvere <host_looker_url> in un indirizzo IP e di effettuare richieste alla rete in cui risiede l'istanza di Looker.

Looker Action Hub ha indirizzi IP in uscita statici da cui provengono sempre le richieste: 35.153.89.114, 104.196.138.163 e 35.169.42.87. Gli amministratori delle istanze ospitate da Looker che hanno attivato la lista consentita degli IP devono aggiungere questi indirizzi IP per eseguire azioni che supportano la trasmissione dei risultati in modalità flusso o che utilizzano OAuth.

Considerazioni sulle istanze ospitate dal cliente

Per utilizzare le integrazioni di Looker, Looker Action Hub deve essere in grado di comunicare con l'istanza di Looker e soddisfare i requisiti dell'hub azioni di Looker. Ci sono vari motivi per cui ciò non è sempre possibile con le istanze Looker ospitate dal cliente. Se la comunicazione bidirezionale tra Looker Action Hub e l'istanza di Looker non è possibile, quest'ultimo potrebbe presentare un comportamento imprevisto o indesiderato, ad esempio per interrompere le query o eseguire azioni non disponibili.

Per risolvere il potenziale problema dell'impossibilità di comunicare con Looker Action Hub con l'istanza di Looker, gli amministratori di Looker possono implementare una delle soluzioni mostrate più avanti in questa pagina. La soluzione o la combinazione di soluzioni appropriata dipenderà dall'architettura dell'istanza di Looker:

Se l'istanza ospitata dal cliente non è risolvibile da Looker Action Hub, ovvero Looker Action Hub non può ricevere richieste dall'istanza di Looker, gli amministratori di Looker possono contattare un esperto delle vendite di Google Cloud per abilitare la funzionalità della licenza public_host_url. La funzionalità di licenza mostra l'opzione di avvio --public-host-url, che consente agli amministratori di specificare un nome host <public_host_url> risolvibile diverso dall'istanza <host_looker_url>. public_host_url esegue l'override del nome host per alcuni URL di callback di Looker Action Hub specifici e instrada questi URL di callback attraverso un proxy inverso che contiene public_host_url come nome risolvibile pubblicamente. Questo proxy inverso accetta richieste solo dagli indirizzi IP in uscita statici per Looker Action Hub. Gli amministratori di Looker che utilizzano questo metodo devono aggiungere alla lista consentita gli indirizzi IP in uscita da cui Looker Action Hub invia richieste all'istanza di Looker: 35.153.89.114, 104.196.138.163 e 35.169.42.87.
Se l'URL dell'istanza ospitata dal cliente è risolvibile dall'istanza di Looker, ma l'hub di azioni di Looker non può inviare richieste all'istanza di Looker, gli utenti potrebbero non essere in grado di configurare o utilizzare azioni che supportano la trasmissione dei risultati in modalità flusso o che utilizzano OAuth. Per risolvere il problema, gli amministratori di Looker devono aggiungere alla lista consentita gli indirizzi IP in uscita da cui Looker Action Hub invia le richieste all'istanza di Looker: 35.153.89.114, 104.196.138.163 e 35.169.42.87.
Se nessuna delle soluzioni sopra citate è appropriata per l'architettura delle istanze di Looker, gli amministratori di Looker possono eseguire il deployment di un hub azioni ospitato dal cliente per tutte le azioni o solo per le azioni che supportano la trasmissione di risultati in streaming o che utilizzano OAuth.
Per eseguire il deployment di un hub azioni ospitato dal cliente, devi assicurarti che il file JAR sia ospitato su un server pubblico in modo che l'hub azioni di Looker possa comunicare con questo hub. Questa soluzione, tuttavia, non è consigliata.

Inoltre, le azioni OAuth e di flusso potrebbero non essere utilizzabili su un'istanza di Looker ospitata dal cliente se l'istanza utilizza un certificato SSL emesso da un'autorità di certificazione (CA) non presente in questo elenco di certificati radice.

Creazione di un'azione personalizzata

Questa sezione descrive i passaggi da seguire per scrivere e testare un'azione personalizzata utilizzando il codice sorgente di Looker Action Hub. Per vedere esempi di codice funzionale, controlla le azioni esistenti nel repository looker-open-source/actions in GitHub.

Per creare un'azione personalizzata:

Configurazione di un repository di sviluppo
Scrittura dell'azione in corso.
Verificare l'azione.
Pubblicazione e abilitazione dell'azione nell'hub delle azioni di Looker o sul tuo server hub azioni privato

Come per qualsiasi azione, potresti dover configurare i modelli LookML con parametri specifici prima di poter utilizzare l'azione per caricare i dati.

Configurazione di un repository di sviluppo

Looker Action Hub è un server Node.js scritto in TypeScript, un piccolo livello sopra il moderno JavaScript che aggiunge informazioni sul tipo per aiutare a individuare gli errori di programmazione. Se hai familiarità con JavaScript, dovresti conoscere la maggior parte del linguaggio TypeScript.

L'esecuzione di Looker Action Hub richiede il software seguente:

Node.js
Gestore della versione del nodo (NVM: per selezionare la versione di Node.js corretta)
Yarn (per gestire le dipendenze)

Una volta installato il software richiesto, puoi configurare l'ambiente di sviluppo. L'esempio seguente utilizza Git.

Clona il repository looker-open-source/actions in locale:

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

Crea una directory con il nome dell'azione nella directory actions/src/actions. Ad esempio:
```
mkdir actions/src/actions/my_action
```
Inizia a completare la directory con i file necessari per eseguire l'azione. Consulta il repository GitHub delle azioni per una struttura di file di esempio.

Looker consiglia di aggiungere anche quanto segue:

Un file README per spiegare lo scopo e i mezzi di autenticazione per l'azione
Un'icona PNG da visualizzare nell'hub azioni di Looker (o nell'hub delle azioni privato sull'istanza di Looker) e nelle finestre di invio dei dati di Looker
Tutti i file per i test che vuoi eseguire sul codice di azione. Questo è diverso dal test dell'azione.

Scrivere un'azione

Un requisito di progettazione del server Looker Action Hub è che rimanga completamente stateless, pertanto non è consentito archiviare informazioni nell'applicazione o nel servizio dell'azione. Qualsiasi informazione necessaria per completare l'azione deve essere fornita nelle chiamate di richiesta del file delle azioni.

I contenuti esatti del file delle azioni variano a seconda del servizio, del tipo o del livello a cui opera l'azione e dei formati di dati o di visualizzazione da specificare. L'azione può anche essere configurata per i flussi di autorizzazione OAuth 2.0.

I file di azione si basano sul metodo API /execute. Le richieste dell'API Looker vengono passate a un DataActionRequest ogni volta che un utente esegue l'azione all'interno di Looker. DataActionRequest contiene tutti i dati e i metadati necessari per eseguire l'azione. È disponibile anche un metodo /form, che può essere utilizzato per raccogliere ulteriori informazioni dall'utente prima che esegua l'azione. I campi specificati in /form verranno visualizzati nel popup Invia o Pianificazione quando gli utenti selezionano l'azione come destinazione per l'invio dei dati.

Quando scrivi il file delle azioni, includi almeno i seguenti parametri contrassegnati come obbligatori nella definizione dell'azione:

Parametro	Obbligatorio	Descrizione	Tipo di dati
`name`	Sì	Un nome univoco per l'azione. Deve essere univoco per tutte le azioni nell'hub azioni di Looker.	string
`url`	Sì	Un URL assoluto dell'endpoint `/execute` per questa azione.	string
`label`	Sì	Un'etichetta leggibile per l'azione.	string
`supportedActionTypes`	Sì	Un elenco dei tipi di azioni supportati dall'azione. I valori validi sono `"cell"`, `"query"` e `"dashboard"`.	string
`formURL`	No	Un URL assoluto dell'endpoint `/form` per questa azione.	string
`description`	No	Descrizione dell'azione.	string
`params`	No	Array di `parameters` per l'azione. Includi il nome, l'etichetta e la descrizione in formato stringa per ogni parametro. Questi sono i campi che vengono visualizzati nella pagina di attivazione dell'azione nel riquadro Amministrazione. Per gestire il modo in cui gli utenti possono inviare i dati a una destinazione di un'azione, puoi specificare un attributo utente per il quale un utente deve avere un valore definito.	`parameters`
`supportedFormats`	No	Un elenco dei formati di dati supportati dall'azione. I valori validi sono `"txt"`, `"csv"`, `"inline_json"`, `"json"`, `"json_detail", "json_detail_lite_stream", "xlsx", "html", "wysiwyg_pdf", "assembled_pdf", and "wysiwyg_png".`	string
`supportedFormattings`	No	Un elenco di opzioni di formattazione supportate dall'azione. I valori validi sono `"formatted"` e `"unformatted"`.	string
`supportedVisualizationFormattings`	No	Un elenco di opzioni di formattazione di visualizzazione supportate dall'azione. I valori validi sono `"apply"` e `"noapply"`.	string
`iconName`	No	Un URI di dati che rappresenta un'immagine icona per l'azione.	string
`requiredFields`	No	Un elenco di descrizioni dei campi obbligatori con cui è compatibile questa azione. Se l'elenco contiene più voci, l'azione richiede più di un campo.	`RequiredField`
`supportedDownloadSettings`	No	Un valore booleano che determina se verrà inviato all'azione un URL di download monouso per facilitare lo streaming illimitato di dati. Il parametro viene impostato dal parametro `usesStreaming`, che è un valore booleano `true/false`. Se `usesStreaming = true`, allora `supportedDownloadSettings = url`. Se `usesStreaming = false`, allora `supportedDownloadSettings = push`.	Booleano
`usesOAuth`	No	Un valore booleano che determina se l'azione è un'azione OAuth. Questo determinerà se per l'azione verrà inviato un link monouso per poter impostare `state` per un utente specifico per questa azione.	Booleano
`usesStreaming`	No	Un valore booleano che determina se l'azione supporta i risultati delle query in streaming. Controlla la colonna Utilizza flusso di dati (Sì/No) nell'elenco dei servizi integrati. Le azioni che eseguono i flussi di risultati potrebbero richiedere la configurazione di un server hub azioni locale. Per ulteriori informazioni, consulta la pagina Configurare un hub di azioni locali per le azioni che utilizzano OAuth o streaming.	Booleano
`minimumSupportedVersion`	No	La versione minima di Looker in cui l'azione verrà visualizzata nell'elenco dell'hub azioni del riquadro Amministrazione.	string

Esempi di azioni di Looker Action Hub sono disponibili su GitHub come riferimento.

Tipi di azioni supportati

Looker supporta tre tipi di azioni, come specificato nel parametro supportedActionTypes dell'azione: query, cella e dashboard.

Un'azione a livello di query: si tratta di un'azione che invia un'intera query. L'azione del segmento, ad esempio, è un'azione a livello di query.
Azione a livello di cella: un'azione a livello di cella invia il valore di una singola cella specifica di una tabella di dati. Questo tipo di azione è diverso dalle azioni sui dati, che possono essere definite per le dimensioni o le misure utilizzando il parametro action. Per inviare informazioni da una cella specifica all'interno di una tabella, Looker utilizza i tag per mappare le azioni alle celle corrispondenti. Le azioni devono specificare quali tag supportano in requiredFields. Per mappare azioni e campi, i campi in LookML devono specificare a quali tag sono mappati con il parametro tags di LookML. Ad esempio, l'azione Twilio Message utilizza un tag phone per consentire agli sviluppatori LookML di stabilire su quali campi di numeri di telefono verrà visualizzata l'azione Twilio.
Un'azione a livello di dashboard:un'azione a livello di dashboard supporta l'invio dell'immagine di una dashboard. Ad esempio, l'azione SendGrid invia le immagini della dashboard via email.

Aggiunta di attributi utente alle azioni personalizzate

Per le azioni personalizzate, puoi aggiungere attributi utente nel parametro params del file delle azioni. Se il parametro è obbligatorio, ogni utente deve avere un valore per questo attributo definito nel proprio account utente o per un gruppo di utenti a cui appartiene, oltre all'send_to_integration autorizzazione, per poter visualizzare l'azione come opzione di destinazione quando vengono inviati o pianificati contenuti.

Per aggiungere un attributo utente alla tua azione:

Un amministratore di Looker potrebbe dover creare l'attributo utente che corrisponde a user_attribute_param se non esiste già.
Definisci un valore valido per l'attributo utente per gli utenti o i gruppi utenti che devono inviare contenuti alla destinazione dell'azione. Questi utenti devono disporre anche delle autorizzazioni send_to_integration.
Il parametro params rappresenta i campi del modulo che un amministratore di Looker deve configurare nella pagina di abilitazione dell'azione dall'elenco Azioni nel riquadro Amministrazione. Nel parametro params del file delle azioni, includi quanto segue:

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

dove user_attribute_name è l'attributo utente definito nel campo Nome della pagina Attributi utente nella sezione Utenti del riquadro Amministrazione, required: true significa che per un utente deve essere definito un valore valido e non nullo per vedere l'azione al momento della pubblicazione dei dati, mentre sensitive: true indica che l'attributo utente è criptato e non viene mai visualizzato nell'UI di Looker una volta inserito. Puoi specificare più sottoparametri di attributi utente.

Esegui il deployment degli aggiornamenti sul server hub azioni.
- Se stai aggiungendo una nuova azione, un amministratore di Looker dovrà attivarla facendo clic sul pulsante Abilita accanto all'azione nella pagina Azioni nel riquadro Amministrazione.
- Se stai aggiornando un'azione esistente, aggiorna l'elenco di azioni facendo clic sul pulsante Aggiorna. Quindi, fai clic sul pulsante Impostazioni.
Nella pagina delle impostazioni o dell'abilitazione delle azioni, un amministratore di Looker deve configurare i campi del modulo dell'azione in modo che vengano estratti le informazioni dall'attributo utente facendo clic sull'icona dell'attributo utente a destra del campo appropriato e selezionando l'attributo desiderato.

Parametri `requiredField` nelle azioni a livello di cella

Per le azioni a livello di cella, puoi configurare i campi LookML del modello per inviare i dati alla destinazione dell'azione specificando i tag supportati dall'azione nel parametro requiredFields del file delle azioni.

Parametro	Obbligatorio	Descrizione	Tipo di dati
`tag`	No	Se presente, corrisponde a un campo con questo tag.	string
`any_tag`	No	Se presente, sostituisce `tag` e corrisponde a un campo che contiene uno dei tag forniti.	string
`all_tags`	No	Se presente, sostituisce `tag` e corrisponde a un campo che contiene tutti i tag forniti.	string

Formati di dati supportati

La classe DataActionRequest definisce il formato di invio dei dati disponibile per l'utilizzo dell'azione. Per le azioni a livello di query, la richiesta conterrà un allegato che può essere in diversi formati. L'azione può specificare uno o più supportedFormats o consentire all'utente di scegliere il formato specificando tutti i formati possibili. Per le azioni a livello di cella, il valore della cella sarà presente in DataActionRequest.

Configurare un'azione per OAuth

Puoi configurare l'azione in modo che gli utenti possano autenticarsi nell'azione con OAuth. Anche se l'hub azioni di Looker deve rimanere stateless, puoi applicare in modo forzato uno stato tramite una richiesta di modulo dall'API Looker Action.

Flusso OAuth dell'azione di Looker

Per le azioni nell'hub azioni di Looker, puoi estendere un OAuthAction anziché un Hub.Action per impostare un valore booleano che indichi quali metodi OAuth sono necessari per autenticare un utente in un'azione. Per ogni azione abilitata per OAuth o abilitata per lo stato, Looker archivia uno stato per utente e per azione, in modo che ogni azione e combinazione di utenti abbia un evento OAuth indipendente.

Il flusso per la creazione di azioni di solito comporta una richiesta /form seguita da una richiesta /execute. Per OAuth, la richiesta /form deve avere un metodo per determinare se l'utente è autenticato all'interno del servizio di destinazione. Se l'utente è già autenticato, l'azione dovrebbe restituire un normale /form, in base a quanto richiesto dalla richiesta /execute. Se l'utente non è autenticato, l'azione restituisce un link che inizializza un flusso OAuth.

Salvataggio dello stato con l'URL OAuth

Looker invierà una richiesta POST HTTP con un corpo vuoto all'endpoint ActionList. Se l'azione restituisce uses_oauth: true nella sua definizione, verrà inviata un state_url monouso in ogni richiesta /form da Looker. state_url è un URL speciale utilizzabile una sola volta che imposta lo stato di un utente per una determinata azione.

Se l'utente non è autenticato con l'endpoint, il valore /form restituito deve contenere un valore form_field di tipo oauth_link che rimanda all'endpoint /oauth di un'azione. state_url deve essere criptato e salvato come parametro state nel oauth_url restituito. Ad esempio:

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

In questo esempio, l'endpoint /oauth reindirizza l'utente al server di autenticazione. L'endpoint /oauth crea il reindirizzamento nel metodo oauthUrl(...) su un'azione OAuth, come mostrato in Dropbox OauthUrl.

Il parametro state contenente il state_url criptato deve essere trasmesso all'hub azioni di Looker.

Salvataggio dello stato con l'URI di reindirizzamento dell'hub azioni

Nell'endpoint /oauth, viene creato anche un redirect_uri per l'hub delle azioni, che viene passato al metodo oauthUrl(...) dell'azione. redirect_uri è nel formato /actions/src/actions/my_maction/oauth_redirect ed è l'endpoint utilizzato se l'autenticazione restituisce un risultato.

Questo endpoint chiamerà il metodo oauthFetchInfo(...), che dovrebbe essere implementato dal metodo OauthAction per estrarre le informazioni necessarie e tentare di ricevere o salvare qualsiasi stato o auth ricevuto dal server di autenticazione.

state decripta il state_url criptato e lo utilizza per PUBBLICARE state su Looker. La volta successiva che un utente effettuerà una richiesta all'azione, lo stato appena salvato verrà inviato all'hub azioni di Looker.

Aggiunta dei file delle azioni al repository Action Hub di Looker

Una volta scritto il file delle azioni, nel repository dell'hub delle azioni di Looker:

Aggiungi il file delle azioni (ad esempio my_action.ts) a actions/src/actions/index.ts.
```
import "./my_action/my_action.ts"
```
Aggiungi eventuali requisiti del pacchetto Node.js utilizzati nella scrittura dell'azione. Ad esempio:
```
yarn add aws-sdk
yarn add express
```
Installa le dipendenze Node.js del server Looker Action Hub.
```
yarn install
```
Esegui i test che hai scritto.

yarn test

Test di un'azione

Per i test completi, puoi provare a eseguire un'azione sull'istanza di Looker ospitando un server hub azioni privato. Questo server deve trovarsi sulla rete internet pubblica con un certificato SSL valido e deve essere in grado di avviare e ricevere connessioni o richieste HTTPS da e verso Looker. A questo scopo, puoi usare una piattaforma basata su cloud come Heroku, come mostrato nell'esempio seguente. In alternativa, puoi utilizzare qualsiasi piattaforma che soddisfi i requisiti indicati sopra.

Configurazione di un server hub azioni locale

In questo esempio, eseguiremo l'azione che abbiamo sviluppato nel repository GitHub looker-open-source/actions/src/actions e eseguiremo il commit del codice su un nuovo ramo Git. Ti consigliamo di lavorare sulle caratteristiche utilizzando i rami in modo da poter monitorare facilmente il codice e, se vuoi, creare facilmente un PR con Looker.

Per iniziare, crea il ramo, quindi organizza ed esegui il commit del tuo lavoro. Ad esempio:
```
git checkout -b my-branch-name
git add file-names
git commit -m commit-message
```
In questo esempio, per eseguire il push di un ramo a Heroku, configura il tuo repository Git con Heroku come opzione remota nella riga di comando:
```
heroku login
heroku create
git push heroku
```
Heroku restituirà l'URL pubblico che ospita l'hub azione per il tuo utilizzo. Visita l'URL o esegui heroku logs per verificare che l'hub azioni è in esecuzione. Se dimentichi l'URL pubblico, puoi eseguire il comando seguente nella riga di comando:
```
heroku info -s | grep web_url
```
Heroku restituirà il tuo URL pubblico. Ad esempio: https://my-heroku-action-server-1234.herokuapp.com

Nella riga di comando, imposta l'URL di base dell'hub azioni:

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

Imposta l'etichetta dell'hub azioni:

heroku config:set ACTION_HUB_LABEL="Your Action Hub"

Looker utilizza un token di autorizzazione per connettersi all'hub di azioni. Genera il token nella riga di comando:
```
heroku run yarn generate-api-key
```
Se non usi Heroku, come in questo esempio, usa:
```
yarn generate-api-key
```
Heroku ti restituirà il token di autorizzazione. Ad esempio: Authorization: Token token="abcdefg123456789"
Imposta il secret dell'hub azioni utilizzando la chiave segreta:
```
heroku config:set ACTION_HUB_SECRET="abcdefg123456789"
```
Le implementazioni ospitate dal cliente potrebbero richiedere la configurazione di variabili di ambiente aggiuntive non documentate qui.
Aggiungi l'azione sull'istanza Looker locale da Amministrazione > Azioni.
- In fondo all'elenco delle azioni, fai clic su Aggiungi hub azioni.
- Inserisci l'URL dell'hub azioni e, facoltativamente, una chiave segreta.
- Individua l'azione nell'elenco Azioni nel menu Amministratore di Looker.
- Fai clic su Abilita.

Se la tua azione richiede il trasferimento di tipi specifici di dati da Looker, assicurati di configurare tutti i modelli in modo da includere il parametro tags appropriato.

Ora puoi testare l'azione.

Test delle azioni a livello di dashboard e di query

Nell'istanza di Looker, configura il modello LookML con i tag, se necessario. Creare e salvare un Look. Nel Look salvato, fai clic sul menu in alto a destra e seleziona Invia con la tua azione come destinazione. Se hai un modulo da inviare, Looker lo mostrerà nella finestra Inviati.

Fai clic su Send Test (Invia test) per inviare i dati. Lo stato dell'azione verrà visualizzato nella Cronologia scheduler del riquadro Amministrazione. Se si verifica un errore, l'azione verrà visualizzata nel riquadro Amministrazione e Looker invierà un'email con il messaggio di errore all'utente che ha inviato l'azione.

Test delle azioni a livello di cella

Configura un campo LookML con i tag appropriati per l'azione. Nell'istanza di Looker, esegui una query che includa quel campo. Individua il campo nella tabella di dati. Fai clic su … nella cella e seleziona … dal menu a discesa. Se ricevi errori, dovrai eseguire un aggiornamento completo della tabella di dati dopo averli risolti.

Se l'azione viene eseguita senza errori, puoi pubblicarla.
Se vuoi continuare a ospitare la tua azione privatamente, puoi pubblicarla nel tuo hub azioni privato.
Se vuoi pubblicare l'azione per l'utilizzo da parte di tutti i clienti di Looker, consulta la sezione Pubblicazione nell'hub azioni di Looker.

Pubblicare e attivare un'azione personalizzata

Sono disponibili due opzioni di pubblicazione per le azioni personalizzate:

Pubblicazione nell'hub azioni di Looker: l'azione viene resa disponibile a chiunque utilizzi Looker.
Pubblicazione su un server hub azioni privato: l'azione rende disponibile l'azione solo sulla tua istanza di Looker.

Una volta pubblicata l'azione, puoi attivarla dalla pagina Azioni nel riquadro Amministrazione.

Pubblicazione nell'hub azioni di Looker

Questo approccio è il più semplice ed è adatto a qualsiasi azione che vuoi rendere disponibile a chiunque utilizzi Looker.

Dopo aver testato l'azione, puoi inviare un PR al repository looker-open-source/actions in GitHub.

Inserisci questo comando:

git push <your fork> <your development branch>

Crea la richiesta di pull con il repository looker-open-source/actions come destinazione.
Compila il modulo di invio di Looker Marketplace e Action Hub. Per saperne di più sui requisiti del modulo, consulta Invio di contenuti a Looker Marketplace.

Looker esaminerà il tuo codice di azione. Ci riserviamo il diritto di rifiutare il tuo PR, ma possiamo aiutarti a risolvere eventuali problemi e offrirti suggerimenti per migliorare. Quindi, il codice viene unito al repository looker-open-source/actions ed eseguito il deployment in actions.looker.com. Una volta eseguito il deployment, il codice sarà disponibile per tutti i clienti di Looker.
Abilita l'azione nell'istanza di Looker in modo che venga visualizzata come opzione per la consegna dei dati.

Pubblicazione su un server hub azioni privato

Se hai azioni personalizzate private per la tua azienda o il tuo caso d'uso, non devi aggiungere la tua azione al repository looker-open-source/actions. Crea invece un hub azioni privato con lo stesso framework Node.js che hai utilizzato per testare l'azione.

Puoi configurare il server dell'hub delle azioni interno sulla tua infrastruttura o utilizzando una piattaforma applicativa basata su cloud (nell'esempio abbiamo utilizzato Heroku). Prima del deployment, ricordati di creare un fork di Looker Action Hub al server dell'hub delle azioni privato.

Configurazione di un modello LookML da utilizzare con un'azione

Per le azioni personalizzate e quelle disponibili nell'hub azioni di Looker, devi identificare i campi di dati pertinenti utilizzando il parametro tags nel modello LookML. La pagina Azioni del riquadro Amministrazione fornisce informazioni sugli eventuali tag richiesti per il servizio.

Ad esempio, un'integrazione Twilio Send Message invia un messaggio a un elenco di numeri di telefono. Nella pagina Azioni nel riquadro Amministrazione, l'integrazione mostra il sottotitolo "L'azione può essere utilizzata con le query con un campo con il tag phone".

Ciò significa che il servizio Twilio Send Message richiede una query che includa un campo per il numero di telefono e che utilizzi il parametro tags per identificare il campo della query che contiene numeri di telefono. Per identificare un campo del numero di telefono in LookML, devi specificare tags: ["phone"]. Il LookML per un campo del numero di telefono potrebbe avere il seguente aspetto:

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

Un'integrazione che non richiede tag mostrerà il sottotitolo "L'azione può essere utilizzata con qualsiasi query" nella pagina Azioni nel riquadro Amministrazione.

Assicurati di identificare tutti i campi obbligatori nel modello LookML con il parametro tags, in modo che gli utenti possano utilizzare il servizio per inviare dati.

Passaggi successivi

Scopri come inviare i contenuti di un Look o di un'esplorazione o di una dashboard a un servizio integrato.