Effectuer des opérations spécialisées à l'aide de la fonction de mise à jour

Date de publication : novembre 2016

S’applique à : Dynamics CRM 2015

Avec les versions précédents, il fallait des messages spécialisés pour mettre à jour certaines valeurs d'attribut d'entité. Dans cette version, UpdateRequest peut désormais être utilisé pour définir ces attributs. Le tableau suivant répertorie les demandes de messages déconseillés spécialisés et les attributs de messages associés pouvant être mis à jour à l'aide de UpdateRequest.

*<entité> fait référence aux entités et fournit cet attribut.

Ces messages spécialisés continueront à fonctionner avec le point de terminaison 2011. Toutefois, il est recommandé d'utiliser la méthode UpdateRequest ou Update si possible pour définir ces attributs. Le message Update simplifie l'API SDK et la facilite pour coder les outils d'intégration de données standard utilisés avec Dynamics CRM. Par ailleurs, il est plus facile de coder et d'enregistrer un plug-in pour exécuter un message unique de Mise à jour au lieu de plusieurs messages spécialisés. La propriété AttributeMetadata.IsValidForUpdate pour les attributs répertoriés ci-dessus a été remplacée par true dans cette version pour activer cette fonctionnalité.

Vous pouvez continuer à utiliser ces messages spécialisés du point de terminaison 2011 dans votre code. Toutefois, l'API Web qui remplacera par la suite le point de terminaison 2011 prendra uniquement en charge le message Update pour ces types d'opérations. Si vous souhaitez avoir une longueur d'avance sur la modification de votre code à aligner avec l'API Web, vous pouvez désormais le faire. Voir Prévisualisation de l'API Web pour plus d'informations.

Impact de cette modification sur les plug-ins

Lorsque les demandes de mise à jour sont traitées, incluant les deux champs Propriétaire et d'autres champs standards pour les entités détenues par l'entreprise, les plug-ins enregistrés pour le message Mise à jour dans la phase de pipeline 20 et/ou la phase 40, s'exécutent une fois pour tous les champs non Propriétaire, puis une fois pour les champs Propriétaire. Voici des exemples de champs Propriétaire : businessunit et manager (pour une entité SystemUser). Voici des exemples d'entités détenues par l'entreprise : SystemUser, BusinessUnit, Equipment et Team.

Lorsque les demandes de mise à jour sont traitées, incluant les deux champs État/Statut et d'autres champs standards pour les entités détenues par l'entreprise, les plug-ins enregistrés pour le message Mise à jour dans la phase de pipeline 20 et/ou l'étape 40 s'exécutent une fois pour tous les champs non État/Statut, puis une fois pour les champs État/Statut.

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

Impact de cette modification sur les workflows

Lorsque les demandes de mise à jour sont traitées, incluant les deux champs Propriétaire et d'autres champs standards, les workflows enregistrés pour le message Mise à jour s'exécutent une fois pour tous les champs non Propriétaire, puis une fois pour les champs Propriétaire. 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, incluant les deux champs État/Statut et d'autres champs standard, les workflows enregistrés pour le message Mise à jour s'exécutent une fois pour tous les champs non État/Statut, puis une fois pour les champs État/Statut. Les workflows enregistrés pour l'étape Modifier le statut restent déclenchés par les mises à jour des champs État/Statut.

Voir aussi

Écrire des plug-ins pour étendre les processus d’entreprise
Écrire des workflows pour automatiser les processus d’entreprise

© 2017 Microsoft. Tous droits réservés. Copyright