Del via

Skrive en lyttefunktion til en Microsoft Azure-løsning

  • Artikel

 

Udgivet: november 2016

Gælder for: Dynamics CRM 2015

Dette emne beskriver, hvordan du skriver en lyttefunktion, der kan læse og behandle Microsoft Dynamics CRM 2015-meddelelser, der bogføres på Microsoft Azure-servicebus. Som en forudsætning,skal du orientere dig om, hvordan man skriver en Microsoft Azure-servicebus-lyttefunktion, før du prøver at lære detaljerne i en Microsoft Dynamics 365-lyttefunktion. Yderligere oplysninger finder du i dokumentationen til Azure Service Bus og eksempelkode.

Dette emne indeholder

Skrive en kølyttefunktion

Skrive en envejs-, tovejs- eller REST-lyttefunktion

Filtermeddelelser

Skrive en kølyttefunktion

En meddelelseskø er et lager af meddelelser, der modtages på et servicebus-slutpunkt. En kølyttefunktion er et program, der læser og behandler meddelelserne i køen. Da servicebusmeddelelser gemmes i en kø, behøver en lyttefunktion ikke aktivt at lytte, for at meddelelser kan modtages i køen. En kølyttefunktion kan startes, når meddelelser er modtaget i køen, og stadig behandle disse meddelelser. Andre typer lyttefunktioner, der er beskrevet i næste afsnit, skal aktivt lytte, for ellers har de ikke mulighed for at læse en meddelelse. Disse meddelelser kan stamme fra Microsoft Dynamics 365 eller fra en anden kilde. Når du skriver en kølyttefunktion, er det vigtigt at kontrollere hvert meddelelseshovedhandling for at finde ud af, om meddelelsen stammer fra Microsoft Dynamics 365.

Du kan foretage en destruktiv meddelelseslæsning ved hjælp af Receive i ReceiveAndDelete-tilstand, hvor meddelelsen læses og fjernes fra køen, eller en ikke-destruktiv læsning ved hjælp af PeekLock-tilstand, hvor meddelelsen læses, men stadig er tilgængelig i køen. Vedvarende kølyttefunktions eksempelkode, der er leveret i dette SDK, indeholder en destruktiv læsning. Yderligere oplysninger om at læse meddelelser fra en kø finder du i Sådan modtager du meddelelser fra en kø.

Et emne svarer til en kø, men implementerer en model for udgivelse/abonnement. En eller flere lyttefunktioner kan abonnere på emnet og modtage meddelelser fra dens kø.Flere oplysninger:Køer, emner og abonnementer

Vigtigt

Vedvarende køer og emner, der understøttes, mens meddelelsesbufferkøer ikke er. Hvis du vil bruge disse kontrakter, skal du skrive dine lytteprogrammer ved hjælp af Azure SDK version 1.7 eller 1.8.

Brug af køer og emner i dit multisystemsoftwaredesign kan medføre afkobling af systemer. Hvis lytteprogrammet nogensinde bliver utilgængeligt, vil leveringen af meddelelsen fra Microsoft Dynamics 365 stadig lykkes, og lytteprogrammet kan fortsætte afviklingen af kømeddelelsen, når det er online igen.Flere oplysninger:Køer, emner og abonnementer.

Opdatere en lyttefunktions meddelelsesbuffer til at bruge vedvarende køer

Følgende procedure viser de generiske trin, du skal følge for at opdatere et lytteprogram, der henter en meddelelse fra en meddelelsesbuffer til en, der modtager meddelelser fra en vedvarende kø.

  1. På Microsoft Azure-portalen og i den samme løsning skal du oprette en kø i den samme sti, som blev brugt til meddelelsesbufferen.

  2. Installer Microsoft Azure SDK version 1.7 eller 1.8 på din udrulningscomputer.

  3. Opdater lyttefunktionens kode ved at fjerne de meddelelsesbufferrelaterede klasser og metoder, og rrstat dem med QueueClient og Receive. Sørg for at bruge den ønskede læsetilstand: RetrieveAndDelete eller PeekLock. Yderligere oplysninger om at læse meddelelser fra en kø finder du i Køer, emner og abonnementer.

  4. Opret lytteprogrammet.

Ingen Microsoft Dynamics 365-konfigurationsændringer er nødvendige, så længe køslutpunktet bruger den samme løsningssti, som meddelelsesbufferen har brugt.

Skrive en envejs-, tovejs- eller REST-lyttefunktion

Udover kølyttefunktionen, der er beskrevet tidligere, kan du skrive en lyttefunktion til tre andre servicebuskontrakter, der understøttes af Microsoft Dynamics 365: envejs, tovejs og REST. En envejslyttefunktion kan læse og behandle en meddelelse, der er sendt til servicebussen. En tovejslyttefunktion kan gøre det samme, men kan også returnere en streng med nogle oplysninger tilbage til Dynamics 365. En REST-lyttefunktion er den samme som tovejslyttefunktionen, bortset fra at den fungerer sammen med et REST-slutpunkt. Bemærk, at disse lyttefunktioner skal lytte aktivt på et serviceslutpunkt for at læse en meddelelse, der sendes via servicebussen. Hvis lyttefunktionen ikke lytter, når Microsoft Dynamics 365 forsøger at sende en meddelelse til servicebussen, vil meddelelsen ikke blive sendt.

Skrivning af en lyttefunktion er struktureret omkring en adresse, binding og kontrakt. Følgende oplysninger angiver adresse, binding og kontrakt i en envejslyttefunktion.

Når din lyttefunktion er registreret med et slutpunkt, kaldes lyttefunktionens Execute-metode, når der sendes en meddelelse til servicebussen, af Microsoft Dynamics 365.Execute-metoden returnerer ingen data fra metodekaldet. Yderligere oplysninger finder du i eksemplet på envejslyttefunktion, Eksempel: Envejs-lyttefunktion.

En tovejslyttefunktion er kodet på en lignende måde som en envejslyttefunktion. En tovejslyttefunktion har følgende adresse, binding og kontrakt:

For denne tovejskontrakt vil metoden Udfør returnere en streng fra metodekaldet. Yderligere oplysninger finder du i eksemplet på tovejslyttefunktion, Eksempel: Tovejs-lyttefunktion.

En REST-lyttefunktion er kodet på en lignende måde som en tovejslyttefunktion. En REST-lyttefunktion har følgende adresse, binding og kontrakt:

For REST-kontrakten vil Execute-metoden returnere en streng fra metodekaldet. Du kan finde flere oplysninger i eksemplet på REST-lyttefunktion, Eksempel: REST-lyttefunktion. Bemærk, at i eksemplet på REST-lyttefunktionen er en WebServiceHost instantieret, og ikke en ServiceHost, som det var tilfældet i tovejseksemplet.

Bemærk

Når du bruger indbygget (ServiceBusPlugin) plug-in med en tovejs- eller REST-lyttefunktion, bruger plug-in'en ikke nogen strengdata, der returneres fra lyttefunktionen. Men en brugerdefineret Azure-aktiveret plug-in kunne gøre brug af disse oplysninger.

Når du kører eksemplerne på lyttefunktioner, bliver du bedt om at angive udstederens hemmelighed, som er Microsoft Azure-servicebus-administrationsnøglen. WS2007 Federation HTTP-bindingen bruger "token"-tilstand og protokollen WS-Trust 1.3.

Filtermeddelelser

Der er en egenskabsbeholder med ekstra oplysninger i hver formidlet meddelelses Properties-egenskab, der er sendt fra Microsoft Dynamics CRM 2015 og CRM Online. Egenskabsbeholderen med vedvarende kø og emnekontraktslutpunkter indeholder følgende oplysninger.

  • Organisation Url

  • Kaldende bruger-id

  • Initierende bruger-id

  • Objektets logiske navn

  • Anmodningsnavn

Disse oplysninger identificerer den organisations-, bruger-, objekt- og meddelelsesanmodning, som er behandlet af Microsoft Dynamics 365, der resulterede i, at servicebusmeddelelsen blev sendt. Din lyttefunktionskode kan vælge at behandle en meddelelse, der modtages, baseret på disse oplysninger.Flere oplysninger:Eksempel: Udfør flere anmodninger

Se også

Azure-udvidelser til Microsoft Dynamics CRM 2015
Skriv en brugerdefineret Azure-følsom plug-in
Eksempel: Vedvarende kølyttefunktion
Eksempel: Envejs-lyttefunktion
Eksempel: Tovejs-lyttefunktion
Eksempel: REST-lyttefunktion
Sende Microsoft Dynamics CRM 2015-data via Azure Service Bus

© 2017 Microsoft. Alle rettigheder forbeholdes. Ophavsret