Customization - Extensibility PDF

Entity extension considerations Describes customization options using the Application Dictionary or Configured Commerce.NET objects and methods. Suggest Edits Configured Commerce is designed to be highly configurable and extensible to accommodate a multitude of business needs. For exa...

Entity extension considerations Describes customization options using the Application Dictionary or Configured Commerce.NET objects and methods. Suggest Edits Configured Commerce is designed to be highly configurable and extensible 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. Extension options Configured Commerce has two ways in which to extend the entities within the platform. This can be done one of the following ways: Using the Application Dictionary Using Configured Commerce.NET objects and methods Use the application dictionary 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: Users of the Admin Console Developers using Configured Commerce.NET objects and methods  Configuration of Integration jobs Note Only basic types such as Boolean and Strings can be stored using application dictionary control types. Use Configured Commerce.NET objects and methods 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. Use custom properties 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 allows you to 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. Does the data need to be managed in Configured Commerce? Does it need to be displayed in the Storefront or should the data only be managed in the ERP or PIM? If the data is not required as described above, you should consider not storing it in the platform and keeping it in an external system. Does Configured Commerce provide a standard property that can store this data? Each Configured Commerce object provides quite a few properties and by default, some of them are not visible in the Admin Console. You can view them by enabling Master Edit Mode from the Debug Tools menu. Once that mode is enabled, you will see more properties displayed on the various detail pages. If a standard property cannot be found, can the data be stored on one of the standard properties that is not currently in use? This might seem odd, but there may be standard properties not currently being used. If you find a standard property with the correct data type, you could store the data in that property. The name of the property won't match the data, but the performance benefits could outweigh the inconsistency. 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. Database schema 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 Configured Commerce Application Dictionary. AppDict.PropertyConfiguration Used to store the custom property definition. This custom property record is associated with the AppDict.EntityConfiguration table. Requ Column Data Type Description ired Unique The unique Id Yes Identifier identifier. The unique identifier of the EntityConfiguratio Unique configurations Yes nID Identifier used for entities. The unique name of the Name nvarchar(256) Yes property used in code. ParentProperty nvarchar(256) No  The label used Label nvarchar(256) to describe the No property. The class nvarchar(204 definition that ControlType No 8) represents the UI control. Identifies if the IsRequired bit property is No required. Identifies if the property is IsTranslatable bit included in No translation services. The string used nvarchar(204 HintText for contextual No 8) help. The date and datetimeoffs time the CreatedOn Yes et(7) property was created. The username CreatedBy nvarchar(100) used to create Yes the property. The date and datetimeoffs time the ModifiedOn Yes et(7) property was modified. The username ModifiedBy nvarchar(100) used to update Yes the property.  The string used ToolTip nvarchar(256) as a description No to the property. The underlying nvarchar(204 data type used PropertyType No 8) to store the property value. Identifies if it is IsCustomPropert bit a custom Yes y property. Identifies if the property can be viewed when CanView bit Yes editing or viewing the entity details. Identifies if the property can be edited when CanEdit bit Yes editing or viewing the entity details. AppDict.EntityConfiguration Used to store the entities that can be used and extended within the platform. Requ Column Data Type Description ired Unique The unique Id Yes Identifier identifier. The name of the Name nvarchar(256) Yes entity. nvarchar(204 The description Description No 8) of the entity.  The label used to Label nvarchar(256) describe the No entity. The label used to describe the PluralizedLabel nvarchar(256) No entity when in a list. DisplayNameFor nvarchar(102 No mat 4) nvarchar(204 InstructionalText No 8) The date and datetimeoffs CreatedOn time the property Yes et(7) was created. The username CreatedBy nvarchar(100) used to create Yes the property. The date and datetimeoffs ModifiedOn time the property Yes et(7) was modified. The username ModifiedBy nvarchar(100) used to update Yes the property. Identifies if an object from the CanView bit Yes entity can be viewed. Identifies if the CanEdit bit entity can be Yes edited. Identifies if an CanCreate bit Yes object from the  entity can be created. Identifies if an object from the CanDelete bit Yes entity can be deleted. AppDict.PropertyPermission 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): ISC_System ISC_Integration ISC_Admin ISC_ContentAdmin ISC_User ISC_ContentApprover ISC_ContentEditor Requ Column Data Type Description ired Unique The unique Id Yes Identifier identifier. The unique identifier of the property PropertyConfiguratio Unique configuration Yes nId Identifier associated with the entity. The role name RoleName nvarchar(256) allowed to Yes interact with the property. datetimeoffs The date and CreatedOn Yes et(7) time the  property was created. The username CreatedBy nvarchar(100) used to Yes create the property. The date and datetimeoffs time the ModifiedOn Yes et(7) property was modified. The username ModifiedBy nvarchar(100) used to Yes update the property. Identifies if the property can be CanView bit viewed when Yes editing or viewing the entity details. Identifies if the property can be edited CanEdit bit Yes when editing or viewing the entity details. dbo.CustomProperty Used to store the values for a given record of an extended entity. Colum Requ Data Type Description n ired  Unique Id The unique identifier. Yes Identifier ParentI Unique Unique Id of the record Yes d Identifier that has been extended. The name of the custom Name nvarchar(100) Yes property. nvarchar(max The value of the objects Value Yes ) custom property. Create datetimeoffs The date and time the Yes dOn et(7) property was created. Create The username used to nvarchar(100) Yes dBy create the property. Modifie datetimeoffs The date and time the Yes dOn et(7) property was modified. Modifie The username used to nvarchar(100) Yes dBy update the property. SQL table name of the ParentT nvarchar(100) entity that has been Yes able extended.