Condivisione di dati tramite un hub delle azioni

Oltre a inviare contenuti alle destinazioni predefinite di Looker, puoi usare le azioni, denominate anche integrazioni, per fornire contenuti a servizi di terze parti integrati con Looker, tramite un server hub azioni.

In questa pagina vengono illustrate le opzioni disponibili per la creazione di azioni personalizzate, che puoi chiedere di aggiungere all'hub azioni di Looker o aggiungere al tuo server hub azioni privato. In questa pagina viene spiegato anche come avviare un server hub azioni locale, per testare le tue azioni personalizzate o gestire 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.
• Creazione e pubblicazione di un'azione personalizzata in un server hub azioni privato per uso privato.

Una volta aggiunta l'azione all'hub azioni, un amministratore di Looker può abilitarla per l'utilizzo durante l'invio di 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 Amministrazione.

Hub azioni di Looker

Looker ospita e fornisce l'hub azioni di Looker, un server stateless che implementa l'API Actions di Looker ed espone le azioni più comuni. Tutti i dati inviati dagli utenti utilizzando un'azione verranno elaborati temporaneamente sul server dell'hub azioni di Looker anziché nella tua istanza di Looker.

Looker è già integrato con diversi servizi. Consulta la pagina di documentazione Impostazioni di amministrazione - Azioni per scoprire come attivare questi servizi esistenti.

Requisiti dell'hub azioni di Looker

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 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 di indirizzi IP è abilitata nella tua istanza di Looker, valuta la possibilità di configurare un server hub azioni locale per gestire le integrazioni di Looker private o le azioni personalizzate. Gli amministratori delle istanze ospitate dal cliente possono anche implementare un server azioni locale specificamente per le azioni di streaming e OAuth.

Richieste dall'istanza 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 Looker devono essere in grado di 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 dell'hub azioni di Looker

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

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

dove name è il nome programmatico 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 le azioni che supportano i risultati in streaming o che utilizzano OAuth.

Un'azione di streaming consente di utilizzare 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é Looker Action Hub è stateless e multi-tenant e non memorizza credenziali specifiche dell'utente di alcun tipo.

Le richieste dall'hub azioni di Looker a un'istanza di Looker hanno i seguenti formati:

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 momento nell'istanza di Looker prima di essere inviati all'hub azioni di Looker. Per questo motivo, l'Action Hub di Looker deve essere in grado sia di risolvere <host_looker_url> in un indirizzo IP sia di effettuare richieste nella rete in cui si trova l'istanza di Looker.

L'Action Hub di Looker ha indirizzi IP di 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 di indirizzi IP devono aggiungere questi indirizzi IP per utilizzare le azioni che supportano i risultati in streaming o che utilizzano OAuth.

Considerazioni per le 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 i requisiti dell'hub azioni di Looker. Per vari motivi, questo non è sempre possibile con le istanze Looker ospitate dal cliente. Se la comunicazione bidirezionale tra l'hub azioni di Looker e l'istanza di Looker non è possibile, l'hub azioni di Looker potrebbe mostrare un comportamento imprevisto o indesiderato, ad esempio query bloccate o azioni non disponibili.

Per risolvere il potenziale problema di mancata comunicazione tra l'Action Hub di Looker e 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 dipende dall'architettura dell'istanza di 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 Looker, gli amministratori di Looker possono contattare uno specialista delle vendite di Google Cloud per attivare la funzionalità di licenza public_host_url. Questa funzionalità della licenza rivela l'opzione di avvio --public-host-url, che consente agli amministratori di specificare un nome host <public_host_url> risolvibile diverso da <host_looker_url> dell'istanza. public_host_url esegue l'override del nome host per alcuni URL di callback di Looker Action Hub e li indirizza tramite un proxy inverso che ha public_host_url come nome risolvibile pubblicamente. Questo proxy inverso accetta richieste solo dagli indirizzi IP statici in uscita 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 effettua 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 in streaming o che utilizzano OAuth. Per risolvere il problema, gli amministratori di Looker devono aggiungere alla lista consentita gli indirizzi IP di uscita da cui Looker Action Hub effettua richieste all'istanza di Looker: 35.153.89.114, 104.196.138.163 e 35.169.42.87.

• Se nessuna delle soluzioni sopra menzionate è adatta all'architettura dell'istanza di Looker, gli amministratori di Looker possono implementare un hub azioni ospitato dal cliente per tutte le azioni o solo per quelle 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 l'hub azioni di Looker possa comunicare con esso. Tuttavia, questa soluzione non è consigliata.

Inoltre, le azioni OAuth e di streaming potrebbero non essere utilizzabili in 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 dell'hub azioni di Looker. Per visualizzare esempi di codice funzionali, controlla le azioni esistenti nel repository looker-open-source/actions in GitHub.

Puoi creare un'azione personalizzata:

1. Configurazione di un repository di sviluppo
2. Scrivere l'azione
3. Test dell'azione
4. Pubblicazione e attivazione dell'azione, nell'hub azioni di Looker o sul tuo server hub azioni privato

Come per qualsiasi azione, potrebbe essere necessario configurare i modelli LookML con parametri specifici prima di poter utilizzare l'azione per distribuire i dati.

Configurazione di un repository di sviluppo

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

Per eseguire Looker Action Hub è necessario il seguente software:

• Node.js
• Node Version Manager (NVM) per selezionare la versione corretta di Node.js
• Yarn (per gestire le dipendenze)

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

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

   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 compilare la directory con i file necessari per eseguire l'azione. Per un esempio di struttura dei file, consulta il repository GitHub delle azioni.

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 azioni privato nella tua istanza di Looker) e nelle finestre di distribuzione dei dati di Looker
• Qualsiasi file per i test che vuoi eseguire sul codice dell'azione. Questo è diverso dal test dell'azione.

Scrivere un'azione

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

Il contenuto esatto del file di azione varia a seconda del servizio, del tipo o del livello a cui opera l'azione e dei formati di dati o visualizzazione da 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. Alle richieste dell'API Looker viene trasmesso un DataActionRequest ogni volta che un utente esegue l'azione in 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 informazioni aggiuntive dall'utente prima che esegua l'azione. I campi specificati in /form verranno visualizzati nel popup Invia o Pianifica quando gli utenti selezionano l'azione come destinazione per la distribuzione dei dati.

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

Gli esempi delle azioni dell'hub azioni di Looker 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 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 azioni e campi, i campi in LookML devono specificare a quali tag sono mappati con il parametro LookML tags. Ad esempio, l'azione Messaggio Twilio utilizza un tag phone in modo che gli sviluppatori LookML possano controllare in quali campi del numero di telefono verrà visualizzata l'azione Twilio.
• Un'azione a livello di dashboard:un'azione a livello di dashboard supporta l'invio di un'immagine di una dashboard. Ad esempio, l'azione SendGrid invia le immagini della dashboard tramite email.

Aggiunta di attributi utente alle azioni personalizzate

Per le azioni personalizzate, puoi aggiungere attributi utente nel parametro params del file di azione. 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'autorizzazione send_to_integration, per visualizzare l'azione come opzione di destinazione quando invia o pianifica i contenuti.

Per aggiungere un attributo utente all'azione:

1. Un amministratore di Looker potrebbe dover creare l'attributo utente corrispondente a user_attribute_param se non esiste già.
2. 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.
3. Il parametro params rappresenta i campi del modulo che un amministratore di Looker deve configurare nella pagina di attivazione dell'azione dall'elenco Azioni nel riquadro Amministrazione. Nel parametro params del file di 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 pannello Amministrazione, required: true indica che un utente deve avere un valore valido e non nullo definito per l'attributo utente per visualizzare l'azione durante la distribuzione dei dati e 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 degli attributi utente.

1. Esegui il deployment degli aggiornamenti sul server dell'hub delle azioni.
   • Se stai aggiungendo una nuova azione, un amministratore di Looker dovrà attivarla facendo clic sul pulsante Attiva accanto all'azione nella pagina Azioni del pannello 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/attivazione dell'azione, un amministratore di Looker deve configurare i campi del modulo dell'azione per estrarre le 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 per inviare i dati alla destinazione dell'azione specificando i tag supportati dall'azione nel parametro requiredFields del file di azione.

Formati di dati supportati

La classe DataActionRequest definisce il formato di distribuzione 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 in DataActionRequest.

Configurazione di 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 uno stato tramite una richiesta di modulo dall'API Looker Action.

Flusso OAuth dell'azione di Looker

Per le azioni in Looker Action Hub, 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 per lo stato, Looker memorizza 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 nel servizio di destinazione. Se l'utente è già autenticato, l'azione deve restituire un /form normale in base a quanto richiesto dalla richiesta /execute. Se l'utente non è autenticato, l'azione restituisce un link che inizializzerà 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, a ogni richiesta /form da Looker verrà inviato un state_url monouso. L'state_url è un URL speciale monouso che imposta lo stato di un utente per una determinata azione.

Se l'utente non è autenticato con l'endpoint, il /form restituito deve contenere un form_field di tipo oauth_link che rimanda all'endpoint /oauth di un'azione. Il 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(...) in un'azione OAuth, come mostrato in Dropbox OauthUrl.

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

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

Nell'endpoint /oauth viene creato e passato al metodo oauthUrl(...) dell'azione anche un redirect_uri per l'hub delle azioni. Questo redirect_uri ha il 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 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.

state decripta state_url criptato e lo utilizza per inviare 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.

Aggiungere i file di azione al repository dell'hub azioni di Looker

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

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

   import "./my_action/my_action.ts"
   

2. Aggiungi tutti i requisiti dei pacchetti Node.js che hai utilizzato per scrivere l'azione. Ad esempio:

   yarn add aws-sdk
   yarn add express
   

3. Installa le dipendenze Node.js del server dell'hub azioni di Looker.

   yarn install
   

4. Esegui i test che hai scritto.

yarn test

Testare un'azione

Per un test completo, puoi provare la tua azione rispetto alla tua istanza di Looker ospitando un server hub azioni privato. Questo server deve trovarsi su internet pubblico 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 sul cloud come Heroku, come mostrato nell'esempio seguente. In alternativa, puoi utilizzare qualsiasi piattaforma che soddisfi i requisiti sopra indicati.

Configurare un server hub azioni locali

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

1. Per iniziare, crea il branch, quindi esegui lo staging e il commit del 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 su 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 ora ospita l'hub delle azioni per il tuo utilizzo. 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à l'URL pubblico. Ad esempio: https://my-heroku-action-server-1234.herokuapp.com

4. Nella riga di comando, imposta l'URL di base dell'action hub:

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

5. Imposta l'etichetta dell'hub delle azioni:

   heroku config:set ACTION_HUB_LABEL="Your Action Hub"
   

6. Looker utilizza un token di autorizzazione per connettersi all'hub azioni. Genera il token nella riga di comando:

   heroku run yarn generate-api-key
   

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

   yarn generate-api-key
   

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

7. Imposta il secret dell'action hub 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 all'istanza locale di Looker andando su Amministrazione > Azioni.

   • In fondo all'elenco delle azioni, fai clic su Aggiungi hub delle azioni.
   • Inserisci l'URL dell'Action Hub e, facoltativamente, una chiave segreta.
   • Trova l'azione nell'elenco Azioni nel menu Amministrazione di Looker.
   • Fai clic su Attiva.

Se l'azione richiede il trasferimento di tipi specifici di dati da Looker, assicurati di configurare i modelli in modo che includano il parametro tags appropriato.

Ora puoi testare l'azione.

Test delle azioni a livello di dashboard e di query

Nella tua istanza di Looker, configura il modello LookML con i tag, se necessario. 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 per la distribuzione, Looker lo visualizzerà nella finestra Inviati.

Fai clic su Invia test per inviare i dati. Lo stato dell'azione verrà visualizzato nella cronologia dello scheduler nel riquadro Amministrazione. Se l'azione genera un errore, questo verrà visualizzato nel pannello Amministratore e Looker invierà un'email con il messaggio di errore all'utente che ha inviato l'azione.

Testare le azioni a livello di cella

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

• Se l'azione viene pubblicata senza errori, puoi pubblicarla.
• Se vuoi continuare a ospitare la tua azione in privato, 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 relativa alla 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: in questo modo, l'azione è disponibile per chiunque utilizzi Looker.
• Pubblicazione in un server hub azioni privato: in questo modo l'azione è disponibile solo nella 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 e funziona per qualsiasi azione che vuoi rendere disponibile a chiunque utilizzi Looker.

Dopo aver testato l'azione, puoi inviare una richiesta pull al repository looker-open-source/actions su 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 dell'hub azioni. Per ulteriori informazioni sui requisiti del modulo, consulta Invio di contenuti a Looker Marketplace.

   Looker esaminerà il codice dell'azione. Ci riserviamo il diritto di rifiutare la tua PR, ma possiamo aiutarti a risolvere eventuali problemi e offrirti suggerimenti per migliorare. Quindi, uniamo il codice al repository looker-open-source/actions e lo implementiamo in actions.looker.com. Una volta implementato, il codice sarà 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 il tuo caso d'uso, non devi aggiungere la tua azione al repository looker-open-source/actions. Crea invece un hub azioni privato utilizzando lo stesso framework Node.js che hai utilizzato per testare l'azione.

Puoi configurare il server dell'hub azioni interno sulla tua infrastruttura o utilizzando una piattaforma applicativa basata su cloud (il nostro esempio utilizzava Heroku). Non dimenticare di eseguire il fork dell'hub azioni di Looker nel tuo 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 richiesti per il servizio, se presenti.

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

Ciò significa che il servizio Twilio Send Message richiede una query che includa un campo del numero di telefono e che utilizzi il parametro tags per identificare il campo della query che contiene i numeri di telefono. Per identificare un campo del numero di telefono in LookML, specifica tags: ["phone"] per quel campo. Il codice 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 sottotesto "L'azione può essere utilizzata con qualsiasi query" nella pagina Azioni del riquadro Amministrazione.

Assicurati di identificare tutti i campi obbligatori nel tuo 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 un'esplorazione o di una dashboard a un servizio integrato.