This document provides frequently asked questions and answers about the Intershop Commerce Platform.
As timezone UTC is used and cannot be changed to ensure the processes in place on the platform. Please use the application-specific options to adjust the time zone (for instance in the back office).
The Intershop Commerce Platform partner can trigger deployments on UAT in self service, see Reference - Intershop Commerce Platform - 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.
See Guide - Intershop Commerce Platform Deployment Process (valid to 7.10) | Scheduling and Lead Time.
See Guide - Intershop Commerce Platform Deployment Process (valid to 7.10) | Performing the Deployment.
In principle, any changes to the system should only be made on the basis of releases.
Intershop Commerce Platform offers hosting and operation of the PWA.
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.
Intershop Commerce Platform offers hosting and operation of custom Microservices.
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="info@test.intershop.de"/>
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.
E-mail trap: for the lower environments an e-mail trap can be used in place of a standard SMTP server. This server should be provided by the customer or partner.
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:
Configuration Details | Data | Notes |
---|---|---|
Remote Location | /home | Subdirectories can be created later if necessary. |
Authentication method | Key | |
User name | <user name>_int <user name>_uat <user name>_prd | 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 |
The customer is responsible for (external) domains and related DNS configuration for example for ICM/PWA Storefront. Therefore the 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 the 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, the 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.
The customer needs to provide additional domains. Only live (LV) clusters use PWA, edit (ED) cluster usually do not need PWA as the main purpose is to perform and check content changes. PWA domains could be separated 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 → | channelA.myDomain.com channelB.myDomain.com channelC.mySecondDomain.com channelD.myThirdDomain.com |
|
SAN | ONE TLS/SSL certificate per MULTIPLE domains | SAN certificate 1 → | channelA.myDomain.com, channelB.myDomain.com, channelC.mySecondDomain.com, channelD.myThirdDomain.com |
|
Wildcard | ONE TLS/SSL certificate per ALL subdomains of a certain single domain | wildcard certificate 1 → wildcard certificate 2 → wildcard certificate 3 → | *.myDomain.com *.mySecondDomain.com *.myThirdDomain.com |
|
A certificate signing request (CSR) is required to order a new certificate. The customer can create this CSR himself.
As an additional service, Intershop offers to create the CSR for the customer. In this case, the customer has to create a service desk ticket with the required information.
Depending on the certificate issuer, at least the certificate type (see certificate types) and a fully qualified domain name are required to create a CSR. The following table shows all information that can/must be defined. All information relates to the customer's company, not to Intershop.
Information | Description | Example | |
---|---|---|---|
CN | Common Name | This is the fully qualified domain name. Depends on the certificate type. | See section above |
O | Organization Name | Usually the legal name of a company or entity and should include any suffixes such as Ltd., Inc., or Corp | Example GmbH & Co. |
OU | Organizational Unit | Internal organization department/division name | IT Department |
L | Locality | Name of the town, city, village, etc. | Jena |
ST | State | Province, region, county, or state. This should not be abbreviated. | Thüringen |
C | Country | The two-letter ISO code for the country where your organization is located | DE |
E-mail address | The organization contact, usually of the certificate administrator or IT department. Recommendation: a central e-mail address (e.g., IT ticket system), not a dedicated person | helpdesk@example.com |
For information on how to access and manage the database, please refer to Guide - Intershop Commerce Platform Database Handling.
There are two options to access the log files:
Option 1: On INT (ED+LV) there are read-only mounts for accessing ICM PRD+UAT (LV+ED) and IOM PRD log files as well:
|
Option 2: Access log files and monitoring files via SMC, which is more comfortable and explained in Concept - Intershop Commerce Platform DevOps - Access and Permissions.
Note
ICM log files and web adapter log files are saved for 30 days and then deleted!
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
Info
kubectl
for exploring the namespace:kubectl get pods -n $namespace
kubectl describe pod -n $namespace $pod
kubectl logs -n $namespace $pod
By default, Intershop Commerce Platform 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., the 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 the type and firmware version of your device. For more information please see the compatibility list: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices Note 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. |