Application Dictionary data scheme

Optimizely Configured Commerce is designed to accommodate a multitude of business needs. For example, an SAP ERP implementation stores customer data which includes organizational code. Configured Commerce does not include an organizational code on customer records. Therefore, there is a need to extend the Configured Commerce customer entity to map ERP properties to Configured Commerce properties.

Configured Commerce has two ways in which to extend the entities within the platform. This can be done one of the following ways:

The entities that define the blueprint of the digital commerce objects needed to operate the platform can be extended using the Admin Console. Additionally, security permissions for fields are also managed from the Application Dictionary. Extending entities within the Admin Console provides a means to enrich the commerce objects with additional data. These fields, or properties, are then populated using any of the following ways:

It is important to note that only basic types such as Boolean and Strings can be stored using application dictionary control types.

Custom properties can also be defined using code. This is usually done within a Handler of the Chain of Responsibility. Defining custom properties in code has the added advantage of storing complex types such as developer defined objects. The limitation here is that those custom properties cannot be edited within the Admin Console.

From an implementation perspective, custom properties are stored as string values separate from the standard Configured Commerce objects, like Customer and Product. This flexibility in structure lets you store a wide range of content, but can also cause a loss in application performance. Before using a custom property to store data, you should make the following considerations regarding the data and be certain that a custom property is the solution.

Custom properties may still be the correct solution. If this is the case and you start to see performance degrading for requests that retrieve those custom properties, you should consider creating a custom endpoint. The endpoint could be used to return only the custom properties you actually need. For example, on the product detail page, you could have a request that retrieves custom properties for that product. This request would be separate from the main product API request that retrieves the product data. If this solution does not work, you could consider creating a custom database table to store the custom properties. The table could be designed specifically for those custom properties, rather than having a table full of string values.

Always consider the need for custom properties. They are a useful and flexible feature, but they can also cause a loss in application performance. Other solutions are available to help offset this loss.

The following tables are used for extending the entities and objects within Configured Commerce. Specifically these tables represent the schema used for custom properties and security. These entities are managed using the Application Dictionary.

Used to store the custom property definition. This custom property record is associated with the AppDict.EntityConfiguration table.

Used to store the entities that can be used and extended within the platform.

Used to store the permissions related to any custom properties added to the existing entities. By default the following roles are automatically assigned to custom properties (Property Configurations):

Used to store the values for a given record of an extended entity.