Condivisione di dati tramite un hub azioni

Oltre a inviare contenuti alle destinazioni integrate di Looker, puoi utilizzare le azioni, denominate anche integrazioni, per fornire 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, 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 spiegato anche come avviare un server hub azioni locale per testare le azioni personalizzate o gestire un server hub azioni privato.

Per iniziare a utilizzare le azioni, puoi:

Una volta che l'azione è stata aggiunta all'hub delle azioni, un amministratore di Looker può attivarla per l'utilizzo dei contenuti Looker a questi servizi.

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

Hub azioni di Looker

Looker ospita e fornisce l'hub azioni di Looker, un server stateless che implementa l'API Looker's Action ed espone azioni popolari. Tutti i dati inviati dagli utenti mediante un'azione verranno elaborati temporaneamente sul server Hub azioni di Looker anziché nell'istanza di Looker.

Looker è già integrato con diversi servizi. Per informazioni su come attivare 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 di istanze ospitate dal cliente potrebbero dover prendere in considerazione fattori aggiuntivi quando scelgono di attivare le integrazioni di Looker dall'hub azioni di Looker, in particolare le integrazioni che supportano i risultati in streaming o che utilizzano OAuth.

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

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

Richieste dall'istanza di Looker alla rete 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 essere in grado di raggiungere questi 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 Hub Action di Looker

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

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

dove name è il nome programmatico dell'azione.

Richieste dalla rete Looker Action Hub all'istanza Looker

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

Un'azione di streaming 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 di Looker di origine, perché l'hub azioni di Looker è stateless e multi-tenant e non archivia alcuna credenziale specifica dell'utente.

Le richieste dall'hub di azioni 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 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 la tua istanza di Looker.

L'hub azioni di Looker dispone di 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 di istanze ospitate da Looker che hanno abilitato la lista consentita IP devono aggiungere questi indirizzi IP per utilizzare qualsiasi azione che supporti i risultati dello streaming o che utilizzano 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. Questa operazione non è sempre possibile con le istanze Looker ospitate dal cliente, per vari motivi. Se la comunicazione bidirezionale tra l'hub azioni di Looker e l'istanza di Looker non è possibile, l'hub azioni di Looker potrebbe presentare comportamenti imprevisti o indesiderati, ad esempio query sospese o azioni non disponibili.

Per risolvere il potenziale problema dell'hub di azioni Looker che non riesce a comunicare con l'istanza di Looker, gli amministratori di Looker possono implementare una delle soluzioni poste di seguito. La soluzione o la combinazione di soluzioni dipenderà dall'architettura dell'istanza di Looker:

  • Se l'istanza ospitata dal cliente non è risolvibile dall'hub azioni di Looker, ovvero non può ricevere richieste dall'istanza di Looker, gli amministratori di Looker possono consultare il proprio account manager Looker per attivare la funzionalità di licenza public_host_url. La funzionalità di licenza rivela l'opzione di avvio di --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 Hub di Looker Action specifici e instrada questi URL di callback attraverso un proxy inverso che ha public_host_url come nome risolvibile pubblicamente. Questo proxy inverso accetta richieste solo da indirizzi IP in uscita statici per Looker Action Hub. Gli amministratori Looker che utilizzano questo metodo devono aggiungere alla lista consentita gli indirizzi IP in uscita da cui l'hub azioni di Looker effettua richieste all'istanza 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 dello 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 effettua richieste all'istanza di Looker: 35.153.89.114, 104.196.138.163 e 35.169.42.87.

  • Se nessuna delle soluzioni indicate sopra è appropriata per l'architettura dell'istanza 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 i 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 Looker Action Hub possa comunicare con l'hub. Looker, tuttavia, non consiglia questa soluzione.

Un altro motivo per cui le azioni OAuth e di streaming potrebbero non essere utilizzabili su un'istanza di Looker ospitata dal cliente è se utilizza un certificato SSL emesso da un'autorità di certificazione (CA) non in questo elenco.

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 vedere esempi di codice funzionali, controlla le azioni esistenti nel repository looker-open-source/actions in GitHub.

Per creare un'azione personalizzata:

  1. Configura un repository di sviluppo
  2. Scrivere l'azione
  3. Test dell'azione
  4. Pubblicazione e abilitazione dell'azione: nell'hub delle azioni di Looker o sul tuo server hub azioni privato

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

Configurazione di un repository di sviluppo

L'hub azioni di Looker è un server Node.js scritto in TypeScript, un piccolo livello sopra il moderno JavaScript che aggiunge informazioni sul tipo per aiutare a rilevare gli errori di programmazione. Se hai familiarità con JavaScript, gran parte del linguaggio TypeScript dovrebbe esserti familiare.

Per eseguire Looker Action Hub sono necessari i seguenti software:

  • Node.js
  • Gestore delle versioni dei nodi (NVM: per selezionare la versione di Node.js corretta)
  • Gomitolo (per gestire le dipendenze)

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

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

    git clone git@github.com:looker-open-source/actions.git
    
  2. Crea una directory con il nome dell'azione nella directory actions/src/actions. Ad esempio:

    mkdir actions/src/actions/my_action
    
  3. Inizia a completare la directory con i file necessari per eseguire l'azione. Consulta il repository GitHub azioni per un esempio di struttura di file.

Looker consiglia di aggiungere anche:

  • Un file README per spiegare lo scopo e i mezzi di autenticazione per l'azione
  • Icona PNG da visualizzare nell'hub azioni di Looker (o nell'hub di azione privato sull'istanza di Looker) e nelle finestre di invio dei dati di Looker
  • I file per i test che vuoi eseguire sul codice di azione, diversi da quelli per testare l'azione.

Scrivere un'azione

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

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

I file delle azioni si basano sul metodo API /execute. Le richieste API Looker vengono trasmesse a DataActionRequest ogni volta che un utente esegue l'azione all'interno di Looker. L'elemento 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 esegua l'azione. I campi specificati nella /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 essere diverso.

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

Parametro Obbligatoria Descrizione Tipo di dati
name Un nome univoco per l'azione. Deve essere univoco per tutte le azioni nell'hub azioni di Looker. string
url Un URL assoluto dell'endpoint /execute per questa azione. string
label Un'etichetta leggibile per l'azione. string
supportedActionTypes Un elenco dei tipi di azione 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 abilitazione 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 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 delle opzioni di formattazione supportate dall'azione. I valori validi sono "formatted" e "unformatted". string
supportedVisualizationFormattings No Un elenco delle 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 delle 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 all'azione verrà inviato un URL di download una tantum per facilitare lo streaming illimitato dei dati. Il parametro è 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. Determina se all'azione verrà inviato un link monouso per poter impostare l'azione state per un utente specifico. Booleano
usesStreaming No Un valore booleano che determina se l'azione supporta risultati di query in streaming. Seleziona la colonna Can Stream Results Yes/No nell'elenco dei servizi integrati. Le azioni relative ai flussi di risultati potrebbero richiedere la configurazione di un server hub azioni locale. Per ulteriori informazioni, consulta la pagina Best practice per la configurazione di un hub azioni locale per le azioni che utilizzano OAuth o lo streaming. Booleano
minimumSupportedVersion No La versione minima di Looker in cui l'azione verrà visualizzata nell'elenco dell'hub di azioni del amministratore. string

Esempi di azioni dell'hub azioni di Looker sono su GitHub come riferimento.

Tipi di azioni supportate

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

  • Un'azione a livello di query: è un'azione che invia un'intera query. L'azione 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 in 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 i tag supportati in requiredFields. Per mappare le azioni e i campi, i campi in LookML devono specificare a quali tag sono mappati con il parametro tags 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à visualizzato 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 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 loro account utente o per un gruppo di utenti a cui appartiene, oltre all'autorizzazione send_to_integration, per visualizzare l'azione come opzione di destinazione quando invia o pianifica contenuti.

Per aggiungere un attributo utente all'azione:

  1. Se non esiste già, un amministratore di Looker potrebbe dover creare l'attributo utente corrispondente all'oggetto user_attribute_param.
  2. Definisci un valore valido per l'attributo utente per gli utenti o i gruppi di utenti che devono inviare i contenuti alla destinazione dell'azione. Questi utenti devono disporre anche di send_to_integration autorizzazioni.
  3. 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 nella pagina Attributi utente della sezione Utenti del riquadro Amministratore, required: true significa che un utente deve avere un valore non nullo e valido definito per quell'attributo utente per vedere l'azione quando invia i dati e sensitive: true significa che l'attributo utente è criptato e non viene mai visualizzato nell'interfaccia utente di Looker una volta inserito. Puoi specificare più sottoparametri attributo utente.

  1. Eseguire il deployment degli aggiornamenti sul server hub azioni.
    • Per aggiungere una nuova azione, è necessario che un amministratore Looker la abiliti facendo clic sul pulsante Enable (Attiva) in corrispondenza dell'azione nella pagina Actions (Azioni) nel riquadro Admin (Amministrazione).
    • Se stai aggiornando un'azione esistente, aggiorna l'elenco delle azioni facendo clic sul pulsante Aggiorna. Quindi, fai clic sul pulsante Impostazioni.
  2. 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 sulla relativa icona a destra del campo appropriato e selezionando l'attributo utente desiderato.

requiredField parametri nelle azioni a livello di cella

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

Parametro Obbligatoria 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 con uno qualsiasi dei tag forniti. string
all_tags No Se presente, sostituisce tag e corrisponde a un campo con tutti i tag forniti. string

Formati di dati supportati

La classe DataActionRequest definisce il formato di invio dei dati disponibile per l'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 il giorno DataActionRequest.

Configurare un'azione per OAuth

Le azioni abilitate per OAuth non possono essere configurate dall'hub azioni di Looker per le istanze Looker per cui è abilitata la funzionalità Lista consentita IP o che non sono in grado di soddisfare i requisiti dell'hub azioni di Looker. Per saperne di più sulla configurazione di un'azione per OAuth, consulta la pagina Best practice per la configurazione di un'azione locale per le azioni che utilizzano OAuth o per lo streaming.

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

Flusso OAuth dell'azione di Looker

Per le azioni nell'hub azioni di Looker, puoi estendere OAuthAction invece di Hub.Action per impostare un valore booleano che indichi i metodi OAuth necessari per autenticare un utente in un'azione. Per ogni azione attivata da OAuth o abilitata per stato, Looker archivia uno stato per utente e per azione, in modo che ogni combinazione di azione e 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 normale /form in base a quanto richiesto dalla richiesta di /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 HTTP POST con un corpo vuoto all'endpoint ActionList. Se l'azione restituisce uses_oauth: true nella sua definizione, quest'ultima riceverà un state_url una tantum in ogni richiesta /form di Looker. state_url è un URL speciale che può essere utilizzato una sola volta e che imposta lo stato di un utente su una determinata azione.

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

Il parametro state contenente quella state_url criptata deve essere passato all'hub azioni di Looker.

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

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

Questo endpoint chiama il metodo oauthFetchInfo(...), che deve 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.

L'elemento state decripta state_url criptato e lo utilizza per POSTARE state di nuovo a Looker. La volta successiva che un utente effettua una richiesta a questa azione, lo stato appena salvato verrà inviato all'hub azioni di Looker.

Aggiunta dei file di azione al repository Hub azioni di Looker

Una volta scritto il file dell'azione, nel repository Hub azioni di Looker:

  1. Aggiungi il file dell'azione (ad esempio my_action.ts) a actions/src/actions/index.ts.

    import "./my_action/my_action.ts"
    
  2. Aggiungi eventuali requisiti del pacchetto Node.js che hai utilizzato per la scrittura dell'azione. Ad esempio:

    yarn add aws-sdk
    yarn add express
    
  3. Installare le dipendenze Node.js del server Hub azioni di Looker.

    yarn install
    
  4. Esegui test che hai scritto.

yarn test

Testare un'azione

Per un test completo, puoi provare a eseguire la tua azione contro l'istanza di Looker ospitando un server hub azioni privato. Questo server deve essere su una 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 di seguito, oppure qualsiasi piattaforma che soddisfi i requisiti riportati sopra.

Configurazione di un server hub azioni locale

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

  1. Per iniziare, crea la tua filiale, quindi metti in scena e sottoponi a commit il tuo lavoro. Ad esempio:

    git checkout -b my-branch-name
    git add file-names
    git commit -m commit-message
    
  2. Per questo 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
    
  3. Heroku restituirà l'URL pubblico che ospita l'hub di azione. Visita l'URL o esegui heroku logs per confermare che l'hub azioni è in esecuzione. Se dimentichi l'URL pubblico, dalla riga di comando puoi eseguire il seguente comando:

    heroku info -s | grep web_url
    

    Heroku restituirà il tuo URL pubblico. Ad esempio: https://my-heroku-action-server-1234.herokuapp.com

  4. 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"
    
  5. Imposta l'etichetta dell'hub di azione:

    heroku config:set ACTION_HUB_LABEL="Your Action Hub"
    
  6. Looker utilizza un token di autorizzazione per connettersi all'hub delle azioni. Genera il token dalla riga di comando:

    heroku run yarn generate-api-key
    

    Se non utilizzi Heroku, come in questo esempio, utilizza:

    yarn generate-api-key
    

    Heroku restituirà il tuo token di autorizzazione. Ad esempio: Authorization: Token token="abcdefg123456789"

  7. Imposta il secret dell'hub di azione 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.

  8. Aggiungi l'azione sull'istanza di Looker locale in Amministrazione > Azioni.

    • Fai clic su Aggiungi hub azioni in fondo all'elenco di azioni.
    • Inserisci l'URL hub azioni e, facoltativamente, una chiave segreta.
    • Puoi trovare l'azione nell'elenco Azioni nel menu Amministrazione di Looker.
    • Fai clic su Attiva.

Se la tua azione richiede che Looker mostri determinati tipi di dati, assicurati di configurare qualsiasi modello in modo da includere il parametro tags appropriato.

Ora puoi testare l'azione.

Verificare le azioni a livello di dashboard e di query

Nell'istanza di Looker, configura il modello LookML con i tag, se necessario. Crea e salva un look. Nell'aspetto salvato, fai clic sul menu in alto a destra e seleziona Invia come azione come destinazione. Se hai un modulo per la consegna, Looker lo visualizzerà nella finestra Posta inviata.

Fai clic su Invia test per inviare i dati. Lo stato dell'azione verrà visualizzato in Cronologia dello scheduler nel riquadro Amministrazione. Se la tua azione rileva un errore, verrà mostrata nel riquadro Amministrazione e Looker invierà un'email con il messaggio di errore all'utente che l'ha inviata.

Verificare le azioni a livello di cella

Imposta un campo LookML con i tag corretti per l'azione. Nell'istanza di Looker, esegui una query che includa questo campo. Trova il campo nella tabella dati. Fai clic su ... nella cella e seleziona Invia dal menu a discesa. Se ricevi errori, devi aggiornare completamente la tabella dei dati dopo averli risolti.

Pubblicazione e abilitazione di un'azione personalizzata

Esistono due opzioni di pubblicazione per le azioni personalizzate:

Dopo aver pubblicato 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 mettere a disposizione di chiunque utilizzi Looker.

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

  1. Inserisci questo comando:

    git push <your fork> <your development branch>
    
  2. Crea la richiesta di pull con il repository looker-open-source/actions come target.

  3. Compila il modulo di invio di Looker Marketplace e Action Hub. Per ulteriori informazioni sui requisiti del modulo, vedi 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 qualsiasi problema tu possa riscontrare e offrirti suggerimenti per il miglioramento. 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 diventerà disponibile per tutti i clienti Looker.

  4. Attiva l'azione nell'istanza di Looker in modo che venga visualizzata come opzione per la distribuzione dei dati.

Pubblicazione su un server hub azioni privato

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

Puoi configurare il server hub azioni interno sulla tua infrastruttura o utilizzare una piattaforma applicativa basata su cloud (il nostro esempio ha utilizzato 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 da utilizzare con un'azione

Per le azioni personalizzate e le azioni disponibili dall'hub azioni di Looker, devi identificare i campi di dati pertinenti utilizzando il parametro tags nel modello LookML.

La pagina Azioni nel riquadro Amministrazione fornisce informazioni sui tag richiesti per il servizio, se disponibili.

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

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

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

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

Invio dei dati con un'azione

I dati possono essere inviati con modalità diverse, a seconda del livello a cui opera l'azione. Le azioni operano a livello di campo, query o dashboard e possono agire su uno o più livelli. Ogni azione elencata nella pagina Azioni del riquadro Amministratore contiene una descrizione di come viene utilizzata. Puoi:

Invio dei dati della cella

Le azioni a livello di campo sono indicate nella pagina Azioni del riquadro Amministratore da una descrizione che include "L'azione può essere utilizzata con i campi" o con un nella colonna Può utilizzare dai campi nell'elenco dei servizi integrati.

Le azioni a livello di campo sono progettate per inviare una cella di dati al servizio specificato. Il funzionamento è simile a quello delle azioni sui dati, con la differenza che le azioni vengono eseguite tramite l'API Action di Looker. Anziché definire un parametro LookML action per una dimensione o una misura, devi configurare il tuo modello LookML codificando i campi pertinenti con le informazioni fornite nella colonna Tag per questa azione nell'elenco dei servizi integrati.

Dopo aver abilitato il servizio e il tagging dei campi nel modello LookML, puoi:

  1. Visualizza i dati che desideri inviare in un look, una dashboard o un'esplorazione. Se il servizio specifica "Action can be used with queries that have a field taggato..." (Azione utilizzabile con le query che hanno un campo taggato), la tua query o uno dei riquadri della dashboard deve includere uno o più campi con gli eventuali tag richiesti.

  2. Il campo taggato in ciascuna cella del look, del riquadro della dashboard o dell'esplorazione contiene un elenco a discesa, indicato dai puntini di sospensione (...). Fai clic sui puntini di sospensione per visualizzare le azioni disponibili per il link.

  3. Nella sezione AZIONI, fai clic sul servizio che desideri ricevere per i dati di riga.

Invio dei dati della dashboard o delle query

Le azioni a livello di query sono indicate nella pagina Azioni del riquadro Amministratore da una descrizione che include "L'azione può essere utilizzata con le query che hanno un campo taggato..." o "L'azione può essere utilizzata con qualsiasi query". In base alla colonna Può inviare o pianificare nell'elenco dei servizi integrati, puoi pubblicare Ogni riga (in un look o un'esplorazione). Le azioni a livello di query sono progettate per fornire i risultati completi della query da Explore o Look al servizio specificato.

Le azioni a livello di dashboard sono indicate nella pagina Azioni del riquadro Amministratore da una descrizione che include "L'azione può essere utilizzata con qualsiasi dashboard". In base alla colonna Può inviare o pianificare nell'elenco dei servizi integrati, puoi inviare una dashboard. Le azioni a livello di dashboard sono progettate per inviare una dashboard al servizio specificato.

Abilitare il servizio e, se necessario, taggare i campi nel modello LookML.

Per caricare Look o esplorazioni, consulta la pagina della documentazione Pubblicazione di Look ed esplorazioni.

Per distribuire le dashboard, consulta le pagine della documentazione Pubblicazione di dashboard precedenti e Pianificazione e invio di dashboard.