Deploying to the Cloud

Analyzing the Code Repository for the Build Process

Objective

After completing this lesson, you will be able to analyze the structure and configuration of a code repository and its manifest.json file.

Code Repository Structure​

Before the Cloud Portal can pull custom code from the connected repository, the repository's structure must be correctly configured and organized so the Cloud Portal can recognize it.

Let's explore a standard code repository structure to understand how its essential files are arranged.

This image illustrates a standard code repository structure recognized and used by the Cloud Portal.

The repository's top level consists of two primary folders:

  1. The core-customize (mandatory) folder houses SAP Commerce Cloud customizations and a manifest file. Its subfolders contain custom extensions and local configuration files.
  2. The js-storefront (optional) folder holds the custom composable storefront Angular project codes along with the manifest.json file.

Each top-level subfolder requires a manifest.json file. When located in the core-customize subfolder, this file defines the code build structure for an SAP Commerce Cloud application. When located in the js-storefront subfolder, it defines the build structure for a custom Composable Storefront.

In the following section, we will explore what the manifest.json file contains.

Cloud Build Manifest

SAP Commerce Cloud uses the manifest.json file to configure the build structure of a custom implementation, including SAP Commerce Cloud, and Composable Storefront.

Since this learning journey primarily focuses on SAP Commerce Cloud, let's examine a typical manifest.json file in the core-customize folder.

This image provides a detailed listing of key components of a typical manifest.json file in the core-customize folder, essential for customizing SAP Commerce Cloud.

The manifest.json file, as illustrated, handles several components. The major ones are:

  • commerceSuiteVersion: Specifies the application version of the server to be built.
  • extensions: Lists the extensions to include in the build process.
  • useConfig: Directs the build to use custom configuration files.
  • properties: Defines the server’s properties.
  • aspects: Defines the server’s application instances (aspects).

Let's examine each component in detail.

Application Version: commerceSuiteVersion

The image depicts the example use of the commerceSuiteVersion component in a manifest.json file.

The commerceSuiteVersion component specifies the exact SAP Commerce Cloud version to download. It is mandatory for the cloud build. You can either automatically use the latest version or select a specific patch. For more details, see: Specifying SAP Commerce Cloud Update Version | SAP Help Portal

Custom Configuration Reuse: useConfig

The image depicts the example use of the useConfig component in a manifest.json file.

You can use the useConfig component to point the manifest.json file to a config folder within your repository. This approach is recommended because it ensures your local development environment aligns seamlessly with what is deployed to SAP Commerce Cloud.

The config folder can hold configurations for:

  • Solr: Custom Solr configuration (e.g., the <CommerceFolder>/config/solr folder)
  • Properties: Location for the property file (e.g., <CommerceFolder>/config/local.properties)
  • Extensions: Location for localextensions.xml file, and the extensions to exclude (e.g., backoffice - not imported from the localextensions.xml file)
  • Languages: The folder containing pre-set languages (e.g., the LANGUAGES folder).

For more details, see: SAP Commerce Cloud Configuration Reuse| SAP Help Portal.

Extensions

This image illustrates two methods for including specific extensions in a manifest.json file.

You can include specific extensions for your SAP Commerce Cloud application using two methods.

  1. Explicitly name them using the extensions component.
  2. List them in the localextensions.xml file and reference it with the useConfig component.

The recommendation is to use the second method to maximize configuration reuse and stay as close to local development as possible. Reference SAP-managed extensions, such as the cloud hot folder (azurecloudhotfolder extension), directly in the manifest.json file.

If you use both methods, the build process combines the extensions from both locations.

Properties

This image illustrates example use of properties component in a manifest.json file.

You can use the properties component to define or override a property in the manifest.json file by specifying these attributes:

  • key: The property name or id (mandatory)
  • value: The value of the property (mandatory)
  • persona: Restricts a property value to a specific environment type, such as development, staging or production (optional).
  • secret: A secret/sensitive property value to be excluded from the build logs (optional)

    It’s recommended to avoid specifying secrets in a manifest.json file. Instead, use static files or service properties. For details, refer to:Updating Service Properties)

For more information, see: Build Manifest Components | Properties page.

Language Packs

This image illustrates the process of organizing language pack zip files into a specific folder and referencing it in the manifest.json file.

As shown, to deploy language packs in SAP Commerce Cloud:

  • Create a folder in the root of the core-customize folder — for example, _LANGUAGES_.
  • Add the language pack ZIP files to the _LANGUAGES_ folder. Language packs must be named langpack*.zip.
  • Add the lang.packs property in the manifest.json file, listing the languages to be included.

For more information, see: Adding Language Packs | SAP Help Portal page.

Aspects

SAP Commerce Cloud containerization support relies on aspects to define the roles of various applications within a Kubernetes cluster.

The SAP Commerce Cloud build process defines several standard aspects by default:

  • jsstorefront: Configures the Composable Storefront
  • backoffice: Handles Backoffice application configurations
  • backgroundProcessing: Performs CronJob tasks in the background
  • api: Establishes OCC Restful web services

The following diagram illustrates a typical aspect definition structure in the manifest.json file.

The images provides the aspect 'backoffice’ definition, showing its name, properties, and webapps in the manifest.json file.

An aspect defines the following:

  • Name: The aspects' name, for example, "backoffice".
  • Properties: Properties applicable only within the context of the aspect. In this example, the property determines the initialization of the search index.
  • Webapps: All web applications accessible within the aspect. Each application includes a contextPath for access. For example, the hac application uses /hac, and the backoffice application uses /backoffice.

For more information, see: Aspects | SAP Help Portal page.

This completes the overview of the major manifest.json components. For a complete list of build manifest components, see the Manifest Components Reference page. For manifest.json examples, see the Configuration Examples page.

Key Takeaways

  • A valid code repository requires a correctly organized structure: a mandatory core-customize folder and an optional js-storefront folder, each containing a manifest.json file that defines its respective build configuration.
  • The manifest.json file controls five key components (commerceSuiteVersion, extensions, useConfig, properties, and aspects), each configuring a distinct part of the SAP Commerce Cloud build process.
  • The useConfig component keeps local development aligned with cloud deployments, while aspects define application roles within the Kubernetes cluster.
Learning

SAP FacebookSAP YoutubeSAP LinkedIn