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

Condivisione di dati tramite un hub azioni

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

Le azioni eseguite tramite un server hub azioni sono diverse dalle azioni sui dati, che sono definite dal parametro LookML action.

Questa pagina illustra le opzioni per creare azioni personalizzate che puoi richiedere di aggiungere all'hub azioni di Looker o 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 di Looker per uso pubblico.
Crea e pubblica un'azione personalizzata su un server hub azioni privato per uso privato.

Dopo aver aggiunto l'azione all'hub delle azioni, un amministratore di Looker può enable per l'utilizzo per l'invio di contenuti di Looker a questi servizi.

Puoi anche configurare più hub azioni se vuoi utilizzare le integrazioni di Looker tramite l'hub azioni di Looker e anche ospitare le tue azioni private o personalizzate. Le azioni per 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 Action di Looker e espone le azioni più utilizzate. Tutti i dati inviati dagli utenti mediante un'azione verranno elaborati temporaneamente sul server Action Hub di Looker anziché nell'istanza di Looker.

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

Requisiti di Looker Action Hub

Per utilizzare le integrazioni di Looker, l'hub azioni di Looker deve essere in grado di comunicare con l'istanza di Looker e soddisfare questi requisiti. Gli amministratori delle istanze ospitate dal cliente potrebbero dover prendere in considerazione altri fattori quando scelgono di abilitare le integrazioni di Looker da Looker Action Hub, in particolare le integrazioni che supportano i risultati trasmessi in streaming o che utilizzano OAuth.

L'hub azioni di Looker deve essere in grado di inviare e ricevere richieste API nei seguenti modi:

Dall'istanza di Looker alla rete dell'hub azioni di Looker
Dal browser dell'utente di Looker alla rete dell'hub azioni di Looker
Dalla rete dell'hub azioni di Looker all'istanza di Looker

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

Richieste dall'istanza di Looker alla rete dell'hub azioni di Looker

Le richieste a actions.looker.com vengono risolte 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 della pubblicità programmatica dell'azione.

Richieste dal browser dell'utente Looker alla rete dell'hub azioni di Looker

Il browser dell'utente di Looker deve essere in grado di effettuare richieste a questi endpoint dell'hub azioni di Looker (per OAuth):

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

dove name è il nome della pubblicità programmatica dell'azione.

Richieste dalla rete dell'hub azioni di Looker all'istanza di Looker

L'hub azioni di Looker deve effettuare richieste all'istanza di Looker per azioni che supportano risultati trasmessi in streaming o che utilizzano OAuth.

Un'azione di inserimento di flussi consente all'azione di consumare le 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 poiché 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 il seguente formato:

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

Questi URL vengono generati immediatamente 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 nella rete in cui si trova l'istanza di Looker.

L'hub azioni di Looker 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 abilitato la lista consentita IP devono aggiungere questi indirizzi IP per utilizzare qualsiasi azione che supporta i risultati trasmessi in streaming o utilizzi OAuth.

Considerazioni sulle istanze ospitate dal cliente

Per utilizzare le integrazioni di Looker, l'hub azioni di Looker deve essere in grado di comunicare con l'istanza di Looker e soddisfare questi requisiti. Questo non è sempre possibile con le istanze Looker ospitate dal cliente, per vari motivi. Se non è possibile comunicare bidirezionale tra l'hub azioni di Looker e l'istanza di Looker, quest'ultimo potrebbe presentare comportamenti imprevisti o indesiderati, come query sospese o azioni non disponibili.

Per risolvere il potenziale problema dell'impossibilità di comunicare con l'istanza di Looker nell'hub azioni di Looker, gli amministratori di Looker possono implementare una delle soluzioni riportate di seguito. La soluzione o combinazione di soluzioni appropriata dipende dall'architettura dell'istanza Looker:

Se l'istanza ospitata dal cliente non è risolvibile dall'hub azioni di Looker, ovvero l'hub azioni di Looker 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. Questa 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 sostituisce il nome host di alcuni URL di callback di Looker Action Hub specifici e li indirizza tramite un proxy inverso che ha public_host_url come nome risolvibile pubblicamente. Questo proxy inverso accetta le richieste solo dagli indirizzi IP in uscita statici per l'hub azioni di Looker. Gli amministratori di Looker che utilizzano questo metodo devono aggiungere alla lista consentita gli indirizzi IP in uscita da cui l'hub azioni di Looker 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 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 i risultati trasmessi in streaming o che utilizzano OAuth. Per risolvere il problema, gli amministratori di Looker devono aggiungere alla lista consentita gli indirizzi IP in uscita da cui l'hub azioni di Looker invia richieste all'istanza di Looker: 35.153.89.114, 104.196.138.163 e 35.169.42.87.
Se nessuna delle soluzioni sopra indicate è appropriata per l'architettura dell'istanza di Looker, gli amministratori di Looker possono eseguire il deployment di un hub di azioni ospitato dal cliente per tutte le azioni o solo per quelle che supportano i risultati trasmessi 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 Looker possa comunicare con quest'ultimo. Looker non consiglia tuttavia questa soluzione.

Un altro motivo per cui le azioni OAuth e di streaming potrebbero non essere utilizzabili su un'istanza 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 dell'hub azioni di Looker. Per visualizzare esempi di codice funzionale, controlla le azioni esistenti nel repository looker-open-source/actions in GitHub.

Puoi creare un'azione personalizzata:

Configurazione di un repository di sviluppo
Scrivere l'azione
Verificare l'azione
Pubblicazione e attivazione dell'azione nell'hub azioni di Looker o sul tuo server hub azioni privato.

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

Configurazione di un repository di sviluppo

L'hub azioni di Looker è un server Node.js scritto in TypeScript, un piccolo livello oltre al moderno codice JavaScript che aggiunge informazioni sul tipo per agevolare l'individuazione degli errori di programmazione. Se hai dimestichezza con JavaScript, probabilmente conosci la maggior parte del linguaggio TypeScript.

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

Node.js
Gestore delle versioni dei nodi (NVM, per selezionare la versione Node.js adeguata)
Yarn (per gestire le dipendenze)

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

Clona il repository looker-open-source/actions localmente:

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:

Un file README per spiegare lo scopo e i mezzi dell'autenticazione per l'azione
Icona PNG da visualizzare nell'hub azioni di Looker (o nell'hub delle azioni private sulla tua istanza di Looker) e nelle finestre di invio dei dati di Looker
Eventuali file per i test che vuoi eseguire sul codice di azione, che è diverso dal test dell'azione

Scrivere un'azione

Un requisito di progettazione per il server Looker Action Hub è che rimanga completamente stateless, quindi non è consentito archiviare qualsiasi informazione nell'applicazione o nel servizio di azione. Tutte le informazioni necessarie per completare l'azione devono essere fornite nelle chiamate di richiesta del file di azione.

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

I file di azioni si basano sul metodo API /execute. Le richieste dell'API Looker vengono passate da una 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. Esiste anche un metodo /form che può essere utilizzato per raccogliere informazioni aggiuntive dall'utente prima che venga eseguita l'azione. I campi specificati in /form verranno visualizzati nel popup Invia o Pianifica quando gli utenti selezionano l'azione come destinazione per la consegna dei dati.

Se utilizzi l'API Looker Action, il formato di questi parametri potrebbe apparire diverso.

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

Parametro	Obbligatorio	Descrizione	Tipo di dati
`name`	Sì	Un nome univoco per l'azione. Deve essere univoco in 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 dati a una destinazione di azione, puoi specificare un attributo utente per il quale l'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"` e `"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 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 include più voci, l'azione richiede più di un campo.	`RequiredField`
`supportedDownloadSettings`	No	Un valore booleano che determina se per l'azione verrà inviato un URL di download utilizzabile una sola volta 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 Può trasmettere risultati sì/no nell'elenco dei servizi integrati. Le azioni che trasmettono risultati in streaming possono richiedere la configurazione di un server hub azioni locale. Per ulteriori informazioni, consulta la pagina Configurazione di un hub azioni locale per azioni che utilizzano OAuth o flussi di dati per ulteriori informazioni.	Booleano
`minimumSupportedVersion`	No	La versione minima di Looker in cui verrà visualizzata l'azione nell'elenco di 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: azione che invia un'intera query. L'azione del segmento, ad esempio, è un'azione a livello di query.
Un'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 dimensioni o 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 controllare su quali campi del numero di telefono verrà visualizzata l'azione Twilio.
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.

Aggiungere attributi utente alle azioni personalizzate

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

Per aggiungere un attributo utente all'azione:

Un amministratore di Looker potrebbe dover creare l'attributo utente corrispondente a user_attribute_param, se non esiste già.
Definisci un valore valido per l'attributo utente per gli utenti o i gruppi di utenti che devono pubblicare contenuti nella 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:

  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 della sezione Utenti del riquadro Amministrazione, required: true indica che un utente deve avere definito per quell'attributo utente un valore valido e non null per vedere l'azione durante l'invio dei dati, mentre sensitive: true indica che l'attributo utente è criptato e non viene mai visualizzato nell'interfaccia utente di Looker una volta inserito. Puoi specificare più sottoparametri di attributi utente.

Esegui il deployment degli aggiornamenti sul server hub azioni.
- Se aggiungi una nuova azione, un amministratore di Looker dovrà abilitarla facendo clic sul pulsante Attiva accanto all'azione nella pagina Azioni del riquadro Amministrazione.
- Se stai aggiornando un'azione esistente, aggiorna l'elenco delle azioni facendo clic sul pulsante Aggiorna. Quindi, fai clic sul pulsante Impostazioni.
Nella pagina delle impostazioni o dell'attivazione delle azioni, un amministratore di Looker deve configurare i campi del modulo dell'azione per estrarre informazioni dall'attributo utente facendo clic sull'icona dell'attributo utente a destra del campo appropriato e selezionando l'attributo utente desiderato.

Parametri `requiredField` nelle azioni a livello di cella

Per le azioni a livello di cella, puoi configurare i campi LookML del modello in modo che forniscano dati a quella destinazione 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, prevale su `tag` e corrisponde a un campo contenente uno dei tag forniti.	string
`all_tags`	No	Se presente, prevale su `tag` e corrisponde a un campo contenente 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 oppure 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 su DataActionRequest.

Configurazione di un'azione per OAuth

Le azioni abilitate per OAuth non possono essere configurate dall'hub azioni di Looker per le istanze Looker in cui è abilitata la funzionalità Lista consentita IP o che non possono soddisfare i requisiti dell'hub azioni di Looker. Per saperne di più sulla configurazione di un'azione per OAuth, consulta la pagina di best practice Configurazione di un hub delle azioni locali per azioni che utilizzano OAuth o flussi di dati.

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

Flusso OAuth dell'azione Looker

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

Il flusso per la creazione di azioni in genere prevede 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 valore /form normale in conformità ai requisiti richiesti 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 in corso...

Looker invia una richiesta POST HTTP con un corpo vuoto all'endpoint ActionList. Se l'azione restituisce uses_oauth: true nella definizione, riceverà un valore state_url una tantum in ogni richiesta /form di Looker. state_url è un URL speciale monouso che imposta lo stato di un utente per una determinata azione.

Se l'utente non viene autenticato con l'endpoint, il /form restituito dovrebbe contenere un form_field di tipo oauth_link che va all'endpoint /oauth di un'azione. state_url deve essere criptato e salvato come parametro state nel campo 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 OauthUrl della casella personale.

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

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

Nell'endpoint /oauth viene anche creato un redirect_uri per l'hub delle azioni, che viene trasmesso al metodo oauthUrl(...) dell'azione. Questo 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 con il 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 file state_url criptato e lo utilizza per PUBBLICARE state in Looker. La volta successiva che un utente richiede l'azione in questione, lo stato appena salvato verrà inviato all'hub azioni di Looker.

Aggiunta dei file delle azioni al repository di Looker Action Hub

Dopo aver scritto il file delle azioni, nel repository di Looker Action Hub:

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 dei pacchetti Node.js che hai utilizzato per la scrittura dell'azione. Ad esempio:
```
yarn add aws-sdk
yarn add express
```
Installa le dipendenze Node.js del server Hub azioni di Looker.
```
yarn install
```
Esegui i test che hai scritto.

yarn test

Test di un'azione

Per il test completo, puoi provare a eseguire l'azione sull'istanza Looker ospitando un server hub azioni privato. Questo server deve essere 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 utilizzare una piattaforma basata su cloud, come Heroku, come mostrato nell'esempio seguente, oppure puoi utilizzare qualsiasi piattaforma che soddisfi i requisiti indicati in precedenza.

Configurazione di un server hub azioni locale

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

Per iniziare, crea il tuo 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
```
Ad esempio, per eseguire il push di un ramo a Heroku, configura il repository Git con Heroku come opzione remota nella riga di comando:
```
heroku login
heroku create
git push heroku
```
Heroku restituirà l'URL pubblico che ora ospita l'hub delle azioni per consentirti di utilizzarlo. Visita l'URL o esegui heroku logs per verificare che l'hub delle azioni sia in esecuzione. Se dimentichi l'URL pubblico, puoi eseguire il seguente comando 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 delle azioni:

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

Imposta l'etichetta dell'hub delle azioni:

heroku config:set ACTION_HUB_LABEL="Your Action Hub"

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

Se l'azione richiede il trasferimento di tipi specifici di dati da Looker, assicurati di configurare eventuali modelli per includere il parametro tags appropriato.

Ora è tutto pronto per testare la tua azione.

Test delle azioni a livello di dashboard e query

Se necessario, configura il modello LookML con i tag nell'istanza di Looker. Crea e salva un Look. Nel Look salvato, fai clic sul menu in alto a destra e seleziona Invia con l'azione come destinazione. Se hai un modulo da consegnare, Looker lo mostrerà nella finestra Inviato.

Fai clic su Invia test per inviare i dati. Lo stato dell'azione viene visualizzato nella Cronologia dello scheduler nel riquadro Amministrazione. Se si verifica un errore nell'azione, questo verrà visualizzato nel pannello 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. Trova il campo nella tabella di dati. Fai clic su … nella cella e seleziona … dal menu a discesa. Se si verificano errori, dovrai eseguire un aggiornamento completo della tabella dei 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 per le azioni private.
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.

Pubblicazione e attivazione di un'azione personalizzata

Sono disponibili due opzioni di pubblicazione per le azioni personalizzate:

Pubblicazione nell'hub azioni di Looker: questa azione rende l'azione disponibile a chiunque utilizzi Looker.
Pubblicazione su un server hub azioni privato: rende l'azione disponibile solo sull'istanza di Looker.

Dopo aver pubblicato l'azione, puoi attivarla dalla pagina Azioni nel pannello Amministrazione.

Pubblicazione nell'hub azioni di Looker

Questo è l'approccio più semplice e funziona per qualsiasi azione che vuoi rendere disponibile a chiunque utilizzi Looker.

Dopo che l'azione è stata testata, puoi inviare un PR al repository looker-open-source/actions in GitHub.

Inserisci questo comando:

git push <your fork> <your development branch>

Crea la tua 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, vedi Inviare 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 migliorarlo. Successivamente, uniamo il codice nel repository looker-open-source/actions e ne eseguiamo il deployment in actions.looker.com. Una volta eseguito il deployment, il codice sarà disponibile per tutti i clienti Looker.
Abilita l'azione nella tua istanza Looker, in modo che venga visualizzata come opzione per l'invio dei dati.

Pubblicazione su un server hub azioni private

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

Puoi configurare il server hub azioni interno sulla tua infrastruttura oppure utilizzando una piattaforma applicativa basata su cloud (il nostro esempio utilizza Heroku). Non dimenticare di creare un fork dell'hub azioni di Looker nel server hub azioni privato prima del deployment.

Configurazione di un modello LookML per l'utilizzo 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 tuo modello LookML.

La pagina Azioni nel riquadro Amministrazione fornisce informazioni sui tag eventualmente necessari per il servizio.

Ad esempio, l'integrazione di Zapier afferma che funziona con qualsiasi query. Non è necessario aggiungere il parametro tags a un campo del modello LookML.

Il servizio Twilio Send Message, tuttavia, invia un messaggio a un elenco di numeri di telefono. Richiede una query che includa un campo numero di telefono e utilizzi il parametro tags per identificare quale campo della query contiene numeri di telefono. Puoi identificare un campo del numero di telefono in LookML specificando tags: ["phone"] per quel campo. Il LookML del campo di un numero di telefono potrebbe avere il seguente aspetto:

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

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 caricare i contenuti di un Look o un'esplorazione o di una dashboard a un servizio integrato.