Le origini dati esterne consentono di definire una connessione a sistemi di terze parti, ad esempio è in uso un sistema di prenotazione alberghiera per verificare se il cliente ha registrato una stanza. Al posto dell’origine dati integrata di Adobe Experience Platform, puoi creare un numero illimitato di origini dati esterne.
I guardrail quando si lavora con sistemi esterni sono elencati in questa pagina.
Sono supportate le API REST basate su POST o GET e che restituiscono JSON. Sono supportate le modalità chiave API, sia l’autenticazione di base che personalizzata.
Prendiamo l’esempio di un servizio API meteorologico che intendo sfruttare per personalizzare i comportamenti del mio percorso secondo i dati meteo in tempo reale.
Di seguito sono riportati due esempi della chiamata API:
La chiamata è composta da un URL principale, https://api.adobeweather.org/weather, due set di parametri ("city" per la città e "lat/long" per la latitudine e la longitudine) e la chiave API (appid).
Di seguito sono riportati i passaggi principali per la creazione e la configurazione di una nuova origine dati esterna:
Dall’elenco delle origini dati, fai clic su Crea origine dati per creare una nuova origine dati esterna.
Sul lato destro dello schermo si apre il riquadro di configurazione dell’origine dati .
Inserisci un nome per l’origine dati.
Non utilizzare spazi o caratteri speciali. Non usare più di 30 caratteri.
Aggiungi una descrizione all’origine dati. Questo passaggio è facoltativo.
Aggiungi l’URL del servizio esterno. Nel nostro esempio: https://api.adobeweather.org/weather.
Per motivi di sicurezza, è consigliabile utilizzare HTTPS. Inoltre, non consentiamo l’uso di indirizzi Adobe che non siano disponibili al pubblico, né di indirizzi IP.
Configura l’autenticazione in base alla configurazione del servizio esterno: Nessuna autenticazione, Base, Personalizzato o Chiave API. Per ulteriori informazioni sulla modalità di autenticazione personalizzata, vedi questa sezione. Le scelte del nostro esempio:
Aggiungi un nuovo gruppo di campi per ciascun set di parametri API facendo clic su Aggiungi un nuovo gruppo di campi. Non utilizzare spazi o caratteri speciali nel nome del gruppo di campi. Nel nostro esempio, dobbiamo creare due gruppi di campi, uno per ciascun insieme di parametri (city e long/lat).
Per il set di parametri "long/lat", viene creato un gruppo di campi con le seguenti informazioni:
Nel caso di una chiamata di GET che richieda i parametri, immetti i parametri nel Valori dinamici e vengono aggiunti automaticamente alla fine della chiamata . Nel caso di una chiamata POST, è necessario:
elencare i parametri da trasmettere al momento della chiamata nel Valori dinamici (nell’esempio seguente: "identifier").
Specificare i parametri anche utilizzando la medesima sintassi nel corpo del payload inviato. A tale scopo, è necessario aggiungere: "param": “nome del tuo parametro”, nell’esempio seguente è "identifier". Attieniti alla sintassi seguente:
{"id":{"param":"identifier"}}
Fai clic su Salva.
L’origine dati è ora configurata ed è pronta per essere utilizzata nei percorsi, ad esempio nelle tue condizioni o per personalizzare un’e-mail. Se la temperatura è superiore a 30°C, puoi decidere di inviare una comunicazione specifica.
Questa modalità di autenticazione viene utilizzata per la tipologia complessa, spesso impiegata per la chiamata dei protocolli di wrapping API come OAuth2 e per il recupero di un token di accesso da inserire nella richiesta HTTP effettiva per l’azione.
Quando configuri l’autenticazione personalizzata, puoi fare clic sul pulsante seguente per verificare la corretta configurazione del payload di autenticazione personalizzata.
Se il test ha esito positivo, il pulsante diventa verde.
Con questa autenticazione, l’esecuzione dell’azione è un processo suddiviso in due fasi:
Questa autenticazione è costituita da due parti.
Definizione dell’endpoint da chiamare per la generazione del token di accesso:
La definizione della modalità di inserimento del token di accesso nella richiesta HTTP dell’azione:
authorizationType: definisce il modo in cui il token di accesso generato deve essere inserito nella chiamata HTTP per l’azione. I valori possibili sono:
tokenInResponse: indica come estrarre il token di accesso dalla chiamata di autenticazione. Questa proprietà può corrispondere a:
Il formato di questa autenticazione è:
{
"type": "customAuthorization",
"authorizationType": "<value in 'bearer', 'header' or 'queryParam'>",
(optional, mandatory if authorizationType is 'header' or 'queryParam') "tokenTarget": "<name of the header or queryParam if the authorizationType is 'header' or 'queryParam'>",
"endpoint": "<URL of the authentication endpoint>",
"method": "<HTTP method to call the authentication endpoint, in 'GET' or 'POST'>",
(optional) "headers": {
"<header name>": "<header value>",
...
},
(optional, mandatory if method is 'POST') "body": {
"bodyType": "<'form'or 'json'>,
"bodyParams": {
"param1": value1,
...
}
},
"tokenInResponse": "<'response' or json selector in format 'json://<field path to access token>'"
}
Adesso puoi modificare la durata della cache del token per un’origine dati di autenticazione personalizzata. Di seguito è riportato un esempio di payload di autenticazione personalizzato. La durata della cache è definita nel parametro “cacheDuration”. Tale parametro Specifica la durata di conservazione del token generato nella cache. L’unità può essere in millisecondi, secondi, minuti, ore, giorni, mesi, anni.
Ecco un esempio per il tipo di autenticazione portatore:
{
"authentication": {
"type": "customAuthorization",
"authorizationType": "Bearer",
"endpoint": "http://localhost:${port}/epsilon/oauth2/access_token",
"method": "POST",
"headers": {
"Authorization": "Basic EncodeBase64(<epsilon Client Id>:<epsilon Client Secret>)"
},
"body": {
"bodyType": "form",
"bodyParams": {
"scope": "cn mail givenname uid employeeNumber",
"grant_type": "password",
"username": "<epsilon User Name>",
"password": "<epsilon User Password>"
}
},
"tokenInResponse": "json://access_token",
"cacheDuration": {
"duration": 5,
"timeUnit": "minutes"
}
}
}
La durata della cache aiuta a evitare troppe chiamate agli endpoint di autenticazione. Il mantenimento del token di autenticazione è memorizzato nella cache dei servizi. Non esiste persistenza. Se un servizio viene riavviato, inizia con una cache pulita. La durata predefinita della cache è di 1 ora. Nel payload di autenticazione personalizzato, può essere adattato specificando un’altra durata di conservazione.
Ecco un esempio per il tipo di autenticazione dell’intestazione:
{
"type": "customAuthorization",
"authorizationType": "header",
"tokenTarget": "x-auth-token",
"endpoint": "https://myapidomain.com/v2/user/login",
"method": "POST",
"headers": {
"x-retailer": "any value"
},
"body": {
"bodyType": "form",
"bodyParams": {
"secret": "any value",
"username": "any value"
}
},
"tokenInResponse": "json://token"
}
Ecco un esempio della risposta della chiamata API di accesso:
{
"token": "xDIUssuYE9beucIE_TFOmpdheTqwzzISNKeysjeODSHUibdzN87S"
}