Préparation et processus de déplacement du domaine Hyperforce de B2C Commerce

Étapes préalables au déplacement du domaine

• 4 semaines avant : ouverture d’une demande d’assistance Commerce Cloud ; note de la date de déplacement du domaine et de la nouvelle destination Hyperforce.
• 4 semaines avant : mise à disposition du lien Hyperforce Public IP Ranges pour obtenir la liste d’adresses IP externes Hyperforce à ajouter à la liste d’autorisation du pare-feu. (La connexion de conformité n’est plus obligatoire).
• 3 semaines avant : l’équipe Salesforce fournit les enregistrements DNS requis à ajouter à votre système DNS avant la migration pour la configuration du courrier.

• 4 semaines avant : ajout de toutes les adresses IP sortantes Hyperforce aux paramètres de pare-feu de toutes les intégrations (y compris les intégrations tierces) pour la connectivité back-end, le cas échéant. La liste d’adresses IP externes Hyperforce se trouve sur https://ip-ranges.salesforce.com/ip-ranges.json             Référence : https://help.salesforce.com/s/articleView?id=003876184&type=1 
• 4 semaines avant : migration de toutes les zones héritées existantes vers des zones proxy. Pour en savoir plus sur les zones héritées et les zones proxy, consultez la FAQ concernant les zones proxy.
• 4 semaines avant : vérification du téléchargement des certificats clients 2FA sur eCDN
  • Dans le cadre de la migration HF, WebDav Auth migre vers eCDN. Vous devrez apporter vos certificats clients et les télécharger sur eCDN pour le téléchargement du code vers l’étape de préproduction
  • Pour que les téléchargements de code fonctionnent, vous devez effectuer les étapes suivantes :
    • Générer un paquet de certificats auto-signés (vous trouverez des instructions détaillées à la page 

      B2C Hyperforce 2FA Secure Upload Customer Instructions

      Télécharger le certificat d’autorité de certification racine auto-signé (i) à l’aide de CDN-API.
    • Le certificat du client doit utiliser le même certificat d’autorité de certification racine auto-signé (i) (voir la documentation d’aide pour en savoir plus)
• 3 semaines avant : vérification que l’enregistrement SPF fait référence au domaine de production (par exemple, https://production-realmname.demandware.net/*), et non à l’adresse IP actuelle.  Cela garantira une transition plus en douceur pour l’envoi d’e-mails de confirmation après le déplacement. Consultez également Best Practices for sending email via the Commerce Cloud B2C platform (Meilleures pratiques pour l’envoi d’e-mails via la plate-forme B2C Commerce Cloud) pour en savoir plus sur l’utilisation de points par rapport aux tirets.
• 2 semaines avant : mise à jour de la page de maintenance pour les cas où la production est hors ligne, le cas échéant.
• 2 semaines avant : ajout de l’enregistrement DNS fourni par Salesforce dans votre système DNS pour la configuration du courrier
• 3 jours avant : pas de soumission de demandes de modification du pare-feu 72 heures avant le déplacement du domaine.

Étapes de déplacement du domaine

• Déplacement PIG Move (Production, Préproduction, Développement) : date communiquée via la requête. L’heure est toujours comprise dans la fenêtre de maintenance de 2 à 7 heures du matin dans le fuseau horaire du POD source.  Pendant ce temps, toutes les instances PIG et la vitrine seront hors service. Les tâches ne s’exécuteront pas, elles doivent donc être reprogrammées avant le déplacement ou exécutées manuellement après.
  • Environ 5 heures avant le début du déplacement PIG : les instances de préproduction et de développement sont mises hors ligne pour empêcher les réplications et autres modifications de données, ce qui contribue à réduire le temps d’arrêt global.
  • Avant le déplacement PIG, SFCC vérifie le décompte des clients et de commandes de PRD BM (juste pour les avoir en cas de problèmes ELS après le déplacement PIG)
    • Vérifier les enregistrements des clients et des commandes en suivant les étapes :
    • Ouvrir BM > Outils marchands > Clients
    • Noter le décompte (avec l’heure et le fuseau horaire)
    • Ouvrir BM > Outils marchands > Commandes
    • Noter le décompte (avec l’heure et le fuseau horaire)
  • Le ticket est signalé comme Global Handover/Follow the Sun, de sorte que l’équipe d’assistance en service surveillera le ticket pendant le déplacement.
  • Environ 2 h 00 heure POD : le déplacement PIG commence.  La page de maintenance est affichée.  La requête Salesforce est mise à jour et indique que la maintenance a commencé.
  • Salesforce exécute les activités principales du déplacement PIG :
    • Mise en place d’une page de maintenance et arrêt des applications/des sites Web sur l’ancien POD.
  • Lancement de la réplication finale des données vers le nouveau POD HF (à partir de l’ancien POD). 
  • Démarrage de toutes les bases de données sur le nouveau POD HF.
  • Démarrage des applications et sites Web sur le nouveau POD HF.
  • Arrêt des bases de données sur l’ancien POD.
• Environ 3 h 00 - 7 h 00 heure POD : déplacement PIG terminé.
  • L’assistance confirme la fonctionnalité de la vitrine et Business Manager
  • L’assistance confirme la fonctionnalité MongoDB
  • La page de maintenance est supprimée.  La requête est mise à jour et indique l’achèvement.  
• Pour les adresses IP de vitrine derrière eCDN, les opérations géreront tous les changements nécessaires.

Étapes ultérieures de déplacement du domaine

• Vérification que l’administrateur du centre de contrôle dispose des autorisations requises pour gérer les instances dans le centre de contrôle.
• L’assistance confirme la fonctionnalité de la vitrine et Business Manager.
• L’assistance confirme la fonctionnalité MongoDB
• Après le déplacement PIG, SFCC vérifie le décompte des clients et de commandes de PRD BM (juste pour les avoir en cas de problèmes ELS après le déplacement PIG) et le compare avec le décompte avant le déplacement PIG
• Vérification du client et de la commande en suivant à nouveau les étapes ci-dessous :
  • Ouvrir BM > Outils marchands > Clients
  • Noter le décompte (avec l’heure et le fuseau horaire)
  • Ouvrir BM > Outils marchands > Commandes
  • Noter le décompte (avec l’heure et le fuseau horaire)
• Les analyses ne résident plus sur le POD, elles ne sont donc plus migrées pendant un déplacement POD. Pour cette raison, elles ne nécessitent plus de temps pour se remplir à nouveau après un déplacement POD et sont immédiatement disponibles.

• Vérification du bon fonctionnement des vitrines et des instances Business Manager.
• Vérification du bon fonctionnement du téléchargement du code.
• Vérification de la connectivité avec les intégrations tierces, le traitement des paiements, la finalisation des commandes, etc.
• Vérification que les pare-feux externes autorisent l’accès entrant à partir du nouveau « POD HF ».
• Vérification du courrier sortant et confirmation que les acheteurs sont en mesure de recevoir des e-mails après avoir passé une commande ou s’être inscrits en tant que membre sur votre vitrine.

1. Travaillez avec les ressources internes d’assurance qualité pour créer un processus de vérification et de validation afin d’effectuer un déplacement postérieur au domaine.
2. Programmez les ressources pour qu’elles soient disponibles et surveillez le déplacement de domaine du ticket depuis le début du déplacement du domaine.  Mettez immédiatement le ticket à jour en cas de problème.
3. Reprogrammez toutes les réplications de données ou de code qui sont programmées pendant la fenêtre de déplacement du domaine (21 h ET le jour précédent - 7 h ET le jour même).  Toute réplication en cours d’exécution pendant le déplacement entraînera l’échec d’une tâche qui devra être désactivée manuellement après le déplacement.