Übersicht über Managed Runtime

Managed Runtime liefert die Infrastruktur für die Bereitstellung, das Hosten und das Überwachen Ihrer PWA Kit-Storefront.

In dieser Anleitung werden die wichtigsten Teile von Managed Runtime und der Zugriff darauf beschrieben.

Der Begriff Umgebung umfasst die gesamte Cloud-Infrastruktur und alle Konfigurationswerte für eine bestimmte von Managed Runtime gehostete Storefront. Mithilfe von Umgebungen können Sie Ihre Production-Storefront von anderen Storefronts getrennt betreiben, die anderen Zwecken wie beispielsweise der Entwicklung oder dem Testen dienen.

Da Umgebungen auf hocheffizienten Microservices ausgeführt werden, die sich automatisch nach oben oder unten skalieren, können Sie ohne zusätzliche Kosten so viele Umgebungen erstellen, wie Sie benötigen. So können Sie beispielsweise eine kurzlebige Umgebung für einen einzelnen agilen Entwicklungssprint oder eine einzelne User Story innerhalb dieses Sprints einrichten. Wenn Sie eine Umgebung nicht mehr benötigen, sollten Sie sie löschen.

Als Production-Umgebungen gekennzeichnete Umgebungen werden vorrangig vom Salesforce-Supportteam überwacht. Für Production-Umgebungen ist auch ein Debugging mit dem Log Center möglich. Um eine Umgebung als Production-Umgebung zu kennzeichnen, haben Sie zwei Möglichkeiten:

1. Verwenden Sie das Runtime Admin-Tool. Schrittweise Anweisungen zum Erstellen einer Umgebung oder zum Bearbeiten einer vorhandenen Umgebung finden Sie im Abschnitt Umgebungen des Administrationshandbuchs.
2. Verwenden Sie die Managed Runtime API. Die Endpunkte projects_target_create und projects_target_partial_update enthalten beiden den Parameter is_production. Um eine Umgebung mit diesen Endpunkten als Production-Umgebung zu kennzeichnen, legen Sie is_production auf true fest.

Der Storefront-Code, der eine Umgebung ausführt, wird als Bündel bezeichnet. Generieren Sie mit den im PWA Kit inbegriffenen Entwickler-Tools ein Bündel und pushen Sie es an Managed Runtime.

Nach dem Pushen des Bündels können Sie mit Runtime Admin oder der Managed Runtime API das Bündel als “bereitgestellt” kennzeichnen. Jedes Projekt kann über mehrere Bündel verfügen, aber in jeder Umgebung kann es nur ein als “bereitgestellt” gekennzeichnetes Bündel geben. Sie können jederzeit ändern, welches der Bündel als bereitgestellt gekennzeichnet wird. Weitere Informationen finden Sie unter Pushen und Bereitstellung von Bündeln.

Um die Verwaltung mehrerer Umgebungen zu vereinfachen, gehört jede Umgebung zu einem Projekt und jedes Projekt gehört zu einer Organisation. Eine Organisation kann mehrere Projekte für mehrere Storefronts enthalten und jedes Projekt kann mehrere Umgebungen enthalten. Ein Managed Runtime-Benutzer kann mehreren Organisationen angehören. Auf diese Weise werden separate Arbeitsströme geschaffen.

Jede Organisation kann maximal 100 Umgebungen und maximal 10 Production-Umgebungen umfassen. Falls Sie diese Höchstwerte erhöhen müssen, wenden Sie sich an Ihren Salesforce Support-Ansprechpartner.

Organisationen und die Zugehörigkeit von Benutzern zu einer Organisation werden über Einstellungen im Account Manager festgelegt. Ein Benutzer kann einer Organisation entweder als Mitglied oder als Administrator angehören. Mitglieder können nur mit den Projekten in Managed Runtime interagieren, für die ihnen eine Projektrolle zugewiesen wurde. Administratoren können mit allen Projekten innerhalb einer Organisation interagieren.

Ein Benutzer kann bei einem Managed Runtime Projekt über folgende Fähigkeiten verfügen:

• Browse (Durchsuchen): Projekt in Runtime Admin anzeigen.
• Manage Redirects (Umleitungen verwalten): Umleitungen für das Projekt verwalten. In der Dokumentation zu Umleitungen finden Sie weitere Informationen.
• Deploy (Bereitstellen): Neue Bündel bereitstellen oder die Bereitstellung auf ein älteres Bündel zurücksetzen.
• Manage Team (Team verwalten): Die Rollen der Teammitglieder für das Projekt anzeigen, hinzufügen, einladen, entfernen und bearbeiten.
• Access Logs (Auf Logs zugreifen): Logs in allen Umgebungen in Echtzeit verfolgen.
• Anzeigen und Verwalten von Umgebungsvariablen: Anzeigen und Verwalten von Umgebungsvariablen in jeder Umgebung. unter Environment Variables (Umgebungsvariablen).

Jedem Benutzer wird ein Projekt zugewiesen, durch das seine Fähigkeiten festgelegt sind. (Ein Benutzer kann nur eine Rolle ausüben.) Projektrollen können jedem Benutzer innerhalb einer Organisation zugewiesen werden.

Die folgende Tabelle zeigt, welche Fähigkeiten mit jeder Rolle verbunden sind:

In jeder Managed Runtime-Umgebung wird die React App im veröffentlichten Bündel innerhalb einer Node.js-Umgebung ausgeführt. Für Antworten auf Seitenabfragen und das Rendering der Ergebnisse verwenden wir das Express Web Framework, das durch die Rendering- und Routingsysteme des PWA Kits unterstützt wird. Wir bezeichnen diese Kombination aus React, Node und Express als den App-Server. (Allerdings wird der App-Server technisch gesehen auf “serverloser” Technologie ausgeführt.) Der App-Server ist für den Betrieb in einer Cloud-Infrastruktur optimiert, die niedrige Rechenkosten, hohe Verfügbarkeit, schnelles Rendering und eine enorme Skalierungskapazität bietet.

Da die Rendering- und Routingsysteme des PWA Kits die Unterschiede zwischen lokalen Entwicklungsumgebungen und Managed Runtime-Umgebungen handhaben, wird Ihr Code nach der Bereitstellung auf eine vorhersehbare Weise ausgeführt. Diese Vorhersehbarkeit entfesselt die Produktivität Ihres Entwicklungsteams, da sie dadurch zu einer häufigeren Bereitstellung von Bündeln angeregt werden.

Derzeit unterstützt der App-Server Transport Layer Security (TLS) ab Version 1.2.

Auf dem App-Server laufender Code hat Zugriff auf die folgenden Umgebungsvariablen:

• DEPLOY_TARGET: ID der Umgebung
• EXTERNAL_DOMAIN_NAME: Der für die Umgebung festgelegte Domain-Name
• MOBIFY_PROPERTY_ID: ID des Projekts, zu dem die Umgebung gehört

Unterstützt wird der App-Server von mehreren Edge-Services, einschließlich:

• Web Application Firewall (WAF) zum Schutz Ihrer Umgebung vor Angreifern
• Proxy-Server zur Beschleunigung von API-Anfragen
• Content Delivery Network (CDN) zur Zwischenspeicherung von Anfragen und zur Beschleunigung des Seitenaufbaus
• Edge-Funktionen für die Bearbeitung von Anfragen und Handhabung von Umleitungen

Der Proxy-Server und das CDN werden in unserer Anleitung zu Proxy-Anfragen eingehend behandelt. Die als Request Processor bezeichnete Edge-Funktion wird in unserer Anleitung zur Maximierung Ihrer Cache-Trefferrate beschrieben.

Die Edge-Services von Managed Runtime sind strategisch über unsere öffentliche Cloud-Infrastruktur verteilt. Jeder Service befindet sich zur Leistungsbeschleunigung so nah wie möglich am Benutzer.

Für die Verwaltung der Einstellungen Ihrer Organisationen, Projekte, Umgebungen und Bündel stellen wir zwei verschiedene Tools bereit:

1. Managed Runtime Admin, eine webbasierte Benutzeroberfläche.
2. Die Managed Runtime API, eine REST API, die zusätzlich zur gleichen Funktionalität des webbasierten Tools einige weitere Fähigkeiten bietet.

Verwenden Sie das Tool Runtime Admin für Routineaufgaben wie die Bereitstellung eines neuen Codebündels in einer Umgebung. Verwenden Sie die API, wenn Sie eine programmgesteuerte Kontrolle benötigen, z. B. zur automatischen Erstellung einer Umgebung als Teil eines Skripts zur kontinuierlichen Integration.

Die Admin-Tools erlauben Ihnen, viele Einstellungen wie die folgenden selbst zu konfigurieren:

• Zulässige IP-Adressen
• Zulässige Access Control Headers
• Aktuell bereitgestelltes Bündel
• Bereitstellungsregion
• Proxys
• Umleitungen
• Benutzerzugriffsrechte
• Marker für Production-Umgebungen

Der Zugriff auf die Admin-Tools wird über Account Manager-Rollen und einen API-Schlüssel gesteuert. Für Prozesse der kontinuierlichen Integration (CI, Continuous Integration) und kontinuierlichen Bereitstellung (CD, Continuous Delivery) werden dedizierte Bot-Benutzer mit ihren eigenen API-Schlüsseln in der Regel von Ihrer Organisation bereitgestellt.

Wissenswertes: Wie Ihre Storefront ist auch das Runtime Admin-Tool eine Headless React App, die in Managed Runtime bereitgestellt wird.

Denken Sie beim Aufbau Ihrer Storefront an die folgenden Einschränkungen von Managed Runtime-Umgebungen:

• Umgebungen antworten nur auf Anfragen, deren HTTP-Host-Header ihrem in Runtime Admin festgelegten externen Host-Namen entspricht.
• Der Pfad / akzeptiert nur HTTP GET-Anfragen.
• Anfrage und Antwort dürfen maximal 6 MB groß sein.
• Die maximale Größe der HTTP-Anfragezeile und -Header beträgt 10240 Bytes. Anfragen, die diese Größe überschreiten, geben die Fehlermeldung HTTP 413 Content Too Large zurück.
• Cookies, einschließlich der HTTP-Anfragen-Header Cookie und der HTTP-Antwort-Header Set-Cookie, werden standardmäßig nicht unterstützt. Sie können aktiviert werden, indem das Attribut allow_cookies für eine Umgebung mit dem Endpunkt projects_target_partial_update festgelegt wird. Sie können Cookies auch in den Umgebungseinstellungen in Runtime Admin aktivieren. Cookies werden in PWA Kit Version 3.1.0 oder höher unterstützt. Siehe Personalize with Cookies (Personalisierung mit Cookies).
• Anfragen mit Headern, die mit _ beginnen, werden nicht unterstützt. Diese Anfragen werden eingestellt.
• HTTP-Anfragen, die aus Managed Runtime-Umgebungen stammen, verwenden keine festen IP-Adressen. Um List-Anfragen vom App-Server zuzulassen, verwenden Sie den AWS IP-Bereich für EC2. Um List-Anfragen von Proxys zuzulassen, verwenden Sie CLOUDFRONT_ORIGIN_FACING.
• Das Pfadpräfix /mobify ist für verwaltete Endpunkte reserviert. Dies schließt folgende Endpunkte ein:
  • /mobify/ping: Gibt einen HTTP 200-Antwortcode zurück, wenn die Umgebung ordnungsgemäß funktioniert.
  • /mobify/redirect/$path: Gibt eine ähnliche Antwort wie projects_target_redirect_retrieve zurück.
  • /mobify/proxy/$name: Gibt eine Antwort aus einem Proxy zurück.
• Sie können den CDN-Cache umgehen, indem Sie den HTTP-Request-Header verwenden: x-mobify-cachebreaker: 1
• IP-Freigabelisten für Umgebungen unterstützen bis zu 250 IP-Adressen. Dieses Limit kann nicht angehoben werden.
• Access Control Header für Umgebungen unterstützen bis zu 2 Header. Jede Kopfzeile:
  • Kann bis zu 128 Zeichen enthalten.
  • kann eine Kombination aus alphanumerischen Zeichen und den Zeichen - und _ sein
  • Siehe Access Control Headers.

• Die Ausführungszeit für App-Server-Anfragen ist auf 20 Sekunden beschränkt. Nach dieser Zeit wird ein HTTP 504 zurückgegeben.
• Durch nicht verarbeitete Ablehnungen von Zusagen wird das App-Rendering unterbrochen.

• Die maximale Größe für Bündel beträgt 400 MB; die maximal Größe aller ssr_only- und ssr_shared-Dateien in einem Bündel beträgt 249 MB.
• Statische Assets, die hochgeladen und bereitgestellt werden können, sind auf die Content-Typen application/javascript, application/json, image/png,image/gif, image/jpeg, image/svg+xml, image/webp, text/css, text/plain und Schriftarten (ttf, woff, woff2, otf usw.) beschränkt. Alle anderen Inhaltstypen müssen von einem externen System bereitgestellt werden.

Für Managed Runtime-Proxys gelten andere Einschränkungen.

Sie können Updates bezüglich der Verfügbarkeit von Managed Runtime-Services unter Salesforce Status abonnieren.

Nach dieser Übersicht über die wichtigsten Aspekte von Managed Runtime sind Sie bereit, die Theorie in die Praxis umzusetzen. Ein guter Startpunkt ist die Anleitung Pushen und Bereitstellung von Bündeln.

• Managed Runtime Administration
• Leitfaden zur Managed Runtime API
• Referenz zur Managed Runtime API

j

Erste Schritte

Einführung in Composable Storefront

Best Practices-Checkliste

Headless Commerce mit Salesforce Commerce API

Übersicht über PWA Kit

Übersicht über Managed Runtime

Managed Runtime API

PWA-Kit-Kompatibilitätsmatrix

Verwenden von Composable Storefront in einer Hybridimplementierung

PWA Kit Framework

Erfolgsfördernde Fähigkeiten

Fragen Sie die Community

Einrichten

Erstellen Sie Ihre Website

Befähigen Sie Ihr Händlerteam

Testen, einführen und überwachen

Verwalten

Deutsch

English

日本語

中文

繁體中文

Français

Deutsch

Italiano

한국어

Português

Español (México)