Externa datakällor concept_t2s_kqt_52b

Med externa datakällor kan du definiera en anslutning till tredjepartssystem om du till exempel använder ett bokningssystem för hotell som kontrollerar om personen har registrerat ett rum. I motsats till den inbyggda datakällan i Adobe Experience Platform kan du skapa så många externa datakällor som behövs.

Stöd finns för REST API:er som använder POST eller GET och returnerar JSON. API-nyckel samt grundläggande och anpassade autentiseringslägen stöds.

Låt oss använda en API-tjänst för väder som exempel. Jag vill använda den för att anpassa resans beteenden beroende på väderdata i realtid.

Här är två exempel på API-anropet:

  • https://api.adobeweather.org/weather?city=London,uk&appid=1234
  • https://api.adobeweather.org/weather?lat=35&lon=139&appid=1234

Anropet består av en huvud-URL (https://api.adobeweather.org/weather), två parameteruppsättningar ("city" för staden och "lat/long" för latitud och longitud) och API-nyckeln (appid).

Här följer de viktigaste stegen för att skapa och konfigurera en ny extern datakälla:

  1. Klicka på Create data source i listan över datakällor för att skapa en ny extern datakälla.

    Detta öppnar konfigurationsfönstret för datakällan till höger på skärmen.

  2. Ange ett namn för datakällan.

    note note
    NOTE
    Använd inte blanksteg eller specialtecken. Använd maximalt 30 tecken.
  3. Lägg till en beskrivning om datakällan. Det här steget är valfritt.

  4. Lägg till den externa tjänstens URL. I vårt exempel: https://api.adobeweather.org/weather.

    note caution
    CAUTION
    Vi rekommenderar starkt att HTTPS används av säkerhetsskäl. Observera också att vi endast tillåter att Adobe-adresser som är allmänt tillgängliga samt IP-adresser används.

  5. Konfigurera autentiseringen beroende på den externa tjänstens konfiguration: No authentication, Basic, Custom eller API key. Mer information om det anpassade autentiseringsläget finns i det här avsnittet. I vårt exempel väljer vi:

    • Type: "API-nyckel"
    • Value: "1234" (det här är värdet på vår API-nyckel)
    • Name: "appid" (det här är API-nyckelns parameternamn)
    • Location: "Frågeparameter" (API-nyckeln finns i webbadressen)

  6. Klicka på Add a New Field Group för att lägga till en ny fältgrupp för varje API-parameteruppsättning. Använd inte blanksteg eller specialtecken i fältgruppens namn. I vårt exempel behöver vi skapa två fältgrupper. En för varje parameteruppsättning ("city" och "long/lat").

För parameteruppsättningen "long/lat" skapar vi en fältgrupp med följande information:

  • Used in: visar antalet resor som använder en fältgrupp. Du kan klicka på ikonen View journeys för att visa en lista över resor som använder den här fältgruppen.
  • Method: välj metoden POST eller GET. I vårt fall väljer vi metoden GET.
  • Response Payload: klicka inuti fältet Payload och klistra in ett exempel på nyttolasten som returneras av anropet. Vi har till exempel använt en nyttolast som finns på en API-webbplats för väder. Kontrollera att fälttyperna är korrekta. Varje gång API:et anropas hämtas alla fält som ingår i exemplets nyttolast. Observera att du kan klicka på Paste a new payload för att ändra den nyttolast som för närvarande används.
  • Dynamic Values: ange de olika parametrarna avgränsade med kommatecken – "long,lat" i vårt exempel. Eftersom parameterns värden är beroende av körningens sammanhang definieras de i resorna. Läs den här sidan.
  • Sent Payload: det här fältet visas inte i vårt exempel. Det är endast tillgängligt om du väljer metoden POST. Klistra in nyttolasten som ska skickas till tredjepartssystemet.

Om ett GET-anrop som kräver parametrar används ska du ange parametrarna i fältet Dynamic Values och de läggs sedan till automatiskt i slutet av anropet. Om ett POST-anrop används måste du:

  • lista de parametrar som ska skickas vid anrop i fältet Dynamic Values (i exemplet nedan: "identifier").

  • även ange dem med exakt samma syntax i brödtexten i den skickade nyttolasten. För att göra detta måste du lägga till: "param" – "namn på parametern" (i exemplet nedan: "identifier"). Följ syntaxen nedan:

    code language-none
    {"id":{"param":"identifier"}}
    

Klicka på Save.

Datakällan är nu konfigurerad och redo att användas i dina resor. Du kan till exempel använda den i dina villkor eller för att personalisera ett e-postmeddelande. Om temperaturen är över 30 °C kan du välja att skicka ett visst meddelande.

Anpassat autentiseringsläge section_wjp_nl5_nhb

Det här autentiseringsläget används vid komplex autentisering som ofta används för att anropa API-omslutningsprotokoll som OAuth2 och för att hämta en åtkomsttoken som ska injiceras i den faktiska HTTP-begäran för åtgärden.

När du konfigurerar den anpassade autentiseringen kan du klicka på knappen nedan för att kontrollera om den anpassade autentiserade nyttolasten är korrekt konfigurerad.

Om testet godkänns blir knappen grön.

Med den här autentiseringen blir åtgärdskörningen en process med två steg:

  1. Anropa slutpunkten för att generera en åtkomsttoken.
  2. Anropa REST API:et genom att injicera åtkomsttoken på rätt sätt.

Denna autentisering består av två delar.

Definitionen av slutpunkten som ska anropas för att generera en åtkomsttoken:

  • slutpunkt: URL som ska användas för att generera slutpunkten

  • metoden för HTTP-begäran på slutpunkten (GET eller POST)

  • rubriker: nyckel-/värdepar som vid behov ska injiceras som rubriker i detta anrop

  • brödtext: beskriver anropets brödtext om metoden är POST. Vi har stöd för en begränsad struktur i brödtexten som definieras i bodyParams (nyckel/värde-par). Brödtextens typ beskriver formatet och kodningen för brödtexten i anropet:

    • "form": innebär att innehållstypen är application/x-www-form-urlencoded (charset UTF-8) och nyckel/värde-paren serialiseras som de är: key1=value1&key2=value2& …
    • "json": innebär att innehållstypen är application/json (charset UTF-8) och nyckel-/värdeparen serialiseras som ett json-objekt som det är: { "key1": "value1", "key2": "value2", …}

Definitionen av hur en åtkomsttoken måste injiceras i åtgärdens HTTP-begäran:

  • authorizationType: definierar hur den genererade åtkomsttoken måste injiceras i HTTP-anropet för åtgärden. Möjliga värden är:

    • innehavare: anger att en åtkomsttoken måste injiceras i auktoriseringsrubriken såsom: behörighet: innehavare <åtkomsttoken>
    • rubrik: anger att en åtkomsttoken måste injiceras som en rubrik där dess namn definieras av egenskapen tokenTarget. Om till exempel tokenTarget är myHeader injiceras åtkomsttoken som en rubrik som: myHeader: <åtkomsttoken>
    • queryParam: anger att en åtkomsttoken måste injiceras som en queryParam där dess namn definieras av egenskapen tokenTarget. Om till exempel tokenTarget är myQueryParam blir webbadressen för åtgärdsanropet: <url>?myQueryParam=<åtkomsttoken>
  • tokenInResponse: anger hur du extraherar åtkomsttoken från autentiseringsanropet. Den här egenskapen kan vara:

    • "response": anger att HTTP-svaret är åtkomsttoken
    • en väljare i en json (förutsatt att svaret är en json. Vi har inte stöd för andra format som XML). Den här väljarens format är json://<sökväg till åtkomsttokens egenskap>. Om svaret på anropet till exempel är: { "access_token": "theToken", "timestamp": 12323445656 }, kommer tokenInResponse att vara: json: //access_token

Autentiseringsformatet är:

{
    "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>'"
}

Du kan ändra cachevaraktigheten på en token för en anpassad autentiseringsdatakälla. Nedan visas ett exempel på en anpassad autentiseringsnyttolast. Cachevaraktigheten definieras i parametern "cacheDuration". Den anger varaktigheten för den genererade token i cachen. Enheten kan vara millisekunder, sekunder, minuter, timmar, dagar, månader och år.

"authentication": {
    "type":"customAuthorization",
    "authorizationType":"Bearer",
    "endpoint":"http://localhost:${port}/epsilon/oauth2/access_token",
    "method":"POST",
    "headers": {
        "Authorization":"Basic EncodeBase64(${epsilonClientId}:${epsilonClientSecret})"
        },
    "body": {
        "bodyType":"form",
        "bodyParams": {
             "scope":"cn mail givenname uid employeeNumber",
             "grant_type":"password",
             "username":"${epsilonUserName}",
             "password":"${epsilonUserPassword}"
             }
        },
    "tokenInResponse":"json://access_token",
    "cacheDuration":
             { "duration":5, "timeUnit":"seconds" }
    }
NOTE
Cachens varaktighet hjälper till att undvika för många anrop till slutpunkterna för autentisering. Kvarhållande av autentiseringstoken cachelagras i tjänster, det finns ingen beständighet. Om en tjänst startas om börjar den med en ren cache. Cachevaraktigheten är som standard 1 timme. I den anpassade autentiseringsnyttolasten kan den anpassas genom att ange en annan kvarhållningstid.
recommendation-more-help
4f4a00c1-77c9-4eee-84df-bbe6206c3ab9