Série v4.7 – Gestion du cycle de vie d’une application

Ce billet fait partie d’une série de billets sur les nouveautés de la version 4.7, mise à disposition le 22 septembre 2016.

Traduction directe d’ “Application Lifecycle Management” (ALM), la gestion du cycle de vie d’une application est une nouvelle fonctionnalité de la version 4.7. Destinée exclusivement aux concepteurs K2, cette nouveauté propose une assistance pour régler les problèmes de dépendance. Dit autrement, cela évite de tout casser quand fait une modification ! 

Petit rappel, dans la conception d’une application avec K2, on fait interagir des éléments – Formulaires, Vues, Smartobjects et Processus.
Le principe est (l’ordre a son importance, vous verrez) :

  1. concevoir des smartobjects sur des sources de services et de données ;
  2. réaliser des vues pour présenter une interface de ces smartobjects ;
  3. modéliser des formulaires contenant des vues.

Ainsi, une modification sur un élément a sans doute un impact sur un autre. Par exemple, retirer un champ d’une vue, utilisé dans une règle, pose des problèmes ; la règle en question ne peut plus utiliser le champs supprimé et cela peut avoir un impact sur d’autres règles ou sur le formulaire. C’est ce qu’on appelle les problèmes de dépendance ! Les plus fréquents sont liés aux propriétés (des smartobjects), aux expressions, aux conditions et aux règles (des vues et formulaires).

Revenons à notre ALM. Lors de la suppression d’un contrôle d’une vue avant la 4.7, le K2 Designer n’avertissait que si ce contrôle était utilisé dans une expression (rien pour les règles). Et il fallait corriger le problème tout de suite (impossible de sauvegarder). Depuis la 4.7, des indications sont données au concepteur pour présenter l’impact d’une modification. Ainsi, lors de la suppression d’un contrôle, le K2 Designer affiche maintenant les dépendances dans une fenêtre de dialogue. De plus, cette fenêtre permet au concepteur de choisir entre le marquage des dépendances cassées ou leur suppression.

enk2besoin_alm_dependance
La fenêtre de dépendance
Marquer les dépendances

Très pratique pour s’assurer que notre modification ne va pas causer des dégâts imprévus. Avec cette option, l’assistant précise avec un quel(s) impact(s) a eu la modification. Rien n’est corrigé, il faut vérifier un par un chacun des impacts que la modification a entraînés. Et cela n’est pas bloquant (sauvegarde et “finish” autorisé – en revanche, pas de checkin) pour les procrastinateurs concepteurs !

Les dépendances indiquées par K2 :

  1. les étapes de l’assistant de configuration sur lesquelles il faut faire des corrections ;
  2. les contrôles avec des erreurs ;
  3. les propriétés des contrôles en erreur ;
  4. les règles qui ont été impactées ;
  5. les actions/conditions à modifier.

enk2besoin_alm_dependance
enk2besoin_alm_dependance
enk2besoin_alm_dependance
enk2besoin_alm_dependance

Supprimer les dépendances

Alternative plus rapide, K2 supprime en cascade tout ce qui n’est plus disponible après la modification.

 A n’utiliser que si vous êtes 100% certain de ne pas causer d’effets de bord.

Corriger les problèmes de dépendance

La meilleure approche pour corriger les problèmes de dépendance est de commencer par le bas (je parle de la liste à 3 points de mon rappel, en début d’article). Je vous avais écrit que l’ordre a son importance  Ensuite, c’est vraiment du cas par cas !

A très bientôt pour un article sur d’autres fonctionnalités de la 4.7.0.

Ce billet fait partie d’une série de billets sur les nouvelles fonctionnalités de la 4.7.0. Les autres articles disponibles sur ce sujet sont :

benjamin

Technical Specialist @t K2 France ----- Twitter : @benjaminbertram ----- LinkedIn : Benjamin Bertram

9 thoughts to “Série v4.7 – Gestion du cycle de vie d’une application”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.