Durchführen spezieller Vorgänge mithilfe des Updates

Veröffentlicht: Januar 2017

Gilt für: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Vor Microsoft Dynamics CRM Online 2015-Update 1 wurden spezielle Nachrichten benötigt, um bestimmte Entitätsattributwerte zu aktualisieren. In dieser Version kann UpdateRequest nun verwendet werden, um diese Attribute festzulegen. In der folgenden Tabelle werden die speziellen veralteten Nachrichtenanforderungen und die zugehörigen Nachrichtenattribute angegeben, die mit UpdateRequest aktualisiert werden können.

*<Entität> verweist auf eine beliebige Entität, die dieses Attribut bereitstellt.

Diese spezialisierten Nachrichten funktonieren weiterhin mit dem Endpunkt von 2011. Allerdings empfiehlt es sich, nach Möglichkeit die Methode UpdateRequest oder Update zu nutzen, um diese Attribute festzulegen. Die Nachricht Update vereinfacht den Organisationsservice und erleichtert die Codierung von standardmäßigen Datenintegrationstools, die mit Dynamics 365 verwendet werden. Außerdem ist es einfacher, ein Plug-In zu codieren und zu registrieren, um anstelle von mehreren speziellen Nachrichten eine einzelne Update-Nachricht auszuführen. Die Eigenschaft AttributeMetadata.IsValidForUpdate für die oben aufgeführten Attribute wurde in diesem Release in true geändert, um diese Funktion zu aktivieren.

Sie können weiterhin die speziellen Nachrichten des Endpunkts von 2011 in Ihrem Code verwenden. Die Web-API, die den Organisationsservice letztendlich ersetzt, unterstützt jedoch nur die Update-Nachricht für diese Arten von Vorgängen. Wenn Sie sich einen Vorsprung für die Abstimmung des Codes auf die Web-API verschaffen möchten, können Sie dies jetzt tun. Weitere Informationen finden Sie unter Verwenden der Microsoft Dynamics 365-Web-API.

Auswirkungen dieser Änderung auf Plug-Ins

Wenn Updateanforderungen verarbeitet werden, die beide Besitzerfelder sowie andere Standardfelder für Entitäten im Besitz von Unternehmenseinheiten enthalten, werden Plug-Ins, die für die Update-Nachricht in Phase 20 und/oder 40 der Pipeline registriert sind, einmal für alle Nicht-Besitzerfelder und dann einmal für die Besitzerfelder ausgeführt. Beispiele für Besitzersfelder sind businessunit und manager (für eine SystemUser-Entität). Beispiele für Entitäten im Besitzen von Unternehmen sind SystemUser, BusinessUnit, Equipment und Team.

Wenn Updateanforderungen verarbeitet werden, die beide Statusfelder sowie andere Standardfelder enthalten, werden Plug-Ins, die für die Update-Nachricht in Phase 20 und/oder 40 der Pipeline registriert sind, einmal für alle Nicht-Statusfelder und dann einmal für die Statusfelder ausgeführt.

Damit Plug-In-Code die gesamten Datenänderungen des Updates erhält, müssen Sie das Plug-In in Phase 10 registrieren und die relevanten Informationen in SharedVariables im Plug-In-Kontext speichern, damit spätere Plug-Ins (in der Pipeline) sie nutzen können.

Auswirkungen dieser Änderung auf Workflows

Wenn Updateanforderungen verarbeitet werden, die beide Besitzerfelder sowie andere Standardfelder enthalten, werden Workflows, die für die Update-Nachricht registriert sind, einmal für alle Nicht-Besitzerfelder und dann einmal für die Besitzerfelder ausgeführt. Die Workflows, die von Benutzern für die Assign-Nachricht registriert werden, werden weiterhin durch Updates von Besitzerfeldern gestartet.

Wenn Updateanforderungen verarbeitet werden, die beide Statusfelder sowie andere Standardfelder enthalten, werden Workflows, die für die Update-Nachricht registriert sind, einmal für alle Nicht-Statusfelder und dann einmal für die Statusfelder ausgeführt. Die Workflows, die für den Schritt Status ändern registriert werden, werden weiterhin über Updates an Statusfeldern gestartet.

Siehe auch

Schreiben von Plug-Ins, um Geschäftsprozesse zu erweitern
Automatisieren Sie Geschäftsprozesse mithilfe des Dynamics 365-Prozesses

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright