Utilizzo dell’API di limitazione utilizzo

Introduzione

Journey OrchestrationLe API di supportano eventi 5000/secondi, ma alcuni sistemi o API esterni non potrebbero avere una velocità effettiva equivalente. Ecco perché Journey Orchestration viene fornito con una funzione dedicata denominata API di limitazione per monitorare e limitare il tasso che imponiamo ai sistemi esterni.

Durante la configurazione di un’origine dati, definirai una connessione a un sistema per recuperare informazioni aggiuntive che verranno utilizzate nei percorsi oppure, per una definizione di azione, configurerai la connessione di un sistema di terze parti per l’invio di messaggi o chiamate API. Ogni volta che una chiamata API viene eseguita dal Percorso, l’API di limitazione viene interrogata, la chiamata viene eseguita tramite il motore API. Se è definito un limite, la chiamata viene rifiutata e il sistema esterno non verrà sovraccaricato.

Per le origini dati esterne, il numero massimo di chiamate al secondo è impostato su 15. Se il numero di chiamate supera il 15 al secondo, le chiamate rimanenti vengono scartate. Puoi aumentare questo limite per le origini dati esterne private. Contatta l’Adobe per includere l’endpoint nell’inserire nell'elenco Consentiti. Ciò non è possibile per le fonti di dati esterne pubbliche. Per ulteriori informazioni sulle best practice e le protezioni durante l’integrazione di sistemi esterni, consulta questo articolo page.

Per ulteriori informazioni sulla configurazione dell’azione o dell’origine dati, consulta Informazioni sulle azioni o Informazioni sulle origini dati

Risorse

Per utilizzare questa API con la Journey Orchestration ad esempio, è necessario utilizzare la console AdobeI/O. Per iniziare, segui questo Guida introduttiva ad Adobe Developer Console e quindi utilizzare le sezioni di questa pagina.

Per testare e preparare la tua integrazione è disponibile una raccolta Postman qui.

Autenticazione

Impostazione dell’accesso alle API

Journey Orchestration L’accesso alle API è configurato attraverso i passaggi seguenti. Ciascuno di questi passaggi è descritto nella sezione Documentazione di Adobe I/O.

1. Verifica di disporre di un certificato digitale oppure creane uno, se necessario. Le chiavi pubbliche e private fornite con il certificato sono necessarie nei passaggi seguenti.
2. Creare una nuova integrazione in Journey Orchestration Servizio in Adobe I/O e configuralo. L’accesso al profilo di prodotto è necessario per Journey Orchestration e Adobe Experience Platform. Le credenziali verranno quindi generate (chiave API, segreto client…).
3. Creare un token web JSON (JWT) dalle credenziali generate in precedenza e firmalo con la tua chiave privata. JWT codifica tutte le informazioni di identità e sicurezza necessarie per Adobe per verificare la tua identità e concedere l’accesso all’API. Questo passaggio è descritto in sezione
4. Sostituire il JWT con un token di accesso tramite una richiesta POST o tramite l’interfaccia Console per sviluppatori. Questo token di accesso dovrà essere utilizzato in ogni intestazione delle richieste API.

Per stabilire una sessione API di Adobe I/O servizio-servizio sicura, ogni richiesta a un servizio Adobe deve includere nell’intestazione Autorizzazione le informazioni riportate di seguito.

curl -X GET https://journey.adobe.io/authoring/XXX \
 -H 'Authorization: Bearer <ACCESS_TOKEN>' \
 -H 'x-api-key: <API_KEY>' \
 -H 'x-gw-ims-org-id: <ORGANIZATION>'

• <organization>: Si tratta dell’ID organizzazione personale, un ID organizzazione viene fornito per Adobe per ciascuna istanza :

  • <organization> : l'istanza di produzione

  Per ottenere il valore dell’ID ORGANIZZAZIONE, rivolgiti all’amministratore o al contatto tecnico Adobe. È inoltre possibile recuperarlo in Adobe I/O durante la creazione di una nuova integrazione, nell’elenco delle licenze (consulta Documentazione di Adobe I/O).

• <access_token>: Token di accesso personale, recuperato durante lo scambio di JWT tramite una richiesta POST.

• <api_key>: la tua chiave API personale. Viene fornito in Adobe I/O dopo la creazione di una nuova integrazione in Journey Orchestration Servizio.

Limitazione della descrizione API

L’API di limitazione di utilizzo consente di creare, configurare e monitorare le configurazioni di limitazione di utilizzo.

Quando una configurazione viene creata o aggiornata, viene eseguito automaticamente un controllo per garantire la sintassi e l’integrità del payload.
Se si verificano alcuni problemi, l'operazione restituisce un avviso o degli errori per facilitare la correzione della configurazione.

Configurazione endpoint

La struttura di base di una configurazione dell’endpoint è la seguente:

{
    "url": "<endpoint URL>",  //wildcards are allowed in the endpoint URL
    "methods": [ "<HTTP method such as GET, POST, >, ...],
    "services": {
        "<service name>": { . //must be "action" or "dataSource" 
            "maxHttpConnections": <max connections count to the endpoint>
            "rating": {          
                "maxCallsCount": <max calls to be performed in the period defined by period/timeUnit>,
                "periodInMs": <integer value greater than 0>
            }
        },
        ...
    }
}

Esempio:

`{
  "url": "https://api.example.org/data/2.5/*",
  "methods": [
    "GET"
  ],
  "services": {
    "dataSource": {
      "maxHttpConnections": 30000,
      "rating": {
        "maxCallsCount": 5000,
        "periodInMs": 1000
      }
    }
  },
  "orgId": "<IMS Org Id>"
}

Avvisi ed errori

Quando un canDeploy viene chiamato , il processo convalida la configurazione e restituisce lo stato di convalida identificato dal relativo ID univoco:

"ok" or "error"

Gli errori potenziali sono:

• ERR_ENDPOINTCONFIG_100: configurazione di tappping: url mancante o non valido
• ERR_ENDPOINTCONFIG_101: configurazione di tappping: url malformato
• ERR_ENDPOINTCONFIG_102: configurazione di tappping: url non valido: carattere jolly nell'url non consentito in host:port
• ERR_ENDPOINTCONFIG_103: configurazione di tappping: metodi HTTP mancanti
• ERR_ENDPOINTCONFIG_104: configurazione di tappping: nessuna classificazione di chiamata definita
• ERR_ENDPOINTCONFIG_107: configurazione di tappping: conteggio massimo chiamate non valido (maxCallsCount)
• ERR_ENDPOINTCONFIG_108: configurazione di tappping: conteggio massimo chiamate non valido (periodInMs)
• ERR_ENDPOINTCONFIG_111: configurazione di tappping: impossibile creare la configurazione dell'endpoint: payload non valido
• ERR_ENDPOINTCONFIG_112: configurazione di tappping: impossibile creare la configurazione dell'endpoint: attesa di un payload JSON
• ERR_AUTHORING_ENDPOINTCONFIG_1: nome di servizio non valido <!--<given value>-->: deve essere 'dataSource' o 'action'

L'avviso potenziale è:

ERR_ENDPOINTCONFIG_106: configurazione di tappping: connessioni HTTP massime non definite: nessuna limitazione per impostazione predefinita

Casi d’uso

In questa sezione sono disponibili i cinque casi d’uso principali che è possibile eseguire per gestire la configurazione dei limiti in Journey Orchestration.

Per facilitare i test e la configurazione, è disponibile una raccolta Postman qui.

Questa raccolta Postman è stata impostata per condividere la raccolta Postman Variable generata tramite Integrazioni della console Adobe I/O > Prova > Scarica per Postman, che genera un file Ambiente Postman con i valori di integrazioni selezionati.

Una volta scaricata e caricata in Postman, devi aggiungere tre variabili: {JO_HOST},{Base_Path} e {SANDBOX_NAME}.

• {JO_HOST} : Journey Orchestration URL gateway
• {BASE_PATH} : punto di ingresso per l’API. Il valore è '/authoring'
• {SANDBOX_NAME} : intestazione x-sandbox-name (ad esempio, "prod") corrispondente al nome della sandbox in cui avranno luogo le operazioni API. Consulta la sezione panoramica sulle sandbox per ulteriori informazioni.

Nella sezione seguente, trovi l’elenco delle chiamate API rimanenti ordinate per eseguire il caso d’uso.

Caso d’uso n° 1: Creazione e distribuzione di una nuova configurazione di tappatura

1. list
2. creare
3. canonizzare
4. distribuire

Caso d’uso n° 2: Aggiornare e distribuire una configurazione di limite non ancora distribuita

1. elenco
2. get
3. update
4. canonizzare
5. distribuire

Caso d’uso n° 3: Disdistribuire ed eliminare una configurazione di limitazione distribuita

1. elenco
2. non distribuire
3. delete

Caso d’uso n° 4: Elimina una configurazione di limitazione distribuita.

In una sola chiamata API, puoi annullare la distribuzione ed eliminare la configurazione utilizzando il parametro forceDelete .

1. elenco
2. elimina, con param forceDelete

Caso d’uso n° 5: Aggiornare una configurazione di limite già distribuita

1. elenco
2. get
3. update
4. non distribuire
5. canonizzare
6. distribuire