Algemene veelgestelde vragen over Bot Framework

Sommige kanalen bieden geen ondersteuning voor tijdelijke type-updates in hun client.

De Verbinding maken orbibliotheek is de expositie van de REST API. De Opbouwfunctiebibliotheek voegt het gespreksdialoogmodel en andere functies toe, zoals prompts, watervallen, ketens en voltooiing van begeleide formulieren. De Builder-bibliotheek biedt ook toegang tot Azure AI-services, zoals begrip van natuurlijke taal.

Wanneer de gebruiker een bericht via een kanaal verzendt, verzendt de Bot Framework-webservice een HTTPS POST naar het webservice-eindpunt van de bot. De bot kan nul, één of veel berichten naar de gebruiker op dat kanaal verzenden door een afzonderlijke HTTPS POST naar het Bot Framework te verzenden voor elk bericht dat wordt verzonden.

Vanuit het perspectief van uw bot betekent 'reactief' dat de gebruiker het gesprek start door een bericht naar de bot te verzenden en dat de bot reageert door op dat bericht te reageren. Daarentegen betekent 'proactief' dat de bot het gesprek start door het eerste bericht naar de gebruiker te verzenden. Een bot kan bijvoorbeeld een proactief bericht verzenden om een gebruiker op de hoogte te stellen wanneer een timer verloopt of een gebeurtenis plaatsvindt.

Zie de C# V4-voorbeelden en Node.js V4-voorbeelden in de opslagplaats BotBuilder-Samples op GitHub voor voorbeelden die laten zien hoe u proactieve berichten verzendt.

Een ETag is een mechanisme voor optimistisch gelijktijdigheidsbeheer. De opslag van de botgegevenstas maakt gebruik van ETags om conflicterende updates voor de gegevens te voorkomen. Een ETag-fout met HTTP-statuscode 412 'Voorwaarde mislukt' geeft aan dat er meerdere berichten parallel zijn ontvangen voordat de bot de eerste bewerking kan voltooien. De dialoogvensterstack en -status worden opgeslagen in botgegevenstassen. U ziet bijvoorbeeld de ETag-fout 'Voorwaarde is mislukt' als uw bot nog steeds een eerder bericht verwerkt wanneer er een nieuw bericht voor dat gesprek wordt ontvangen.

De Bot Framework-service moet zichzelf en haar klanten beschermen tegen aanstootgevende oproeppatronen (bijvoorbeeld een Denial of Service-aanval), zodat geen enkele bot de prestaties van andere bots nadelig kan beïnvloeden. Om dit soort beveiliging te bereiken, hebben we frequentielimieten (ook wel beperking genoemd) toegevoegd aan onze eindpunten. Door een frequentielimiet af te dwingen, kunnen we de frequentie beperken waarmee een client of bot een specifieke aanroep kan doen. Bijvoorbeeld: als snelheidsbeperking is ingeschakeld, moet een bot, als een bot een groot aantal activiteiten wil posten, deze gedurende een bepaalde periode buiten de ruimte plaatsen. Het doel van snelheidsbeperking is niet om het totale volume voor een bot te beperken. Het is ontworpen om misbruik van de gespreksinfrastructuur te voorkomen die geen menselijke gesprekspatronen volgt. Het overspoelen van twee gesprekken met meer inhoud dan twee mensen kan bijvoorbeeld ooit verbruiken.

We stellen de frequentielimieten continu af om ze zo soepel mogelijk te maken en tegelijkertijd onze service en onze gebruikers te beschermen. Omdat drempelwaarden af en toe veranderen, worden de getallen momenteel niet gepubliceerd. Als u uw bot op een App Service host, is de bot gebonden aan de beperkingen van de App Service. Zie de SLA-samenvatting voor Azure-services als u last hebt van snelheidsbeperking. Neem gerust contact met ons op bf-reports@microsoft.comvoor meer informatie.

Sommige kanalen hebben limieten voor de grootte of het type bestanden dat kan worden verzonden. De nettoladingen van activiteiten van Direct Line en Facebook worden bijvoorbeeld beperkt tot 262.144 bytes, terwijl de Bot Framework Emulator geen limiet heeft. Dergelijke limieten worden opgelegd door het kanaal. Als u een bericht verzendt dat deze limiet overschrijdt, krijgt u mogelijk een foutmelding, zoals: De lengte van de aanvraaginhoud is overschreden van 262.144 bytes. U kunt echter een koppeling naar de resource opgeven als een internetbijlage. Zie hoe u media toevoegt aan berichten voor meer informatie over het verzenden van bijlagen.

Het is onwaarschijnlijk dat u last hebt van snelheidsbeperking, zelfs bij hoog volume. De meeste frequentielimieten zouden alleen optreden als gevolg van bulksgewijs verzenden van activiteiten (van een bot of van een client), extreme belastingstests of een bug. Wanneer een aanvraag wordt beperkt, wordt een HTTP 429-antwoord (Te veel aanvragen) geretourneerd, samen met een header Opnieuw proberen na die aangeeft hoe lang (in seconden) moet worden gewacht voordat de aanvraag opnieuw wordt geprobeerd. U kunt deze informatie verzamelen door analyses voor uw bot in te schakelen via Azure-toepassing Insights. U kunt ook code toevoegen in uw bot om berichten te registreren.

Snelheidsbeperking wordt veroorzaakt door een van de volgende voorwaarden:

• Een bot verzendt te vaak berichten
• Een client van een bot verzendt te vaak berichten
• Direct Line-clients vragen te vaak een nieuwe websocket aan

Soms is het nodig om een gesprek over te dragen van een bot naar een mens, bijvoorbeeld wanneer de bot de gebruiker niet begrijpt of de aanvraag niet kan worden geautomatiseerd. In deze gevallen biedt de bot een overgang naar mensen. De Bot Framework SDK biedt ondersteuning voor de overdracht aan een mens. Er zijn enkele gebeurtenistypen voor het signaleren van handoff-bewerkingen. Deze gebeurtenissen worden uitgewisseld tussen een bot en een agenthub, ook wel engagement hub genoemd. Deze agenthub wordt gedefinieerd als een toepassing of een systeem waarmee agents, meestal mensen, aanvragen van gebruikers en escalatieaanvragen van bots kunnen ontvangen en verwerken. Zie het artikel Overgangsgesprekken van bot naar menselijk artikel voor gedetailleerde informatie.