Stratégie de modification

ccppmop1592
Cette rubrique relative à la stratégie de modification décrit les différences entre les
configurations
et les
personnalisations
des produits
PPM classique
et la portée de leur support technique.
Cette stratégie s'applique à toutes les versions actives de
PPM classique
sur site et
PPM classique
SaaS, notamment 15.x, 14.x, 13.x et les versions antérieures.
Configurations
La section
Configurations
porte sur l'utilisation de fonctions décrites permettant de modifier le comportement initial du produit livré. Exemples de fonctionnalités décrites que vous pouvez utiliser pour créer des configurations : flux de processus, portlets Studio et intégrations XOG. CA Technologies prend en charge les fonctionnalités décrites, mais non les configurations associées elles-mêmes. Par exemple, la fonctionnalité Studio utilisée pour créer un portlet de diagramme est prise en charge, mais les caractéristiques du code NSQL sous-jacent permettant de fournir des données au portlet ne le sont pas. Dans ce cas, le fonctionnement des fonctionnalités décrites sera vérifié en fonction du changement de configuration spécifique, mais CA Technologies ne résoudra pas la configuration elle-même. En plus du code NSQL, les scripts GEL, les modifications apportées aux univers, domaines ou attributs de création de rapports BusinessObjects et les intégrations personnalisées XOG, entraînant ou non des problèmes de performances, constituent d'autres exemples de changements de configuration non pris en charge. CA Technologies collaborera avec le client pour isoler les problèmes rencontrés lors de l'utilisation des fonctionnalités décrites dans le but de confirmer qu'ils découlent de l'exécution incorrecte des fonctions du produit (et non de la conception ou l'implémentation incorrecte de configurations).
Personnalisations
Les
personnalisations
concernent l'utilisation de méthodes non décrites utilisées pour modifier le comportement du produit. Par exemple, l'ajout de schémas de base de données, les déclencheurs et les modifications de code sont des personnalisations. Toutes les personnalisations de code doivent être précédées du préfixe Z_ pour permettre au client et à CA Technologies de détecter les personnalisations présentes dans le système.
Les clients doivent comprendre que les configurations sont mises à niveau d'une version à l'autre avec leurs modifications (à condition d'être valides dans la nouvelle version), tandis que les personnalisations ne le sont pas. Les personnalisations doivent tout au moins être à nouveau appliquées aux systèmes mis à niveau et très souvent, elles requièrent une nouvelle conception et implémentation pour fonctionner avec les fonctionnalités modifiées du produit. CA Technologies prendra en charge un système personnalisé, à l'exclusion des parties auxquelles les personnalisations sont directement appliquées. En général, l'équipe du support technique demandera au client de supprimer une personnalisation à des fins de diagnostic du produit, dans le cas où elle favoriserait ou masquerait le problème. Le client doit respecter cette demande pour bénéficier du support technique.
CA Technologies peut, s'il est jugé utile, examiner les personnalisations et proposer des alternatives ; le support technique pourra parfois informer le client que le système ne sera pas pris en charge en cas d'application de cette personnalisation. Les personnalisations ne sont sous aucun prétexte acceptées dans les environnements
Clarity
Logiciel à la demande (ou SaaS, anciennement A la demande).
Directives liées aux modifications
Pour éviter tout risque de refus d'assistance pour un problème particulier en raison de modifications, suivez les directives suivantes :
  • N'ajoutez pas de champs aux tables de bases de données prédéfinies. Créez plutôt d'autres tables pour contenir des données personnalisées que vous pouvez joindre à la table prédéfinie.
  • Accédez directement aux tables prédéfinies en lecture seule ; pour les mettre à jour, utilisez les fonctionnalités XOG.
  • Les déclencheurs doivent s'activer en fonction de conditions qui doivent être exceptionnelles. Les déclencheurs doivent uniquement lire des données prédéfinies. Ils doivent être simples et écrits de manière à éviter tout blocage. Les déclencheurs doivent être désactivés lors des mises à niveau.
  • Tous les objets de base de données personnalisés doivent être supprimés avant la mise à niveau du produit, puis rajoutés par la suite.
  • Ne modifiez pas le code source, notamment Java, XML, XSL, XBL, PMD et tous les autres fichiers système similaires fournis avec le produit.