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​

The Cloud Portal cannot yet pull the custom code from the connected code repository. This is because the code repository's structure must be correctly configured and organized so that it can be recognized by the Cloud Portal.

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

This image illustrates a standard structure of a code repository, recognizable and utilized by the Cloud Portal.

As depicted, the code repository's top level consists of two primary folders:

  1. Core-customize (mandatory) folder houses SAP Commerce Cloud customizations and a manifest file.

    The subfolder contains the 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.

An additional third folder, datahub (optional), may also be present at the repository's top level. It contains the back-end data integration implementation details based on the SAP Commerce Cloud Data Hub. For further details, consult the SAP Help Portal and review the configuration example of Data Hub.

A manifest.json file is required in each top-level subfolder. When located in the core-customize subfolder, this file outlines the code build structure for an SAP Commerce Cloud application. Conversely, when it's in the js-storefront subfolder, the manifest.json delineates the build structure for a custom Composable Storefront.

But what exactly constitutes the definition of the manifest.json file? We'll explore this in more detail in the following section.

Be aware that an alternative method for arranging the code repository in a single directory with one manifest.json is available too. Use of this configuration method is, however, no longer recommended, and it's been marked as deprecated.

Cloud Build Manifest

SAP Commerce Cloud uses the manifest.json file to configure the custom implementation's build structure, including SAP Commerce Cloud, composable storefront, and Data Hub.

As we're primarily focusing on SAP Commerce Cloud throughout this learning journey, let's examine a typical manifest.json file located in the core-customize folder.

This image provides a detailed listing of the crucial components incorporated in a typical manifest.json file. This file is situated within the core-customize folder and is pivotal for customizing SAP Commerce Cloud.

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

  • commerceSuiteVersion: Application version of the to-be-built server.
  • extensions: Extensions to be included in the build process.
  • useConfig: Use of custom configuration files.
  • properties: Properties of the server.
  • aspects: Aspects (also known as Application instances) of the server.

Let's examine each component one at a time to delve deeper into its fundamentals.

Application Version

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

As depicted earlier, the application version specifies the exact SAP Commerce Cloud version to be downloaded. It’s a mandatory component for the cloud build. You can either opt to automatically use the latest version or select a specific patch. You can find more details here: Specifying SAP Commerce Cloud Update Version | SAP Help Portal

Custom Configuration Reuse

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

As shown before, you can configure the manifest.json file to direct it towards a config folder within your repository. This method is highly recommended as it guarantees that your local development aligns seamlessly with what is deployed to SAP Commerce Cloud.

In the config folder, it’s possible to hold configurations for:

  • Solr (custom Solr configuration, for example, the config/solr folder)
  • Properties (location for the property file, for example, the config/local.properties)
  • Extensions (to exclude any specific extension, for example, backoffice)
  • Languages (the folder containing the preset languages, for example, the ‘_LANGUAGES_’ folder)

More details can be found here: SAP Commerce Cloud Configuration Reuse| SAP Help Portal.

Extensions

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

As depicted, two methods exist to include specific extensions for your SAP Commerce Cloud application.

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

The second method is recommended to maximize configuration reuse and adhere to local development as closely as possible. SAP-managed extensions such as the cloud hot folder (the azurecloudhotfolder extension) need to be referenced from the manifest.json file.

If both methods are utilized, the build process combines the extensions defined in both locations.

Properties

This image visually demonstrates the application of properties in a manifest.json file as an example.

As shown, the "properties" component can be used 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 (optional), such as development, staging or production.
  • 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 the service properties (refer to: Updating Service Properties)

You can find more information about using "properties" in the Build Manifest Components | Properties page.

Language Packs

This image illustrates the necessary process of organizing language pack ZIP files into a specific folder and subsequently referencing to it within a manifest.json file.

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

  • Create a folder called, for example, _LANGUAGES_ in the root of the core_customize folder.
  • Add the language pack ZIP files to the _LANGUAGES_ folder.
  • Add the property "lang.packs" in the manifest.json file, listing the languages to be included.

You can find more information in the Adding Language Packs | SAP Help Portal page.

Aspects

Containerization support in SAP Commerce Cloud mainly relies on "aspects." These aspects are used to define the roles of various applications within a Kubernetes cluster.

As part of the default configuration within the SAP Commerce Cloud build process, several standard aspects are defined. These include:

  • 'jsstorefront', which configures the Composable Storefront
  • 'backoffice' for Backoffice application configurations
  • 'backgroundProcessing' for performing CronJob tasks in the background
  • 'api' for establishing OCC Restful web services

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

The images provide the definition of the aspect 'backoffice', incorporating its name, properties, and webapps in a manifest.json file.

As illustrated, an aspect defines:

  • Name: This refers to the name of the aspect. For instance, "backoffice".
  • Properties: These are the properties that are only applicable within the context of the aspect. In this instance, the property that determines the initialization of the search index is included.
  • Webapps: These are all the accessible web applications for the aspect. Each application comes with a contextPath, which enables access. For example, the hac application can be accessed using the contextPath "/hac", and the backoffice application can be accessed using the contextPath "/backoffice".

You can find more information in the Aspects | SAP Help Portal page.

That’s it for a quick walk-through of the major components of a manifest.json file.

If you want a complete list of the build manifest components, check the Manifest Components Reference page.

If you are looking for examples on manifest.json, you can find them in Configuration Examples page.

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn