Condividi tramite

Recapito pull con HTTP

  • Articolo

Questo articolo parte dalle informazioni contenute in Che cos'è Griglia di eventi di Azure? e dall'articolo che descrive i concetti di Griglia di eventi per fornire informazioni essenziali sull'utilizzo del recapito pull di Griglia di eventi tramite HTTP. Vengono illustrati i concetti fondamentali, i modelli di risorse e le modalità di recapito dei messaggi supportate. Alla fine del documento sono disponibili collegamenti utili agli articoli che illustrano come usare Griglia di eventi e agli articoli che offrono informazioni concettuali approfondite.

Nota

Questo documento illustra come iniziare a usare le funzionalità di Griglia di eventi che si servono del protocollo HTTP. Questo articolo è utile per gli utenti che devono integrare applicazioni nel cloud. Se è necessario comunicare i dati dei dispositivi IoT, vedere Panoramica della funzionalità Broker MQTT in Griglia di eventi di Azure.

CloudEvents

Gli argomenti dello spazio dei nomi di Griglia di eventi accettano eventi conformi alla specifica CloudEvents 1.0, standard aperto, della Cloud Native Computing Foundation (CNCF) usando ilbinding del protocollo HTTP in formato JSON.

Per altre informazioni, vedere Supporto di CloudEvents.

Modalità contenuto CloudEvents

La specifica CloudEvents definisce tre modalità di contenuto utilizzabili: binaria, strutturata e in batch.

Importante

Con qualsiasi modalità di contenuto è possibile scambiare dati evento testuali (JSON, text/*, ecc.) o codificati in formato binario. La modalità di contenuto binaria non viene usata esclusivamente per l'invio di dati binari.

Le modalità di contenuto non riguardano la codifica usata, binaria o testuale, ma il modo in cui i dati dell'evento e i relativi metadati vengono descritti e scambiati. La modalità di contenuto strutturata usa una singola struttura, ad esempio un oggetto JSON, in cui sia gli attributi di contesto che i dati evento si trovano nel payload HTTP. La modalità di contenuto binaria separa gli attributi di contesto, di cui viene eseguito il mapping alle intestazioni HTTP, e i dati evento, ovvero il payload HTTP codificato in base al valore del tipo di supporto in Content-Type.

Per altre informazioni, vedere Modalità di contenuto CloudEvents.

Messaggi ed eventi

Un CloudEvent in genere contiene dati evento che annunciano un'occorrenza in un sistema, ovvero una modifica dello stato del sistema. Tuttavia, è possibile trasmettere qualsiasi tipo di dati quando si usa CloudEvents. Ad esempio, è possibile usare il formato di scambio CloudEvents per inviare un messaggio di comando per richiedere un'azione a un'applicazione downstream. Un altro esempio è il routing dei messaggi dal broker MQTT di Griglia di eventi a un argomento. In questo scenario viene eseguito il routing di un messaggio MQTT impacchettato in una busta CloudEvents.

Recapito pull

Con il recapito pull, l'applicazione si connette a Griglia di eventi per leggere CloudEvents usando una semantica simile a quella delle code.

Il recapito pull offre questi vantaggi nell'utilizzo degli eventi:

  • Usare gli eventi in base al proprio ritmo, su larga scala o a una velocità di ingresso supportata dall'applicazione.

  • Utilizzare gli eventi in un momento a scelta. Ad esempio, in base ai requisiti aziendali, i messaggi vengono elaborati di notte.

  • Utilizzare eventi tramite un collegamento privato in modo che i dati usino spazio IP privato.

Nota

  • Gli spazi dei nomi forniscono un modello di risorse più semplice con un singolo tipo di argomento. Attualmente Griglia di eventi supporta la pubblicazione di eventi applicazione personalizzati tramite gli argomenti dello spazio dei nomi. Non è possibile utilizzare gli eventi dei servizi di Azure o dei sistemi SaaS partner usando gli argomenti dello spazio dei nomi. Non è nemmeno possibile creare argomenti di sistema, argomenti di dominio o argomenti partner in uno spazio dei nomi.
  • Gli argomenti dello spazio dei nomi supportano il formato JSON CloudEvents.

Sottoscrizioni di eventi coda

Quando si ricevono eventi o si usano operazioni che gestiscono lo stato dell'evento, un'applicazione specifica un endpoint HTTP dello spazio dei nomi, un nome di argomento e il nome di una sottoscrizione di eventi coda. Una sottoscrizione di eventi coda ha il valore deliveryMode impostato su "queue". Le sottoscrizioni di eventi coda vengono usate per sfruttare gli eventi tramite l'API di recapito pull. Per altre informazioni su come creare queste risorse, vedere Creare spazi dei nomi, argomenti e sottoscrizioni di eventi.

Si usa una sottoscrizione di eventi per definire i criteri di filtro per gli eventi e, così facendo, si definisce in modo efficace il set di eventi disponibili per l'utilizzo tramite tale sottoscrizione di eventi. Una o più applicazioni sottoscrittore (utente) possono connettersi allo stesso endpoint dello spazio dei nomi e usare lo stesso argomento e la stessa sottoscrizione di eventi.

Diagramma generale di un server di pubblicazione e di un consumer che usano una sottoscrizione di eventi. Il consumer usa il recapito pull.

Operazioni di recapito pull

L'applicazione usa le operazioni seguenti quando si usa il recapito pull.

  • Un'operazione di ricezione viene usata per leggere uno o più eventi usando una singola richiesta a Griglia di eventi. Per impostazione predefinita, il broker attende fino a 60 secondi prima che gli eventi diventino disponibili. Ad esempio, gli eventi diventano disponibili per il recapito quando vengono pubblicati per la prima volta. Una richiesta di ricezione riuscita restituisce zero o più eventi. Se gli eventi sono disponibili, restituisce il maggior numero possibile di eventi disponibili fino al numero di eventi richiesto. Griglia di eventi restituisce anche un token di blocco per ogni evento letto.
  • Un token di blocco è un tipo di handle che identifica un evento che è possibile usare per controllarne lo stato.
  • Una volta che un'applicazione consumer riceve un evento e la elabora, riconosce tale evento. Questa operazione indica a Griglia di eventi di eliminare l'evento in modo che non venga recapitato a un altro client. L'applicazione consumer riconosce uno o più token con una singola richiesta specificando i token di blocco prima della scadenza.

In altre occasioni, l'applicazione consumer potrebbe voler rilasciare o rifiutare gli eventi.

  • L'applicazione consumer rilascia un evento ricevuto per segnalare a Griglia di eventi che non è pronta per elaborare tale evento e renderlo disponibile per un nuovo recapito. Lo fa chiamando l'operazione di rilascio con i token di blocco che identificano gli eventi da restituire a Griglia di eventi. L'applicazione può decidere se l'evento deve essere rilasciato immediatamente o se deve essere usato un ritardo prima che l'evento sia disponibile per un nuovo recapito.

  • È possibile scegliere di rifiutare un evento se c'è una condizione, possibilmente permanente, che impedisce all'applicazione consumer di elaborare l'evento. Ad esempio, un messaggio in formato non valido può essere rifiutato perché non può essere analizzato correttamente. Gli eventi rifiutati vengono contrassegnati come non recapitabili, se è disponibile una destinazione di messaggi non recapitabili. In caso contrario, vengono eliminati.

Ambito in cui vengono eseguite le operazioni di recapito pull

Quando si richiama un'operazione di ricezione, conferma, rilascio, rifiuto o rinnovo del blocco, tali azioni vengono eseguite nel contesto della sottoscrizione di eventi. Ad esempio, se si riconosce un evento, tale evento non è più disponibile tramite la sottoscrizione di eventi usata quando si chiama l'azione di riconoscimento. Un'altra sottoscrizione di eventi potrebbe comunque avere lo "stesso" evento disponibile. Ciò è dovuto al fatto che una sottoscrizione di eventi ottiene una copia degli eventi pubblicati. Tali copie di eventi sono effettivamente distinte l'una dall'altra nelle sottoscrizioni di eventi. Ogni evento ha un proprio stato indipendente dagli altri eventi.

Forma dei dati durante la ricezione di eventi tramite il recapito pull

Quando si recapitano eventi tramite il recapito pull, Griglia di eventi include una matrice di oggetti che a sua volta include gli oggetti event e brokerProperties. Il valore della proprietà event è il CloudEvent recapitato in modalità contenuto strutturata. L'oggetto brokerProperties contiene il token di blocco associato al CloudEvent recapitato. L'oggetto JSON seguente è una risposta di esempio a un'operazione di ricezione che restituisce due eventi:

{
    "value": [
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDXYS23Z+5Hq754VqQjxywE",
                "deliveryCount": 2
            },
            "event": {
                "specversion": "1.0",
                "id": "A234-1234-1235",
                "source": "/mycontext",
                "time": "2018-04-05T17:31:00Z",
                "type": "com.example.someeventtype",
                "data": "some data"
            }
        },
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDLeaL+nRJLNq3/5NXd/T0b",
                "deliveryCount": 1
            },
            "event": {
                "specversion": "1.0",
                "id": "B688-1234-1235",
                "source": "/mycontext",
                "type": "com.example.someeventtype",
                "time": "2018-04-05T17:31:00Z",
                "data": {
                    "somekey" : "value",
                    "someOtherKey" : 9
                }
            }
        }
    ]
}

Recapito push e pull

Griglia di eventi supporta il recapito di eventi push e pull tramite HTTP. Con il recapito push si definisce una destinazione in una sottoscrizione di eventi, un webhook o un servizio di Azure a cui Griglia di eventi invia eventi. Con il recapito pull, le applicazioni sottoscrittori si connettono a Griglia di eventi per utilizzare gli eventi. Il recapito pull è supportato per gli argomenti in uno spazio dei nomi di Griglia di eventi.

Importante

Hub eventi è supportato come destinazione per le sottoscrizioni agli argomenti dello spazio dei nomi. Nelle prossime versioni, gli spazi dei nomi di Griglia di eventi supporteranno tutte le destinazioni attualmente disponibili in Griglia di eventi base insieme a destinazioni aggiuntive.

Diagramma generale che mostra il recapito push e il recapito pull con il tipo di risorse coinvolte.

Quando usare il recapito push e il recapito pull

Di seguito sono riportate linee guida generali che consentono di decidere quando usare il recapito pull o push.

Recapito pull

  • È necessario il controllo completo su quando ricevere gli eventi. Ad esempio, l'applicazione potrebbe non essere sempre aggiornata, non abbastanza stabile o elaborare i dati in determinati momenti.
  • È necessario il controllo completo sull'utilizzo degli eventi. Ad esempio, un servizio downstream o un livello nell'applicazione consumer presenta un problema che impedisce l'elaborazione di eventi. In tal caso, l'API di recapito pull consente all'app consumer di rilasciare un evento già letto al broker in modo che possa essere recapitato in un secondo momento.
  • Si vogliono usare collegamenti privati quando si ricevono eventi, che è possibile solo con il recapito pull, non con il recapito push.
  • Non è possibile esporre un endpoint e usare il recapito push, ma è possibile connettersi a Griglia di eventi per utilizzare gli eventi.

Recapito push

  • Si vuole evitare il polling costante per determinare che si è verificata una modifica dello stato del sistema. È invece possibile usare Griglia di eventi per inviare eventi al momento in cui si verificano modifiche dello stato.
  • Si dispone di un'applicazione che non può effettuare chiamate in uscita. Ad esempio, l'organizzazione potrebbe preoccuparsi dell'esfiltrazione dei dati. Tuttavia, l'applicazione può ricevere eventi tramite un endpoint pubblico.

Passaggi successivi

Gli articoli seguenti forniscono informazioni su come usare Griglia di eventi o informazioni aggiuntive sui concetti.