Partager via


Comportement des opérations de mise à jour spécialisées

Il existe plusieurs messages spécialisés déconseillés qui exécutent des opérations de mise à jour. Dans les versions antérieures, il était nécessaire d’utiliser ces messages, mais maintenant les mêmes opérations doivent être effectuées à l’aide de IOrganizationService.Update ou à l’aide de la classe UpdateRequest avec IOrganizationService.Execute

Demande de message déconseillé Attribut(s) à mettre à jour
AssignRequest <entité>.OwnerId
SetStateRequest <entité>.StateCode
<entité>.StatusCode
SetParentSystemUserRequest SystemUser.ParentSystemUserId
SetParentTeamRequest Team.BusinessUnitId
SetParentBusinessUnitRequest BusinessUnit.ParentBusinessUnitId
SetBusinessEquipmentRequest Equipment.BusinessUnitId
SetBusinessSystemUserRequest SystemUser.BusinessUnitId

<entité> fait référence à toute entité qui fournit cet attribut.

Important

Lorsque vous mettez à jour la colonne StateCode, il est important de toujours définir le StatusCode souhaité.

StateCode et StatusCode ont des valeurs dépendantes. Il peut y avoir plusieurs valeurs StatusCode valides pour une valeur StateCode donnée, mais chaque colonne StateCode a une seule valeur de DefaultStatus configurée. Lorsque vous mettez à jour StateCode sans spécifier de StatusCode, la valeur d’état par défaut est définie par le système.

De plus, lorsque l’audit est activé sur la table et la colonne StatusCode, la valeur modifiée de la colonne StatusCode ne sera pas capturée dans les données d’audit, sauf si elle est spécifiée dans l’opération de mise à jour.

Pour plus d’informations, voir Messages de mise à jour hérités.

Cette modification a introduit des comportements spéciaux qui doivent être notés pour les plug-ins et les flux de travail.

Pour les plug-ins

Lorsque les demandes de mise à jour sont traitées qui incluent les deux champs propriétaires ainsi que d’autres champs standard pour les tables appartenant à l’entreprise, les plug-ins inscrits pour le message de mise à jour dans les phases PreOperation et/ou PostOperation s’exécutent une fois pour tous les champs non-propriétaires, puis une fois pour les champs propriétaires. Exemples de champs propriétaires seraient : businessunit et manager (pour une table SystemUser). Parmi les exemples de tables appartenant à l’entreprise, citons SystemUser, BusinessUnit, Equipment et Team.

Lorsque les demandes de mise à jour sont traitées qui incluent les champs d’état/état ainsi que d’autres champs standard, les plug-ins inscrits pour le message de mise à jour dans les phases PreOperation et/ou PostOperation s’exécutent une fois pour tous les champs non-état/état, puis une fois pour les champs d’état/état.

Pour que le code du plug-in reçoive les modifications complètes des données de la mise à jour, vous devez inscrire le plug-in dans le PreOperation puis stocker les informations dans SharedVariables pertinentes dans le contexte du plug-in pour que les plug-ins ultérieurs (dans le pipeline) puissent les utiliser.

Pour les flux de travail

Lorsque les demandes de mise à jour sont traitées qui incluent les deux champs propriétaires et d’autres champs standard, les flux de travail inscrits pour le message de mise à jour s’exécutent une fois pour tous les champs non-propriétaires, puis une fois pour les champs propriétaires. Les workflows enregistrés pour le message Attribuer par les utilisateurs continuent à être déclenchés par les mises à jour des champs Propriétaire.

Lorsque les demandes de mise à jour sont traitées qui incluent les champs d’état/état ainsi que d’autres champs standard, les flux de travail inscrits pour le message de mise à jour s’exécutent une fois pour tous les champs non-état/état, puis une fois pour les champs d’état/état. Les flux de travail inscrits pour l’étape Modifier l’état continuent d’être déclenchés par des mises à jour des champs d’état/état.

Voir aussi

Mettre à jour et supprimer des tables à l’aide du Kit de développement logiciel (SDK) pour .NET
Infrastructure d’événements