You're not logged in.
  1. Documentation
  2. discover
  3. components
  4. connecting a commerce platform

Connecting a Commerce Platform

Last updated a day ago

Learn how to connect CoreMedia Content Cloud with a commerce platform

This guide provides an overview of efficient ways to connect CoreMedia Content Cloud with a commerce platform. It focuses on the Augmentation Scenario, where the Commerce System and storefront manage the overall experience while using CMS-provided content. Teams can leverage products, variants, and categories within the CMS to create a consistent and engaging experience for consumers, true to our motto "Elevate Experience"!

DOC 439 1

Goals of This Guide

This description focuses on the overall approach to system integration and content management across environments, rather than specific configuration details. For this purpose, please also refer to the respective commerce integration manual, e.g., SFCC, SAP, HCL, Commercetools, at https://documentation.coremedia.com/reference-materials/. Additionally, we linked reference material at the end of this guide.

Environments

Following a genuine Software Development Lifecycle, you can have an extensive range of environments, each meticulously designed to ensure the robustness of the system:

1. Development Environment (Local)

  • Purpose: This is where developers write and test their code. It’s typically used for local development and initial testing. The developers use their individual machines (laptops/desktops) for coding.

  • Required: Yes

  • Comments: Developers can work with minimized workspaces depending on the tasks. For example, a CoreMedia Developer can connect a local front-end application (CAE or headless Front-end) against the Integration environment (Dev) and, therefore, doesn’t have to run the entire application on the developer’s machine. In this case, the code workspace and some minimal tooling are sufficient.

2. Integration Environment (Dev)

  • Purpose: This environment integrates code changes from multiple developers and runs (ideally) automated units and integration tests. It ensures that code from different team members works together before proceeding to further testing.

  • Required: Yes

  • Comments: CoreMedia Content Cloud Service customers should leverage a development sandbox for this environment.

3. Test/QA Environment

  • Purpose: This environment is used for functional testing, user acceptance testing (UAT), and quality assurance (QA). The goal is to match the production environment as closely as possible.

  • Required: Yes

  • Comments: CoreMedia Content Cloud Service customers should leverage a UAT instance for this environment. The focus is on finding bugs and ensuring the application meets the required specifications.

4. Staging Environment (Pre-Production)

  • Purpose: This environment simulates the production environment as closely as possible. Testers should run full tests before deployment to production as a final quality assurance. Staging is where user acceptance testing (UAT) and performance testing take place.

  • Required: No

  • Comments: CoreMedia Content Cloud Service customers should leverage a UAT instance for this environment. This environment ensures the application performs and behaves the way it would in production. It is a dress rehearsal for production deployment.

5. Production Environment (Prod)

  • Purpose: This is the live environment where the application is made available to end users. All configurations and resources must be stable, scalable, and secure. Content Creators leverage this environment to create and manage their engaging experiences.

  • Required: Yes

  • Comments: CoreMedia Content Cloud Service customers should leverage a Production instance for this environment.

6. Disaster Recovery (DR) Environment

  • Purpose: The Disaster Recovery (DR) Environment serves as a backup in case of catastrophic failure in the production environment. Having a DR increases the options for business continuity, providing a safety net in case of unexpected events.

  • Required: No

  • Comments: The environment should ensure backup readiness and business continuity in case of catastrophic failures. Due to the nature of the CMCC Service platform, the infrastructure covers these aspects and doesn’t need to be leveraged in a Service scenario. However, testing deployment and rollback procedures and leveraging consistent data backups are recommended.

7. Performance Testing Environment

  • Purpose: The Performance Testing Environment is specifically used for load and performance testing. Testers evaluate how the application behaves under various traffic conditions. The goal is to ensure that the system can handle high traffic loads and remain performant under all conditions.

  • Required: No

  • Comments: This environment ensures the system can handle high traffic loads and remain performant under various conditions. CoreMedia Content Cloud Service customers should leverage a UAT instance for this environment.

8. Security Testing Environment

  • Purpose: The Security Testing Environment is specifically designed to perform security assessments, vulnerability scanning, and penetration testing without affecting other environments. Its sole purpose is to identify and address before deployment to production. Testers also ensure compliance with security standards.

  • Required: No

  • Comments: CoreMedia Content Cloud Service customers should leverage the combination of UAT and Production instances.

We recommend a basic setup of local instances (developers’ machines), one integration environment (“Dev”), one UAT, and one production instance, at a minimum. As the smallest stack, this setup is also mandatory in a CMCC-Service account.

CMCC Architecture and Commerce Hub

CoreMedia Content Cloud uses a two-part approach:

  1. Management Side: This is for editors, who create and manage content and experiences using various sources. Only editors, developers, and administrators have access.

  2. Delivery Side: This ensures reliable, scalable, and high-performance delivery of content.

The delivery system, including the preview and live Content Application Engine (CAE) or Headless Service, connects to the Commerce Service via the Commerce Hub. The Commerce Hub links to specific commerce systems through dedicated connectors. Ready-made Commerce Hub Connectors and resources for custom integrations are available at https://releases.coremedia.com under "Downloads":

downloads
Figure 1. Simplified CMCC Architecture with Commerce Hub Integration

Tipp: Clicking on any picture in this guide will enlarge them.

The architecture diagram below shows how CoreMedia Content Cloud integrates with the Commerce Service. You can install multiple Commerce Hub Connectors in a single setup, as needed.

DOC 439 CMCC with commerce hub Fig. 1
Figure 2. Simplified CMCC Architecture with Commerce Hub Integration

The following diagram depicts the various directions of communication between the CoreMedia Content Cloud and the commerce system in a headful scenario. For simplification reasons, it only shows a single delivery unit – but the concept applies to CMCC’s preview and CMCC’s live rendering engines.

DOC 439 request flow Fig. 2
Figure 3. Simplified request flow between CoreMedia ContentCloud and the Commerce Platform (Augmentation Scenario)

To enable communication between CMCC and the commerce service, two interaction flows must be considered:

Editorial Interaction: During content creation, editors access the storefront preview directly from CMCC Studio. Here, the CMS redirects the request to the commerce service’s preview URL. The commerce system must identify this as a preview scenario and fetch content from CMCC’s preview delivery, not the live delivery.

Content Delivery to End Users: Consumers access the storefront independently, either in preview mode (e.g., for quality assurance) or live mode. It’s essential to differentiate these requests, which can be achieved using methods such as URL parameters, separate domains, or distinct systems, depending on the commerce service’s capabilities.

The diagram outlines how content delivery operates for both preview and live scenarios.

DOC 439 message sequence diagram Fig. 3
Figure 4. Message Sequence Diagram for a Browser Request in an Augmentation Scenario

With the above architecture and request patterns in mind, we can now answer the central question of this “How-to”: How do we pair CoreMedia Content Cloud instances with the commerce instances?

Options for Integration

The options for integrating CMCC with a commerce platform depend on the platform itself and existing technical and business processes for site generation. However, several key principles apply:

1. Preview vs. Live Modes: CMCC offers distinct engines for previewing content (available to the editorial team) and delivering live content (published content only). Not all commerce systems can differentiate between these modes. The critical question is whether the commerce platform can handle content delivery tailored to preview and live modes and if storefronts can explicitly request content from CMCC’s preview or live engines.

2. Catalog Availability: Commerce setups vary. In some cases, only the live production catalog is fully available, while lower environments might lack access to the entire catalog or require replication actions from staging environments. This can impact the editorial process, as limited catalog availability in non-production environments may hinder testing of content tied to commerce items.

3. Instance Availability: The number of lower environments often depends on business and commercial priorities. For example, a live trading platform may require additional instances for security and performance monitoring, while a brand website might prioritize content creation speed. Industry-specific needs play a significant role in these decisions.

For both B2C and B2B customers, environment planning must align with the partnership between CMCC and the commerce platform. These examples offer a foundation for defining standard setups tailored to unique requirements.

One-to-One Setup

In this approach, a single CMCC instance connects to one commerce system instance. Depending on the commerce system’s capabilities, a proxy might be required to link the storefront with the preview and live rendering engines on the CMCC side. Platforms like Salesforce Commerce Cloud can handle this without a proxy by adding a URL parameter (e.g., www.mystorefront.com?preview=true) to toggle between preview and live modes. However, not all scenarios support this. In such cases, an additional proxy can help distinguish between preview and live requests. Some CoreMedia Commerce Hub Connectors use request header parameters to route requests to the correct rendering engine on the Content Management side.

DOC 439 example one to one setup Fig. 4
Figure 5. Message Sequence Diagram for a Browser Request in an Augmentation Scenario

If a smaller number of CMCC or commerce instances needs to be leveraged, or the business processes eliminate the One-to-one setup, consider the Jointly Used Instances setup.

Jointly-Used Instances Setup

This setup varies depending on your requirements and offers two main patterns:

1. Single CMCC Instance with Multiple Commerce Platforms

One CMCC instance connects to several commerce platforms, allowing centralized content management across multiple systems.

2. Single Commerce Platform with Multiple CMCC Instances

While less common, this setup links one commerce platform to multiple CMCC instances. It is typically used for highly customized configurations, such as headless front-ends.

This approach is flexible but best suited for specialized use cases.

DOC 439 mapping with 4 commerce instances Fig. 5
Figure 6. Mapping With 4 Commerce Instances That Only Serve a Single Delivery (Preview or Live) – Instance View

The primary consideration for this setup is the alignment between content and commerce items. Suppose the CMCC Management Side shows an ImageMap or Teaser with links to one or more products:

Are those products also available under the same SKUs leveraging the second commerce system connected to the CMCC Live delivery?

Are the catalogs comparable?

DOC 439 connection view Fig. 6
Figure 7. Mapping With 4 Commerce Instances That Only Serve a Single Delivery (Preview or Live) – Connection View

Minimizing Repository Jumps

To streamline operations, aim to minimize switching between the content and commerce repositories, aligning catalogs closely with their related content.

  1. Lower Environments: In lower environments, it’s generally acceptable to connect a single commerce instance exclusively to either the preview or live delivery system. Since publication is not usually a focus during feature testing or performance evaluations, this setup works well.

  2. Test/QA Environments: If performance testing is part of the Test/QA environment, connect the commerce instance to the CMS delivery system. Testers will need to publish content to view the “storefront result,” which introduces a minor inconvenience but ensures accurate testing.

Summary

Integrating CoreMedia Content Cloud with a commerce service instance offers flexibility with various approaches. To ensure success:

  • Design the infrastructure not only for technical connectivity but also with consideration for commercial and business workflows.

  • Leverage helper tools, such as proxies, to enable CoreMedia Commerce Hub connectors to facilitate seamless communication between the commerce platform and either the CMCC Management or Delivery sides.

  • Note that proxies are not included in the default setup and must be implemented as part of a custom solution.

This approach ensures a tailored, efficient integration that aligns with both technical and business needs.

Further Reading

Copyright © 2024 CoreMedia GmbH, CoreMedia Corporation. All Rights Reserved.
Loading...