Overview

The YaaS Persistence and Commerce services support multi-tenancy to accommodate different projects, so you can configure project-specific properties to adapt applications to the project's needs. Use the Configuration service to manage such project-specific configuration properties on behalf of services or clients.

Usage examples

  • A credit card payment application that requires third-party account information
  • An inventory application that enables you to specify priorities for different sourcing strategies


API Reference

/{tenant}/configurations

Manages configuration properties for a given tenant.

/{tenant}/configurations

get

Gets all configuration properties. The caller must have a 'hybris.configuration_view' or 'hybris.configuration_manage' scope assigned. Fallback values will be not applied and with that will not be part of the response collection. This method uses a paging mechanism. If no paging parameters are provided, the default values are used.

post

Creates a new configuration property. The caller must have a 'hybris.configuration_manage' scope assigned.

/{tenant}/configurations/{propertyKey}

Manages a single configuration property for a given tenant.

get

Gets a configuration property. The caller must have a 'hybris.configuration_view' or 'hybris.configuration_manage' scope assigned. If the property was not previously set, fallback is explicitly enabled, the fallback value is set, and then its value is returned.

put

Updates an existing configuration property. The caller must have a 'hybris.configuration_manage' scope assigned.

delete

Removes a configuration property. The caller must have a 'hybris.configuration_manage' scope assigned.

/{tenant}/clients/{client}/configurations

Manages configuration properties for a given tenant and client.

/{tenant}/clients/{client}/configurations

get

Gets all configuration properties. The caller must have a 'hybris.configuration_view' or 'hybris.configuration_manage' scope assigned. Additionally, you may need to provide a property-specific role which allows you to retrieve the specific properties. If this is not satisfied, no results are returned to the caller. In the corner case, the result could be an empty list. Fallback values will be not applied and with that will not be part of the response collection. This method uses a paging mechanism. If no paging parameters are provided, the default values are used.

post

Creates a new configuration property. The caller must have a 'hybris.configuration_manage' scope assigned.

/{tenant}/clients/{client}/configurations/{propertyKey}

Manages a single configuration property for a given tenant and client.

get

Gets a client-specific configuration property. The caller must have a 'hybris.configuration_view' or 'hybris.configuration_manage' scope assigned. Additionally, you may need to provide a property-specific role which allows you to retrieve the property. If this is not satisfied, a forbidden result is returned. If the property was not previously set, fallback is explicitly enabled, the fallback value is set, and then its value is returned.

put

Updates an existing configuration property. The caller must have a 'hybris.configuration_manage' scope assigned. Additionally, you may need to provide a property-specific role which allows you to modify the property. If this is not satisfied, a forbidden result is returned.

delete

Removes a configuration property. The caller must have a 'hybris.configuration_manage' scope assigned. Additionally, you may need to provide a property-specific role which allows you to delete the property. If this is not satisfied, a forbidden result is returned.


Configuration Properties

The Configuration service uses independent key-value pairs, or configuration properties, to store all configuration information. Such configuration properties are used throughout the API. Here is an example of a simple configuration property:

    {
        "key" : "answer",
        "value" : 42
    }

Key syntax

Each configuration property is identified by a textual key, such as propertyKey, which can contain any printable Unicode character, with the exception of those listed:

  • / and \ — Forward slash and backslash
  • {C} — Invisible control characters and unused code points
  • {M} — A character intended to be combined with another character, such as accents or umlauts
  • {Z} — Any kind of whitespace or invisible separator (other than a single space between two non-space characters)

The Configuration service treats keys in an opaque manner. In particular, the service does not perform any normalization to uppercase or lowercase characters, or similar adjustments.

Value syntax

The value of a configuration property consists of any valid JSON value, so the value can be a string, a number, an object, an array, or a Boolean value: true/false/null. Therefore, the notation rules of JSON apply. For example, you must always enclose a string value in quotation marks:

    "stringValue"

On the other hand, never enclose a Boolean value in quotation marks:

    true

A more complex configuration property value might look like this:

    {
        "pageSize" : 23,
        "sortOrder" : [
            {
                "column" : "price",
                "ascending" : true
            },
            {
                "column" : "rating",
                "ascending" : false
            }
        ]
    }

Currently, the Configuration service does not validate the type of a configuration value, so you can easily replace a number with a string or an array.

Additional fields

In certain contexts, a configuration property might have these additional fields:

  • secured – A Boolean flag that controls additional security features. In particular, setting this to true activates encrypted storage for the configuration property. The default is false.
  • permissions – An object that defines fine-grained, dynamic access control for client-specific configuration properties.

For more information on how and where to use these fields, see the API Reference of the resource endpoints that use them.


Project-Specific Configuration

By design, the Configuration service stores configuration properties in a project-specific context. This ensures that one project cannot access a configuration property in a different project.

Every API endpoint for retrieving or storing project configuration information is secured, so you must provide correct scopes as defined in the API.

The Configuration service allows you to enter and update the configuration during runtime, either by performing REST calls, by using the Builder or by back-office applications. This means that you do not need to store the project's configuration or preferences, nor provide a user interface for this purpose. It is especially useful for applications that do not consume any other persistence or storage, to keep these lightweight.

The project context of a property is reflected in the path. It is defined in https://api.beta.yaas.io/hybris/configuration/v1/myProject/configurations/myPropertyKey.


Client-Specific Configuration

You can define configuration properties in a client-specific context, so they do not conflict with the configuration properties of other clients. The client-specific configuration property is associated with a particular project.

If you need to assign the value of a property to a specific client, or a property has a different value for a different client, define the value in that client's context. For example:

https://api.beta.yaas.io/hybris/configuration/v1/myproject/clients/project.myspecificclient/configurations/myPropertyKey

Project, client, and scope access limits

You cannot access the configuration of one project from another project. Access to client-specific properties is limited to the client that created the property and has an access token with the appropriate scopes, depending on the type of request: hybris.configuration_view or hybris.configuration_manage. These scopes are described in detail in the API Console.

By default, one client cannot access or create the configuration properties of another client. However, there are two exceptions to that rule:

  • defined per-property access permissions
  • holding the admin scope

Access permissions

For client-specific configurations, you can define additional scopes that give clients permissions to read or modify the property. Provide the permissions JSON attribute, together with the configuration value and key when you create the value. For example:

"permissions": {
    "view": [
        {
            "client": "project.storefront",
            "scope": "readStripe"
        },
        {
            "client": "project.adminui",
            "scope": "readStripe"
        }
    ],
    "manage": [
        {
            "client": "project.adminui",
            "scope": "manageStripe"
        }
    ]
}

The permissions attribute consists of two arrays. One defines the view permissions, and the second defines the manage permissions. The view permissions array defines which clients can read the configuration property. The manage permissions array defines which clients can read, modify, or delete the property, as well as read and modify the permissions for other clients, including its own.

By default, the permissions attributes for every configuration property are empty, and only the client that owns the property can access them, provided it holds the appropriate global scopes.

To update permissions for a property, add the permissions attribute next to the value that needs updating. You can also update the permissions by not providing the value attribute. If you provide the value without permissions, only the value updates. To disable this default behavior, set the patch flag to false. If you do not provide the permissions or value, the system removes them. You must have manage-level rights to update the permissions for a configuration property.

When another client requests access to a configuration property in the Configuration service, the system compares the scopes from the token to the appropriate permissions stored with the configuration property. The service grants access if at least one client and scope combination matches the requesting client and scope. In addition, the client must hold the appropriate global hybris.configuration_view and hybris.configuration_manage scopes. Otherwise, the service returns a 403 Forbidden response.

When making a GET request to the value, the permissions field is hidden by default. To include the field in the response body, list it in the fields query parameter.

Admin scope

The hybris.configuration_admin scope provides full access to all configuration properties of the current project. In particular, the scope provides this functionality:

  • It overrides all dynamic permission checks that are based on the ACLs of the particular configuration properties, which helps to prevent accidental lock-outs.
  • It allows access to the configuration properties that any service or client owns, not just the calling service or client.
  • It implies existing service scopes.
  • It does not weaken any project-specific access restrictions. Cross-project access to configuration properties is always forbidden.

A typical use case for this role is that any admin application can initialize and manage a configuration property as long as it acts on behalf of an administrative user with this role assigned. Model all further measures to protect the property using the previously described security concepts.


Fallback Mechanism

When retrieving a property, the fallback mechanism activates using the fallback Boolean query parameter. For example:

https://api.beta.yaas.io/hybris/configuration/v1/myProject/configurations/propertyKey?fallback=true

By default, the fallback mechanism is disabled: fallback=false. If you do not define a property with the key propertyKey for a project or client, and the fallback mechanism is explicitly activated as shown in the previous example, then the system searches for and returns the fallback value for the propertyKey.

Depending on the property type, the system searches for the value using these search criteria:

  • Client-specific property
  • Project-specific property
  • Global property

If the system does not find a fallback for propertyKey, it returns either a null or 404 error response. The nullable query parameter controls this behavior.

Examples

Example 1

The propertyKey has no value set for myProject, and the global fallback for propertyKey is fallbackValue:

Request
  • Method: GET
  • Request URL: https://api.beta.yaas.io/hybris/configuration/v1/myProject/configurations/propertyKey?fallback=false
Response
  • Response code: 404
Request
  • Method: GET
  • Request URL: https://api.beta.yaas.io/hybris/configuration/v1/myProject/configurations/propertyKey?fallback=true
Response
  • Status code: 200
  • Response body:
      {
        "key": "propertyKey",
        "value": "fallbackValue"
      }
    

Example 2

The propertyKey has the value valueSetByUser for myProject, and the global fallback for propertyKey is fallbackValue:

Request
  • Method: GET
  • Request URL: https://api.beta.yaas.io/hybris/configuration/v1/myProject/configurations/propertyKey?fallback=false
Response
  • Status code: 200
  • Response body:
      {
       "key": "propertyKey",
       "value": "valueSetByUser"
      }
    

Example 3

The propertyKey has the value valueSetForGlobal as a global fallback, valueSetForProjectA set for projectA, and no value set for projectB and clientB:

Request
  • Method: GET
  • Request URL: https://api.beta.yaas.io/hybris/configuration/v1/projecta/clients/project.clientb/configurations/propertyKey?fallback=false
Response
  • Status code: 404
Request
  • Method: GET
  • Request URL: https://api.beta.yaas.io/hybris/configuration/v1/projecta/clients/project.clientB/configurations/propertyKey?fallback=true
Response
  • Status code: 200
  • Response body:
      {
       "key": "propertyKey",
      "value": "valueSetForProjectA"
      }
    

Example 4

The propertyKey has the value valueSetForGlobal as a global fallback, and no value set for projectA nor for the combination of projectA and project.clientB:

Request
  • Method: GET
  • Request URL: https://api.beta.yaas.io/hybris/configuration/v1/projecta/clients/project.clientB/configurations/propertyKey?fallback=false
Response
  • Status code: 404
Request
  • Method: GET
  • Request URL: https://api.beta.yaas.io/hybris/configuration/v1/projecta/clients/project.clientB/configurations/propertyKey?fallback=true
Response
  • Status code: 200
  • Response body:
      {
       "key": "propertyKey",
       "value": "valueSetForGlobal"
      }
    

Supported global fallbacks

Currently, the following global fallbacks are available, which are defined for all projects:

configuration.locales

The property key configuration.locales is a prioritized list of locales, and the first one is considered the default locale. It contains only the locales listed in the configuration.supportedLocales property key. For example:

  ["en","de"]

configuration.supportedLocales

The property key configuration.supportedLocales is a list of all locales supported with a human-readable name for each, in English. Localization of these names follows the schema from the https://api.yaas.io/patterns/v1/schema-localized.json file. For example:

    {
     "en" : { "name" : { "en" : "English" } }, 
    "de" : { "name" : { "en" : "German"  } },
    "ru" : { "name" : { "en" : "Russian" } }
    }

configuration.currencies

The property key configuration.currencies is a prioritized list of currencies, and the first one is considered the default currency. It contains only currencies listed in the configuration.supportedCurrencies property key. For example:

  ["USD","EUR"]

configuration.supportedCurrencies

The property key configuration.supportedCurrencies is a list of all currencies supported with a human-readable name for each, in English. Localization of these names follows the schema from the https://api.yaas.io/patterns/v1/schema-localized.json file. For example:

    {    
      "USD" : { "name" : { "en" : "US Dollar" } },
      "EUR" : { "name" : { "en" : "Euro" } },
      "PLN" : { "name" : { "en" : "Polish Zloty" } }
    }


Data Compression

The Configuration service supports data compression. You can send and receive encoded data to reduce response times and bandwidth usage. This feature provides significant value, especially when working with big data sets. The supported format for content encoding is GZIP.

To send compressed data to the Configuration service within the request body, set the gzip value for the Content-Encoding header. To retrieve compressed data in the GZIP format, use the Accept-Encoding header with the gzip value.

It is recommended that you use data encoding every time you send a large amount of data in the body of your request, as well as when you expect to receive a large data set in the response from the service.


Optimistic Locking

The Configuration service provides the means to prevent unpredictable property modifications in case of race conditions. It implements an optimistic locking functionality, which allows the callers to make sure that the property they are updating or deleting is not modified by another caller in the meantime.

When you retrieve a configuration property, one of the attributes inside the metadata attribute is the version attribute. This version sets to 1 after creating the property and increases by 1 with every update. If you do not use the optimistic locking functionality, you can ignore this attribute.

Modify a property with a version

To make sure that the property you modify is the same property that you previously retrieved, for example in an UI, append a query parameter version to your PUT or DELETE request. You can see this query parameter in the API Console). The value of this parameter must be the same version of the property when you last read it.

Making a request with a version number increases the stored version by 1, as long as the stored version is equal to the version provided in the request. If the property was modified in the meantime, the Configuration service recognizes that the version from the request is smaller than the stored version and responds with 409 Conflict.


Security

The Configuration service is a container for your project-specific configuration properties. You control the data stored in the Configuration service, and only you know whether the property contains personal data and which data subject the data relates to. Therefore, to meet the data privacy requirements, you must map properties containing personal data to corresponding data subjects, and implement a logic to serve the data subject's requests related to its personal data, such as requests for information or deletion. To meet these goals, follow the instructions provided in the Developer Guidelines for Data Privacy.


Security

The Configuration service is a container for your project-specific configuration properties. You control the data stored in the Configuration service, and only you know whether the property contains personal data and which data subject the data relates to. Therefore, to meet the data privacy requirements, you must map properties containing personal data to corresponding data subjects, and implement a logic to serve the data subject's requests related to its personal data, such as requests for information or deletion. To meet these goals, follow the instructions provided in the Developer Guidelines for Data Privacy.


  • Send feedback

    If you find any information that is unclear or incorrect, please let us know so that we can improve the Dev Portal content.

  • Get Help

    Use our private help channel. Receive updates over email and contact our specialists directly.

  • hybris Experts

    If you need more information about this topic, visit hybris Experts to post your own question and interact with our community and experts.