Delen via


Azure-integratie met Microsoft Dynamics 365

 

Gepubliceerd: januari 2017

Is van toepassing op: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

U kunt Microsoft Dynamics 365 (online en on-premises) met het Microsoft Azure-platform verbinden door de uitvoeringspipeline van de gebeurtenis Dynamics 365 te koppelen aan de Microsoft Azure Service Bus. Na configuratie kunnen via deze verbinding gegevens worden doorgegeven naar de servicebus, die zijn verwerkt als onderdeel van de huidige Dynamics 365-bewerking.Microsoft Azure Service Bus-oplossingen die Dynamics 365 ondersteunen, kunnen op de servicebus luisteren naar de Microsoft Dynamics 365-gegevens en deze daaruit uitlezen.

Deze verbinding tussen Microsoft Dynamics 365 en het Microsoft Azure-platform biedt een beveiligd en betrouwbaar kanaal voor het communiceren van Dynamics 365-gegevens tijdens uitvoeringstijd naar externe op de cloud gebaseerde bedrijfstaktoepassingen (LOB).

In dit onderwerp

Belangrijkste elementen van de verbinding

Scenario Microsoft Dynamics 365 naar servicebus

Een contract instellen tussen Microsoft Dynamics 365 en een Azure-oplossing

Beheer van runtimefouten

Belangrijkste elementen van de verbinding

De belangrijkste elementen die de verbinding implementeren tussen Microsoft Dynamics 365 en de Microsoft Azure Service Bus worden hieronder beschreven: Een overzicht in de volgende paragraaf toont deze elementen in werking.

  • Gegevenscontext
    De gegevenscontext bevat de zakelijke gegevens die als onderdeel van de huidige Dynamics 365-bewerking worden verwerkt. Deze verwerking wordt geïnitieerd wanneer een aanvraag om een bepaalde bewerking uit te voeren bij het Dynamics 365-platform is ingediend door een gebruiker, een workflow of een toepassing. De gegevenscontext wordt doorgegeven aan alle invoegtoepassingen of aangepaste workflowactiviteiten die bij de gebeurtenispipeline zijn geregistreerd, voor uitvoering op de specifieke combinatie van aanvraag en entiteit die momenteel worden verwerkt. De gegevenscontext is van het type IPluginExecutionContext, wanneer hij wordt doorgegeven in de pipeline, en van het type RemoteExecutionContext als hij wordt gepost naar de servicebus.

    De gegevenscontext die is gevat in het bericht dat wordt gepost naar de Microsoft Azure Service Bus kan als indeling XML of JSON hebben, naast de binaire standaardindeling voor .NET. Dit biedt voor platformoverschrijdende interoperabiliteit, waarin op Azure gehoste clients niet-.NET-clients de Dynamics 365-gegevens uit de servicebus kunnen lezen.Deze functie werd geïntroduceerd in update 1 van CRM Online 2016 en in CRM 2016 Service Pack 1 (on-premises)..

    Voor meer informatie over over de hierboven beschreven technologieën, zie Begrijp de gegevenscontext in een plug-in, Pipeline voor gebeurtenisuitvoering en Een listenertoepassing schrijven voor een Microsoft Azure-oplossing.

  • Invoegtoepassingen.
    Invoegtoepassingen zijn een van de twee methoden waarmee berichten met de gegevenscontext op de Microsoft Azure Service Bus worden gepost. De andere methode is een aangepaste workflowactiviteit. Er zijn twee soorten invoegtoepassingen die de functie voor de Dynamics 365-Azure-verbinding ondersteunen: kant-en-klare (OOB) en aangepaste. In beide gevallen wordt het aangeraden de invoegtoepassing te registreren voor asynchrone uitvoering, voor de beste systeemprestaties.

    Een kant-en-klare invoegtoepassing met ondersteuning voor Azure wordt geleverd met Dynamics 365 en kan worden geregistreerd door middel van het hulpprogramma voor invoegtoepassingsregistratie in de SDK-download. Deze plug-in wordt met volledig vertrouwen uitgevoerd met het Microsoft Dynamics 365-platform. U moet een invoegtoepassingsstap registreren in de pipeline van de gebeurtenisuitvoering, die de combinatie van bericht en entiteit identificeert die uitvoering van de invoegtoepassing triggert en melding van het posten uitvoert. Wanneer de invoegtoepassing wordt uitgevoerd, meldt hij door een meldingsservice van het service-eindpunt (IServiceEndpointNotificationService) aan de asynchrone service dat deze de gegevenscontext van de huidige aanvraag in de Microsoft Azure Service Bus moet posten.

    U kunt ook uw eigen aangepaste invoegtoepassing schrijven die Azure ondersteunt. De aangepaste invoegtoepassing wordt uitgevoerd in de modus voor gedeeltelijk vertrouwen in de sandbox. Een aangepaste invoegtoepassing kan het posten van de gegevenscontext in de servicebus initiëren door meldingsservice van het service-eindpunt. U kunt code toevoegen om deze service aan te roepen, waardoor de invoegtoepassing Azure-compatibel wordt. Voor meer informatie over invoegtoepassingen in het algemeen, zie Een invoegtoepassing schrijven. Voor meer informatie over Azure-invoegtoepassingen, zie Een aangepaste Azure-bewuste invoegtoepassing schrijven.

  • Aangepaste werkstroomactiviteiten
    Net zoals bij invoegtoepassingen kunnen aangepaste workflowactiviteiten worden geschreven om het posten van de gegevenscontext van het huidige aanvraagbericht in de Microsoft Azure Service Bus te initiëren door middel van de meldingsservice van de service-eindpuntmelding (IServiceEndpointNotificationService).Meer informatie:Voorbeeld: Azure-bewuste aangepaste werkstroomactiviteit.

  • Asynchrone service
    Na melding door de meldingsservice van het service-eindpunt handelt de asynchrone service het posten in de Microsoft Azure Service Bus af van de gegevenscontext van het aanvraagbericht, dat momenteel door de pipeline van de gebeurtenisuitvoering wordt verwerkt. Elk bericht wordt uitgevoerd door een systeemtaak van de asynchrone service. Een gebruiker kan de status van elke systeemtaak bekijken met de weergave Systeemtaken van de Microsoft Dynamics 365-webtoepassing.

    Voor meer informatie over over de asynchrone service, zie Asynchrone service in Microsoft Dynamics 365.

  • Microsoft Azure Service Bus
    De servicebus geeft de gegevenscontext van het aanvraagbericht door tussen Microsoft Dynamics 365 en de listenertoepassingen van de Microsoft Azure Service Bus-oplossing. De servicebus biedt daarbij ook gegevensbeveiliging, zodat alleen geautoriseerde toepassingen toegang hebben tot de geposte Dynamics 365-gegevens. Autorisatie van Microsoft Dynamics 365 voor het posten van de gegevenscontext in de servicebus en van de listenertoepassingen om deze te lezen, wordt beheerd door Microsoft Azure Active Directory Access Control Service (ACS) of door Shared Access Services (SAS) in Microsoft Azure.

    Notitie

    Over SAS-autorisatie: Deze functie werd geïntroduceerd in update 1 van CRM Online 2016 en in CRM 2016 Service Pack 1 (on-premises). SAS is een modernere vorm van autorisatie en biedt betere prestaties dan ACS.

    Voor meer informatie over de servicebus, zie Servicebus.Voor meer informatie over autorisatie van de servicebus, zie Verificatie en autorisatie voor de servicebus.

  • Microsoft Azure-oplossing
    Om de verbinding tussen Dynamics 365 en Azure te laten functioneren moet er minstens één oplossing zijn in een Microsoft Azure Service Bus-oplossingaccount zijn die een of meerdere service-eindpunten bevat. Voor een contract van het relaiseindpunt, moet een listenertoepassing die Dynamics 365 ondersteunt actief luisteren op het eindpunt voor de Dynamics 365 -aanvraag op de servicebus. Voor een wachtrij-eindpuntcontract hoeft een listener niet actief te luisteren. Een listener gaat Dynamics 365 ondersteunen als die wordt gekoppeld aan de Microsoft.Xrm.Sdk-assembly zodat het type RemoteExecutionContext wordt gedefinieerd.Meer informatie:Een listenertoepassing schrijven voor een Microsoft Azure-oplossing

    Microsoft Dynamics 365 ondersteunt het verzenden van gebeurtenisgegevens aan een Azure Event Hubs-oplossing.Deze functie werd geïntroduceerd in update 1 van CRM Online 2016 en in CRM 2016 Service Pack 1 (on-premises)..Voor meer informatie over event hubs, zie Werken met Dynamics 365-gebeurtenisgegevens in uw Azure Event Hub-oplossing.

Scenario Microsoft Dynamics 365 naar servicebus

Nu gaan we een scenario identificeren waarin die eerder genoemde verbindingsonderdelen worden geïmplementeerd. Als vereiste is ACS geconfigureerd om Microsoft Dynamics 365 als de ondersteunde uitgever te zien en is de Microsoft Azure Service Bus-oplossing met regels geconfigureerd om toe te staan dat Microsoft Dynamics 365 op het eindpunt plaatst waarop de listener luistert.

Het volgende schema laat de fysieke elementen zien waaruit het scenario uit bestaat.

Scenario Microsoft Dynamics CRM-naar-servicebus

De volgorde van gebeurtenissen zoals beschreven in dit diagram wordt geïdentificeerd als volgt:

  1. Een listenertoepassing is geregistreerd op een Microsoft Azure Service Bus-oplossingeindpunt en begint actief te luisteren naar de externe Microsoft Dynamics 365-uitvoeringscontext op de servicebus.

  2. Een gebruiker voert een bewerking in Microsoft Dynamics 365 uit die de uitvoering activeert van de geregistreerde OOB-invoegtoepassing of een aangepaste invoegtoepassing die Azure ondersteunt. De invoegtoepassing initieert een bericht door een asynchrone servicesysteemtaak van de gegevenscontext van de huidige aanvraag naar de servicebus.

  3. De claims die door Microsoft Dynamics 365 worden geplaatst, worden geverifieerd. De servicebus geeft vervolgens de externe de uitvoeringscontext door aan de listener. De listener verwerkt de contextinformatie en voert een zakelijke taak met die informatie uit. De asynchrone service wordt ingelicht met behulp van de servicebus, over een succesvol bericht en de status van de gerelateerde systeemtaak wordt ingesteld op voltooid.

Een contract instellen tussen Microsoft Dynamics 365 en een Azure-oplossing

Voor elk oplossingeindpunt configureert u een contract dat de afhandeling van deze externe "uitvoeringscontextberichten" op de servicebus en de beveiliging die op dat eindpunt moet worden gebruikt. Servicebusberichten worden op een eindpunt ontvangen met een van de ondersteunde hier genoemde contracten.

  • Wachtrij
    Een wachtrijcontract biedt een berichenwachtrij in de cloud. Met een wachtrijcontract hoeft een listener niet actief te luisteren naar berichten op het eindpunt. Voor wachtrijen lezen is er een vernietigende lezing en een niet-vernietigende lezing. Een vernietigende lezing leest een beschikbaar bericht uit de wachtrij en het bericht wordt verwijderd. Een niet-vernietigende leesbewerking verwijdert een bericht niet uit de wachtrij.

    Het type wachtrij dat Microsoft Dynamics 365 ondersteunt, wordt persistente wachtrij genoemd. Persistente wachtrijen hebben een veel langere, maar eindige duur van de berichtbeschikbaarheid die in code kan worden opgegeven.

  • Unidirectioneel
    Een unidirectioneel contract vereist een actieve listener. Als er geen actieve listener op een eindpunt is, mislukt het bericht naar de servicebus.Microsoft Dynamics 365 probeert het bericht met exponentieel langere tussenpozen opnieuw te posten, totdat de asynchrone systeemtaak die de aanvraag post uiteindelijk wordt afgebroken en de status ervan wordt ingesteld op "Mislukt".

  • Bidirectioneel
    Een bidirectioneel contract is vergelijkbaar met een unidirectioneel contract, behalve dat een tekenreekswaarde kan worden geretourneerd van de listener naar de invoegtoepassing of de aangepaste workflowactiviteit die het posten van het bericht initieert.

  • REST
    Een REST-contract is vergelijkbaar met een bidirectioneel contract op een REST-eindpunt.

  • Onderwerp
    Vergelijkbaar met een wachtrij, behalve dat een of meer listeners zich kunnen aanmelden om berichten uit het onderwerp te ontvangen.

  • Gebeurtenishub
    Dit contracttype is van toepassing op Event Hub-oplossingen van Microsoft Azure.

Belangrijk

Om deze contracten te kunnen gebruiken, moet u uw listenertoepassingen schrijven met behulp van Microsoft AzureSDK v1.7 of hoger.

Het identificeren van het soort beveiliging dat het contract gebruikt, maakt deel uit van de configuratie van het contract. Een contract kan transportbeveiliging gebruiken, die Transport Layer Security (TLS) of Secure Sockets Layer (SSL) (HTTPS) gebruikt.

Claimenverificatie wordt gebruikt voor beveiligde toegang tot de servicebus. De claim die wordt gebruikt om de servicebus te verifiëren, wordt gegenereerd in Microsoft Dynamics 365 en ondertekend door het AppFabricIssuer-certificaat dat in de Microsoft Dynamics 365-configuratiedatabase is opgegeven.

Beheer van runtimefouten

Wanneer er een fout optreedt nadat is geprobeerd naar de servicebus te posten, controleert u de status van de verwante systeemtaak in de Microsoft Dynamics 365-webtoepassing voor meer informatie over de fout. Als de servicebus of een listener/eindpunt niet beschikbaar is, wordt het huidige bericht dat in Microsoft Dynamics 365 wordt verwerkt niet geplaatst naar de bus. De asynchrone service zal blijven poberen het bericht in een exponentieel patroon te plaatsen, waarbij de service eerst probeert vaak te posten en vervolgens met steeds langere tussenpozen. Voor een interne Microsoft Dynamics 365-fout wordt niet geprobeerd berichten te plaatsen. Voor een externe servicebus- of netwerkfout krijgt de gerelateerde systeemtaak een wachtstatus.

Zie ook

Azure-extensies voor Microsoft Dynamics 365
Azure-integratie met Microsoft Dynamics 365 configureren
Invoegtoepassingen schrijven om bedrijfsprocessen uit te breiden
Asynchrone service in Microsoft Dynamics 365
Entiteit AsyncOperation (systeemtaak)

Microsoft Dynamics 365

© 2017 Microsoft. Alle rechten voorbehouden. Auteursrecht