This document describes how to run PWA and ICM using the Hybrid Approach, so that pages from the Intershop Progressive Web App and pages from the classic storefront (Responsive Starter Store) can be run in parallel.
A possible scenario would be to have the shopping experience with all its SEO optimizations handled by the PWA and to delegate highly customized parts of the checkout or My Account area to ICM.
The minimum version requirements for the involved systems are as follows:
You can use older ICM versions, but they have limitations that require evaluation.
For this reason, examples for ICM 7.10.x versions are included where it seems helpful.
Note
This feature relies on the PWA and ICM being able to read and write each other's apiToken
cookies.
This means that cookies written by the PWA and ICM must have the same domain and the same path. This works since all Responsive Starter Store requests and responses are proxied through the PWA SSR, simulating a common domain (an actual common domain for PWA and ICM is not required).
It is also important that the cookie must not be set to HttpOnly
.
Instead, the apiToken
cookie should be set with Secure
and SameSite=Strict
.
The secure access required for the PWA/NGINX deployments in production-like environments is handled by the Ingress controller, so the PWA and the NGINX container itself can be deployed without SSL.
ICM needs to be deployed with secure access only which is the default with ICM 11 and later versions.
For a minimally invasive implementation, the mechanics for the Hybrid Approach are mainly implemented outside of ICM and in deployment-specific components of the PWA.
ICM is proxied in the express.js server of the server-side rendering (SSR) process and hereby made available to the outside.
A newly introduced mapping table is used in the SSR to decide whether an incoming request should be handled by the PWA or ICM.
This mapping table is also used in the browser-side PWA to switch from the single-page application context to ICM.
ICM must be run with Secure URL-only Server Configuration, which can be done by adding SecureAccessOnly=true
to the appserver configuration.
This is the default for ICM 11+ deployments.
Furthermore, the synchronization of the apiToken
cookie must be switched on, so that users and baskets are synchronized between PWA and ICM.
See Concept - Integration of Progressive Web App and inSPIRED Storefront.
If you also want to support the correct handling for links generated in e-mails, the property intershop.WebServerSecureURL
must point to NGINX.
Configuration via icm_as
Helm chart:
INTERSHOP_APITOKEN_COOKIE_ENABLED: true
INTERSHOP_APITOKEN_COOKIE_SSLMODE: true
INTERSHOP_WEBSERVERSECUREURL: https://<NGINX>
Configuration via icm.properties (ICM 11+ in a Docker container):
intershop.environment.HYBRID=intershop.apitoken.cookie.enabled=true,intershop.apitoken.cookie.sslmode=true
intershop.WebServerSecureURL=https://<NGINX>
Configuration via $SERVER/share/system/config/cluster/appserver.properties (ICM 7.10):
SecureAccessOnly=true
intershop.apitoken.cookie.enabled=true
intershop.apitoken.cookie.sslmode=true
intershop.WebServerSecureURL=https://<NGINX>
The server-side rendering process must be started with SSR_HYBRID=1
.
Warning
Only for development environments
The PWA must also be run with secure URLs if no NGINX is deployed to handle https
access to the PWA.
See SSR Startup - Development for a reference on how to achieve this locally.
Warning
Only for development environments
It might be necessary to set TRUST_ICM=1
if the used development ICM is deployed with an insecure certificate or a certificate that does not work for the PWA parts.
Also, the Service Worker must be disabled for the PWA, as it installs itself in the browser of the client device and takes over the routing process, making it impossible to break out of the PWA and delegate to ICM.
The Service Worker is disabled by default.
The mapping table resides in the PWA source code and provides the page-specific mapping configuration for the Hybrid Approach.
{
id: "Product Detail Page",
icm: `${ICM_CONFIG_MATCH}/ViewProduct-Start.*(\\?|&)SKU=(?<sku>[\\w-]+).*$`,
pwaBuild: `product/$<sku>${PWA_CONFIG_BUILD}`,
pwa: `^.*/product/([\\w-]+).*$`,
icmBuild: `ViewProduct-Start?SKU=$1`,
handledBy: "icm"
}
Each entry contains:
icm
and pwa
)pwaBuild
and icmBuild
)handledBy
(either icm
or pwa
) to decide on the target upstreamThe properties icm
and pwaBuild
can use named capture groups.
They are only used in the node.js process running on the server.
However, pwa
and icmBuild
are used in the client application where named capture groups are not yet supported by all browsers.
With version 0.23.0 the PWA has been changed to no longer reuse the Responsive Starter Store application types, but rather to be based on the newly introduced headless application type for REST clients - intershop.REST
.
This application type is completely independent of the Responsive Starter Store.
For this reason, the PWA must be configured to know which application to use to work with the Responsive Starter Store again (hybridApplication
).
icmApplication
setting in the environment
files to specify the intershop.REST
-based application used by the PWA (usually rest
in the inSPIRED demo scenario).hybridApplication
setting in the environment
files to specify the Responsive Starter Store application (usually -
in the inSPIRED demo scenario).Note
If for some reason the CMS content of the Responsive Starter Store is to be reused directly in the PWA in a Hybrid Approach, the PWA needs some code adaptions and has to use the same application as the Responsive Starter Store. For more details, see the older version of this documentation - Hybrid Approach - PWA Adaptions (3.0.0).
This section describes how to develop and test a PWA using the Hybrid Approach in a local development environment.
This development environment includes a local installation of ICM with the Responsive Starter Store, the PWA, and the NGINX.
After successful configuration and deployment, you can access the different systems with these URLs:
URL | Comment | |
---|---|---|
PWA (via NGINX) | https://pwa.example.com | with https access and NGINX features |
PWA | http://pwa.example.com:4200 | direct access to the SSR rendering |
ICM (Responsive Starter Store) | https://icm.example.com:8443/INTERSHOP/web/WFS/inSPIRED-inTRONICS_Business-Site/en_US/-/USD/Default-Start | direct access, no Hybrid Approach |
ICM (back office) | https://icm.example.com:8443/INTERSHOP/web/WFS/SLDSystem |
For a more realistic Hybrid Approach environment, do not use localhost
as the development domain or 127.0.0.1
as the IP address.
Instead, configure a different domain in the operating system's etc/hosts
file, pointing to the real IP address of your computer.
This guide uses example.com
as the domain.
For better distinction we use separate subdomains for pwa
and icm
.
192.168.178.77 pwa.example.com
192.168.178.77 icm.example.com
The different parts of the server will then listen on different ports.
For this guide ICM will listen on port 8443
and the PWA SSR process will listen on port 4200
while the NGINX will respond on the default HTTPS port 443
.
ICM needs to be set up like a regular ICM development environment with the Responsive Starter Store (icm-responsive).
The icm.properties
file must contain the following:
intershop.WebServerURL = http://pwa.example.com
intershop.WebServerSecureURL = https://pwa.example.com
webserver.http.port = 8080
webserver.https.port = 8443
intershop.environment.HYBRID=intershop.apitoken.cookie.enabled=true,intershop.apitoken.cookie.sslmode=true
https://pwa.example.com
apiToken
cookie must be enabledThe configurations relevant to the Hybrid Approach for running the PWA are:
ICM_BASE_URL
points to ICM https port - https://icm.example.com:8443
TRUST_ICM=true
SSR_HYBRID=true
must be setLOGGING=true
helps with analysis and debuggingNote
The PWA SSR process itself does not need to run with SSL/https.
This is taken care of by the NGINX container to provide the secure access to the PWA.
A local PWA built from the current PWA project sources can be run in a number of ways:
Via Docker
docker build -t dev_pwa . && docker run -it -p 4200:4200 -e ICM_BASE_URL=https://icm.example.com:8443 -e TRUST_ICM=true -e SSR_HYBRID=true -e LOGGING=true --name hybrid-pwa dev_pwa
Via bash
ICM_BASE_URL=https://icm.example.com:8443 TRUST_ICM=true SSR_HYBRID=true LOGGING=true npm run start
Via bash with SSR development server with auto compile
ICM_BASE_URL=https://icm.example.com:8443 TRUST_ICM=true SSR_HYBRID=true LOGGING=true npm run start:ssr-dev
Note
A development Hybrid Approach setup can also be tested without NGINX.
In this case, the PWA SSR process must run with SSL.
This can be achieved by using --ssl
as an additional parameter.
The PWA with Hybrid Approach would then be reachable at https://pwa.example.com:4200
.
ICM_BASE_URL=https://icm.example.com:8443 TRUST_ICM=true SSR_HYBRID=true LOGGING=true npm run start:ssr-dev -- --ssl
The configurations relevant to the Hybrid Approach for running the NGINX are:
UPSTREAM_PWA
points to the PWA SSR process - http://pwa.example.com:4200
ICM_BASE_URL
points to ICM https port - https://icm.example.com:8443
SSL=true
CACHE=false
443
To start the NGINX container from the project sources with Docker:
docker build -t dev_nginx nginx && docker run -it -p 443:443 -e UPSTREAM_PWA=http://pwa.example.com:4200 -e SSL=true -e CACHE=false --name hybrid-nginx dev_nginx
You can also start the PWA and NGINX with docker compose
.
This is the easiest way to start and test the PWA part of a development Hybrid Approach environment.
For actual development on the PWA side, starting the SSR development server with auto compile might be more efficient.
services:
pwa:
image: intershophub/intershop-pwa-ssr
build:
context: .
ports:
- '4200:4200'
environment:
ICM_BASE_URL: 'https://icm.example.com:8443'
SSR_HYBRID: 'true'
TRUST_ICM: 'true'
LOGGING: 'true'
nginx:
image: intershophub/intershop-pwa-nginx
build: nginx
depends_on:
- pwa
ports:
- '443:443'
environment:
UPSTREAM_PWA: 'http://pwa:4200'
ICM_BASE_URL: 'https://icm.example.com:8443'
SSL: 1
CACHE: 0
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Website, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.