Pull-leverans med HTTP

  • Artikel

Den här artikeln bygger på artikeln Vad är Azure Event Grid? och i artikeln Event Grid-begrepp för att tillhandahålla viktig information innan du börjar använda Event Grids pull-leverans via HTTP. Den omfattar grundläggande begrepp, resursmodeller och meddelandeleveranslägen som stöds. I slutet av det här dokumentet hittar du användbara länkar till artiklar som vägleder dig om hur du använder Event Grid och till artiklar som erbjuder djupgående konceptuell information.

Kommentar

Det här dokumentet hjälper dig att komma igång med Event Grid-funktioner som använder HTTP-protokollet. Den här artikeln är lämplig för användare som behöver integrera program i molnet. Om du behöver kommunicera IoT-enhetsdata kan du läsa Översikt över MQTT Broker-funktionen i Azure Event Grid.

CloudEvents

Event Grid-namnområdesämnen accepterar händelser som följer CNCF:s öppna CloudEvents 1.0-standardspecifikation med http-protokollbindningen med JSON-format.

Mer information finns i CloudEvents-begreppen .

CloudEvents con tältläge s

CloudEvents-specifikationen definierar tre tältläge som du kan använda: binär, strukturerad och batchbaserad.

Viktigt!

Med valfri con tältläge kan du utbyta text (JSON, text/*osv.) eller binära kodade händelsedata. Binärt con tältläge används inte uteslutande för att skicka binära data.

Con tältläge handlar inte om den kodning som du använder, binär eller text, utan om hur händelsedata och dess metadata beskrivs och utbyts. Den strukturerade con tältläge använder en enda struktur, till exempel ett JSON-objekt, där både kontextattributen och händelsedata är tillsammans i HTTP-nyttolasten. Binärkon tältläge separerar kontextattribut som mappas till HTTP-huvuden och händelsedata, som är HTTP-nyttolasten kodad enligt medietypvärdet i Content-Type.

Mer information finns i CloudEvents con tältläge s.

Meddelanden och händelser

En CloudEvent innehåller vanligtvis händelsedata som meddelar en förekomst i ett system, det vill säga en ändring av systemtillståndet. Du kan dock förmedla alla typer av data när du använder CloudEvents. Du kanske till exempel vill använda Exchange-formatet CloudEvents för att skicka ett kommandomeddelande för att begära en åtgärd till ett underordnat program. Ett annat exempel är när du dirigerar meddelanden från Event Grids MQTT-asynkron meddelandekö till ett ämne. I det här scenariot dirigerar du ett MQTT-meddelande i ett CloudEvents-kuvert.

Pull-leverans

Med pull-leverans ansluter ditt program till Event Grid för att läsa CloudEvents med hjälp av köliknande semantik.

Pull-leverans erbjuder följande fördelar med händelseförbrukning:

  • Använd händelser i din egen takt, i stor skala eller i en ingressfrekvens som ditt program stöder.

  • Använd händelser vid en tidpunkt som du själv väljer. Till exempel, med tanke på affärskrav, bearbetas meddelanden på natten.

  • Använd händelser via en privat länk så att dina data använder privat IP-utrymme.

Kommentar

  • Namnområden ger en enklare resursmodell med en enda typ av ämne. För närvarande stöder Event Grid publicering av egna programhändelser via namnområdesämnen. Du kan inte använda händelser från Azure-tjänster eller SaaS-partnersystem med hjälp av namnområdesavsnitt. Du kan inte heller skapa systemämnen, domänämnen eller partnerämnen i ett namnområde.
  • Namnområdesämnen stöder CloudEvents JSON-format.

Köhändelseprenumerationer

När du tar emot händelser eller använder åtgärder som hanterar händelsetillstånd anger ett program en HTTP-slutpunkt för namnområdet, ett ämnesnamn och namnet på en köhändelseprenumeration . En köhändelseprenumeration har sin leveransMode inställd på "kö". Köhändelseprenumerationer används för att använda händelser med hjälp av PULL-leverans-API:et. Mer information om hur du skapar dessa resurser finns i skapa namnrymder, ämnen och händelseprenumerationer.

Du använder en händelseprenumeration för att definiera filtreringsvillkoren för händelser och när du gör det definierar du effektivt den uppsättning händelser som är tillgängliga för förbrukning via den händelseprenumerationen. En eller flera prenumerantprogram (konsument) kan ansluta till samma namnområdesslutpunkt och använda samma ämnes- och händelseprenumeration.

Diagram på hög nivå för en utgivare och konsument med hjälp av en händelseprenumeration. Konsumenten använder pull-leverans.

Pull-leveransåtgärder

Programmet använder följande åtgärder när du arbetar med pull-leverans.

  • En mottagningsåtgärd används för att läsa en eller flera händelser med en enda begäran till Event Grid. Som standard väntar mäklaren i upp till 60 sekunder på att händelser ska bli tillgängliga. Händelser blir till exempel tillgängliga för leverans när de först publiceras. En lyckad mottagningsbegäran returnerar noll eller fler händelser. Om händelser är tillgängliga returneras så många tillgängliga händelser som möjligt upp till det begärda antalet händelser. Event Grid returnerar också en låstoken för varje händelseläsning.
  • En låstoken är en typ av handtag som identifierar en händelse som du kan använda för att styra dess tillstånd.
  • När ett konsumentprogram tar emot en händelse och bearbetar den bekräftar den händelsen. Den här åtgärden instruerar Event Grid att ta bort händelsen så att den inte levereras på nytt till en annan klient. Konsumentprogrammet bekräftar en eller flera token med en enda begäran genom att ange deras låstoken innan de upphör att gälla.

Vid vissa andra tillfällen kanske ditt konsumentprogram vill släppa eller avvisa händelser.

  • Ditt konsumentprogram släpper en mottagen händelse för att signalera att Event Grid inte är redo att bearbeta händelsen och göra den tillgänglig för omleverans. Det gör den genom att anropa versionsåtgärden med låstoken som identifierar de händelser som ska returneras tillbaka till Event Grid. Ditt program kan styra om händelsen ska släppas omedelbart eller om en fördröjning ska användas innan händelsen är tillgänglig för omleverans.

  • Du kan välja att avvisa en händelse om det finns ett villkor, eventuellt permanent, som hindrar ditt konsumentprogram att bearbeta händelsen. Ett felaktigt meddelande kan till exempel avvisas eftersom det inte kan parsas. Avvisade händelser är obeställbara om ett mål med obeställbara meddelanden är tillgängligt. Annars tappas de.

Omfång för vilka pull-leveransåtgärder som körs

När du anropar en åtgärd för att ta emot, bekräfta, släppa, avvisa eller förnya lås utförs dessa åtgärder i kontexten för händelseprenumerationen. Om du till exempel bekräftar en händelse är händelsen inte längre tillgänglig via den händelseprenumeration som används när du anropar bekräftelseåtgärden. En annan händelseprenumeration kan fortfarande ha samma händelse tillgänglig. Det beror på att en händelseprenumeration hämtar en kopia av de publicerade händelserna. Dessa händelsekopior skiljer sig effektivt från varandra mellan händelseprenumerationer. Varje händelse har sitt eget tillstånd oberoende av andra händelser.

Dataform när du tar emot händelser med pull-leverans

När du levererar händelser med pull-leverans innehåller Event Grid en matris med objekt som i sin tur innehåller objekten event och brokerProperties . Värdet för händelseegenskapen är CloudEvent som levereras i strukturerade con tältläge. BrokerProperties-objektet innehåller låstoken som är associerad med den levererade CloudEvent. Följande json-objekt är ett exempelsvar från en mottagningsåtgärd som returnerar två händelser:

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

Push- och pull-leverans

Event Grid stöder leverans av push- och pull-händelser med HTTP. Med push-leverans definierar du ett mål i en händelseprenumeration, en webhook eller en Azure-tjänst som Event Grid skickar händelser till. Med pull-leverans ansluter prenumerantprogram till Event Grid för att använda händelser. Pull-leverans stöds för ämnen i ett Event Grid-namnområde.

Viktigt!

Event Hubs stöds som mål för prenumerationer till namnområdesämnen. I kommande versioner kommer Event Grid-namnområden att stödja alla mål som för närvarande är tillgängliga i Event Grid Basic tillsammans med ytterligare destinationer.

Diagram på hög nivå som visar push-leverans och pull-leverans med den typ av resurser som ingår.

När du ska använda push-leverans jämfört med pull-leverans

Följande är allmänna riktlinjer som hjälper dig att bestämma när du ska använda pull- eller push-leverans.

Pull-leverans

  • Du behöver fullständig kontroll över när händelser ska ta emot. Ditt program kanske till exempel inte är igång hela tiden, inte tillräckligt stabilt, eller så bearbetar du data vid vissa tidpunkter.
  • Du behöver fullständig kontroll över händelseförbrukningen. Till exempel har en underordnad tjänst eller ett lager i ditt konsumentprogram ett problem som hindrar dig från att bearbeta händelser. I så fall tillåter PULL-leverans-API:et att konsumentappen släpper en redan läst händelse till asynkron meddelandekö så att den kan levereras senare.
  • Du vill använda privata länkar när du tar emot händelser, vilket endast är möjligt med pull-leveransen, inte push-leveransen.
  • Du har inte möjlighet att exponera en slutpunkt och använda push-leverans, men du kan ansluta till Event Grid för att använda händelser.

Push-leverans

  • Du vill undvika konstant avsökning för att fastställa att en systemtillståndsändring har inträffat. Du använder hellre Event Grid för att skicka händelser till dig när tillståndsändringar sker.
  • Du har ett program som inte kan göra utgående anrop. Din organisation kan till exempel vara bekymrad över dataexfiltrering. Ditt program kan dock ta emot händelser via en offentlig slutpunkt.

Nästa steg

I följande artiklar får du information om hur du använder Event Grid eller ger dig ytterligare information om begrepp.