---

Febbraio 2018

Volume 33 Numero 2

Il presente articolo è stato tradotto automaticamente.

Azure - Architettura basata su eventi sul cloud con la Griglia di eventi di Azure

Da David Barkol

È un'ora da un progettista cloud interessante. La velocità dell'innovazione ha portato a forefront una serie di nuove sfide e tecnologie che vengono modificate le soluzioni modo sono progettate. Beneficiare di tale crescita sono sviluppatori e progettisti che è possono scegliere tra una varietà di servizi e le opzioni.

Come gli sviluppatori passano attraverso l'esercizio di scomporre le architetture per sfruttare i vantaggi dei nuovi servizi come funzioni di Azure, App per la logica e altri, area ostacoli familiarità. In molti casi, si trova noi riunire nuovamente "glue" che consente di lavorare insieme questi servizi. L'avvio della griglia di eventi di Azure recente mira a risolvere questo problema, fornendo un servizio di routing di prima classe di evento nel cloud che sono completamente gestiti estremamente flessibile e scalabile.

In questo articolo verrà esplorare la flessibilità di griglia di eventi di Azure e Mostra come può essere utilizzato per risolvere familiarità problemi in applicazioni aziendali. Si consiglia di estrarre l'annuncio della disponibilità generale di griglia di eventi al anche aka.ms/egblog.

Inversione di dipendenze

Il concetto di utilizzo degli eventi in un'applicazione o la soluzione non è nuovo. In effetti, la programmazione basata sugli eventi ha utilizzato correttamente il concetto per molto tempo. Le code di pubblicazione/sottoscrizione e GUI sono solo alcuni degli esempi che consentono di sfruttare il principio di reazione agli eventi che si verificano in un'organizzazione, l'applicazione o del sistema.

Uno dei tenant principale di un'architettura basata su eventi è per invertire le dipendenze che possono disporre di servizi esistenti tra loro. Figura 1 viene illustrato un esempio di un set di processi che si basano su loro per comunicare e supportano un reparto risorse umane (HR).

Figura 1 Services che contengono la logica su altri servizi

Per questa struttura funzionare, ogni servizio deve contenere la logica di base su altri utenti di comunicare. Queste dipendenze creare problemi, non solo in termini di scala, ma anche che questa logica è sparsi nell'intera architettura. Nel corso del tempo, quando questi tipi di soluzioni espande, diventano sempre più fragile e difficili da gestire quando vengono introdotti ulteriori modifiche e le dipendenze.

In alternativa, il concetto di una progettazione basata sugli eventi rimuove queste dipendenze promuovendo il concetto di un evento come un elemento che è un cittadino l'architettura di prima classe. Questa considerazione importante consente molti altri sistemi la possibilità di utilizzare un servizio centralizzato senza l'onere di dipendenze e la logica in diverse località geografiche in tutta l'applicazione. Figura 2 evidenzia l'inversione di dipendenze per la soluzione del reparto risorse Umane introducendo il concetto principale.

Figura 2 centralizzata servizio che inverte le dipendenze tra gli altri servizi

Questo servizio chiave è ciò che il resto dell'articolo è dedicato. Sarà esplorazione della griglia di eventi di Azure e come può essere usato per supportare la nuova generazione delle soluzioni.

Introduzione della griglia di eventi di Azure

Griglia di eventi Azure è un servizio di nuovo, completamente gestito che supporta il routing di eventi utilizzando un modello di pubblicazione-sottoscrizione. In sostanza, della griglia di eventi è un servizio di routing di eventi che gestisce il routing e il recapito di eventi da numerose origini e i sottoscrittori. Figura 3, eseguito nella documentazione di panoramica della griglia di eventi (bit.ly/2qhaj9q), illustra molti dei server di pubblicazione e i gestori che possono essere utilizzati con griglia eventi oggi.

Figura 3 Panoramica della griglia di eventi di Azure

Viene creato un evento da un server di pubblicazione, ad esempio un account di archiviazione Blob, hub eventi o anche una sottoscrizione di Azure. Se si verificano gli eventi, che sta pubblicate in un endpoint denominato di un argomento che gestisce il servizio di griglia di eventi per tutti i messaggi in arrivo del digest. L'elenco dei servizi in Azure che si integrano con griglia di eventi è in aumento, con molte altre ancora l'orizzonte.

I Publisher di eventi non sono limitati ai servizi in Azure. Infatti, un caso d'uso molto comune include gli eventi che provengono da applicazioni personalizzate o i sistemi eseguiti da qualsiasi posizione. Sono incluse le applicazioni che sono ospitati in locale, in un Data Center o in altri cloud. Questi tipi di server di pubblicazione sono definiti come argomenti personalizzati. Se una richiesta HTTP al servizio di griglia di eventi possono registrare, quindi si tratta di candidati per l'invio di eventi.

I gestori di eventi includono diversi servizi in Azure, nonché. Questi illustrare alcune delle tecnologie emergenti senza server in Azure, ad esempio App per la logica e funzioni. Oltre automazione di Azure, un altro tipo di gestore eventi può essere qualsiasi callback HTTP, detta anche un WebHook. I gestori registrati con griglia eventi tramite la creazione di una sottoscrizione di eventi. Se l'endpoint del gestore eventi è pubblicamente accessibile e crittografati da Transport Layer Security, è possano inserire messaggi a esso dalla griglia di eventi.

A differenza di molti altri servizi di Azure, non è Nessuno spazio dei nomi della griglia di eventi che deve essere eseguito il provisioning o gestito. Argomenti per le risorse native di Azure sono compilati in e completamente trasparente all'utente mentre argomenti personalizzati vengono effettuato il provisioning ad hoc e presenti in un gruppo di risorse. Le sottoscrizioni di eventi sono semplicemente associate a un argomento. Questo modello semplifica la gestione degli argomenti sotto forma di sottoscrizioni e rende griglia eventi multi-tenant, consentendo di notevole scalabilità orizzontale.

Griglia di eventi Azure è indipendente da qualsiasi lingua o dalla piattaforma. Mentre si integra in modo nativo con servizi di Azure, può facilmente essere sfruttata da qualsiasi elemento che supporta il protocollo HTTP, che rende un servizio molto intelligente e innovativo.

Gli eventi o i comandi

Prima si approfondire alcuni codice e creare una soluzione che illustra alcune di queste funzionalità, consente di distinguere tra un evento e un comando. La differenza può talvolta essere meno evidente, ma è importante da comprendere quando si progettano i sistemi che si basano sui messaggi.

Quando una determinata azione o una risposta, viene inviato un messaggio, è molto probabile che un comando. Ad esempio, se un dipendente viene alzata di livello all'interno dell'organizzazione e viene inviato un messaggio per indicare il suo nuovo manager di compilare un modulo, quindi è caratterizzata da un obiettivo specifico o finalità. Perché il mittente del messaggio ha una previsione e in alcuni casi, potrebbe anche prevede una risposta, è possibile classificare questo come un comando.

Se viene pubblicato un messaggio senza informazioni o le aspettative di come verrà gestito, è considerato un evento. Si supponga che in un'organizzazione, lo stesso dipendente è richiesta per modificare l'indirizzo di posta. Poiché questa operazione potrebbe essere interessante di molti sistemi all'interno dell'organizzazione, ma non richiede il server di pubblicazione in particolare essere a conoscenza di uno di essi, è un messaggio che non definisce qualsiasi scopo. In questo caso, il server di pubblicazione è semplicemente la notifica le parti interessate che si è verificato un evento. È un evento e chiaramente un'occorrenza di un oggetto che rappresenta un'opzione valida per un servizio come griglia di eventi.

È possibile analizzare molte altre time queste distinzioni e inoltre come selezionare messaggistica servizio appropriato in Azure, tuttavia, che non rientra nell'ambito di questo articolo. Si consiglia di leggere questo post dettagliato Clemens Vasters dell'argomento: bit.ly/2CH3sbQ.

Uno Scenario di analisi delle risorse umane

Il modo migliore per ottenere una comprensione più approfondita della griglia di eventi è scrivendo codice che sfrutta le funzionalità. In questo articolo verrà esaminato alcuni eventi originati da un'applicazione HR fittizia. Verrà pubblicare eventi a un argomento personalizzato e quindi sottoscrivere gli eventi utilizzando diversi gestori diversi.

Per semplicità, saranno implementa due tipi di eventi di sistema delle risorse Umane, quando un dipendente viene aggiunto a un'organizzazione e quando un dipendente viene rimosso. Questi eventi sono abbastanza natura che fornirà opzioni che illustrano come filtrare e gestire eventi in modi diversi. Viene illustrata una rappresentazione visiva della soluzione nel figura 4.

Figura 4 soluzione di esempio

A livello generale, la soluzione è costituita da diversi componenti chiave che viene realizzato in questo articolo. È possibile analizzarli in seguito.

Eventi dipendente sarà un argomento dell'evento della griglia a cui l'applicazione delle risorse Umane può inviare messaggi. Ciò include gli eventi per nuovi e rimossi i dipendenti dell'organizzazione. Ogni messaggio conterrà informazioni dipendente, proprio reparto e il tipo di evento.

Nuovo dipendente iniziale sarà un'App di logica che sottoscrive i messaggi per i nuovi dipendenti dell'organizzazione. Verrà infine inviato un messaggio di benvenuto al nuovo dipendente.

Nuovo ordine di apparecchiature dipendente è una funzione di Azure che viene eseguita la sottoscrizione agli eventi per i nuovi dipendenti del reparto tecnico. Creerà quindi un messaggio in una coda per un'ulteriore elaborazione.

Record dipendente è un sito Web personalizzato basato su ASP.NET Core che dovrà esporre un'API Web per la ricezione dei messaggi quando un dipendente lascia l'organizzazione.

Creazione di un argomento personalizzato

Per iniziare, è necessario creare alcune risorse di base in Azure. È possibile avviare la Shell di Cloud di Azure dal portale o usare l'interfaccia della riga di comando (CLI) in locale. Informazioni dettagliate su come utilizzare la Shell di Cloud sono reperibile in bit.ly/2CsFtQB. Se non si utilizza la Shell Cloud prima di, altamente consigliabile.

La prima cosa che farò è creare un gruppo di risorse per gestire e incapsulare le risorse di Azure:

az group create --name <resource-group-name> --location <location>

Dopo aver creato il gruppo, viene eseguito il provisioning di un argomento dell'evento della griglia. Questo fornirà un endpoint per pubblicare eventi personalizzati dall'applicazione delle risorse Umane. Il nome dell'argomento deve essere univoco all'area di lavoro, poiché sarà un servizio accessibile pubblicamente in Azure. Il percorso deve essere anche in un'area con il servizio di griglia di eventi disponibile. In genere con il percorso westus2 o fare riferimento all'elenco dei servizi disponibili in ogni area di Azure (vedere bit.ly/2DU15ln).

az eventgrid topic create --name <topic-name> \
  --location <location> \
  --resource-group <resource group name>

Dopo avere eseguito il comando per creare l'argomento, verranno restituiti i dettagli sulla risorsa. L'output sarà simile a, ma non esattamente come, qui il codice:

{
  "endpoint": "https://<topic name>.westus2-1.eventgrid.azure.net/api/events",
  "id": "/subscriptions/xxxx-xxx-xx-xxx-xx/resourceGroups/eventgridsolution-rg/providers/Microsoft.EventGrid/topics/<topic name>",
  "location": "westus2",
  "name": "<topic name>",
  "provisioningState": "Succeeded",
  "resourceGroup": "eventgridsolution-rg",
  "tags": null,
  "type": "Microsoft.EventGrid/topics"
}

Prendere nota del valore di endpoint, verrà utilizzato in un secondo momento durante la pubblicazione di eventi. È necessario anche uno delle chiavi di due accesso generati per l'autorizzazione. Per recuperare le chiavi, è possibile elencare quelli associati all'argomento. È possibile e consigliabile ciclo e rigenerare le chiavi come misura di sicurezza, esattamente come avviene con altri servizi in Azure.

az eventgrid topic key list --name <topic-name> --resource-group <resource-group-name>

Se le preferenze si intende utilizzare nel portale di Azure, è possibile creare e visualizzare tutte queste opzioni e impostazioni disponibili, nonché.

Pubblicazione di un evento

Prima di inviare il primo evento, è necessario conoscere lo schema di eventi che è previsto dall'argomento. Ogni evento, indipendentemente se il server di pubblicazione è una risorsa di Azure o l'applicazione personalizzata, sarà conformi a questa struttura descritta nel seguente codice (un utile riferimento per lo schema di eventi, nonché alcuni esempi, è reperibile in bit.ly/2CG8oxI):

[
  {
    "topic": string,
    "subject": string,   
    "id": string,
    "eventType": string,
    "eventTime": string,
    "data":{
      object-unique-to-each-publisher
    }
  }
]

La prima cosa da notare è che gli eventi vengono inviati in una matrice. Questa operazione viene eseguita intenzionalmente per offrire la possibilità di inviare più eventi all'interno di una richiesta. Gli eventi possono essere inviati in batch, riducendo in tal frammentarietà rete supportando gli scenari in cui la connettività non è sempre disponibile.

Il primo evento che desidera pubblicare viene generato quando un nuovo dipendente unisce un'organizzazione. Il payload per questo evento potrebbe essere simile al contenuto di figura 5.

Figura 5 dipendenti aggiunta eventi

[{
  "id": "30934",
  "eventType": "employeeAdded",
  "subject": "department/engineering",
  "eventTime": "2017-12-14T10:10:20+00:00",
  "data":{
    "employeeId": "14",
    "employeeName": "Nigel Tufnel",
    "employeeEmail": "nigel@contoso.com",
    "manager": "itmanager@contoso.com",
    "managerId": "4"
  }
}]

Avanti in questo articolo userà la stessa struttura, con alcune differenze nei valori, come quando un dipendente lascia l'organizzazione. Le proprietà chiave in questo caso sono i seguenti:

eventType è un valore utilizzato per identificare in modo univoco il tipo di evento pubblicato. Questa proprietà può essere utilizzata da gestori che desiderano sottoscrivere solo i tipi di evento specifico, anziché tutti i tipi.

oggetto è un valore, ad esempio eventType, che è disponibile per fornire contesto aggiuntivo sull'evento, con la possibilità di specificare anche un ulteriore filtro ai sottoscrittori. È possibile usare eventType sia soggetto appena quando si crea le sottoscrizioni. Oggetto ed eventType fornire un contesto per l'evento.

i dati sono un bucket definiti server di pubblicazione che è semplicemente un oggetto che può contenere una o più proprietà. I server di pubblicazione assegnare informazioni rilevanti sull'evento all'interno di questa proprietà. Ad esempio, l'evento di archiviazione Blob di Azure include informazioni dettagliate su quali URL e il tipo di contenuto blob creato o eliminato.

Per pubblicare l'evento, utilizzare Postman (o uno strumento simile) per simulare il messaggio proveniente dall'applicazione delle risorse Umane per l'indirizzo dell'endpoint indicato in precedenza. Per l'autorizzazione, aggiungere un elemento nell'intestazione denominata aeg chiave di firma di accesso condiviso, ovvero il valore è una delle chiavi di accesso generate quando viene creato l'argomento. Il corpo della richiesta conterrà il payload citato in figura 5.

Poiché non è presente alcun sottoscrittore, c'è niente da osservare ancora. Il passaggio successivo sarà per vedere in azione creando alcuni gestori di eventi per la griglia di eventi per gli eventi per effettuare il push.

Gestione degli eventi con una funzione di Azure

Ora arriva fun fa parte di sottoscrivere gli eventi. Il primo gestore sarà una funzione di Azure. Per informazioni di base per creare una funzione, vedere bit.ly/2A6pFgu. Questa situazione, si desidera sottoscrivere in particolare gli eventi per i dipendenti aggiunti di recente. Inoltre e solo come importante, questo gestore deve essere richiamato solo per i dipendenti che appartengono al reparto theengineering.

La maggior parte degli esempi di informazioni sulla creazione di una funzione tramite il portale di Azure, ovvero Super-facilmente e rapidamente. Vorrei che illustrano come eseguire questa operazione in locale, da Visual Studio. Questo verrà operazioni preliminari per il codice più ambienti di produzione. Si utilizzerà inoltre un'utilità denominata ngrok (vedere ngrok.com) per supportare il debug locale con la griglia di eventi.

Se si desidera seguire la procedura, è necessario ngrok, nonché una versione aggiornata di Visual Studio (versione 15.5.2 utilizzato per questo articolo). Per iniziare, creare un nuovo progetto e selezionare le funzioni di Azure dai modelli Cloud. Nella finestra di dialogo Nuovo progetto, selezionare l'opzione di attivazione HTTP e mantenere i valori predefiniti.

Aggiornare il codice per la funzione in base a ciò che viene rappresentato in figura 6. È possibile rinominare il file in modo da riflettere il nome della funzione.

Figura 6 implementazione per il nuovo gestore eventi dipendente >

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;
using Newtonsoft.Json;
namespace NewEmployeeApp
{
  public static class NewEmployeeHandler
  {
    public class GridEvent<T> where T : class
    {
      public string Id { get; set; }
      public string EventType { get; set; }
      public string Subject { get; set; }
      public DateTime EventTime { get; set; }
      public T Data { get; set; }
      public string Topic { get; set; }
    }
      [FunctionName("newemployeehandler")]
      public static async Task<HttpResponseMessage> Run(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = null)]
        HttpRequestMessage req,
        TraceWriter log)
         {
          log.Info("New Employee Handler Triggered");
          // Retrieve the contents of the request and
          // deserialize it into a grid event object.
          var jsonContent = await req.Content.ReadAsStringAsync();
          var gridEvent =
            JsonConvert.DeserializeObject<List<GridEvent<Dictionary<string,
              string>>>>(jsonContent)
              ?.SingleOrDefault();
            // Check to see if the event is available and
            // return an error response if its missing.
            if (gridEvent == null)
            {
              return req.CreateErrorResponse(HttpStatusCode.BadRequest,
                $@"Missing event details");
            }
          // Check the header to identify the type of request
          // from Event Grid. A subscription validation request
          // must echo back the validation code.
          var gridEventType = req.Headers.GetValues("Aeg-Event-Type"). 
            FirstOrDefault();
          if (gridEventType == "SubscriptionValidation")
          {
            var code = gridEvent.Data["validationCode"];
            return req.CreateResponse(HttpStatusCode.OK,
              new { validationResponse = code });
          }
          else if (gridEventType == "Notification")
          {
            // Pseudo code: place message into a queue
            // for further processing.
            return req.CreateResponse(HttpStatusCode.OK);
          }
          else
          {
            return req.CreateErrorResponse(HttpStatusCode.BadRequest,
              $@"Unknown request type");
          }
        }
  }
}

È importante codice in questa sezione. All'inizio è una classe denominata GridEvent destinati in modo da riflettere il payload e lo schema di eventi dalla griglia di eventi. Idealmente, sarebbe inserire questa classe in una libreria comune in modo che possa essere riutilizzato. Per questo esempio, è possibile deserializzare il contenuto della richiesta in un oggetto fortemente tipizzato.

Griglia eventi verrà inviato ai relativi tipi di due sottoscrittori di richieste, SubscriptionValidation e notifica, che è possibile identificare un valore dall'intestazione del controllo. La richiesta di convalida è importante assicurarsi che tutti i sottoscrittori vengono aggiunti in modo esplicito. Devo eseguire qui è visualizzato il codice di convalida per confermare che è possibile ricevere messaggi:

var code = gridEvent.Data["validationCode"];
return req.CreateResponse(HttpStatusCode.OK,
  new { validationResponse = code });

Le richieste di convalida possono essere inoltre individuate in base al tipo di evento: Microsoft.EventGrid.SubscriptionValidationEvent. Se il tipo di evento di notifica, quindi procedere con l'implementazione della logica di business. Questo approccio di programmazione difensivo è consigliabile quando si espone endpoint da altri servizi.

Funzioni che sono ospitate in Azure e vengono fatto riferimento con il dominio azurewebsites.net, non richiedono la logica di convalida della sottoscrizione. Al contrario, si tratta di consentito dalla griglia di eventi insieme a molti altri servizi, ad esempio App per la logica e i callback di automazione di Azure, eseguire documentazione. Poiché prevede di test in locale, è necessario restituire il codice di convalida per la griglia di eventi riconoscere la funzione come un endpoint valido.

Infine, il runtime di griglia eventi SDK consente di gestire gran parte del programma di installazione, tramite la deserializzazione di eventi e creazione fortemente tipizzata oggetti evento griglia, per convalidare automaticamente gli endpoint. Redazione del presente documento, il runtime aggiornato SDK non sono ancora disponibili.

Test di funzione locale

Iniziamo la funzione da Visual Studio in modo che venga eseguito in locale sulla porta 7071. Quando è in esecuzione, aprire un prompt dei comandi e utilizzare ngrok per creare un tunnel sicuro:

ngrok http -host-header=localhost 7071

Otterrà un indirizzo HTTPS da ngrok da usare come l'endpoint del sottoscrittore. L'indirizzo dovrebbe essere simile https://d69f6bed.ngrok.io, ma con un sottodominio diverso viene eseguito ogni volta che il comando ngrok. Aggiungere la route del nostro funzione all'URL in modo che risulti simile simile https://<generated-value>.ngrok.io/api/newemployeehandler. Questo sarà l'indirizzo dell'endpoint per la sottoscrizione dell'evento.

Con l'esecuzione della funzione e tunnel sicuro sul posto, ora è possibile creare la sottoscrizione dell'evento da CLI o della Shell di Cloud di Azure:

az eventgrid event-subscription create --name <event-subscription-name> \
  --resource-group <resource group name> \
  --topic-name <topic name> \
  --subject-ends-with engineering \
  --included-event-type employeeAdded \
  --endpoint <function endpoint>

Facoltativamente, è possibile aggiungere una sottoscrizione di eventi dal portale, compilare la finestra di dialogo, come illustrato nella figura 7.

Figura 7, la creazione di una sottoscrizione di eventi dal portale

Si desidera chiamare diversi argomenti importanti per la creazione della sottoscrizione di eventi.

oggetto-inizia-con (filtro di prefisso) è un argomento facoltativo che consente di filtrare in base al prefisso del campo negli eventi oggetto. È una corrispondenza di stringa letterale. Espressioni regolari e caratteri jolly non sono supportate.

termina con oggetto (filtro di suffisso) è un argomento facoltativo in base a un suffisso per filtrare gli eventi. Espressioni regolari e caratteri jolly non sono supportate.

incluso--tipo di evento (tipi di evento) è un elenco facoltativo di tipi di evento da sottoscrivere. Ogni tipo è separato da uno spazio.

Ora è possibile visualizzare per l'esempio di evento di pubblicazione in questo articolo per garantire che gli eventi vengono propagate attraverso da Postman, alla griglia di eventi e infine alla funzione locale. È possibile modificare i valori nella richiesta per convalidare i filtri funzionino come previsto.

Gestione degli eventi: WebHook e logica App

La sottoscrizione dell'evento successiva è un'App di logica. Come illustrato nell'esempio di funzione di Azure, è interessato solo nel tipo di evento dei dipendenti. Poiché si desidera inviare un messaggio ai dipendenti di tutti i reparti è non di sfruttare i filtri di prefisso o suffisso. La versione completa dell'App per la logica viene visualizzata figura 8.

Figura 8 A logica App che accoglie i nuovi dipendenti

App per la logica inizia con un trigger di griglia di eventi. Selezionando il tipo di risorsa Microsoft.EventGrid.topics mi consentirà di scegliere tra gli argomenti personalizzati nella sottoscrizione.

L'azione di analizzare JSON può essere utile per l'accesso alle proprietà all'interno dell'oggetto dati. Si utilizzerà il payload di esempio per generare lo schema:

{
  "id": "40000",
  "eventType": "employeeAdded",
  "subject": "department/finance",
  "eventTime": "2017-12-20T10:10:20+00:00",
  "data":{
    "employeeId": "24",
    "employeeName": "David St. Hubbins",
    "employeeEmail": "david@contoso.com",
    "manager": "finance@contoso.com",
    "managerId": "10"
  }
}

Successivamente, il filtro per il tipo di evento deve essere eseguito con una condizione di azione. Questo rappresenta una lieve differenza da come la sottoscrizione dell'evento è stata creata con la funzione perché non è possibile selezionare questa opzione nel caso in cui attivare griglia.

L'ultimo passaggio invia un messaggio di posta elettronica al dipendente. Usa le proprietà che sono state recuperate dal secondo passaggio per popolare i campi di oggetto del messaggio di posta e l'indirizzo del destinatario. Per testare App per la logica, fare clic su Esegui nella finestra di progettazione e inviare un messaggio all'endpoint come prima.

La sottoscrizione dell'ultimo evento è un callback HTTP di base o WebHook. Aggiorna un'applicazione ASP.NET Core esistente con un'API Web per gli eventi in ingresso. Il codice per il WebHook sarà molto simile alla funzione Azure ho scritto in precedenza. Alcune piccole differenze includono il modo in cui i valori di intestazione vengono recuperati per controllare il tipo di richiesta, come illustrato nel figura 9.

Figura 9 A Web API Controller che riceve gli eventi

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Text;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Newtonsoft.Json;
namespace EmployeeRecords.Controllers
{
  public class GridEvent<T> where T : class
  {
    public string Id { get; set; }
    public string Subject { get; set; }
    public string EventType { get; set; }
    public T Data { get; set; }
    public DateTime EventTime { get; set; }
  }
  [Produces("application/json")]
  [Route("api/EmployeeUpdates")]
  public class EmployeeUpdatesController : Controller
  {
    private bool EventTypeSubcriptionValidation
      => HttpContext.Request.Headers["aeg-event-type"].FirstOrDefault() ==
        "SubscriptionValidation";
    private bool EventTypeNotification
      => HttpContext.Request.Headers["aeg-event-type"].FirstOrDefault() ==
        "Notification";
    [HttpPost]
    public async Task<HttpResponseMessage> Post()
    {
      using (var reader = new StreamReader(Request.Body, Encoding.UTF8))
      {
        var jsonContent = await reader.ReadToEndAsync();
        var gridEvent =
          JsonConvert.DeserializeObject<List<GridEvent<Dictionary<string,
          string>>>>(jsonContent)
            .SingleOrDefault();
        if (gridEvent == null)
        {
          return new HttpResponseMessage { StatusCode = HttpStatusCode.BadRequest};
        }
        // Check the event type from Event Grid.
        if (EventTypeSubcriptionValidation)
        {
          // Retrieve the validation code and echo back.
          var validationCode = gridEvent.Data["validationCode"];
          var validationResponse =
            JsonConvert.SerializeObject(new { validationResponse =
            validationCode });
          return new HttpResponseMessage
          {
            StatusCode = HttpStatusCode.OK,
            Content = new StringContent(validationResponse)
          };
        }
        else if (EventTypeNotification)
        {
          // Pseudo code: Update records
          return new HttpResponseMessage { StatusCode = HttpStatusCode.OK };
        }
        else
        {
          return new HttpResponseMessage { StatusCode = HttpStatusCode.BadRequest };
        }
      }
    }
  }
}

Quando si crea la sottoscrizione dell'evento, il tipo di evento registrato deve essere employeeRemoved. Questa modifica soddisfa il requisito che il gestore desidera solo ricevere messaggi per un dipendente che viene rimosso dall'organizzazione. Si noti inoltre che il prefisso e suffisso filtri vengono utilizzati perché il sottoscrittore desidera ricevere una notifica per ogni occorrenza, indipendentemente dal reparto:

az eventgrid event-subscription create --name <event-subscription-name> \
  --resource-group <resource group name> \
  --topic-name <topic name> \
  --included-event-type employeeRemoved \
  --endpoint <function endpoint>

Infine, tenere presente che l'endpoint per la sottoscrizione dell'evento deve essere protetta. Se si fa riferimento un servizio App in Azure, è necessario specificare HTTPS nell'indirizzo oppure la sottoscrizione di aggiunta avrà esito negativo.

Conclusioni

Azure griglia di eventi è realmente un servizio di modifica di gioco. In questo articolo risolto uno scenario di integrazione dell'applicazione comune. Griglia di eventi è stata usata come la tecnologia di attivazione per connettere l'applicazione ad altri servizi, ad esempio una funzione di Azure, un'App per la logica e anche un WebHook personalizzato può risiedere in qualunque posizione. Quando è integrata con le app senza, griglia eventi indicati, come i due insieme possono sfruttare la funzionalità di integrazione che supporta Azure e un notevole scalabilità. Il codice in questo articolo è reperibile in github.com/dbarkol/AzureEventGrid.

---

David Barkolè uno specialista di Azure in Microsoft sul Team nero trasportatore globale. È possibile contattarlo su Twitter: @dbarkol o tramite posta elettronica in dabarkol@microsoft.com.

Grazie ai seguenti esperti Microsoft per la revisione dell'articolo: Bahram Banisadr e Dan Rosanovsanova
Dan Rosanova è il responsabile del principio Program Manager responsabile della suite di messaggistica di Azure di prodotti tra cui Bus di servizio, gli hub di eventi, inoltro di Azure e della griglia di eventi.
 
Bahram Banisadr è PM responsabile della griglia di eventi di Azure per compilare il connettivo per servizi di Azure.

---

Viene illustrato in questo articolo nel forum di MSDN Magazine