News: PWA Kit 3.0.0 ist jetzt mit Unterstützung für Node 18 verfügbar. Aktualisieren Sie Ihre Projekte und Umgebungen, damit sie weiterhin ordnungsgemäß funktionieren. Mit älteren Versionen können Sie Ihre Website nicht bereitstellen.

Übersicht über Managed Runtime

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

Managed Runtime unterstützt nur Anwendungen, die mit einer PWA Kit-Vorlage erstellt wurden. Die Werbeträgernummer für die verfügbaren Vorlagen finden Sie auf GitHub im PWA Kit Repository in den template-*-Ordnern.

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

Bevor Sie Managed Runtime und Runtime Admin verwenden können, müssen sie aktiviert sein, und Sie müssen Zugriff darauf anfordern. Um Managed Runtime und Runtime Admin für Ihre Organisation zu aktivieren, wenden Sie sich an Ihr Salesforce Account-Team. Um Zugriff zu erhalten, bitten Sie Ihren Commerce Cloud-Administrator, Ihrem Konto mithilfe des Account Managers eine der folgenden Rollen hinzuzufügen: Managed Runtime User oder Managed Runtime Admin.

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.

In der Managed Runtime API werden Umgebungen als "Ziele" bezeichnet, aber beide Begriffe haben in diesem Kontext dieselbe Bedeutung.

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:

Verwenden Sie das Runtime Admin-Tool. Phasenweise Anweisungen zum Erstellen einer Umgebung oder zum Bearbeiten einer vorhandenen Umgebung finden Sie im Abschnitt Umgebungen des Administrationshandbuchs.
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.

Standardmäßig können Sie bis zu 10 Umgebungen als Production-Umgebung kennzeichnen. Um Ihr Kontingent zu erhöhen, wenden Sie sich an den Support.

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.

Ein Bündel ist ein Snapshot Ihres Codes zu einem bestimmten Zeitpunkt. Er ist unveränderlich: Nach seiner Erstellung kann ein Bündel nicht mehr modifiziert werden. Das Vorhandensein dieses vollständigen und genauen Verlaufs von Bündeln hilft bei der Fehlerbehebung von Bereitstellungen.

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.

Wenn Sie einem Benutzer die Zugehörigkeit zur Admin-Organisation zuweisen möchten, wenden Sie sich an den Salesforce Support.

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.

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:

Rolle	Durchsuchen	Umleitungen verwalten	Bereitstellen	Team verwalten	Auf Logs zugreifen
Admin	Ja	Ja	Ja	Ja	Ja
Entwickler	Ja	Ja	Ja	Nein	Ja
Vermarkter	Ja	Ja	Nein	Nein	Nein
Schreibgeschützt	Ja	Nein	Nein	Nein	Nein

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:

Managed Runtime Admin, eine webbasierte Benutzeroberfläche.
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 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.
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 Content-Typen müssen über das externe 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.