CX Works

A single portal for curated, field-tested and SAP-verified expertise for your SAP C/4HANA suite. Whether it's a new implementation, adding new features, or getting additional value from an existing deployment, get it here, at CX Works.

Implementing Internationalization with SAP Commerce Cloud

Implementing Internationalization with SAP Commerce Cloud

Internationalization in an e-commerce context is the means of adapting to different languages, currencies, regional differences and other technical requirements of your target markets.

In a SAP Commerce Cloud context, this means that the solution will be available in more than just one country or region. This page summarizes challenges and recommended practices to enable the solution to be available in multiple countries or regions.

Table of Contents

Introduction

The internationalization decisions start with a good understanding of the business logic and the requirements for a country or region-specific data. In some cases, the data and business logic might be common for all countries or regions and the focus is on the localization of the content. In other cases, you need to consider if the following should be country or region specific or if common to all markets:

  • Product assortment and product content
  • Web Content Management System (WCMS)
  • Customers
  • Parts of the business processes such as tax calculation or order fulfillment
  • Front-end processes such as checkout or customer registration
    • Different payment options
    • Different fields to capture
    • Different required field

In addition, internationalization brings complexity in the following areas:

  • Making sure the customer is using the correct storefront
  • Support for multiple languages, currencies, address formats
  • Content needs to be translated as part of the standard activities after going live

You also need to consider deployment architecture and decide if you have regional data centers that reduce latency for the end customers or if you use a single data center with a distributed Content Delivery Network (CDN).

There is of course also project delivery complexities to a global project requiring internationalization, but this is not covered on this page.

  • Development teams could be in different countries or regions
  • Code base could be region specific
  • International rollout
    • Should you have a phased approach?
    • Should you start with the most complex or least complex market first?

Overall, it is important to ensure your requirements account for internationalization in the specific areas below. You need to be specific about where it will be supported, globally or locally. It is important to realize that for each of the considerations, it is not a one size fits all, each one may be very different for each region as displayed in the following table:


Parameter Region 1 Region 2 Region 3 Cluster 4

Language

Local

Local

Local

Global

Currency Local Local Local Global
Content Local Global Global Global
Merchandising Local Global Global Global
Fulfillment Local Local Global Global

Frontend and Checkout

Local Local Global Global
Marketing Local Global Global Global
Customer Service Local Local Global Global


Customer

Customer behaviors vary across geographies. Buying patterns and decision-making factors can be completely different in different regions. To successfully attract customers, you need to take into consideration different aspects of customer behaviors and preferences and understand target customer segments and journeys. When determining the potential of the market and customer profiles, the following aspects should be taken into considerations:

  • Internet penetration and bandwidth availability
  • Internet buying population
  • Income and social classes
  • Customer shopping preferences (price sensitivity, promotions, content quality)
  • Internet buying preferences (categories bought online)
  • Target customer segments
  • Buying journeys (funnels) for target segments
  • Visual and device preferences (mobile first, media representation)

Once you have established which regions you will support, it is also important to determine how you will assign a customer to a region. The most common way is by the billing address. However, other business logic such as IP address could also be implemented.

Language and Local

In a multi-country SAP Commerce Cloud implementation, each new supported language requires a content preparation strategy. The following topics need to be considered:

  • Determine the languages you will support in each of the regions where your solution will be available.
  • Determine the page templates used for the commerce channel. It may be common templates across countries or each country may have their own set of templates or a combination of both (see more in the "Web Content" section below).
  • Plan the content management process. It may be centralized or country-based content management.
  • The language-specific content should be prepared using a professional translation team. It is also preferable to have a legal review on critical contents. This should be accounted for as part of your publication workflow.
  • The default language would usually be the language predominantly used in the region. However, the customer should have the option to select another language.

You'll find details about encoding, UI element localization, and more in Internationalization and Localization.

Business Processes

Several business processes can be region specific. Typical examples are:

  • Solr
    • Different languages need to be properly set up, including stop words, synonyms and server configuration.
  • Prices
    • If internationalization of prices is managed in SAP Commerce Cloud, expect complex rules around currency conversions, rounding, markups, and markdowns.
  • Taxes
    • Some markets (for example, USA) have complex tax system where taxes are usually calculated by third-party providers (for example, Avalara). As you need to pay for the service, it is important to limit calls to the tax calculation service. Typically, this would only be used in the checkout process.
    • Other markets have a simple tax system which can be managed inside SAP Commerce Cloud.
    • In some countries, it is custom or mandatory to show the tax amount in the checkout process. In other countries, the tax is shown only on the invoice.
    • For cross-border shipping, customs needs to be taken into consideration.
  • Promotions
    • The business requirements should determine whether promotions will be done on a global level or will be managed locally.
    • Each country and the country’s business unit may follow different pricing strategies based on customer buying behavior. It may be based on cost-based pricing, market-based pricing, dynamic pricing and others.
    • Different types of promotions specific for individual markets need to be taken in consideration.
    • Understanding the price sensitivity of specific markets is needed. Some markets are looking for discounts when buying online while some buy online due to convenience, thus are more flexible on prices.
    • Specific regulations regarding pricing need to be analyzed. Regulations in some countries may impose that showing the pricing denomination is essential or that certain elements cannot be discounted (for example, tax cannot be discounted in the USA).
  • Payment
    • Different markets may support different payment options (cash on demand, bank transfer, credit, debit, gift card, e-wallets)
    • Most payment providers can handle multiple regions with the same merchant ID. However, always double check during the design phase.
  • Shipping
    • Factor in different delivery types (address delivery, click and collect, lockers and more)
    • Acceptable delivery speeds may differ per region (same day delivery, standard shipping and more).
    • Cost of delivery may be important in some regions (free delivery versus paid delivery).
    • The out-of-the-box delivery calculation (deliveryzone extension) is unlikely to meet the needs of a multi-region project and a custom FindDeliveryCostStrategyimplementation will be required.
  • Order fulfillment
    • The order fulfillment process, returns, refunds and more could be different per region which can also be impacted by legal reasons. For example, customers are allowed to return goods in a given period or time. The time period could differ from region to region. Also, the restocking fee is not always permitted in all regions.
  • Social Media
    • Used for marketing, ratings and reviews, customer service, analytics.
    • Each region may have their own unique popular social media channels and laws around using it. Consider the popular channels of the regions that you will engage with.
    • Online stores should plan their social commerce strategy with the popular channels. For example, in the USA, Facebook, Twitter, Instagram, Snapchat and Pinterest are the most popular channels. In China, however, popular social channels involved in e-commerce are Pinduoduo and WeChat.
  • Customer Support
    • Customer support operations can be handled centrally or locally. While having customer support centrally and not supporting all languages will probably reduce the customer satisfaction rate, it will also lower your costs.

    • You will need to decide on which languages and through which channels you will provide customer service.

    • Besides supporting traditional channels such as e-mail and telephone, you may also need to analyze and support country-specific customer support channels. For example, live chat, support agent co-browsing sessions or market specific social networks.

We recommend as a practice to have regional business processes orchestrated using some internationalization service. The service does not exist in the out-of-box code yet but should provide a central repository for all region specific business logic. Each time a region requires different handling, the service should be called as opposed to the code cluttered with numerous if() else if() statements to determine the logic to execute for the current region.

Product Content

Product content for different regions can be stored in the same catalog or in separate catalogs. Combining both approaches is common. Some countries can share one catalog while others require a dedicated product catalog.


Considerations

Catalog per Region

Shared Catalog

Performance Dedicated catalogs do not perform or scale well, especially for large catalogs and/or a large number of countries or regions that need to be supported. Every stock keeping unit (SKU) or product in catalog version is a unique copy in the database. This means there are potentially hundreds of database rows to represent a single product localized information (localized values, prices, medias, product features) If the total number of persisted SKUs reaches 500K-1M products, you will need to spend considerable effort on performance tuning in particular for the Product Cockpit search, catalog synchronization, and the Solr index. Although performance impact cannot be ruled out, shared-catalogs generally perform better compared to the dedicated-catalogs as there are no duplicate copies of the products for each country or region.
Product Assortment

A catalog per country or region provides good support for region specific product assortments (different products sold in different regions). Typically, you would have a catalog synchronization job filtering items based on attributes or products to ensure products are only synchronized to the intended catalogs.

To support different product assortments in the search engine (for example, Solr), you would also require at least one search index for each country or region.

Product assortment can be achieved with a shared catalog by using personalization rules (search restrictions) that filter products in the current storefront based on the assigned values of the product.

Customizations are also required to the Solr index and search to support filtering also on search pages.

Product Release Time If the business needs different availability times (online and offline dates) for different regions, a catalog per region supports this out-of-the-box. Not easily achievable.
Localization One of the advantages of having a dedicated catalog per region, is the ability to have different content in the same language for different regions. For example, your client sells toothpaste. In this case, the English version of the product description needs to be different in Germany and in the UK because legally it is a controlled product and different content or images might need to be shown. However, for most of the use-cases, the English version for both the German and the UK market could be exactly same. It is definitely much easier to manage the content in one catalog if the values are the same across many regions (and they typically are). There is no need to synchronize, approve and set up complex business rules. The one source of truth is clear. In the case of exceptions, there is always a possibility to use multiple locales within one catalog and language.
Prices Different prices (in the same currency) for different regions are supported out-of-the-box.

Some customization is required. There are several areas for customization:

  • Assign Price Row to UserPriceGroup.
  • Set the correct UserPriceGroup into the session.
  • Customize the Solr index and populate the results objects.
Synchronization    In other words, which catalogs should be synchronized, which items, what are the dependencies, how will the synchronization be triggered? All this could be quite complex and needs appropriate consideration for the optimal configuration and design to meet the business requirements. The out-of-the-box Staged -> Online catalog version setup works fine in many cases.


Web Content

The main question here is how many sites do you want to maintain? Again, a combined approach is recommended and is supported through the Multi-Country Site features in SmartEdit. Some regions require dedicated catalogs while others could share the catalogs. Special attention should be given to the BaseStore - Catalog relation. Typically, there would be a catalog for each BaseStore. However, depending on business requirements, you can also have multiple catalogs for each BaseStore (for example, catalog for categories, catalog for media, multiple product catalogs) or a catalog shared by multiple BaseStores.


Considerations

Catalog per Region

Shared Catalog

URLs and Cookies The WCMS website is the root type for all the catalog specific content. Therefore, dedicated catalogs means a specific website for each region. This can be seen in the Apparel store sample data that ships with the B2C accelerator. The WCMS websites need to have different URLs. The regional URLs could differ in the domain part (apparel.de, apparel.com) or in the resource part (apparel.com/de, apparel.com/us). It is easy to have different cookies per region or share cookies across regions as long as the URLs differs in the resource part. However, if the domain differs in the top level (for example, apparel.com versus apparel.de), then cookies cannot be shared. One website shared by multiple regions means the same URL and cookies for users from multiple regions (see the Electronics store for an example that ships with the B2C accelerator). If there is a need for region specific cookies, you need to use region specific cookie names.
Customers The customers can access any region and website. Out-of-the-box, there is no relation between the customer type and the BaseStore or CMSSite. However, this is easy to add by creating a relation and taking it into consideration when authenticating. A customer is typically assigned to a region specific user group in order to receive user-specific content.
Region-Specific Content

It is easy to provide region-specific content in a dedicated regional catalog. However, some of the resources (such as header and footer) should be shared across regions regardless of the region specific content. The catalog structure document dives into this topic in more detail. The two main options are:

  • A shared master catalog synchronizes into regional catalogs. However, the synchronization could remove some of the regional content unless you provide a customization that allows some content to be protected from being overwritten by content from the upstream catalog.
  • A separate third catalog having shared catalog.

Region specific content can be achieved using WCMS restrictions. In this scenario, you do not have issues with synchronization and cross-catalog references. However, the usability could suffer if many pages and components have a regional flavor.

Shared Content As discussed above, shared content is possible, but you need to have a dedicated catalog for the shared content and configure it to be synchronized to the dedicated region catalogs. Content from a parent page can be shared. The hierarchy of your content catalogs is important.
Content Localization (languages, currencies) Supported out-of-the-box. This solution is similar to the localization of the product content. Multiple languages and locales take care of the content and a price dropdown selector is provided out-of-the-box. Region specific prices in the same currency can be easily achieved by UserPriceGroup.
Solr Region-specific catalog typically means you also have specific Solr indexes for each region as this is the only approach that is supported out-of-the-box. A shared catalog typically exports into one shared Solr index. Regional content is typically exported into separate Solr fields using a specific field naming convention. Some of them are out-of-the-box (such as locales and currencies), some may need some customization (such as region specific prices in the same currency).
Redirecting to the Correct Region Dedicated sites allow accessing a region that is different to the customer's region, if that is desirable. For example, Amazon is quite liberal in this respect. However, a redirect to the correct regional URL based on a business rule can be implemented as well.

A customer is assigned to the current user group upon login. The anonymous users are assigned to the region by IP address geolocation. However, they should also be given the option to chose a country from a dropdown or a dedicated region selection page, in case they are temporarily accessing the site in another region.


Deployment Architecture

The following issues need to be taken into account when considering the deployment architecture. Go to "Where in the World Is Your SAP Commerce Cloud Instance?" for more on instance strategy.


Multi-tenancy has limited support for SAP Commerce Cloud. It is only being included here for solutions that are running on-premise in the event you want to explore it as an option.

Consideration

Single DB, Cluster and Tenant

Multiple Tenants, Single Cluster

Multiple Clusters, Multiple Databases

Sharing Data The easiest option is to share data. The service layer is used to provide access. Data is strictly separated by the platform either by using a tenant prefix for tables names in the same schema or having a schema for each tenant Data is completely separated into different schemas and/or database servers.
Catalog Data Synchronization between Regions Use the out-of-the-box Synchronizing Catalogs. Use Integration API, Importing and Exporting Using the Data Hub or ImpEx files. Use Integration API, Importing and Exporting Using the Data Hub or ImpEx files.
Region-Specific Business Logic Same code base, same extensions, same Spring beans. Everything is shared thus making it more difficult to introduce a specific logic for a region without creating dependencies in the code. The same basic code base is shared, however, you may enable some tenant specific extensions. You get region specific Spring beans including singletons. The code base could be the same across all regions or it could be completely different. The same applies for extensions. This offers the most flexibility but also the most maintenance to support multiple code bases and deployments.
Downtime Outage or deployment of new functionality affects all regions. Outage or deployment of new functionality affects all regions. Only one region is affected.
Performance Every request comes to the same server cluster and database. Therefore, high traffic sites could be challenging to set up. Every request comes to the same server cluster and database. Therefore, high traffic sites could be challenging to set up. It is easy to split the traffic into a dedicated cluster per region. This approach makes high traffic sites easier to set up as the load is spread over multiple clusters.
Latency Chatty protocols, for example, the one used by the ZK framework will lead to perceived bad performance due to latency for distant users Chatty protocols, for example, the one used by the ZK framework will lead to perceived bad performance due to latency for distant users. You can create clusters with a data center as close to the end users as needed to reduce latency.
Management and Costs One cluster to manage, therefore, hardware and management costs are minimized. One cluster to manage, therefore, hardware and management costs are minimized. Increased hardware costs and more environments to manage and maintain.



Conclusion

This article introduced you to the fundamental challenges of internationalization. If you want to find out more about how you can implement any of these considerations in your SAP Commerce Cloud solution, please contact SAP Expert Services.