This document provides frequently asked questions and answers about the Intershop CaaS offering.
The CaaS partner can trigger deployments on UAT in self service, see Reference - CaaS Responsibilities Matrix.
Any other changes to the system that go beyond this must be agreed with Intershop in advance. The changes most likely affect system behavior and must be implemented in the production environment. The goal is to have consistent system settings for all environments.
In principle, any changes to the system should only be made on the basis of releases.
The hosting and operation of the PWA is offered by Intershop as an additional service (front-end as a service).
As the PWA is typically highly individualized, the costs depend on the infrastructure resources required and the operational effort. The latter depends, for example, on the factors of the number of deployments, number of incidents, etc.
The PWA is operated using containers in a Kubernetes cluster. In order to prepare a concrete offer, a sizing of the entire infrastructure is necessary.
Hosting and operation of custom Microservices is offered by Intershop as an additional service.
As Microservices are typically highly individualized, the costs depend on the infrastructure resources required and the operational effort. The latter depends, for example, on the factors of the number of deployments, number of incidents, etc.
Microservices are operated using containers in a Kubernetes cluster. In order to prepare a concrete offer, a sizing of the entire infrastructure is necessary.
To use the mail service of ICM (app server), it is necessary to set correct Mail-From addresses, e.g., in pipeline:
<configurationValues name="DefaultEmailFrom" value="firstname.lastname@example.org"/>
Each app server runs a Postfix mail server. This server catches all mails via localhost and forwards them to the customers mail server.
In Intershop Commerce Management it looks like this:
All other configuration items such as host name, port, email address, login user and password are set directly by the Intershop PPS team on each app server directly.
To enable the import or export of data from an SFTP-based transfer server or service to the Intershop application server and vice versa:
Enter the following configuration details:
|Remote Location||/home||Subdirectories can be created later if necessary.|
|User name||<user name>_int|
|The username depends on the environment.|
|Pass phrase||The pass phrase is not used, but a required field when you use the web form, so it is necessary to type in anything.|
|Key File Path||/home/intershop/.ssh/id_rsa|
Customer is responsible for (external) domains and related DNS configuration for example for ICM/PWA Storefront. Therefore customer needs to provide corresponding SSL/TLS certificate(s) for each desired domain, e.g., one per ICM cluster or multiple ones per ICM cluster in case of different channels made available under different domains, see below.
Generally, domain configuration should be done on CNAME base, whereas Intershop will provide target domain name for corresponding environments and clusters.
Basically, three environments (Production (PRD), User Acceptance Test (UAT) and Integration (INT)) with two clusters each (live (LV) and edit (ED)) are provided for standard ICM system. Therefore at least six (6) domains are required, optionally more (if so, number of domains has to be the same for each tier, e.g., INT and UAT and PRD), for example:
Applies only, if PWA is in use.
Customer needs to provide additional domains. Only live (LV) clusters use PWA, edit (ED) cluster usually do not need PWA as a main purpose is to perform and check content changes. PWA domains could be seperated by channels (channel specific) as well. Therefore at least three (3) domains are needed, for example:
Applies only if IOM is in use.
In addition to the ICM, corresponding domains and certificates are also required for the IOM. As IOM is only connected to the live (LV) cluster of each environment, independent of the number of channels, three (3) domains are required.
General note: provided SSL/TLS certificates shall have a valid duration period of 1 (one) year. Intershop requires both public key(s), the certificate(s) as well as private key file(s).
|Option||SSL/TLS Certification Relation||Certificate (example)||Domain (example)||Notes|
|Basic||ONE SSL/TLS certificate per ONE domain|
certificate 1 →
certificate 2 →
certificate 3 →
certificate 4 →
|SAN||ONE TLS/SSL certificate per MULTIPLE domains|
SAN certificate 1 →
|Wildcard||ONE TLS/SSL certificate per ALL subdomains of a certain single domain|
wildcard certificate 1 →
wildcard certificate 2 →
wildcard certificate 3 →
To access the database, add your public SSH key to the INT live or edit environment. This way you are able to access database either directly via command line, or, preferably and much more comfortable via SQL Management Studio or Azure Data Studio.
To do so, you need to connect to INT via SSH and establish an SSH tunnel/port forwarding to enable to access DB via a local port on your machine forwarding traffic to the remote host.
Credentials and connection information can be found here: /var/intershop/share/system/config/cluster/orm.properties.
It is sufficient to establish an SSH tunnel/port forwarding to either INT (LV) or INT (ED) in order to be able to access DB as the same physical DB machine operates in the background where databases are located.
Also note that a connection via SSH can only be established if the originating public IP address, where attempting to access from, is included on the whitelist.
For more instructions on how to establish an SSH tunnel, see Guide - CaaS Database Access.
On INT (ED+LV) there are read-only mounts for accessing ICM PRD+UAT (LV+ED) and IOM PRD log files as well:
This task requires Azure CLI and kubectl on your local machine. Alternatively you may use https://shell.azure.com.
To access PWA logs or check the status of a pod do the following:
Connect to the cluster by using Azure CLI:
az aks get-credentials --subscription $subscription -g $resource-group -n $name
kubectlfor exploring the namespace:
kubectl get pods -n $namespace
kubectl describe pod -n $namespace $pod
kubectl logs -n $namespace $pod
By default, CaaS Intershop solutions, hosted on Microsoft Azure, are accessible on the Internet via a public IP address. To grant customer and partner clients or servers access to Azure, their public addresses are kept on a whitelist. Those connections, for example to storefront and back office sites or provided APIs are HTTPS-only and therefore TLS encrypted. TLS/SSL certificates are installed on the Azure web server tiers for that purpose. No additional VPN is required in this case.
A VPN is required if one of the clients or servers from partners or customers has no direct access to public internet. Typical cases are: internal services like mail (SMTP), ERP or PIM. In this case, a VPN tunnel establishes a virtually direct and secured connection between the customer or partner and the Azure environment. Prior to configuring the VPN, precisely site-to-site (S2S) VPN, affected parties (e.g. customer and Intershop) have to agree on networks to be used, i.e. one or more private IP address range(s). Those private IP ranges must not overlap with IPs or IP ranges already in use or planned to be used. For this reason, it is important for Intershop to know as early as possible whether a VPN is necessary and which private network range(s) should be used.
Example: The customer has a mail service on its private network, without direct access to public internet. It should be used to send e-mails originating in an Azure based Intershop Commerce Management environment (ICM). As the mail service has no access to public internet and therefore cannot be directly connected to, a VPN tunnel between Azure, where ICM is hosted, and the private network where the related mail service’s hosts are located is required.
To create a VPN tunnel between Azure and your (or your partners) on-premise infrastructure, Intershop requires the following information:
|Public IP address of your device|
This is the device on your (or your partners) side. Intershop needs this IP address to establish a connection.
While configuring the VPN in Azure, Intershop will get a public IP address for the opposite side.
Intershop will communicate the newly created public IP address as soon as possible.
|Address space of your local network(s)|
Azure needs to know the private address ranges corresponding to your network.
Each VPN gateway needs to know the local area networks of both sides, otherwise it will not work.
Multiple subnets are possible but may not overlap.
Type of VPN
Azure supports IKEv1 and IKEv2, but it depends on your device which type can be used.
Intershop may check the requirements for you, this requires type and firmware version of your device.
For more information please see the compatibility list:
IKEv1 (PolicyBased VPN) is no longer recommended for a productive environment. Microsoft has decided to limit the PolicyBased VPN to the Basic SKU in December 2017. That limits the bandwidth to 100 Mbps.
|Shared Key (PSK)||Both VPN devices have to use the same shared key. Intershop will create a key if no key is provided by the customer.|
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 Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.