Transition des applications vers Dataverse ServiceClient

  • Article

Nous opérons une transition depuis SDK Microsoft Dataverse pour .NET pour inclure un nouveau client de service Web qui utilise la bibliothèque d’authentification Microsoft (MSAL) pour l’authentification. Cet article contient les informations dont vous avez besoin pour comprendre pourquoi nous apportons ces modifications, ce qui est impacté et comment mettre à jour vos applications clientes afin qu’elles continuent à fonctionner comme prévu.

Notes

Une partie de notre documentation existante pour développeur et de notre exemple de code utilise les API du SDK Dataverse qui se trouvent dans le package CoreAssemblies NuGet. Cet article décrit le nouveau package Dataverse.Client NuGet recommandé et les modifications nécessaires pour en faire usage. Les mises à jour de la documentation et de l’exemple de code se produisent au fil du temps.

Pourquoi la modification ?

Il y a quelques bonnes raisons pour les changements apportés au SDK Dataverse pour .NET. Quelques-unes sont répertoriées ci-dessous.

Prise en charge d’application multiplateforme

La nouvelle classe DataverseServiceClient prend en charge le développement .NET Core. Accédez à Microsoft.PowerPlatform.Dataverse.Client et sélectionnez l’onglet Frameworks pour voir quelles cibles de génération sont prises en charge.

Authentification MSAL

La bibliothèque d’authentification Microsoft Azure Active Directory (ADAL.NET) ne reçoit plus de support. La bibliothèque d’authentification Microsoft (MSAL.NET) est l’API d’authentification recommandée à l’avenir. Notre nouvelle API ServiceClient utilise MSAL alors que nos anciennes API CrmServiceClient utilisent ADAL.

Performances et avantages fonctionnels

La classe Dataverse ServiceClient prend en charge une surface d’interface plus petite, l’authentification en ligne par instance et Microsoft.Extensions.Logging.ILogger. Comme pour l’authentification en ligne, vous pouvez transmettre une fonction de gestionnaire d’authentification personnalisée au constructeur ServiceClient. De cette façon, vous pouvez avoir un gestionnaire d’authentification par connexion de service Web au lieu d’un seul par processus.

Qu’est-ce qui est impacté ?

Vous trouverez ci-dessous un bref résumé de l’impact sur certains types de projets de codage.

  • Plug-ins ou activités de workflow personnalisées – sans modification

  • Applications en ligne nouvelles ou existantes – vous devez lire cet article

  • Applications sur site – cet article ne vous concerne pas, pas encore

Que devez-vous faire ?

La bonne nouvelle est que les signatures des membres des classes ServiceClient et CrmServiceClient sont les mêmes, sauf que les noms de classe eux-mêmes sont légèrement différents. Le code d’application ne devrait pas nécessiter de modifications importantes.

Projets d’application (en ligne) basés sur .NET Framework

Pour mettre à jour vos projets d’application, procédez comme suit :

  1. Supprimez les anciens packages CoreAssemblies NuGet (et associés) de votre projet.
  2. Ajoutez le nouveau package Dataverse.Client NuGet à votre projet.
  3. Changez chaque mention de la classe CrmServiceClient en ServiceClient dans votre code.
  4. Corrigez toute incompatibilité d’espace de noms, car la nouvelle classe ServiceClient est maintenant dans l’espace de noms Microsoft.PowerPlatform.Dataverse.Client.

Projets basés sur .NET Core (en ligne)

Ajoutez simplement le package Dataverse.Client NuGet à vos projets, ajoutez du code pour appeler les API du SDK Dataverse, et générez la build.

Plug-ins ou activités de workflow personnalisées

Vous n’avez vraiment rien à faire ici. Continuez à utiliser les packages Microsoft.CrmSdk.CoreAssemblies NuGet (et associés) avec .NET Framework 4.6.2.

Clients locaux

Laissez vos projets d’application et votre code tels quels. Continuez à utiliser le package Microsoft.CrmSdk.CoreAssemblies NuGet et la classe CrmServiceClient. Cependant, prévoyez de mettre à jour vos projets en utilisant des clients de service personnalisés pour utiliser plutôt les classes CrmServiceClient ou ServiceClient à l’avenir. Consultez la chronologie prévue pour l’arrêt du point de terminaison SOAP 2011 ci-dessous.

Notes

Si vous utilisez une authentification personnalisée avec CrmServiceClient, vous pouvez continuer à utiliser votre code d’authentification personnalisé avec ServiceClient.

Exemples de code

Disponibles ici : Exemples de code ServiceClient

Chronologie

Le tableau suivant énumère quelques dates importantes à garder à l’esprit.

Délai d’exécution Événement
Juin 2022 Version en disponibilité générale du package Microsoft.PowerPlatform.Dataverse.Client NuGet
Décembre 2022 Fin de la prise en charge d’ADAL par Microsoft
À une date ultérieure Arrêt planifié du point de terminaison SOAP 2011 pour l’accès par des applications clientes n’utilisant pas nos clients de service (CrmServiceClient ou ServiceClient)

Important

La classe CrmServiceClient continuera à fonctionner comme documenté même après la désactivation de l’authentification ADAL. Les deux classes de client de service continueront de fonctionner comme indiqué après la désactivation du point de terminaison SOAP 2011. Si nécessaire, nous pouvons publier un assembly mis à jour contenant des clients de service révisés que votre application devra charger au moment de l’exécution.

Voir aussi

Présentation de la bibliothèque d’authentification Microsoft (MSAL)
Migrer des applications vers la bibliothèque d’authentification Microsoft (MSAL)

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).