Migrating to the SAP Commerce Cloud - Notes from SAP CX Live 2018

SAP just wrapped up their annual CX Live event in Barcelona, Spain. We were excited to see that a good portion of the event was focused on the new SAP Commerce Cloud. The value proposition of Digital Commerce in the cloud has always been the same: improve operational efficiency, reduce time to market, scale on demand to meet customer needs, and minimize downtime. In the latest release of SAP Commerce Cloud, SAP completely redesigned their cloud hosting approach from the ground up and fundamentally altered their strategy for the better. They are now capable of effectively hosting SAP Commerce in a cloud-based environment. Avatria has extensive experience with cloud hosting and can help on-premises SAP Commerce (Hybris) customers embark on the journey to the cloud in weeks, not months. To start, we thought we would provide readers with some helpful information that we learned at SAP CX Live 2018.

SAP will help but there’s still work for the customer and integration partner.

When a customer begins the process of migrating to the SAP Commerce Cloud, SAP assigns a migration team to help support the migration. Their goal is to minimize time and cost, and make the process as painless as possible for the customer. They will take care of:

• Standing up the environment landscape (takes about an hour once the request is submitted).

• Migrating the database and media once provided with a “Data Migration Package” (one environment at a time).

• Provisioning any new nodes (horizontal scaling).

• Migrating Solr Configs (via support ticket).

• Providing the customer with IP addresses for all publicly available load balancers so that DNS can be configured accordingly.

However, the customer and integration partner (in this case Avatria) must complete the below tasks:

• Convert the local.properties and localextensions.xml files into a Manifest file. This Manifest file (represented in JSON format) allows for configuration properties to be globally defined, defined on a per-environment basis (called Personas), and defined based on the function that the node is performing (e.g. Storefront vs Backoffice, called “Aspects”).

• Create a Git access key for SAP so that the Commerce Cloud can access the customer’s source code for release generation.

• Add Web Tier assets via the Cloud Portal. These include but are not limited to:

  • SSL certs (preferably wildcard certs) that support the subdomains that will be utilized

  • Redirect rules

  • Static files

  • Maintenance page

• Generate Data Migration Packages for each environment and provide them to SAP.

• Extract Solr Configs and provide them to SAP to install via a support ticket.

• Stand up an SMTP server or utilize a third-party service to facilitate email communication. More information is included below.

• Generate the first release and start deploying through the customer’s landscape.

• During cut-over:

  • Configure the customer’s DNS using the IP Addresses of their public load balancers found in the Cloud Portal.

While SAP has done their best to make this process as easy as possible, there are still quite a few migration tasks that are technically complex. Avatria can help facilitate this process to ensure a seamless, speedy migration.

SAP’s Cloud Architecture is standardized and enforces best practices that may or may not make sense for your organization.

There are a lot of factors to evaluate when considering a migration to the SAP Commerce Cloud, some of which are mentioned above. While SAP Commerce Cloud is an excellent offering, migrating to it may or may not be the best option for every existing SAP Commerce customer. The good news is that Avatria can help you make this decision. To start, we have provided a list of some items that should be taken into consideration when migrating to the Commerce Cloud. For more information, contact us today.

Environment Landscape

• There are 4 different types of Hybris nodes in each environment. Each performs a specific function which allows us to move tasks that may be performance-intensive off of the Storefront and Backoffice nodes. They are:

  • Storefront: Serves storefront traffic.

  • Backoffice: Facilitates access to the Backoffice.

  • Scheduled Jobs and Processes: This will facilitate any scheduled cron jobs and other event-based processes that impact performance.

  • Admin: This will provide access to the HAC.

• SAP enables us to create a domain for each type of node. For example, the storefront nodes would be www.acme.com, whereas the Backoffice nodes would be backoffice.acme.com. This allows specific security rules to be applied to each grouping of nodes so that access to the non-Storefront nodes can be isolated to internal resources at your company, and access to the Storefront nodes can be made publicly available.

• SAP uses the same n-tier architecture across each environment. This is a huge plus because it ensures that any environment issues are discovered early on in the release cycle.

• The n-tier architecture that SAP uses involves a load balancer on top of an Apache web server, which sits on top of Hybris, which sits on top of Solr and a SQL Server Database. This means that migrating to the Commerce Cloud with an Oracle Database may require that you use ImpEx to export all of your data (not including file system data), and import it into Commerce Cloud via ImpEx.

• You may add additional environments to your landscape by contacting SAP directly.

Customization and Integration

• One of goals of every Application Architect is to design their solution in a way that ensures that the upgrade path is not jeopardized. This means that one must avoid making modifications to the core platform. In the past, SAP has provided a workaround to allow core platform modifications by allowing developers to place their modifications in a “customize” directory. In SAP Commerce Cloud, this type of platform customization is no longer supported. Simply put, “ant customize” cannot be run and nothing in your ${HYBRIS_CONFIG_DIR}/customize directory can be migrated.

• There are no third-party appliances allowed on any node. However, SAP will give you access to Kibana for log monitoring, uptime monitoring by CatchPoint, performance monitoring by DynaTrace. All of this comes included in Commerce Cloud’s fees.

• Any load testing that is performed will require SAP Expert Services to help analyze DynaTrace since direct access is not provided. However, SAP anticipates being able to provide DynaTrace to their customers in the next couple quarters.

• SAP has released a successor to Data Hub called SAP Cloud Platform Integration (SCPI) that ships as a new Backoffice perspective. This means that Data Hub will eventually be retired. SAP doesn’t expect this to happen for 2-3 years and if you already have it, you can keep it. However, SCPI can be used to facilitate any net-new SAP integration or other ETL.

• SAP no longer supports utilization of the integrated SMTP server. This means that you must stand up your own outside of SAP Commerce Cloud or update your implementation to use a third-party email service like Salesforce Marketing Cloud (formerly called ExactTarget).

Release Management

• Commerce Cloud requires the Git Source Code Management system. If not yet on Git, stand up a Git repository (or use a cloud version, which is preferred). The Git repository will contain the contents of your bin/custom directory. Examples of cloud versions include: Bitbucket and GitHub.

• There is currently no support for “Live Updates,” rolling deployments, red/black deployments, or any form of deployments that avoid an outage during deployment. When deploying a release, nodes are brought down, the release is deployed to the admin cluster, a System Update is performed, and then the remaining nodes are brought back up. SAP anticipates being able to support zero-downtime deployments sometime in the near future.

• Releases are deployed one node at a time and can be smoke tested before bringing up the entire cluster. As such, it is recommended to utilize a new type system version for each new release that is deployed.

• After a release is deployed, logging can only be altered on the admin nodes since access to the HAC is only supported on those nodes.

Miscellaneous

• Database snapshots must be requested. When they are requested the storefront is brought down to generate the snapshot.

• There is no cookie interrogation supported at any tier above the application servers.

• Any redirect/rewrite rules must be added to the Apache Web Server tier. This is something that you will want to consider if you have an implementation that directs traffic to an external CMS for some pages and to Hybris for others.

• SSL is also terminated on the Apache web servers.

If you want to learn more SAP has some great resources…

SAP has released quite a bit of documentation about migrating to the SAP Commerce Cloud in their Enterprise Support Academy.

So What Now?

If you have been considering a migration to the cloud, now is the time. SAP has finally put together a best-in-class cloud solution for Digital Commerce, built on Azure. From what we witnessed, they have the internal expertise capable of delivering. The only thing that remains is finding the right partner to help facilitate the journey to the SAP Commerce Cloud. Avatria is just that partner. Contact us or message me directly at brian.ballard@avatria.com if you want to learn more.