Verhalten spezialisierter Update-Vorgänge

Es gibt mehrere veraltete spezialisierte Nachrichten, die Aktualisierungsvorgänge ausführen. In früheren Versionen wurde es erforderlich, um die Nachrichten zu verwenden, aber jetzt können dieselben Vorgänge mithilfe von IOrganizationService Update ausgeführt werden. oder UpdateRequest Klasse mit IOrganizationService.Execute

Veraltete Nachrichtenanforderung	Zu aktualisierende(s) Attribut(e)
AssignRequest	<Entität>.OwnerId
SetStateRequest	<Entität>.StateCode <Entität>.StatusCode
SetParentSystemUserRequest	SystemUser.ParentSystemUserId
SetParentTeamRequest	Team.BusinessUnitId
SetParentBusinessUnitRequest	BusinessUnit.ParentBusinessUnitId
SetBusinessEquipmentRequest	Arbeitsgerät.BusinessUnitId
SetBusinessSystemUserRequest	SystemUser.BusinessUnitId

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

Wichtig

Wenn Sie die Spalte StateCode aktualisieren, ist es wichtig, dass Sie immer den gewünschten StatusCode festlegen.

StateCode und StatusCode haben abhängige Werte. Es kann mehrere gültige StatusCode-Werte für einen bestimmten StateCode-Wert geben, aber für jede StateCode-Spalte ist ein einziger DefaultStatus-Wert konfiguriert. Wenn Sie StateCode aktualisieren, ohne einen StatusCode anzugeben, wird der Standardstatuswert vom System festgelegt.

Wenn die Überwachung für die Tabelle und die StatusCode-Spalte aktiviert ist, wird der geänderte Wert für die StatusCode-Spalte nicht in den Überwachungsdaten erfasst, es sei denn, er wird im Aktualisierungsvorgang angegeben.

Weitere Informationen: Veraltete Update-Nachrichten

Diese Änderung führte ein spezielles Verhalten ein, das für Plug-Ins und Workflows beachtet werden soll.

Für Plug-Ins

Wenn Aktualisierungsanforderungen verarbeitet werden, die sowohl Eigentümer-Felder als auch andere Standard-Felder für unternehmenseigene Tabellen enthalten, werden Plug-Ins, die für die Nachricht Update in den Phasen PreOperation und/oder PostOperation registriert sind, einmal für alle Nicht-Eigentümer-Felder und dann einmal für die Eigentümer-Felder ausgeführt. Beispiele für Besitzer-Felder wären businessunit und manager (für eine SystemUser-Tabelle). Beispiele für Tabellen, die dem Unternehmen gehören, sind SystemUser, BusinessUnit,Equipment und Team.

Wenn Updateanforderungen verarbeitet werden, die Zustand-/Statusfelder sowie andere Standardfelder enthalten, werden Plug-Ins, die für die Update-Nachricht in den Phasen PreOperation und/oder PostOperation registriert sind, einmal für alle Nicht-Zustand-/Statusfelder und dann einmal für die Zustand-/Statusfelder ausgeführt.

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

Für 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

Tabellen mit dem SDK für .NET aktualisieren und löschen
Ereignisframework

Hinweis

Können Sie uns Ihre Präferenzen für die Dokumentationssprache mitteilen? Nehmen Sie an einer kurzen Umfrage teil. (Beachten Sie, dass diese Umfrage auf Englisch ist.)

Die Umfrage dauert etwa sieben Minuten. Es werden keine personenbezogenen Daten erhoben. (Datenschutzbestimmungen).