Lire en anglais

Partager via


Gestion d’un formulaire d’application piloté par modèle sain ALM

Cet article vous fournit des informations sur les différents scénarios sur la façon d’implémenter et de mettre en pratique une gestion saine du cycle de vie des applications (ALM) pour personnaliser les formulaires dans vos solutions d’applications pilotées par modèle.

Les sections suivantes décrivent le fonctionnement de la fusion de formulaires et la gestion des personnalisations. Les scénarios de développement de base avec des recommandations pour maintenir un ALM réussi pour un formulaire d’application basé sur un modèle sont traités en détail dans chaque section qui suit. Chaque scénario comprend des étapes à suivre qui peuvent vous aider à mettre en œuvre un processus ALM approprié lors de la mise à jour de votre solution ou de votre application basée sur un modèle.

Créer un nouveau formulaire et le maintenir à l’aide de plusieurs solutions gérées

Suivez ces étapes pour implémenter un formulaire sain ALM pour ce scénario.

  1. Créez un nouveau formulaire nommé FormA dans votre environnement de développement et effectuez des personnalisations sur le formulaire.
  2. Créez une nouvelle solution (nommée Solution A dans le diagramme ci-dessous) dans l’environnement de développement, qui sera une solution non gérée et ajoutera votre nouveau formulaire. Exportez la solution comme gérée. Cette étape exporte un FormXml complet pour le formulaire.
  3. Dans votre environnement de test, importez la solution gérée de l’étape 2, ce qui crée FormA dans l’environnement de test. Dans le schéma ci-dessous, FormA est créé dans l’environnement de test et l’interface utilisateur du formulaire affiche Field1 et Field2 que Solution A a ajoutés au formulaire.
  4. Lorsque vous personnalisez davantage le formulaire que vous avez créé à l’étape 1 en utilisant un nouvel environnement de développement (source), importez la Solution A gérée créée à l’étape 2 et assurez-vous que l’instance de développement que vous utilisez a FormA dans un état géré. Comme le montre le schéma ci-dessous, Solution A gérée est importée dans l’environnement de développement et le formulaire est personnalisé en créant des personnalisations actives. Puis, FormA peut ensuite être ajouté à une nouvelle solution non gérée (Solution B dans le diagramme) et exporté en tant que solution gérée à partir de l’environnement de développement. Cette étape exporte un FormXml différentiel pour le formulaire.
  5. Dans votre environnement de test, importez la solution gérée (Solution B) de l’étape 4. Comme le montre le schéma ci-dessous Solution B ajoute un nouveau Field3 à FormA et en enlevant Field2, qui a été ajouté par Solution A. L’interface utilisateur du formulaire dans l’environnement de test affiche désormais Field3 et Field1 sur le formulaire mais pas Field2 après la fusion.

Diagramme ALM du formulaire du scénario 1.

Exemple malsain pour ce scénario

Comme le montre le diagramme ci-dessous, ce n’est pas une pratique ALM saine de créer plusieurs solutions gérées à partir de l’environnement de développement où la solution de base (Solution A) est dans un état non géré. En effet, lorsque vous créez une autre solution non gérée (Solution B) pour le formulaire non géré, le FormXml est exporté en tant que FormXml complet, au lieu d’un FormXml différentiel comme indiqué dans le scénario valide ci-dessus. Par la suite, les modifications telles que la suppression d’une colonne ne prendront pas effet.

Exemple d’un formulaire ALM malsain pour ce scénario.

Création d’un nouveau formulaire et personnalisations à l’aide de correctifs et de mises à niveau

Suivez ces étapes pour implémenter un formulaire sain ALM pour ce scénario.

  1. Créez un nouveau formulaire nommé FormA dans votre environnement de développement et effectuez des personnalisations sur le formulaire.

  2. Créez une solution (nommée Solution A dans le diagramme ci-dessous), qui sera une solution non gérée et ajoutera votre nouveau formulaire. Exportez la solution comme gérée. Cette étape exporte un FormXml complet pour le formulaire.

  3. Dans votre environnement de test, importez la solution gérée de l’étape 2, ce qui créera le formulaire dans l’environnement de test. Dans le schéma ci-dessous, FormA est créé dans l’environnement de test et l’interface utilisateur du formulaire affiche Field1 et Field2 que Solution A a ajoutés au formulaire.

  4. Lorsque vous personnalisez davantage le formulaire que vous avez créé à l’étape 1 à l’aide de correctifs, utilisez le même environnement où Solution A est dans un état non géré et créez un correctif pour la solution et personnalisez le formulaire. Ensuite, exportez la solution comme solution gérée. Cette étape exporte un formXml complet pour le formulaire.

  5. Dans votre environnement de test, importez la solution de correctif gérée de l’étape 4. Comme le montre le schéma ci-dessous, le correctif Solution A ajoute un nouveau Field3 au FormA et en supprimant Field2, qui a été ajouté par Solution A.

    Notes

    Les correctifs contenant full formXml sont toujours comparés à la couche de base à partir de laquelle le patch a été créé et ignorent tous les correctifs intermédiaires entre la base et le correctif actuel. Par conséquent, Field2 est supprimé puisqu’il existe dans la couche de base Solution A et la suppression est détectée. D’autre part, Field3 est ajouté par cette solution de correctif et ne peut pas être supprimé par les correctifs suivants. Ainsi, les champs ajoutés par le biais de solutions de patch sont de nature additive.

  6. Lorsque vous personnalisez davantage le formulaire que vous avez créé à l’étape 1 à l’aide de mises à niveau, utilisez le même environnement où Solution A est dans un état non géré et clonez Solution A pour créer une solution de mise à niveau et personnalisez le formulaire. Ensuite, exportez la mise à niveau de Solution A comme solution gérée. Cette étape exporte un FormXml complet pour le formulaire.

  7. Dans votre environnement de test, importez la mise à niveau de Solution A de l’étape 6. Comme le montre le schéma ci-dessous, la mise à niveau de Solution A ajoute un nouveau Field4 au FormA et en enlevant Field2, qui a été ajouté par Solution A. L’interface utilisateur du formulaire dans l’environnement de test affiche désormais Field1 et Field3 et Field4, mais Field2 sera supprimé après que le formulaire a fusionné à partir de l’importation.

Diagramme ALM du formulaire du scénario 2.

Personnaliser un formulaire existant géré et le maintenir à l’aide de plusieurs solutions gérées

Suivez ces étapes pour implémenter un formulaire sain ALM pour ce scénario.

  1. Modifiez un formulaire géré existant, nommé FormB dans cet exemple, dans votre environnement de développement et effectuez des personnalisations sur le formulaire. Notez que la solution A est le solution gérée déjà installé pour le formulaire dans l’environnement de développement.
  2. Créez une nouvelle solution (nommée Solution B dans le diagramme ci-dessous), qui est une solution non gérée et ajoutez FormB. Exportez la solution comme gérée. Cette étape exporte un FormXml différentiel pour le formulaire.
  3. Dans votre environnement de test, importez la solution gérée de l’étape 2, ce qui créera une seconde couche de solution pour le formulaire. Dans le schéma ci-dessous, FormB obtient les modifications fusionnées de Solution A et Solution B dans l’environnement de test. L’interface utilisateur du formulaire affiche Field1 et Field3 sur le formulaire mais pas Field2 qui a été supprimé par Solution B.
  4. Lorsque vous personnalisez davantage le formulaire que vous avez personnalisé à l’étape 1 en utilisant de nouvelles solutions gérées, assurez-vous d’utiliser un nouvel environnement de développement qui a FormB dans un état géré. Comme le montre le schéma ci-dessous, les solutions gérées Solution A et Solution B sont importées dans le nouvel environnement de développement. FormB est personnalisé en créant des personnalisations actives, qui peuvent ensuite être ajoutées à une nouvelle solution (Solution C dans le diagramme) et exportées sous forme de solution gérée.
  5. Dans votre environnement de test, importez la Solution C gérée de l’étape 4. Comme le montre le schéma ci-dessous, Solution C ajoute un nouveau Field4 à FormB et enlève Field3, qui a été ajouté par Solution B. L’interface utilisateur du formulaire dans l’environnement de test affiche désormais Field1 et Field4 sur le formulaire, mais pas Field2 et Field3.

Diagramme ALM du formulaire du scénario 3.

Exemple malsain pour ce scénario

Comme le montre le diagramme ci-dessous, ce n’est pas une pratique ALM saine de créer plusieurs solutions gérées à partir de l’environnement de développement qui contient une autre solution non gérée créée pour le même formulaire. Remarquerez que Solution B est dans un état non géré. Lorsque vous créez une autre solution non gérée (Solution C) pour FormB, le FormXml est exporté en tant que FormXml différentiel comme indiqué à l’étape 4 du scénario ci-dessus. Mais, FormB contient également les modifications de Solution B, qui seront écrasées par vos nouvelles modifications.

Par exemple, comme le montre le schéma ci-dessous, Field3 est ajouté à FormB dans Solution B. Mais maintenant, lorsque vous créez un nouveau Solution C dans cet environnement, avec Solution B dans un état non géré et supprimez Field3, Field3 sera également supprimé dans l’environnement de développement. Field3 ne sera pas suivi dans le diff FormXml lorsque la solution est exportée, puisque le changement d’ajout et de suppression de cette colonne a été effectué dans le même couche actif. Cela signifie que lorsqu’il est géré Solution C est importé dans l’environnement de test, le formulaire affichera toujours le Field3 car le FormXml différentiel ne l’enregistre jamais comme supprimé (comme il a été supprimé à l’étape 5 dans le scénario ALM de formulaire sain ci-dessus). Effectuer vos personnalisations de formulaire de cette manière entraînera une incohérence entre l’environnement de développement et l’environnement de test.

Un autre exemple d’un formulaire ALM malsain pour ce scénario.

Personnaliser un formulaire existant géré et le maintenir à l’aide de correctifs et de mises à niveau

Suivez ces étapes pour implémenter un formulaire sain ALM pour ce scénario.

  1. Personnalisez un formulaire géré existant, nommé FormB dans cet exemple, dans votre environnement de développement et effectuez des personnalisations sur le formulaire. Notez que Solution A est la solution gérée déjà installé pour le formulaire dans l’environnement de développement.

  2. Créez une solution (nommée Solution B), qui sera une solution non gérée et ajoutez FormB. Exportez la solution comme gérée. Cette étape exporte un FormXml différentiel pour le formulaire.

  3. Dans votre environnement de test, importez la Solution B gérée de l’étape 2, ce qui créera une seconde couche de solution pour le formulaire. Dans le schéma ci-dessous, FormB obtient les modifications fusionnées de Solution A et Solution B dans l’environnement de test. De plus, l’interface utilisateur de FormB affiche Field1 et Field3 sur le formulaire mais pas sur Field2, qui a été supprimé par Solution B.

  4. Lorsque vous personnalisez davantage le formulaire que vous avez personnalisé à l’étape 1 à l’aide d’une solution de correctif, vous pouvez utiliser le même environnement de développement que l’étape 1 où Solution B existe dans un état non géré. Comme le montre le schéma ci-dessous, Solution A est dans un état géré et Solution B est dans un état non géré. Le formulaire est encore plus personnalisé et vous créez un patch pour Solution B en ajoutant votre formulaire à cette solution et en l’exportant en tant que solution de correctifs gérée. Cette étape exporte un FormXml différentiel.

  5. Dans votre environnement de test, importez la Solution B de correctifs gérée de l’étape 4. Comme le montre le schéma ci-dessous, le Dispositif de Solution B ajoute un nouveau Field4 au FormB et en supprimant Field3, qui a été ajouté par Solution B.

    Notes

    Les correctifs sont de nature additive et ne peuvent pas supprimer des composants du formulaire, tels que des colonnes. Donc, Field3 ne sera pas supprimé du formulaire. L’interface utilisateur du formulaire dans l’environnement de test affiche désormais Field1, Field3, et Field4 sur le formulaire, mais pas Field2.

  6. Lorsque vous personnalisez davantage le formulaire que vous avez créé à l’étape 1 à l’aide de mises à niveau, utilisez le même environnement où Solution B est dans un état non géré et clonez Solution B pour créer une solution de mise à niveau et personnalisez FormB. Exportez la mise à niveau comme solution gérée. Cette étape exporte un FormXml différentiel pour le formulaire.

  7. Dans votre environnement de test, importez la solution de mise à niveau gérée Solution B de l’étape 6. Comme le montre le schéma ci-dessous, Mise à niveau de Solution B ajoute un nouveau Field5 à FormB et enlève Field3, qui a été ajouté par Solution B. L’interface utilisateur du formulaire dans l’environnement de test affiche désormais Field1 et Field4 et Field5 sur le formulaire, mais Field2 et Field3 ont été supprimé.

Modifiez un formulaire géré existant à l’aide d’un diagramme de correctifs et de mises à niveau.

Maintenir des solutions et des personnalisations non gérées pour une nouveau formulaire dans plusieurs environnements de développement

Suivez ces étapes pour implémenter un formulaire sain ALM pour ce scénario.

  1. Dans Environnement de développement 1, créez un nouveau formulaire FormA et effectuez des personnalisations sur le formulaire.
  2. Créez une solution (nommée Solution A dans le diagramme ci-dessous) dans l’environnement de développement, qui sera une solution non gérée, et ajoutera votre nouveau formulaire. Exportez la solution comme non gérée. Cette étape exporte un FormXml complet pour le formulaire.
  3. Dans Environnement de développement 2, importez la solution non gérée de l’étape 2, qui crée le formulaire dans Environnement de développement 2. Dans le schéma ci-dessous, FormA est créé et l’interface utilisateur du formulaire affiche Field1 et Field2 que Solution A a ajoutés au formulaire.
  4. Vous personnalisez davantage le formulaire dans Environnement de développement 2 en effectuant des personnalisations actives dans l’environnement, telles que l’ajout d’une nouvelle colonne nommée Field3. FormA affiche désormais Field1, Field2 et Champ3.
  5. Dans votre Environnement de développement 1, vous personnalisez davantage le formulaire également en ajoutant Field4. L’interface utilisateur du formulaire dans Environnement de développement 1 affiche désormais Field1, Field2, et Field4.
  6. Exportez la Solution A non gérée avec les modifications apportées à l’étape 5. Cette étape exporte un FormXml complet pour le formulaire.
  7. Dans Environnement de développement 2, importez la Mise à niveau de Solution A non gérée de l’étape 6. Étant donné que la solution que vous importez contient le FormXml complet pour FormA, il écrase la personnalisation active effectuée dans Environnement de développement 1. Ainsi, le formulaire affiche désormais uniquement Field1, Field2, et Field4, mais non Field3, qui était la personnalisation active supplémentaire effectuée dans Environnement de développement 1. Ce comportement se produit avec toute importation de solution non gérée qui a le FormXml complet pour le formulaire.

Solutions non gérées dans plusieurs environnements.

Maintenir des solutions et des personnalisations non gérées pour un formulaire existant dans plusieurs environnements de développement

Suivez ces étapes pour implémenter un formulaire sain ALM pour ce scénario.

  1. Dans Environnement de développement 1, personnalisez un formulaire existant, nommé FormB dans cet exemple. Effectuez ensuite des personnalisations sur le formulaire.
  2. Créez une nouvelle solution (nommée Solution B dans le diagramme ci-dessous) qui sera une solution non gérée et ajoutez FormB. Exportez la solution comme non gérée. Cette étape exporte un FormXml différentiel pour le formulaire.
  3. Dans Environnement de développement 2, importez la solution non gérée de l’étape 2, ce qui créera une seconde couche de solution pour le formulaire. L’interface utilisateur de FormB montre Field1, Field2, et Field3 après la fusion du formulaire.
  4. Vous personnalisez davantage le formulaire dans Environnement de développement 2 en effectuant des personnalisations actives dans l’environnement, telles que l’ajout d’une nouvelle colonne nommée Field4. FormB affiche désormais Champ1, Champ2, Champ3 et Champ4.
  5. Dans Environnement de développement 1, vous personnalisez davantage le formulaire également en ajoutant une nouvelle colonne nommée Field5. L’interface utilisateur du formulaire dans Environnement de développement 1 affiche désormais Field3 et Field5.
  6. Exportez la Solution B non gérée avec les modifications apportées à l’étape 5. Cette étape exporte un FormXml différentiel pour le formulaire.
  7. Dans Environnement de développement 2, importez la Mise à niveau de Solution B non gérée de l’étape 6. Étant donné que la solution que vous importez contient le FormXml différentiel pour FormB, il fusionnera avec la personnalisation active effectuée dans Environnement de développement 1. Donc, le formulaire montre maintenant Field1, Field2, Field3, Field4 et Field5. Ce comportement se produit pour toute importation de solution non gérée qui a le FormXml différentiel pour le formulaire.
  8. Si la fusion de formulaires à l’étape 7 n’est pas ce que vous souhaitez même si vous importez un FormXml différentiel avec la solution non gérée et que vous souhaitez pouvoir écraser les personnalisations actives effectuées dans Environnement de développement 2, alors supprimez la couche active pour FormB. Plus d’informations : Supprimer une couche non gérée.
  9. Exportez la Solution B non gérée avec les modifications apportées à l’étape 5. Cette étape exporte un FormXml différentiel pour le formulaire.
  10. Dans Environnement de développement 2, importez la Mise à niveau de Solution B non gérée de l’étape 9. Comme il n’y a pas de couche active pour le formulaire dans Environnement de développement 2, (voir étape 8), toutes les modifications de la Solution B non gérée sont importées même si vous importez le FormXml différentiel pour FormB. Donc, le formulaire montre maintenant uniquement Field1, Field2, Field3, et Field5. Ce comportement se produit pour toute importation de solution non gérée qui a le FormXml différentiel pour le formulaire. C’est le même résultat que l’étape 7 dans le scénario Maintenir des solutions et des personnalisations non gérées pour un formulaire existant dans plusieurs environnements de développement.

Schéma de la gestion du cycle de vie des applications du formulaire du scénario 6.

Formulaire XML complet et différentiel

Chaque package de solution exporté comprend un fichier customizations.xml. Chaque fois qu’un formulaire est inclus dans une solution, la définition de formulaire associée existe dans les sections FormXml du fichier customizations.xml. FormXml peut être soit complet ou alors différentiel (diff).

FormXml complet

Le FormXml que vous obtenez en exportant une solution pour un formulaire dans un état non géré s’appelle un FormXml complet. Complet signifie qu’il contient la définition complète du formulaire. Lorsque vous créez un nouveau formulaire et que vous l’exportez, le formulaire sera toujours un FormXml complet car le formulaire dans l’environnement à partir duquel vous exportez est dans un état non géré et est également dans un état de création. Si vous exportez d’autres solutions à partir de ce même environnement, celles-ci incluront également un FormXml complet. Parce que l’attribut solutionaction indique un FormXml différentiel, le FormXml complet dans le fichier customization.xml dans la solution que vous exportez ne contiendra aucun attribut solutionaction.

FormXml différentiel (diff)

Le FormXml que vous obtenez lorsque vous exportez une solution pour un formulaire dans un état géré s’appelle un FormXml différentiel ou diff. Différentiel signifie que le FormXml contient uniquement les modifications apportées aux personnalisations actives dans cet environnement et non la définition complète du formulaire. Lorsque vous personnalisez un formulaire géré existant et que vous l’exportez, le formulaire sera toujours un FormXml différentiel car il ne contiendra que les modifications actives qui y ont été apportées. Le FormXml différentiel dans le fichier customization.xml de la solution que vous exportez contiendra les attributs solutionaction définissant quels sont les changements, comme Ajouté, Supprimé, Modifié.

Le FormXml différentiel garantit que votre solution n’exprimera que les changements dont votre application a besoin et sera moins impactée par les changements des autres couches. Le FormXml différnetiel rend également la solution moins volumineuse et l’aide à importer plus rapidement.

Voir aussi

Recommandations pour une forme saine d’ALM