Test samtaleagenter ved bruk av Direct Line

Direct Line API fungerer som et kommunikasjonsgrensesnitt for at klientapplikasjoner kan samhandle med samtaleagenter bygget med Copilot Studio. Direct Line API muliggjør overføring av meldinger mellom klientapplikasjonen og agenten enten via WebSocket-strømmer eller HTTP-forespørsler. For ytelsestesting gjør Direct Line det mulig for lasttestverktøy å replikere faktisk brukeratferd, generere belastning og måle svartider.

Kommuniser med Direct Line ved hjelp av WebSockets

Du kan distribuere samtaleagenter som er bygd med Copilot Studio til webapplikasjoner som enten innebygde iFrame eller ved å bruke et egendefinert lerret. Begge distribusjonsalternativene bruker WebSocket-kommunikasjon med Direct Line. Hvis du distribuerer samtaleagenten din til en app ved å bruke en av disse metodene, bør ytelsestestskriptet ditt bruke WebSocket-kommunikasjon for å generere belastning som ligner ekte brukeratferd, og måle ytelsen med høy grad av tillit.

Klientapplikasjoner som bruker Direct Line og WebSocket-kommunikasjon bør følge denne flyten:

  1. For å initiere en samtale må en klientapplikasjon først skaffe en samtaletoken. Hvis agenten din er konfigurert med en Direct Line-hemmelighet, skaff et token ved å kontakte Direct Line-regionale endepunktet. Token for agenter som ikke bruker hemmeligheter kan hentes fra token-endepunktet.
  2. Klientapplikasjonen starter en samtale ved å bruke tokenet, og mottar en Conversation ID og en WebSocket-strøm-URL.
  3. Brukermeldinger sendes ved å sende en HTTP POST-forespørsel med Conversation ID-en.
  4. Meldinger fra samtaleagenten mottas over WebSocket-strømmen.

Skjermbilde som viser flyten av Direct Line-kommunikasjon ved bruk av WebSockets.

Bruk HTTP GET for å kommunisere med Direct Line

Hvis lasttestverktøyet ditt ikke kan bruke WebSocket-kommunikasjon, eller hvis klientapplikasjonen din ikke bruker WebSocket-kommunikasjon, kan du motta aktiviteter ved å sende HTTP GET i stedet. Som vist i diagrammet nedenfor, endres ikke flyten for oppstart av samtalen.

Skjermbilde som viser flyten av Direct Line-kommunikasjon via HTTP GET.

Mål svartider

For å vurdere hvordan belastning påvirker brukeropplevelsen, sørg for at ytelsestestskriptene dine sporer og rapporterer svartid for følgende trinn:

Trinn Innvirkning på brukeropplevelse
Generer token Tiden det tar å starte en ny samtale
Start samtale Tiden det tar å starte en ny samtale
Send aktivitet Tiden det tar å sende en ny brukermelding (inkluderer ikke agentens svar)
Motta aktiviteter/Hente aktiviteter Tiden det tar for en agent å svare

Å spore responstider for Generate Token, Start Conversation og Send Activity er enkelt for lasttestingsverktøy, siden disse trinnene bruker standard HTTP-forespørsler. Å måle tiden det tar for en agent å svare på brukermeldinger er imidlertid mer komplekst, av følgende grunner:

  • Sending og mottak av aktiviteter over Direct Line følger et asynkront mønster. Når en brukermelding sendes ved hjelp av en Send Activity-forespørsel, er svaret ikke en melding fra agenten. I stedet bekrefter det bare at brukermeldingen er vellykket publisert.

  • Avhengig av utformingen kan en samtaleagent sende et hvilket som helst antall meldinger tilbake som svar på en brukermelding. Derfor bør du i de fleste tilfeller måle tiden det tar for agenten å gi svar, som tiden som går mellom en brukermelding og den siste agentmeldingen. I det følgende eksempelet utløser en enkelt brukermelding tre agentmeldinger, med API-kall som kjører imellom. Hver melding tar omtrent to sekunder å bli mottatt, men fra brukerens perspektiv tar det seks sekunder før agenten svarer på brukerens forespørsel.

    Skjermbilde som viser svartiden mellom meldingene.

Identifiser agentens siste svar

For å måle hvor lang tid det tar for agenten å fullføre sine svar, må ytelsestestskriptet ditt:

  • Identifiser den siste agentmeldingen som følger etter en brukermelding
  • Beregn tidsforskjellen mellom de to

Den underliggende protokollen som Copilot Studio bruker har ikke et begrep om et 'siste svar', siden både agenten og brukeren kan sende meldinger når som helst. Derfor må ytelsestestskriptet ditt anta at dersom agenten ikke sender en melding innenfor en angitt tidsperiode, blir det ikke sendt flere meldinger før brukeren sender en ny melding. Implementeringen av denne logikken varierer avhengig av hvordan skriptet ditt kommuniserer med Direct Line.

Bruk WebSockets

Når kommunikasjonen med Direct Line skjer over WebSockets, bør du anta at agenten ikke sender flere meldinger når ingen flere rammer kan leses fra WebSocket. Dette kan indikeres av en timeout når du forsøker å lese neste ramme, selv om den nøyaktige oppførselen avhenger av din implementering. For en referanseimplementering som bruker WebSockets, vurder å bruke HTTP GET.

Bruk HTTP GET

Ytelsestestingsskripter som bruker HTTP GET i stedet for WebSockets bør polle Activities-endepunktet for å hente hele settet av bruker- og agentmeldinger. Ved polling må du sørge for å gi agenten din tilstrekkelig tid til å svare. F.eks., hvis agenten din må kalle et backend-API for å svare på en brukerhenvendelse, og API-et bruker opptil fem sekunder på å svare, bør ikke skriptet ditt polle Activities-endepunktet før fem sekunder har gått.

Den følgende forenklede nyttelasten viser responsen som kommer tilbake fra Aktiviteter-endepunktet:

[
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000012",
    "timestamp": "2025-01-07T09:12:22.0329242Z",
    "from": {
      "id": "a688eb7d-092a-42a8-8ef5-73123b9c2aaa",
      "name": ""
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "I also want to set up a new account",
  },
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000017",
    "timestamp": "2025-01-07T09:12:24.5478686Z",
    "from": {
      "id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
      "name": "Load Testing",
      "role": "bot"
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "Sure, please bear with me as I set up your new account",
    "replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012",
  },
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000018",
    "timestamp": "2025-01-07T09:12:33.1960413Z",
    "from": {
      "id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
      "name": "Load Testing",
      "role": "bot"
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "Almost done! Thank you for your patience",
    "replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012",
  },
  {
    "type": "message",
    "id": "98SryQaHr2rGthOGpChPK2-us|0000019",
    "timestamp": "2025-01-07T09:12:41.9166159Z",
    "from": {
      "id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
      "name": "Load Testing",
      "role": "bot"
    },
    "conversation": {
      "id": "98SryQaHr2rGthOGpChPK2-us"
    },
    "text": "All done! Your new account is now active.",
    "inputHint": "acceptingInput",
    "replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012"
  }
]

Når du parser nyttelasten og beregner svartider, følg disse retningslinjene:

  • Meldinger fra agenten har egenskapen role: bot, mens meldinger fra brukeren ikke har noen role egenskap.
  • Agentmeldinger sendt som svar på brukermeldinger har egenskapen replyToId, som har verdien av egenskapen id til brukermeldingen.
  • Du kan beregne agentens svartider som tidsforskjellen mellom brukermeldingen og den siste agentmeldingen som svarer på brukermeldingen.