Fontes de dados externas

Fontes de dados externas permitem definir uma conexão com sistemas de terceiros, por exemplo, se você estiver usando um sistema de reserva de hotel para verificar se a pessoa reservou um quarto. Ao contrário da fonte de dados integrada da Adobe Experience Platform, você pode criar quantas fontes de dados externas forem necessárias.

As APIs REST que usam POST ou GET e devolvem JSON são compatíveis. A chave de API, os modos de autenticação básicos e personalizados são compatíveis.

Vamos ver o exemplo de um serviço de API meteorológica usada para personalizar os comportamentos da jornada de acordo com os dados climáticos em tempo real.

Dois exemplos da chamada de API:

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

A chamada é composta de um URL principal (https://api.adobeweather.org/weather), dois conjuntos de parâmetros ("city" para a cidade e "lat/long" para a latitude e a longitude) e a chave da API (appid).

Estas são as principais etapas para criar e configurar uma nova fonte de dados externa:

  1. Na lista de fontes de dados, clique em Add para criar uma nova fonte de dados externa.

    Essa ação abre o painel de configuração da fonte de dados no lado direito da tela.

  2. Insira um nome para a sua fonte de dados.

    OBSERVAÇÃO

    Não use espaços ou caracteres especiais. Não use mais de 30 caracteres.

  3. Adicione uma descrição à fonte de dados. Esta etapa é opcional.

  4. Adicione o URL do serviço externo. Em nosso exemplo: https://api.adobeweather.org/weather.

    CUIDADO

    Recomendamos o uso de HTTPS por motivos de segurança. Observe também que não permitimos o uso de endereços da Adobe que não estejam disponíveis publicamente, bem como o uso de endereços IP.

  5. Configure a autenticação dependendo da configuração do serviço externo: No authentication, Basic, Custom ou API key. Para obter mais informações sobre o modo de autenticação personalizado, consulte esta seção. Em nosso exemplo, escolhemos:

    • Type: "Chave de API"
    • Value: "1234" (este é o valor da nossa chave de API)
    • Name: "appid" (este é o nome do parâmetro da chave de API)
    • Location: "Parâmetro de query" (a chave de API está localizada no URL)

  6. Adicione um novo grupo de campos para cada conjunto de parâmetros da API clicando em Add a New Field Group. Não use espaços ou caracteres especiais no nome do grupo de campos. Em nosso exemplo, precisamos criar dois grupos de campo, um para cada conjunto de parâmetros (city e long/lat).

Para o conjunto de parâmetros "long/lat", criamos um grupo de campos com as seguintes informações:

  • Used in: exibe o número de jornadas que usam um grupo de campos. Você pode clicar no ícone View journeys para exibir a lista de jornadas usando esse grupo de campos.
  • Method: selecione o método POST ou GET. No nosso caso, selecionamos o método GET.
  • Cache duration: no nosso caso, queremos que os dados de meteorologia sejam armazenados em cache por 10 minutos.
  • Response Payload: clique dentro do campo Payload e cole um exemplo da carga útil retornada pela chamada. Para nosso exemplo, usamos uma carga encontrada em um site da API de meteorologia. Verifique se os tipos de campo estão corretos. Cada vez que a API é chamada, o sistema recuperará todos os campos incluídos no exemplo de carga útil. Observe que você pode clicar em Paste a new payload se desejar alterar a carga útil transmitida no momento.
  • Dynamic Values: insira os diferentes parâmetros separados por vírgula, "long,lat" no nosso exemplo. Como os valores dos parâmetros dependem do contexto de execução, eles serão definidos nas jornadas. Consulte esta página.
  • Sent Payload: este campo não aparece no nosso exemplo. Ele só estará disponível se você selecionar o método POST. Cole a carga útil que será enviada para o sistema de terceiros.

No caso de uma chamada GET que exige parâmetros, você informa os parâmetros no campo Dynamic Values e eles são adicionados automaticamente no final da chamada. No caso de uma chamada POST, é necessário:

  • listar os parâmetros que serão transmitidos no momento da chamada no campo Dynamic Values (no exemplo abaixo: "identificador").

  • especificá-los também com a mesma sintaxe no corpo da carga útil enviada. Para fazer isso, é necessário adicionar: "param": "nome do parâmetro" (no exemplo abaixo: "identificador"). Siga a sintaxe abaixo:

    {"id":{"param":"identifier"}}

Clique em Save.

A fonte de dados agora está configurada e pronta para ser usada em suas jornadas, por exemplo em suas condições ou para personalizar um email. Se a temperatura estiver acima de 30°C, você pode decidir enviar uma comunicação específica.

Modo de autenticação personalizado

Esse modo de autenticação é usado para autenticação complexa, frequentemente usada para chamar protocolos de empacotamento de API como OAuth2, para recuperar um token de acesso que será inserido na solicitação real HTTP para a ação.

Ao configurar a autenticação personalizada, você pode clicar no botão abaixo para verificar se a carga útil de autenticação personalizada está configurada corretamente.

Se o teste for bem-sucedido, o botão ficará verde.

Com essa autenticação, a execução da ação é um processo de duas etapas:

  1. Chame o endpoint para gerar o token de acesso.
  2. Chame a REST API inserindo de maneira correta o token de acesso.

Esta autenticação tem duas partes.

A definição do endpoint que será chamado para gerar o token de acesso:

  • endpoint: URL que será usado para gerar o endpoint
  • método da solicitação HTTP no endpoint (GET ou POST)
  • cabeçalhos: pares de chave/valor que serão inseridos como cabeçalhos nesta chamada, caso necessário
  • corpo: descreve o corpo da chamada se o método for POST. Oferecemos suporte a uma estrutura de corpo limitada, definida em bodyParams (pares de chaves/valores). O bodyType descreve o formato e a codificação do corpo na chamada:
    • 'form': significa que o tipo de conteúdo será application/x-www-form-urlencoded (charset UTF-8) e os pares chave/valor serão serializados como estão: key1=value1&key2=value2&…
    • 'json': significa que o tipo de conteúdo será application/json (charset UTF-8) e que os pares de valores principais serão serializados como um objeto json como a seguir: { "key1": "value1", "key2": "value2", …}

A definição da forma como o token de acesso deve ser inserido na solicitação HTTP da ação:

  • authorizationType: define como o token de acesso gerado deve ser inserido na chamada HTTP para a ação. Os valores possíveis são:

    • bearer: indica que o token de acesso deve ser injetado no cabeçalho da Autorização, como: Authorization: Bearer <access token>
    • header: indica que o token de acesso deve ser inserido como um cabeçalho, o nome do cabeçalho definido pela propriedade tokenTarget. Por exemplo, se o tokenTarget for myHeader, o token de acesso será inserido como um cabeçalho como: myHeader: <access token>
    • queryParam: indica que o token de acesso deve ser inserido como um queryParam, o nome do parâmetro do query definido pela propriedade tokenTarget. Por exemplo, se o tokenTarget for myQueryParam, o URL da chamada de ação será: <url>?myQueryParam=<access token>

  • tokenInResponse: indica como extrair o token de acesso da chamada de autenticação. Essa propriedade pode ser:

    • 'response': indica que a resposta HTTP é o token de acesso
    • um seletor em um json (supondo que a resposta seja um json, não oferecemos suporte a outros formatos, como XML). O formato desse seletor é json://<path to the access token property>. Por exemplo, se a resposta da chamada for: { "access_token": "theToken", "timestamp": 12323445656 }, o tokenInResponse será: json: //access_token

O formato dessa autenticação é:

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

É possível alterar a duração do cache do token para uma fonte de dados de autenticação personalizada. Encontre abaixo um exemplo de payload de autenticação personalizada. A duração do cache é definida no parâmetro "cacheDuration". Especifica a duração de retenção do token gerado no cache. A unidade pode ser milissegundos, segundos, minutos, horas, dias, meses, anos.

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

Nesta página