Middleware

VAN TOEPASSING OP: SDK v4

Middleware is een klasse die zich tussen de adapter en uw bot-logica bevindt, en die tijdens de initialisatie wordt toegevoegd aan de middlewareverzameling van uw adapter. Met de SDK kunt u uw eigen middleware schrijven of middleware toevoegen die door anderen is gemaakt. Elke activiteit die wordt verzonden naar of vanuit uw bot, loopt via uw middleware.

De adapter verwerkt en stuurt binnenkomende activiteiten door middel van de pijplijn voor bot-middleware naar de logica van uw bot en keert vervolgens weer terug. Elke activiteit stroomt in en uit de bot, maar elk deel van middleware kan de activiteit controleren of hierop reageren, zowel vóór als na uitvoering van de bot-logica.

Voordat u overgaat tot middleware, is het belangrijk om bots in het algemeen te begrijpen en hoe ze activiteiten verwerken.

Gebruikt voor middleware

De vraag komt vaak op: 'Wanneer moet ik acties implementeren als middleware versus het gebruik van mijn normale botlogica?' Middleware biedt u extra mogelijkheden om te communiceren met de gespreksstroom van uw gebruikers voor en na elke beurt van het gesprek wordt verwerkt. Met Middleware kunt u ook informatie over het gesprek opslaan en ophalen, indien nodig, aanvullende verwerkingslogica aanroepen. Hieronder vindt u enkele veelvoorkomende scenario's waarin wordt aangegeven waar middleware nuttig kan zijn.

Elke activiteit bekijken of erop reageren

Er zijn tal van situaties waarin uw bot iets moet doen voor elke activiteit of voor elke activiteit van een bepaald type. U kunt bijvoorbeeld elke berichtactiviteit registreren die uw bot ontvangt of een terugvalreactie geven als de bot anders geen reactie heeft gegenereerd. Middleware is een uitstekende plek voor dergelijke processen, met de mogelijkheid om zowel voor als na de rest van de botlogica te handelen.

De turncontext wijzigen of verbeteren

Bepaalde gesprekken kunnen veel vruchtbaarder zijn als de bot meer informatie heeft dan wat in de activiteit is opgegeven. Middleware in dit geval kan kijken naar de gespreksstatusinformatie die het tot nu toe heeft, een query uitvoeren op een externe gegevensbron en deze toevoegen aan het turncontextobject voordat de uitvoering wordt doorgegeven aan de botlogica.

De SDK definieert middleware voor logboekregistratie die binnenkomende en uitgaande activiteiten kan vastleggen, maar u kunt ook uw eigen middleware definiëren.

De middleware-pijplijn van de bot

Voor elke activiteit roept de adapter middleware aan in de volgorde waarin u deze hebt toegevoegd. De adapter geeft het contextobject door voor de beurt en een volgende gemachtigde. De middleware roept de gemachtigde aan om het besturingselement door te geven aan de volgende middleware in de pijplijn. Middleware heeft ook de mogelijkheid om dingen te doen nadat de volgende gemachtigde terugkeert voordat de methode wordt voltooid. U kunt het zien als elk middlewareobject de eerste en laatste kans heeft om te handelen met betrekking tot de middlewareobjecten die deze volgen in de pijplijn.

Bijvoorbeeld:

• De draaihandler van het eerste middlewareobject voert code uit voordat u de volgende aanroept.
  • Met de tweede middlewareobjecthandler wordt code uitgevoerd voordat u de volgende aanroept.
    • De draaihandler van de bot wordt uitgevoerd en retourneert.
  • De tweede middlewareobjecthandler voert eventuele resterende code uit voordat deze wordt geretourneerd.
• De turn-handler van het eerste middlewareobject voert alle resterende code uit voordat deze wordt geretourneerd.

Als middleware de volgende gemachtigde niet aanroept, roept de adapter geen van de volgende middleware- of bothandlers aan en worden de pijplijn kortsluitingen niet aangeroepen.

Zodra de middleware-pijplijn van de bot is voltooid, is de turn over en valt de context buiten het bereik.

Middleware of de bot kan antwoorden genereren en reactiegebeurtenishandlers registreren, maar houd er rekening mee dat antwoorden in afzonderlijke processen worden verwerkt.

Volgorde van middleware

Aangezien de volgorde waarin middleware wordt toegevoegd, de volgorde bepaalt waarin de middleware een activiteit verwerkt, is het belangrijk om te bepalen welke volgorde middleware moet worden toegevoegd.

Notitie

Dit is bedoeld om u een gemeenschappelijk patroon te geven dat werkt voor de meeste bots, maar zorg ervoor dat u rekening houdt met hoe elk onderdeel van middleware met de anderen voor uw situatie zal communiceren.

Middleware die zorgt voor de taken op het laagste niveau die eerst aan elke bot moeten worden toegevoegd aan uw middleware-pijplijn. Voorbeelden hiervan zijn logboekregistratie, afhandeling van uitzonderingen en vertaling. Bestel deze afhankelijk van uw behoeften, zoals of u wilt dat het binnenkomende bericht eerst wordt vertaald, voordat berichten worden opgeslagen, of als de berichtenopslag eerst moet plaatsvinden, wat kan betekenen dat opgeslagen berichten niet worden vertaald.

Botspecifieke middleware moet als laatste worden toegevoegd aan uw middleware-pijplijn, middleware die u implementeert om enige verwerking uit te voeren voor elk bericht dat naar uw bot wordt verzonden. Als uw middleware gebruikmaakt van statusgegevens of andere gegevens die zijn ingesteld in de botcontext, voegt u deze toe aan de middleware-pijplijn na de middleware die de status of context wijzigt.

Kortsluiting

Een belangrijk idee rond middleware en antwoordhandlers is kortsluiting. Als de uitvoering moet worden voortgezet door de lagen die erop volgen, is middleware (of een antwoordhandler) vereist om de uitvoering door te geven door de volgende gemachtigde aan te roepen. Als de volgende gemachtigde niet binnen die middleware (of antwoordhandler) wordt aangeroepen, worden de bijbehorende pijplijn short circuits en volgende lagen niet uitgevoerd. Dit betekent dat alle botlogica en eventuele middleware verder langs de pijplijn worden overgeslagen. Er is een subtiel verschil tussen uw middleware en uw antwoordhandler kortsluiting van een draai.

Wanneer middleware kortsluitingen een draai hebben, wordt de handler van de bot niet aangeroepen, maar worden alle middlewarecode die vóór dit punt in de pijplijn wordt uitgevoerd, nog steeds uitgevoerd tot voltooiing.

Voor gebeurtenis-handlers betekent niet volgende aanroepen dat de gebeurtenis wordt geannuleerd, wat heel anders is dan middleware-overslaan logica. Door de rest van de gebeurtenis niet te verwerken, verzendt de adapter deze nooit.

Tip

Als u een reactiegebeurtenis voor kortsluiting uitvoert, zoals SendActivities, moet u ervoor zorgen dat dit het gedrag is dat u van plan bent. Anders kan dit leiden tot een moeilijke oplossing van bugs.

Reactie-gebeurtenis-handlers

Naast de toepassings- en middlewarelogica kunnen antwoordhandlers (ook wel gebeurtenis-handlers of gebeurtenis-handlers genoemd) worden toegevoegd aan het contextobject. Deze handlers worden aangeroepen wanneer het bijbehorende antwoord op het huidige contextobject plaatsvindt voordat het werkelijke antwoord wordt uitgevoerd. Deze handlers zijn handig wanneer u weet dat u iets wilt doen, vóór of na de werkelijke gebeurtenis, voor elke activiteit van dat type voor de rest van het huidige antwoord.

Waarschuwing

Wees voorzichtig met het niet aanroepen van een activiteitsreactiemethode vanuit de respectieve reactie-gebeurtenishandler, bijvoorbeeld het aanroepen van de methode voor verzenden activiteit vanuit een handler voor verzenden. Dit kan een oneindige lus genereren.

Onthoud dat elke nieuwe activiteit een nieuwe thread krijgt om uit te voeren. Wanneer de thread voor het verwerken van de activiteit wordt gemaakt, wordt de lijst met handlers voor die activiteit gekopieerd naar die nieuwe thread. Er worden na dat punt geen handlers toegevoegd voor die specifieke activiteitsgebeurtenis. De handlers die zijn geregistreerd op een contextobject, worden op dezelfde manier verwerkt als de manier waarop de adapter de middleware-pijplijn beheert. Handlers worden namelijk aangeroepen in de volgorde waarin ze worden toegevoegd en het aanroepen van de volgende gedelegeerde geeft het besturingselement door aan de volgende geregistreerde gebeurtenis-handler. Als een handler de volgende gemachtigde niet aanroept, worden geen van de volgende gebeurtenis-handlers aangeroepen, de kortsluitingen van de gebeurtenis en verzendt de adapter het antwoord niet naar het kanaal.

Status verwerken in middleware

Een veelgebruikte methode voor het opslaan van de status is het aanroepen van de methode voor het opslaan van wijzigingen aan het einde van de turn-handler. Hier volgt een diagram met de focus op het gesprek.

Het probleem met deze benadering is dat alle statusupdates die zijn gemaakt van een aantal aangepaste middleware die plaatsvindt nadat de turn-handler van de bot is geretourneerd, niet worden opgeslagen in duurzame opslag. De oplossing is om de aanroep naar de methode voor het opslaan van wijzigingen te verplaatsen naar nadat de aangepaste middleware is voltooid door een exemplaar van de middleware voor automatisch opslaan toe te voegen aan het begin van de middlewarestack, of ten minste vóór een van de middleware die de status kan bijwerken. De uitvoering wordt hieronder weergegeven.

Voeg de statusbeheerobjecten toe die moeten worden bijgewerkt naar een botstatussetobject en gebruik deze vervolgens wanneer u de middleware voor automatisch opslaan maakt.

Aanvullende bronnen

U kunt de middleware voor transcriptlogger bekijken, zoals geïmplementeerd in de Bot Framework SDK [C# | JS].