Vorbereitung und Prozess der Verschiebung von B2C Commerce Hyperforce-Bereichen

Schritte vor der Bereichsverschiebung

• 4 Wochen vorher: Öffnen Sie einen Commerce Cloud-Supportfall mit dem Datum der Bereichsverschiebung und dem neuen Hyperforce-Ziel.
• 4 Wochen vorher: Stellen Sie den Link Öffentliche IP-Bereiche für Hyperforce zur Verfügung, um die Liste der externen IPs für Hyperforce zu erhalten, die zur Zulassungsliste der Firewall hinzugefügt werden sollen (keine Compliance-Anmeldung mehr erforderlich).
• 3 Wochen vorher: Das Salesforce-Team stellt die DNS-Datensätze zur Verfügung, die zur Mail-Konfiguration vor der Migration zu Ihrem DNS-System hinzugefügt werden müssen.

• 4 Wochen vorher: Fügen Sie gegebenenfalls alle ausgehenden Hyperforce-IPs zu den Firewall-Einstellungen aller Integrationen (einschließlich Integrationen von Drittanbietern) hinzu, um die Backend-Konnektivität sicherzustellen. Die Liste der externen IPs für Hyperforce finden Sie unter folgendem Link: https://ip-ranges.salesforce.com/ip-ranges.json.             Referenz: https://help.salesforce.com/s/articleView?id=003876184&type=1 
• 4 Wochen vorher: Migrieren Sie alle vorhandenen Legacy-Zonen in Proxy-Zonen. Weitere Informationen zu Legacy- und Proxy-Zonen finden Sie unter Häufig gestellte Fragen zu Proxy-Zonen.
• 4 Wochen vorher: Überprüfen Sie, ob die 2FA-Client-Zertifikate auf eCDN hochgeladen wurden.
  • Im Rahmen der HF-Migration wird WebDav Auth nach eCDN verschoben und Sie müssen Ihre Client-Zertifikate für den Code-Upload für das Staging auf eCDN hochladen.
  • Damit Code-Uploads funktionieren, führen Sie die folgenden Schritte aus:
    • Generieren Sie ein selbstsigniertes Zertifikatpaket. Detaillierte Anweisungen hierzu finden Sie unter folgendem Link: 

      B2C Hyperforce 2FA Secure Upload Customer Instructions.

      Laden Sie das selbstsignierte Stamm-CA-Zertifikat (i) mit der CDN-API hoch.
    • Client-Zertifikate sollten dasselbe selbstsignierte Stamm-CA-Zertifikat (i) verwenden (siehe Hilfedokument für weitere Details).
• 3 Wochen vorher: Überprüfen Sie, ob sich der SPF-Datensatz auf die Produktionsdomäne (z. B. https://production-realmname.demandware.net/*) bezieht und nicht auf die aktuelle IP-Adresse.  Dadurch wird ein nahtloser Übergang sichergestellt für das erfolgreiche Senden von E-Mail-Bestätigungen nach dem Verschieben. Lesen Sie außerdem Best Practices für das Senden von E-Mails über die B2C-Plattform von Commerce Cloud bezüglich der Verwendung von Punkten im Vergleich zu Strichen.
• 2 Wochen vorher: Aktualisieren Sie gegebenenfalls die Wartungsseite mit dem Datum, an dem die Produktion offline ist.
• 2 Wochen vorher: Fügen Sie den von Salesforce bereitgestellten DNS-Datensatz zur Mail-Konfiguration zu Ihrem DNS-System hinzu.
• 3 Tage vorher: Übermitteln Sie 72 Stunden vor der Bereichsverschiebung keine weiteren Anfragen zu Firewall-Änderungen.

Schritte bei der Bereichsverschiebung

• PIG-Verschiebung (Produktion, Staging, Entwicklung): Das Datum wird über den Fall kommuniziert. Der Zeitpunkt liegt immer im Wartungsfenster zwischen zwei und sieben Uhr morgens der Zeitzone der Quell-POD.  In diesem Zeitraum sind alle PIG-Instanzen und die Storefront nicht verfügbar. Aufträge werden nicht ausgeführt. Sie sollten daher neu geplant und bereits vor der Verschiebung oder manuell danach ausgeführt werden.
  • ~5 Stunden vor Beginn der PIG-Verschiebung: Die Staging- und Entwicklungsinstanzen gehen offline, um Replikationen und anderen Datenänderungen vorzubeugen. Hierdurch wird die Dauer der Ausfallzeit reduziert.
  • Vor der PIG-Verschiebung überprüft SFCC die Anzahl der Kunden und Bestellungen von PRD BM (damit sie bei ELS-Problemen nach der PIG-Verschiebung notfalls verfügbar sind).
    • Überprüfen Sie die Kunden- und Bestellungsdatensätze mit folgenden Schritten:
    • Öffnen Sie "BM > Händlerwerkzeuge > Kunden".
    • Notieren Sie sich die Anzahl (einschließlich Uhrzeit und Zeitzone).
    • Öffnen Sie "BM > Händlerwerkzeuge > Bestellungen".
    • Notieren Sie sich die Anzahl (einschließlich Uhrzeit und Zeitzone).
  • Das Ticket ist mit "Globale Übergabe / Follow the Sun" gekennzeichnet, wodurch das diensthabende Support-Team das Ticket für die gesamte Dauer der Verschiebung überwachen wird.
  • ~0200 POD-Zeit: Die PIG-Verschiebung beginnt.  Die Wartungsseite wird angezeigt.  Im Salesforce-Fall wird notiert, dass die Wartung begonnen hat.
  • Salesforce führt die Kernaktivitäten der PIG-Verschiebung durch:
    • Zeigen Sie die Wartungsseite an und schließen Sie Web und Anwendungen auf dem alten POD.
  • Beginnen Sie mit der abschließenden Datenreplikation auf den neuen HF POD (vom alten POD). 
  • Starten Sie auf dem neuen HF POD alle Datenbanken.
  • Starten Sie Web und Apps auf dem neuen HF POD.
  • Fahren Sie die Datenbanken auf dem alten POD herunter.
• ~0300-0700 POD-Zeit: Die PIG-Verschiebung ist abgeschlossen.
  • Der Support bestätigt die Funktionalität von Business Manager und der Storefront.
  • Der Support bestätigt die Funktionalität von MongoDB.
  • Die Wartungsseite wird entfernt.  Der Fall wird als abgeschlossen gekennzeichnet.  
• Für Storefront-IDs hinter eCDN werden alle erforderlichen Änderungen vom Betreiber verwaltet.

Schritte nach der Bereichsverschiebung

• Überprüfen Sie, ob der Administrator von Control Center über die erforderlichen Berechtigungen zur Verwaltung der Instanzen in Control Center verfügt.
• Der Support bestätigt die Funktionalität von Business Manager und der Storefront.
• Der Support bestätigt die Funktionalität von MongoDB.
• Nach der PIG-Verschiebung überprüft SFCC die Anzahl der Kunden und Bestellungen von PRD BM (damit sie bei ELS-Problemen nach der PIG-Verschiebung notfalls verfügbar sind) und vergleicht sie mit der Anzahl vor der PIG-Verschiebung.
• Überprüfen Sie die Anzahl der Kunden und Bestellungen, indem Sie erneut die folgenden Schritte ausführen:
  • Öffnen Sie "BM > Händlerwerkzeuge > Kunden".
  • Notieren Sie sich die Anzahl (einschließlich Uhrzeit und Zeitzone).
  • Öffnen Sie "BM > Händlerwerkzeuge > Bestellungen".
  • Notieren Sie sich die Anzahl (einschließlich Uhrzeit und Zeitzone).
• Analytics ist auf dem POD nicht mehr vorhanden und wird daher bei einer POD-Verschiebung nicht länger migriert. Aus diesem Grund ist nach einer POD-Verschiebung kein erneutes Ausfüllen mehr erforderlich und Analytics sollte sofort verwendet werden können.

• Überprüfen Sie, ob die Instanzen und Storefronts in Business Manager verfügbar sind.
• Überprüfen Sie, ob das Hochladen von Code ordnungsgemäß funktioniert.
• Überprüfen Sie die Konnektivität mit Integrationen von Fremdanbietern, das Verarbeiten von Zahlungen, das Abschließen von Bestellungen usw.
• Überprüfen Sie, ob externe Firewalls den eingehenden Zugriff vom neuen "HF POD" zulassen.
• Überprüfen Sie die ausgehenden E-Mails und bestätigen Sie, dass Einkäufer nach dem Aufgeben einer Bestellung oder dem Anmelden als Mitglied bei Ihrer Storefront E-Mails erhalten können.

1. Erarbeiten Sie mit den internen QS-Ressourcen einen Überprüfungs- und Bewertungsprozess, der nach der Bereichsverschiebung durchlaufen wird.
2. Planen Sie Ressourcen ein, die das Ticket für die Bereichsverschiebung von Anfang an überwachen.  Aktualisieren Sie das Ticket sofort, wenn ein Problem auftritt.
3. Planen Sie alle Replikationen von Daten oder Code neu, die im Zeitfenster der Bereichsverschiebung (21 Uhr ET vorheriger Tag bis 7 Uhr ET Tag der Verschiebung) hätten ausgeführt werden sollen.  Alle Replikationen, die während der Verschiebung ausgeführt werden, führen zu einem fehlgeschlagenen Auftrag, der nach der Verschiebung manuell korrigiert werden muss.