HCL Commerce Liste de contrôle de déploiement

La liste de contrôle de déploiement de HCL Commerce s'appuie sur des leçons tirées de l'expérience de groupes internes HCL, de clients externes et de partenaires commerciaux ayant déployé des solutions basées sur HCL Commerce. Son but est de susciter le débat ; il ne s'agit pas d'une liste d'instructions détaillées.

Contrôle d'accès

  • Le contrôle d'accès aux commandes et aux pages JSP est-il appliqué correctement ?
  • Assurez-vous que le contrôle d'accès est activé.
  • Assurez-vous que l'accès à chaque commande d'URL est limité aux seuls utilisateurs qui sont supposés les exécuter. Les commandes d'URL peuvent être tapées dans la zone d'adresse du navigateur ; la protection doit donc s'étendre au-delà des liens disponibles sur la page JSP.
  • Assurez-vous que l'accès à chaque vue est également limité au groupe d'utilisateurs adéquat. Par exemple, les pages supplémentaires de HCL Commerce Accelerator ne doivent être visibles que par des rôles spécifiques.
  • Les sous-ensembles de rôles appropriés sont-ils affectés aux bons groupes d'administrateurs ? Est-il nécessaire de réinitialiser des mots de passe ?
    Durant les tests, peut-être avez-vous utilisé un compte d'utilisateur bénéficiant du rôle d'administrateur de site ou de vendeur, mais au moment de déployer le système auprès d'utilisateurs spécifiques, veillez à ce que chacun ne reçoive que les rôles qui lui reviennent.

Base de données

  • La base de données de production est-elle bien exempte de données de test ou de données erronées ?

    Assurez-vous que toutes les données des catalogues de test sont supprimées avant de mettre votre site en ligne. L'accès à une base de données plus petite sera plus rapide. Pour débarrasser la base de données de toutes données résiduelles, servez-vous de l'utilitaire de nettoyage prévu à cet effet.

  • Les statistiques de la base de données sont-elles à jour ?
    • Les statistiques de la base de données sont utilisées par l'optimiseur de requêtes pour sélectionner le meilleur moyen d'exécuter une requête.
    • Si les statistiques de la base de données sont fausses, l'optimiseur de requêtes risque d'emprunter une ligne d'action résultant en un temps d'exécution bien plus long que prévu.
    • Consultez la description de REORG et REORGCHK dans la documentation IBM Db2.
  • La configuration et les réglages de la base de données ont-ils reçu l'aval de l'administrateur de base de données ?
    • La base de données de HCL Commerce est un maillon essentiel de la chaîne, car c'est l'endroit où sont stockées toutes les données relatives aux utilisateurs, aux catalogues et aux commandes.
    • La base de données doit être configurée correctement compte tenu de la quantité de mémoire disponible, de la taille du catalogue, des éventuelles nouvelles tables/colonnes qui ont été ajoutées et des nouvelles requêtes qui sont exécutées. Par exemple, faut-il créer de nouveaux index pour épauler le nouveau code SQL dans les EJB, les beans d'accès ou les beans de données ?

Mise en cache

  • Le fichier cachespec.xml est-il paramétré correctement pour la mise en cache et l'invalidation ?

    Le fichier cachespec.xml contient les règles qui déterminent dans quelles circonstances mettre en cache les servlets, les pages et les fragments et combien de temps les conserver ; il contient aussi les règles d'invalidation.

  • Les caches sont-ils amorcés (préremplis) pour optimiser les temps de réponse ?
    • Vous pouvez créer des scripts automatisés, qui balaient toutes les pages du site afin de préremplir le cache.
  • Le cache du serveur Web et le cache d'Edge Server sont-ils configurés et chargés correctement ?
    • Assurez-vous de mettre en cache les biens appropriés aux endroits appropriés
    • La mise en cache du serveur Web, qui inclut la technologie ESI (Edge Side Include), est disponible en standard.
    • La mise en cache aux frontières (edge), avec des services tels que Akamai, est disponible moyennant un coût supplémentaire.

Intégration

  • Une solution de rechange est-elle prévue au cas où un système d'arrière-plan deviendrait indisponible ou tarderait à répondre ?
    • L'un des tests fonctionnels devrait examiner le cas où le système d'arrière-plan est indisponible et étudier l'impact sur le client.
    • Le client sera-t-il invité à réessayer plus tard ? Une valeur par défaut sera-t-elle appliquée, puis vérifiée manuellement plus tard ?

Pages de magasin

  • Le graphisme et les pages définitives du magasin sont-ils approuvés ?

    Assurez-vous que les éléments graphiques et la présentation définitive des pages JSP sont approuvés et téléchargés à destination du site de production.

  • Les pages d'erreur sont-elles explicatives et utiles au client ?
    • Si un lien de commande d'URL contient une faute de frappe ou si l'exécution d'une commande dépasse le délai qui lui est imparti, la page d'erreur générique sera présentée au client. Modifiez cette page pour lui donner le même aspect que les autres pages du site et afin de fournir au client un moyen de retenter l'action ou de poursuivre son chemin en passant outre l'erreur.
    • Il convient également de modifier la page d'erreur 404 (page not found) du serveur Web afin de fournir une ligne d'action au client.

Chargement initial de données

  • Les ultimes mises à jour du catalogue sont-elles chargées et vérifiées ?
    • Vérifiez que les informations contenues dans le catalogue sont exactes.
  • Les derniers prix et niveaux de stocks sont-ils chargés et vérifiés ?
    • Vérifiez que les prix sont corrects ; par exemple, assurez-vous qu'il n'existe pas d'article à 0.00 ou 0.01 CAD (ou 0,00 € ou 0,01 €).
    • Certains clients font la chasse aux articles dont le prix est anormalement bas (du fait d'une mauvaise configuration).
    • Vérifiez que les niveaux de stocks sont à jour.
  • Les contrats appropriés sont-ils déployés ?
    • Tout contrat doit être déployé pour être en vigueur.

Campagnes

  • Les activités de campagne appropriées sont-elles actives ?

    Une activité de campagne peut être en mode actif ou inactif. Pour être en vigueur, elle doit être placée en mode actif.

Surveillance du site

  • Les administrateurs système savent-ils comment déterminer si le site fonctionne bien et savent-ils reconnaître les signes de problèmes ou de dysfonctionnements ?
    • Assurez-vous que les administrateurs système savent quels journaux examiner pour dépister les erreurs et quels outils utiliser pour surveiller les performances. Par exemple, le moniteur de cache et les afficheurs de journaux WebSphere Application Server.
  • Existe-t-il un plan de surveillance de l'utilisation des ressources ?
    • Quelles sont les limites acceptables pour les ressources et à partir de quel niveau d'utilisation l'alerte doit-elle être donnée ?
  • Le point de rupture du site est-il connu ?
    • Les tests de performances et de montée en charge doivent vous permettre d'identifier de quelle manière le site s'engorge à mesure que le trafic augmente.
  • Les journaux appropriés du serveur d'applications sont-ils activés ?
    • Assurez-vous que les informations sont tracées avec une granularité suffisamment fine pour aider à identifier la cause des problèmes.
    • Vérifiez que les journaux sont archivés et non réécrits afin qu'ils puissent être examinés a posteriori en cas d'incident.
  • HCL Commerce est-il configuré avec le niveau de journalisation adéquat ?

Génération de rapports

Faut-il activer le moniteur d'événements marketing ?

  • La mesure de l'efficacité des campagnes marketing ne peut se faire sans l'activation préalable de certains moniteurs d'événements. Par exemple, le moniteur (ou observateur) d'événements marketing doit être actif si vous voulez enregistrer le nombre de fois où une publicité particulière a été vue par les clients et le nombre de fois où ils ont cliqué dessus.
Les journaux appropriés du serveur Web sont-ils en fonction ?
  • Avez-vous besoin de certaines informations consignées dans les journaux du serveur Web pour générer vos rapports ? Ces informations peuvent être, par exemple, le type de navigateur utilisé par le client, la destination des réacheminements, les données d'accès (heure du jour) ou le chemin parcouru de lien en lien.

Sauvegarde et récupération

Existe-t-il une sauvegarde de la base de données du site de production, du code personnalisé et des paramètres de configuration ?
  • Toutes les informations de configuration devraient être sauvegardées afin de permettre la création d'une copie de l'environnement de test ou de l'environnement de production en cas d'urgence.
  • Assurez-vous que l'intégralité du code source est sauvegardée afin que les futurs changements puisse être appliqués.
  • Assurez-vous que toutes les données relatives aux clients et aux commandes sont sauvegardées.
Un plan de reprise après incident majeur est-il en place ?
  • Quelles sont les mesures prévues en cas de panne du ou des disques de la base de données ?
  • Quelles sont les mesures prévues en cas de non-réponse du serveur WebSphere Application Server ?
  • Quelles sont les mesures prévues en cas d'indisponibilité du serveur Web ?
  • Quelles sont les mesures prévues si l'équilibreur de charge cesse de fonctionner ?
Avez-vous prévu un plan de gestion du site pour le cas où il devrait être mis hors service temporairement ou pour une longue durée ?
  • Quel écran sera présenté au client si le site est mis hors service pour une intervention de maintenance d'urgence ou en cas de problème réseau ?

Mises à niveaux et correctifs

Une fenêtre de maintenance périodique est-elle prévue ?
  • Avez-vous prévu des fenêtres de maintenance périodique pour le système d'exploitation ou les équipements du réseau ?
  • Ces fenêtres de maintenance sont-elles bien prévues aux heures de faible trafic ?
Un plan est-il prévu sur la manière d'appliquer les mises à niveau et les correctifs au site ?
  • Quelles sont les étapes à effectuer pour apporter des modifications au site de production ?
  • Quels changements nécessiteront la mise hors service temporaire du site ?
  • Quels changements pourront être appliqués sans nécessiter la mise hors service du site ?
Un plan prévoit-il la marche à suivre pour appliquer les mises à jour d'urgence au catalogue, par exemple pour changer des produits ou des prix ?
  • En cas de découverte d'une information erronée (par exemple, un prix affiché à 10,00 € au lieu de 100,00 € ou une description d'article manifestement incorrecte, telle qu'un pull en acrylique 100 % cachemire), quelle procédure est prévue pour mettre à jour le site Web. La source de données sera-t-elle également mise à jour ?
  • La personne en charge des mises à jour d'urgence sait-elle exactement comment procéder ? Des approbations sont-elles requises ?

Développement, test, phase de transfert et production

  • Etes-vous certain que les fonctionnalités clés, les scripts et les processus essentiels fonctionnent dans l'environnement de production comme ils fonctionnaient dans l'environnement de test ?