Verwenden Sie Webhooks zum Erstellen externer Handler für Serverereignisse
Ab Version 9.0 von Dynamics 365 for Customer Engagement-Apps können Sie Daten über Ereignisse, die auf dem Server auftreten, über Webhooks an eine Webanwendung senden. Webhooks ist ein einfaches HTTP-Muster zur Verbindung von Web-APIs und -diensten mit einem Veröffentlichungs-/Abonnementmodell. Webhook-Absender benachrichtigen Empfänger über Ereignisse, indem sie Anfragen mit einigen Informationen zu den Ereignissen an Empfängerendpunkte senden.
Mit Webhooks können Entwickler und ISVs Daten aus dem Customer Engagement in Ihren eigenen benutzerdefinierten Code integrieren, der von externen Diensten gehostet wird. Mit dem Webhook-Modell können Sie Ihren Endpunkt sichern, indem Sie einen Authentifizierungsheader oder Abfrage-Zeichenfolgenparameterschlüssel verwenden. Dies ist einfacher als das SAS-Authentifizierungsmodell, das Sie derzeit möglicherweise für die Azure Service Bus-Integration verwenden.
Beim Entscheiden zwischen dem Webhook-Modell und der Azure Service Bus-Integration sollten Sie Folgendes berücksichtigen:
- Azure Service Bus kann in großem Umfang verarbeitet werden und bietet einen vollständigen Warteschlangenmechanismus, wenn Dynamics 365 viele Ereignisse schiebt.
- Webhooks können nur bis zu dem Punkt skaliert werden, an dem Ihr gehosteter Webdienst die Nachrichten verarbeiten kann.
- Webhooks ermöglicht synchrone und asynchrone Schritte. Azure Service Bus ermöglicht nur asynchrone Schritte.
- Webhooks senden POST-Anforderungen mit JSON-Nutzlast und können von allen Programmiersprachen oder Webanwendungen an jedem beliebigen Ort konsumiert werden.
- Webhooks und Azure Service Bus können von einem Plug-In oder einer benutzerdefinierten Workflowaktivität aufgerufen werden.
Erste Schritte
Die Anwendung von Webhooks gliedert sich in drei Teile:
- Erstellen oder Konfigurieren eines Services zum Konsumieren von Webhook-Anforderungen.
- Registrierung des Webhook-Schrittes auf dem Dynamics 365 Service oder
- Aufrufen des Webhooks von einem Plug-In oder einer benutzerdefinierten Workflowaktivität.
Dieses Thema beginnt damit zu erklären, wie ein Webhook registriert wird und wie die Registrierung mit einer Anforderungs-Anmelde-Website getestet wird. Anhand dieser Informationen erfahren Sie mehr über die Anforderungen beim Erstellen und Konfigurieren eines Services zum Konsumieren von Webhooks. Dies wird in Erstellen oder Konfigurieren eines Services zum Konsumieren von Webhook-Anforderungen erläutert.
Registrieren eines Webhooks
Verwenden Sie das Plug-In-Registrierungstool, um einen Webhook zu registrieren. Um das Plug-in-Registrierungs-Tool zu erhalten, gehen Sie zu Dataverse Bereitstellungtools
Im Plug-In-Registrierungstool gibt es eine neue Option zum Registrieren eines neuen Webhooks, die ausgewählt werden kann.
Wenn Sie einen Webhook registrieren, müssen Sie drei Arten von Informationen zur Verfügung stellen:
| Element | Beschreibung |
|---|---|
| Name | Ein eindeutiger Name, der den Webhook beschreibt. |
| Endpunkt-URL | Die URL, an die Ausführungskontextinformationen gepostet werden. |
| Authentifizierung | Eine von drei Authentifizierungsoptionen. Für jeden Authentifizierungstyp müssen Sie die Schlüssel bereitstellen, durch die die Anforderung als legitim erkannt wird. |
Authentifizierungsoptionen
Die richtige zu verwendende Authentifizierungsoption zur Webhook-Registrierung und die Werte hängen davon ab, was der Endpunkt erwartet. Der Besitzer des Endpunkts muss Ihnen mitteilen, was verwendet werden soll. Um Webhooks mit Dynamics 365 zu verwenden, muss der Endpunkt eine der drei unten beschriebenen Authentifizierungsoptionen zulassen:
| Typ | Beschreibung |
|---|---|
| HttpHeader | Enthält eine oder mehrere Schlüsselwertpaare im Header der HTTP-Anforderung. Beispiel: Key1: Value1Key2: Value2 |
| WebhookKey | Enthält einer Abfragezeichenfolge mithilfe code als den Schlüssel und einen Wert, der vom Endpunkt erforderlich ist. Wenn Sie den Internet-Hook mithilfe des Plug-In Registrierungstools nutzen, können Sie nur den Wert eingeben.Beispiel: ?code=00000000-0000-0000-0000-000000000001 |
| HttpQueryString | Enthält eine oder mehrere Schlüsselwertpaare als Zeichenfolgenparameter. Beispiel: ?Key1=Value1&Key2=Value2 |
Notiz
Die Option WebhookKey ist für die Verwendung mit Azure-Funktionen hilfreich, da von der Authentifizierungsabfragezeichenfolge erwartet wird, dass sie einen Schlüsselnamen von code hat.
Alle Anforderungen an den konfigurierten Endpunkt sollten fehlschlagen, wenn die in der Anforderung übergebenen Authentifizierungsoptionen nicht übereinstimmen. Dies ist die Aufgabe des Endpunkts.
Webhookregistrierungen abfragen
Webhook-Registrierungen werden gespeichert in der ServiceEndpoint-Entität und haben einen Vertrag-Wert von 8.
Informationen zu registrierten Webhooks erhalten Sie durch Abfrage der ServiceEndpoint-Entität.
Web-API:
GET [organization URI]/api/data/v9.1/serviceendpoints?$filter=contract eq 8&$select= serviceendpointid,name,authtype,url
FetchXml:
<fetch>
<entity name="serviceendpoint" >
<attribute name="serviceendpointid" />
<attribute name="name" />
<attribute name="authtype" />
<attribute name="url" />
<filter>
<condition attribute="contract" operator="eq" value="8" />
</filter>
</entity>
</fetch>
Informationen zu den festgelegten Authentifizierungswerten sind in der AuthValue-Eigenschaft gespeichert und können nicht abgerufen werden.
Registrieren eines Schritts für einen Webhook
Das Registrieren eines Schritts für einen Webhook gleicht dem Registrieren eines Schritts für ein Plug-In. Der Hauptunterschied ist, dass Sie keine Konfigurationsinformationen angeben können.
Genau wie bei einem Plug-In geben Sie die Nachricht und bei Bedarf Informationen zu Entitäten an. Sie können auch angeben, wo in der Ereignis-Pipeline der Webhook ausgeführt werden soll. Zudem können Sie den Ausführungsmodus festlegen und angeben, ob AsyncOperation bei erfolgreicher Operation gelöscht werden sollen.
Informationen zu Schrittname und Beschreibung werden basierend auf den ausgewählten Optionen automatisch gefüllt, Sie können die Daten jedoch ändern. Wenn Sie keine Filterattribute für eine Nachricht festlegen, die diese unterstützt, werden Sie zwecks optimalem Leistungsverfahren dazu aufgefordert.
Ausführungsmodus und Debuggen der Webhookregistrierung
Die Auswahl, die Sie bei der Webhookregistrierung treffen, wirkt sich auf die Erfahrung aus, die Sie beim Debuggen machen, wenn etwas nicht funktioniert.
Asynchroner Modus
Wenn Sie einen asynchronen Ausführungsmodus verwenden, wird ein asyncoperation-Auftrag erstellt, um Erfolg oder Misserfolg der Operation zu erfassen. Wenn Sie bei einem Erfolg die "asyncoperation" löschen, geben Sie Speicherplatz in Ihrer Datenbank frei.
Alle Fehler, die auftreten, werden in Systemaufträgen aufgezeichnet. In der Webanwendung können Sie Einstellungen > System > Systemaufträge aufrufen, um den Status von Webhooks anzuzeigen. Es gibt einen Statusgrund-Wert vom Typ Fehler. Öffnen Sie die fehlerhafte Systemauftragsentität, um herauszufinden, warum der Auftrag fehlgeschlagen ist.
Synchroner Modus
Wenn Sie den synchronen Ausführungsmodus verwenden, werden alle Fehler dem Benutzer der Anwendung gemeldet. Dazu wird ein Endpunkt nicht verfügbar-Fehlerdialog angezeigt, der den Benutzer darüber informiert, dass der Webhook-Service-Endpunkt möglicherweise falsch konfiguriert oder nicht verfügbar ist. Im Dialogfeld können Sie eine Protokolldatei mit Informationen zu etwaigen Fehlern herunterladen.
Notiz
Sie sollten den synchronen Modus verwenden, wenn es wichtig ist, dass die Operation, die vom Webhook ausgelöst wird, sofort erfolgt, oder wenn Sie möchten, dass die gesamte Transaktion fehlschlägt, sofern die Webhook-Nutzlast von einem Service empfangen wird. Eine einfache Webhook-Schritt-Registrierung bietet begrenzte Optionen zur Fehlerbehandlung. Sie können aber auch Webhooks mit den Plug-In-Workflowaktivitäten aufrufen, wenn Sie mehr Kontrolle benötigen. Weitere Informationen: Aufrufen des Webhooks von einem Plug-In oder einer benutzerdefinierten Workflowaktivität.
Mögliche Ursachen für Fehler
Webhooks sind verhältnismäßig einfach. Der Service sendet die Anforderung und wertet die Antwort aus. Das System kann keine Daten analysieren, die mit dem Text der Antwort zurückgegeben werden, es wird nur ein Blick auf den Reaktionswert StatusCode geworfen
Das Timeout beträgt 60 Sekunden. Im Allgemeinen kommt es zu einem Misserfolg, wenn keine Antwort vor dem Timeout zurückgegeben wird oder wenn der Reaktionswert StatusCode nicht innerhalb des Bereiches 2xx ist, und so einen Erfolg anzeigt. Dies gilt nicht, wenn der zurückgegebene Fehler in folgender Tabelle enthalten ist:
StatusCode |
Beschreibung |
|---|---|
502 |
Ungültiges Gateway |
503 |
Dienst ist nicht verfügbar |
504 |
Gateway-Timeout |
Diese Fehler weisen auf ein Netzwerkproblem hin, das möglicherweise mit einem anderen Versuch aufgelöst werden kann. Der Webhook-Service macht nur dann einen oder mehrere Versuche, wenn diese Fehlercodes zurückgegeben werden.
Siehe Abfrage bei asynchronen Aufträgen bei einem bestimmten Schritt fehlgeschlagen für Informationen zum Abrufen von Daten zu fehlgeschlagenen asynchronen Aufträgen.
Abfragen von Schritten, die für ein Webhook registriert sind
Daten zu registrierten Webkooks befinden sich in der SdkMessageProcessingStep-Entität.
Sie können die Schritte abfragen, die für einen bestimmten Webhook registriert sind, wenn Sie die serviceendpointid für das Webhook kennen. Lesen Sie Webhookregistrierungen abfragen für eine Abfrage, um die ID für einen registrierten Webhook zu erhalten.
Web-API:
Sie können diese Web-API-Abfrage verwenden, bei der <id> die ServiceEndpointId des Webhooks darstellt:
GET [organization URI]/api/data/v9.1/serviceendpoints(@id)/serviceendpoint_sdkmessageprocessingstep?$select=sdkmessageprocessingstepid,name,description,asyncautodelete,filteringattributes,mode,stage?@id=<id>
Weitere Informationen über den registrierten Schritt erhalten Sie, wenn Sie die Web-API-Abfrage nutzen, bei der die <stepid> die SdkMessageProcessingStepId für den Schritt ist:
GET [organization URI]/api/data/v9.1/sdkmessageprocessingsteps(@id)?$select=name,description,filteringattributes,asyncautodelete,mode,stage&$expand=plugintypeid($select=friendlyname),eventhandler_serviceendpoint($select=name),sdkmessagefilterid($select=primaryobjecttypecode),sdkmessageid($select=name)?@id=<stepid>
FetchXml:
Sie können dieses FetchXML verwenden, um dieselben Informationen in einer Abfrage zu erhalten. Dabei ist <serviceendpointid> die ID des Webhooks:
<fetch>
<entity name="sdkmessageprocessingstep" >
<attribute name="name" />
<attribute name="filteringattributes" />
<attribute name="stage" />
<attribute name="asyncautodeletename" />
<attribute name="description" />
<attribute name="mode" />
<link-entity name="serviceendpoint" from="serviceendpointid" to="eventhandler" link-type="inner" alias="endpnt" >
<attribute name="name" />
<filter>
<condition attribute="serviceendpointid" operator="eq" value="<serviceendpointid>" />
</filter>
</link-entity>
<link-entity name="sdkmessagefilter" from="sdkmessagefilterid" to="sdkmessagefilterid" link-type="inner" alias="fltr" >
<attribute name="primaryobjecttypecode" />
</link-entity>
<link-entity name="sdkmessage" from="sdkmessageid" to="sdkmessageid" link-type="inner" alias="msg" >
<attribute name="name" />
</link-entity>
</entity>
</fetch>
Fehlgeschlagene asynchrone Aufträge für einen gegebenen Schritt abfragen
Wenn Sie die sdkmessageprocessingstepid einen gegebenen Schritts kennen, können Sie eine Fehlerabfrage an die AsynchronousOperations-Entität stellen. Mit dem OwningExtensionId-Wert können Sie die Ergebnisse nach einem bestimmten registrierten Schritt filtern. Die folgenden Beispiele nutzen <stepid> für die sdkmessageprocessingstepid des nächsten Schritts.
Web-API:
GET [organization URI]/api/data/v9.1/asyncoperations?$orderby=completedon desc&$filter=statuscode eq 31 and _owningextensionid_value eq @stepid&$select=name,friendlymessage,errorcode,message,completedon?@stepid=<stepid>
FetchXml:
<fetch>
<entity name="asyncoperation" >
<attribute name="name" />
<attribute name="friendlymessage" />
<attribute name="errorcode" />
<attribute name="message" />
<attribute name="completedon" />
<filter>
<condition attribute="owningextensionid" operator="eq" value="<stepid>" />
</filter>
<order attribute="completedon" descending="true" />
</entity>
</fetch>
Testen der Registrierung mit einer Anforderungsanmelde-Website
Ehe Sie weitermachen und einen Service erstellen oder konfigurieren, um Webhooks zu konsumieren, sollten Sie testen, welche Daten der Service empfängt, sodass Sie wissen, welche Art von Daten Sie verarbeiten müssen. Zu diesem Zweck können Sie eine oder mehrere Anforderungsanmelde-Websites nutzen. Zum Zwecke dieses Beispiels führen wir RequestBin aus, um ein Ziel für die Webhook-Anforderungen zu erstellen. Verwenden Sie die folgenden Schritte:
Gehen Sie zu https://requestbin.com/ und klicken Sie auf RequestBin erstellen.
Die nächste Seite enthält einen Container-URL wie:
https://<random string>.x.pipestream.net. Kopieren Sie diese URL.Verwenden Sie das Plug-In-Registrierungstool, um einen neuen Webhook zu registrieren, wie unter Registrieren eines Webhooks beschrieben. Verwenden Sie die in Schritt 2 kopierte URL als die Endpunkt-URL. Legen Sie einen Namen und alle gewünschten Authentifizierungseigenschaften fest. RequestBin wertet diese Werte nicht so aus, wie dies ein tatsächliche Website, die Daten verarbeitet, tut. Sie können aber sehen, wie sie übergeben werden.
Verwenden Sie das Plug-In-Registrierungstool, um einen Schritt mit dem Webhook zu registrieren, den Sie in Schritt 3 erstellt haben, wie in Registrieren eines Schritts für einen Webhook beschrieben. Achten Sie darauf, dass Sie ein Ereignis verwenden, das Sie einfach durch die Bearbeitung von Daten in der Dynamics 365-Anwendung ausführen können, z.B. die Aktualisierung einer Entität eines Kontakts.
Verwenden Sie die Dynamics 365 App, um den Vorgang zum Auslösen des Ereignisses durchzuführen.
Nachdem Sie das Ereignis ausgelöst haben, kehren Sie zur RequestBin-Seite aus Schritt 2 zurück. Sie sollten eine Seite ähnlich der folgenden sehen:
Anmerkung
Die Ergebnisse, die auf dieser Website angezeigt werden, geben nicht notwendigerweise die Großschreibung der gesendeten Werte wieder. Bei HTTP-Headern wird die Groß-/Kleinschreibung beachtet, und die RequestBin-Website wird angezeigt, um einige Formatierungsregeln anzuwenden, damit die Werte leichter gelesen werden können. Die von Dynamics 365 gesendeten Werte werden jedoch alle in Kleinbuchstaben geschrieben, unabhängig davon, was hier angezeigt wird. Weitere Informationen: Header-Daten
Dieses Beispiel zeigt die Daten, die in der Webhook-Anforderung zum Aktualisieren eines Kontakts übergeben werden, wobei der Webhook registriert wurde, um HttpHeader-Authentifizierungs-Schlüsselwertpaare zu übergeben:
| Key | Value |
|---|---|
X-Test1 |
test1 |
X-Test2 |
test2 |
Sie finden Ausführungskontextdaten als JSON-Zeichenfolge im RAW BODY-Abschnitt unten im Eintrag. Dies sind die Daten, die der Webdienst, der die Webhook-Anforderung verarbeitet, bewerten muss. Weitere Informationen:: Anforderungstext
Erstellen oder Konfigurieren eines Services zum Konsumieren von Webhook-Anforderungen.
Webhooks sind ein einfaches Muster, das mit einer Vielzahl von Technologien angewendet werden kann. Es gibt keine erforderlichen Frameworks, Plattformen oder Programmiersprachen, die Sie verwenden müssen. Nutzen Sie Ihr Wissen und Ihre Fähigkeiten, um die entsprechende Lösung bereitzustellen. Azure-Funktionen stellen eine ausgezeichnete Methode dar, um eine Lösung mit Webhooks zur Verfügung zu stellen, sind aber keine Notwendigkeit. Dieser Abschnitt enthält keine Anweisungen für eine bestimmte Lösung, stattdessen werden die Daten beschrieben, die an Ihren Service übergeben werden, damit dem Service ein Wert hinzugefügt werden kann.
Wie in Testen der Registrierung mit einer Anforderungsanmelde-Website beschrieben, können Sie einen Test-Webhook-Schritt registrieren und die Anforderungsanmelde-Website nutzen, um die bestimmten Daten zu erfassen, die von Ihrer Anwendung verarbeitet werden können.
An einen Service übergebene Daten
Es gibt drei Datentypen in der Anforderung: Abfragezeichenfolge, Header-Daten und Anforderungstext.
Abfragezeichenfolge
Die einzige Art von Daten, die als Abfragezeichenfolge übergeben werden, sind möglicherweise die Authentifizierungswerte, die übergeben werden, wenn der Webhook für die Nutzung der Optionen WebhookKey oder HttpQueryString konfiguriert ist, wie in Authentifizierungsoptionen beschrieben.
Header-Daten
Wenn Sie die Authentifizierungsoption HttpHeader auswählen, müssen Sie die Schlüssel-Wert-Paare verwenden, die für den Service erforderlich sind.
Andere Daten, die möglicherweise an Ihren Service übergeben wurden, finden Sie in der untenstehenden Tabelle:
| Key | Wertbeschreibung |
|---|---|
x-request-id |
Ein eindeutiger Bezeichner für die Anforderung |
x-ms-dynamics-organization |
Der Name des Mandanten, der die Anforderung sendet |
x-ms-dynamics-entity-name |
Der logische Name der Entität, die in den Ausführungskontextdaten übergeben wird. |
x-ms-dynamics-request-name |
Der Name des Ereignisses, für das der Webhook-Schritt registriert wurde. |
x-ms-correlation-request-id |
Eindeutiger Bezeichner für die Nachverfolgung eines beliebigen Erweiterungstyps. Diese Eigenschaft wird von der Plattform zur Vorbeugung von Endlosschleifen verwendet. In den meisten Fällen kann diese Eigenschaft ignoriert werden. Dieser Wert wird möglicherweise verwendet, wenn Sie sich an den technischen Support wenden, da er zum Abfragen von Telementrie verwendet werden kann,um herauszufinden, was während der gesamten Operation passiert ist. |
x-ms-dynamics-msg-size-exceeded |
Wird nur gesendet, wenn die Größe der HTTP-Nutzlast 256 KB übersteigt. |
Anforderungstext
Der Text enthält die Zeichenfolge, die den JSON-Wert einer Instanz der RemoteExecutionContext-Klasse darstellt. Hierbei handelt es sich um dieselben Daten, die für Azure Service Bus-Integrationen übergeben werden.
Der Service, den Sie erstellen, muss diese Daten analysieren, um für Ihren Service die relevanten Informationen zu extrahieren, um dessen Funktion bereitzustellen. Die Art, wie Sie das Analysieren dieser Daten festlegen, hängt von Ihren Einstellungen und der verwendeten Technologie ab.
Wichtig
Aufgrund bestimmten Service-Busoptimierungen wird jedoch nicht empfohlen, dass .NET-Entwickler einJSON formatierten Nachrichtenanforderungstext an ein RemoteExecutionContext Objekt deserialisieren. Besser ist es JObject zu verwenden, um den Nachrichtentext zu analysieren.
Im Folgenden finden Sie ein Beispiel serialisierter JSON-Daten, die für einen Schritt übergeben werden, der mit den folgenden Eigenschaften übergeben wird.
| Eigenschaft | Beschreibung |
|---|---|
| Meldung | Update |
| Primäre Entität | Kontakt |
| Sekundäre Entität | keine |
| Filterattribute | firstname,lastname |
| Im Kontext des Benutzers ausführen | Aufrufender Benutzer |
| Ausführungsreihenfolge | 1 |
| Ereignis-Pipeline-Phase der Ausführung | PostOperation |
| Ausführungsmodus | Asynchron |
In diesem Beispiel wurde der Vorname des Kontakts von "Jim" in "James" geändert.
{
"BusinessUnitId": "e2b9dd85-e89e-e711-8122-000d3aa2331c",
"CorrelationId": "b374239d-4233-41a9-8b17-a86cb4f737b5",
"Depth": 1,
"InitiatingUserId": "75c2dd85-e89e-e711-8122-000d3aa2331c",
"InputParameters": [{
"key": "Target",
"value": {
"__type": "Entity:http:\/\/schemas.microsoft.com\/xrm\/2011\/Contracts",
"Attributes": [{
"key": "firstname",
"value": "James"
}, {
"key": "contactid",
"value": "6d81597f-0f9f-e711-8122-000d3aa2331c"
}, {
"key": "fullname",
"value": "James Glynn (sample)"
}, {
"key": "yomifullname",
"value": "James Glynn (sample)"
}, {
"key": "modifiedon",
"value": "\/Date(1506384247000)\/"
}, {
"key": "modifiedby",
"value": {
"__type": "EntityReference:http:\/\/schemas.microsoft.com\/xrm\/2011\/Contracts",
"Id": "75c2dd85-e89e-e711-8122-000d3aa2331c",
"KeyAttributes": [],
"LogicalName": "systemuser",
"Name": null,
"RowVersion": null
}
}, {
"key": "modifiedonbehalfby",
"value": null
}],
"EntityState": null,
"FormattedValues": [],
"Id": "6d81597f-0f9f-e711-8122-000d3aa2331c",
"KeyAttributes": [],
"LogicalName": "contact",
"RelatedEntities": [],
"RowVersion": null
}
}],
"IsExecutingOffline": false,
"IsInTransaction": false,
"IsOfflinePlayback": false,
"IsolationMode": 1,
"MessageName": "Update",
"Mode": 1,
"OperationCreatedOn": "\/Date(1506409448000-0700)\/",
"OperationId": "4af10637-4ea2-e711-8122-000d3aa2331c",
"OrganizationId": "4ef5b371-e89e-e711-8122-000d3aa2331c",
"OrganizationName": "OrgName",
"OutputParameters": [],
"OwningExtension": {
"Id": "75417616-4ea2-e711-8122-000d3aa2331c",
"KeyAttributes": [],
"LogicalName": "sdkmessageprocessingstep",
"Name": null,
"RowVersion": null
},
"ParentContext": {
"BusinessUnitId": "e2b9dd85-e89e-e711-8122-000d3aa2331c",
"CorrelationId": "b374239d-4233-41a9-8b17-a86cb4f737b5",
"Depth": 1,
"InitiatingUserId": "75c2dd85-e89e-e711-8122-000d3aa2331c",
"InputParameters": [{
"key": "Target",
"value": {
"__type": "Entity:http:\/\/schemas.microsoft.com\/xrm\/2011\/Contracts",
"Attributes": [{
"key": "firstname",
"value": "James"
}, {
"key": "contactid",
"value": "6d81597f-0f9f-e711-8122-000d3aa2331c"
}],
"EntityState": null,
"FormattedValues": [],
"Id": "6d81597f-0f9f-e711-8122-000d3aa2331c",
"KeyAttributes": [],
"LogicalName": "contact",
"RelatedEntities": [],
"RowVersion": null
}
}, {
"key": "SuppressDuplicateDetection",
"value": false
}],
"IsExecutingOffline": false,
"IsInTransaction": false,
"IsOfflinePlayback": false,
"IsolationMode": 1,
"MessageName": "Update",
"Mode": 1,
"OperationCreatedOn": "\/Date(1506409448000-0700)\/",
"OperationId": "4af10637-4ea2-e711-8122-000d3aa2331c",
"OrganizationId": "4ef5b371-e89e-e711-8122-000d3aa2331c",
"OrganizationName": "OneFarm",
"OutputParameters": [],
"OwningExtension": {
"Id": "75417616-4ea2-e711-8122-000d3aa2331c",
"KeyAttributes": [],
"LogicalName": "sdkmessageprocessingstep",
"Name": null,
"RowVersion": null
},
"ParentContext": null,
"PostEntityImages": [],
"PreEntityImages": [],
"PrimaryEntityId": "6d81597f-0f9f-e711-8122-000d3aa2331c",
"PrimaryEntityName": "contact",
"RequestId": null,
"SecondaryEntityName": "none",
"SharedVariables": [{
"key": "ChangedEntityTypes",
"value": [{
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "feedback",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "contract",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "salesorder",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "connection",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "socialactivity",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "postfollow",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "incident",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "invoice",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "entitlement",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "lead",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "opportunity",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "quote",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "socialprofile",
"value": "Update"
}, {
"__type": "KeyValuePairOfstringstring:#System.Collections.Generic",
"key": "contact",
"value": "Update"
}]
}],
"Stage": 30,
"UserId": "75c2dd85-e89e-e711-8122-000d3aa2331c"
},
"PostEntityImages": [{
"key": "AsynchronousStepPrimaryName",
"value": {
"Attributes": [{
"key": "fullname",
"value": "James Glynn (sample)"
}, {
"key": "contactid",
"value": "6d81597f-0f9f-e711-8122-000d3aa2331c"
}],
"EntityState": null,
"FormattedValues": [],
"Id": "6d81597f-0f9f-e711-8122-000d3aa2331c",
"KeyAttributes": [],
"LogicalName": "contact",
"RelatedEntities": [],
"RowVersion": null
}
}],
"PreEntityImages": [],
"PrimaryEntityId": "6d81597f-0f9f-e711-8122-000d3aa2331c",
"PrimaryEntityName": "contact",
"RequestId": null,
"SecondaryEntityName": "none",
"SharedVariables": [],
"Stage": 40,
"UserId": "75c2dd85-e89e-e711-8122-000d3aa2331c"
}
Wichtig
Wenn die Größe der gesamten HTTP-Nutzlast 256 KB übersteigt, wird der x-ms-dynamics-msg-size-exceeded-Header mit eingeschlossen und die folgenden RemoteExecutionContext-Eigenschaften werden entfernt:
Einige Operationen enthalten diese Eigenschaften nicht.
Aufrufen eines Webhooks von einem Plug-In oder einer benutzerdefinierten Workflowaktivität
Da ein Webhook eine Art Dienstendpunkt ist, können Sie diesen ebenso aufrufen, ohne dass die Registrierung eines Schritts mit einem Plug-In oder einer Workflowaktivität erforderlich ist, wie dies auch bei einem Azure Service Bus-Endpunkt der Fall ist. Sie müssen die ServiceEndpointId für die IServiceEndpointNotificationService-Schnittstelle bereitstellen. Sehen Sie die folgenden Azure Service Bus-Beispiele, um weitere Informationen zu erhalten:
- Beispiel: Benutzerdefiniertes Azure-fähiges Plug-In
- Beispiel: Azure-fähige benutzerdefinierte Workflowaktivität
Siehe auch
Erweitern von Customer Engagement auf dem Server
Schreiben von Plug-Ins, um Geschäftsprozesse zu erweitern
Automatisieren der Geschäftsprozesse in Customer Engagement (on-premises)
Asynchroner Service in Dynamics 365 Customer Engagement (on-premises)
Azure-Erweiterungen für Dynamics 365 Customer Engagement (on-premises)
Beispiel: Benutzerdefiniertes Azure-fähiges Plug-In
Beispiel: Azure-fähige benutzerdefinierte Workflowaktivität
Azure-Funktionen
ServiceEndPoint-Entität
SdkMessageProcessingStep Entity
AsynchronousOperations-Entität
RemoteExecutionContext
IServiceEndpointNotificationService