Application Lifecycle Management et Environment Lifecycle Management
Un aspect primordial des mappages de table et de leur personnalisation est la gestion des modifications. Il est important de savoir gérer ces différents mappages de table. De plus, il est impératif de savoir gérer la version de ces mappages et des différentes modifications qui sont apportées au cours de l’intégration en double écriture.
Dans Dataverse, les concepts de contrôle de version et d’Application Lifecycle Management (ALM) sont mis en œuvre via des solutions. Par conséquent, il est logique que les mappages en double écriture soient gérés comme des solutions Microsoft Power Apps. Ce mécanisme permet de modifier le packaging et de conserver divers composants de Dataverse. Les mappages d’entités, les extensions et les personnalisations prennent en charge la solution et sont gérés de la même manière que Dataverse. « Prendre en charge » la solution signifie qu’un composant est une partie du système, qu’il peut être packagé et, par conséquent, importé et exporté entre des environnements et des systèmes.
Options d’extensibilité
La première étape consiste à personnaliser les mappages standard prêts à l’emploi à partir de la solution en double écriture. Dans le module Intégrer des applications de finances et d’opérations dans Microsoft Power Platform à l’aide de concepts clés et de la configuration, vous avez appris à installer la solution d’orchestration et la solution principale. Ces deux solutions proposent des mappages prêts à l’emploi que vous pouvez personnaliser.
Mappages de tables
Les entreprises souhaitent souvent ajuster et modifier les mappages de tables. Ce faisant, elles modifient également certaines propriétés du mappage. Chaque mappage de table possède un éditeur et une version, que vous pouvez modifier à mesure que vous le personnalisez. De plus, vous pouvez incrémenter chaque mappage de table dans la version. Cependant, gardez à l’esprit que la double écriture prend en charge les mappages de table uniquement entre les tables inter-sociétés ou les tables propres à la société des deux côtés. Vous ne pouvez pas mapper une table inter-sociétés sur une table propre à une société. Le fait de prendre en compte le concept de clé d’intégration vous informera lorsque vous personnaliserez ces mappages. Chaque solution en double écriture peut contenir un ou plusieurs mappages de table en double écriture.
Mappage de colonnes
Dans les mappages de table en double écriture, vous pouvez également modifier et configurer les colonnes. Vous avez la possibilité d’ajouter une nouvelle colonne en sélectionnant Ajouter un mappage, puis en sélectionnant une colonne existante ou personnalisée dans la liste. Vous pouvez également ajouter des colonnes Système et Client. Vous pouvez personnaliser le sens de la synchronisation (unidirectionnelle ou bidirectionnelle) et ajouter des transformations en sélectionnant le type de mappage.
Vous pouvez sélectionner deux types de transformations :
- Par défaut : les valeurs par défaut sont appliquées aux colonnes de destination lorsqu’aucune valeur de colonne source n’est disponible.
- Mappage des valeurs : définit la façon dont les valeurs présentes dans une table doivent être mappées sur les valeurs de l’autre table.
Pour en savoir plus, consultez Personnaliser les mappages de tables et de colonnes.
Ces modifications apportées aux mappages de table standard ou nouveaux sont enregistrées dans le cadre de la solution principale en double écriture, plus précisément, le référentiel Mappages d’entité de double écriture contenu dans ALM. De plus, vous pouvez créer des solutions personnalisées pour maîtriser encore davantage la gestion des versions et du cycle de vie.
Filtrage
Une question fréquemment posée lors de la mise en œuvre de la double écriture concerne les fonctionnalités de filtrage et la manière de les modifier dans les applications de finances et d’opérations et les applications d’engagement client. Les fonctionnalités de filtrage peuvent affecter votre intégration en double écriture, il est donc important de connaître les options qui s’offrent à vous.
Des filtres pour la double écriture dans les applications de finances et d’opérations sont disponibles pour les types de données primitifs et les requêtes simples. Ces filtres ne prennent pas en charge les types de données date-heure, les chaînes longues ou les conteneurs et autres colonnes complexes que vous pourriez avoir.
Les expressions de filtre en double écriture pour les applications de finances et d’opérations sont évaluées et transformées en une instruction SQL, où des valeurs null sont généralement attendues. Cependant, les filtres null ne sont pas pris en charge en raison des limitations de la plateforme pour les applications de finances et d’opérations ; null correspond à des données, celles-ci ne sont pas simplement manquantes. Par exemple, un filtre sur une entité de données peut être défini sur une chaîne vide " ". Si l’évaluation se termine par une chaîne vide, elle sera évaluée comme true. Cependant, si l’évaluation est NULL, et que la valeur renvoyée est NULL, alors elle n’est pas évaluée comme true.
Dans ces cas, et pour des situations de filtrage plus complexes, nous vous conseillons de prendre les mesures suivantes :
- Tentez d’utiliser une colonne calculée, un champ booléen ou un autre critère de filtre simpliste qui renverra un ensemble de données plus simplifié. Les colonnes calculées peuvent gérer spécifiquement des plages de dates ou d’autres scénarios plus complexes au niveau de l’entité.
- Vérifiez que les données filtrées sont mappées pour corriger les champs et les colonnes s’il est important que les données filtrées soient transférées. Ce concept est important. Par exemple, imaginez un scénario dans lequel vous avez une personne à contacter, qui est utilisée pour un mappage en double écriture. Vous avez un filtre sur le numéro du contact associé, mais vous n’avez pas de mappage physique sur la colonne du numéro du contact. Dans ce cas, les modifications apportées à ce filtre ne sont pas récupérées par l’intégration à double écriture, car la double écriture suit uniquement les champs qui sont mappés directement. Par conséquent, vous devrez vous assurer que la colonne filtrée fait partie de la carte. Veillez à évaluer les processus métier afin de vous assurer que les colonnes filtrées qui font partie de l’ajout, de la suppression ou de la mise à jour des données sont également mappées.
Les filtres de Dataverse sont différents, car ils utilisent des expressions de filtre OData et sont plus simples que les filtres disponibles dans les applications de finances et d’opérations. Seuls les opérateurs de filtre standard qui agissent directement sur les colonnes Table sont pris en charge dans les applications de finances et d’opérations.
Pour en savoir plus, consultez Filtrer les résultats - Opérateurs de filtre standard.
Environment lifecycle management
Lorsque vous disposez d’une solution, qu’il s’agisse d’une solution personnalisée ou d’une solution standard étendue, vous pouvez la publier et l’importer dans un autre environnement. Cette option existe car, généralement, un ratio d’environnements de 1:1 existe pour les applications de finances et d’opérations et Dataverse.
Par exemple, dans les applications de finances et d’opérations, vous pouvez avoir plusieurs environnements de développement, un environnement de test, un environnement intermédiaire et un environnement de production. Au fur et à mesure que vous développez de nouvelles fonctionnalités pour les applications de finances et d’opérations, la solution est publiée via des packages dans chaque environnement à des fins différentes. Dans l’environnement de test, vous pouvez demander à tous les utilisateurs de tester les capacités et les nouvelles fonctionnalités qui ont été développées. Lorsque la solution a été promue dans l’environnement de phase, vous n’aurez peut-être que peu de validation à faire avant d’envoyer les modifications en production, où les utilisateurs utiliseront la nouvelle fonctionnalité ou la personnalisation.
Un processus similaire existe pour Dataverse. Ce processus de transfert du développement et des modifications d’un environnement à un autre fait partie d’ELM et d’ALM.
Un autre aspect d’ELM consiste à mettre à jour la version des applications de finances et d’opérations ou de Dataverse, et même la solution principale de double écriture, pour obtenir davantage de fonctionnalités et fonctions publiées par Microsoft pour améliorer l’utilisation quotidienne des applications.
La promotion ou le transfert du développement d’un environnement vers un autre, et le processus de mise à jour de chaque environnement pour les applications de finances et d’opérations et Dataverse, s’appelle Environment Lifecycle Management (ELM).
Dans Dataverse, ce processus ressemble à la publication de nouvelles versions de solutions, tandis que dans les applications de finances et d’opérations, il s’apparente au processus de promotion et d’application de packages de code personnalisés aux environnements. Pour la double écriture, ce processus ressemble au processus de mise à jour des mappages de table en fonction des nouvelles solutions et de la logique métier appliquées aux deux systèmes. Chaque processus est nécessaire pour garantir que les environnements connectés par double écriture sont à jour, disposent des informations les plus récentes et précises pour les utilisateurs professionnels et affichent les versions mises à jour des mappages pour l’intégration.
Pour plus d’informations sur la double écriture, la promotion de solutions et la gestion du cycle de vie de la double écriture, consultez Application Lifecycle Management.
Pour plus d’informations sur les solutions les plus récentes et les mappages de table publiés par Microsoft pour la double écriture, consultez Nouveautés ou modifications dans la double écriture.