Create a Data Model

Learning Objectives

After completing this unit, you’ll be able to:

• Describe the importance of the system of record table.
• Explain how data is stored for a Salesforce B2C Commerce implementation.
• List the questions you need to ask to determine what data needs to be shared between sites.
• List what data you should document for each data type.
• Describe what you need to document for legacy data migration.

What’s the Data Model?

The data model is a key part of the technical solution design. To make decisions related to the merchant’s data model, you must must first have a high-level understanding of merchant data, such as:

• How data is stored in B2C Commerce
• What data can be shared between sites

Where B2C Commerce data is stored depends on the architecture. For the client server model, data is stored in the server or on the client.

Server Side Data

Here’s what you need to consider for server side data.

Session Data

Session data functionality is available through the script API class: dw.system.session. If you need it to reference a persistent business object, use its identifier instead. Session attribute values can only be these:

• Primitive data types (Number, String, Boolean, Date)
• B2C Commerce value types (Money, Quantity, Decimal, Calendar)

Use .privacy instead of .custom, because .custom is used for personalization; .privacy is cleared when the customer logs out, but .custom is not.

Document the size limits.

• Strings are limited to 2000 characters.
• Session is limited to 4000 characters in total size.
• Work-around for these limits is to use string compression like lz-string.

Persistent Business Objects

You can extend system objects (for example, Basket, Campaign, Category, Content, SitePreference, or ServiceConfig) to collect more information via dw.object.ExtensibleObject. System objects with sensitive data inherit dw.customer.EncyptedObject. The storefront is read-only with the exception of customer, basket, and order data objects.

Here are some other data considerations.

• Generic mapping
  • Offers fast read-only access to a large volume key-value store
  • Not suitable for frequently modified data
• File system
  • Built-in WebDAV server and HTTP client-side access
  • Can be written or updated only from jobs
• Custom cache
  • Used for speeding up access to third-party/volatile data
  • Shared across sessions
  • Specific to each application server
  • Data can be purged before it expires when the cache size becomes too big

Custom Objects

Document the custom objects used.

• Site-specific or organization-wide
• Keep quotas in mind.
  • object.NonStageableCustomObjectPO (400k)
  • object.StagableCustomObjectPO (400k)

Documentation

Attach documents like these to the specification (or provide a link to them).

• Data mapping document
• Custom attribute matrix
• Custom object matrixes

Client Side Data

Client side data is about the shopper’s browser. That means data that’s stored with cookies and local, session, and cache storage. Here are some considerations.

• Cookies
  • Use for personalization, not for sensitive (PCI/PII) data
  • Sent with every (including static resources) request; excessive use of cookies can cause performance issues due to traffic
• Local storage and session storage
  • Synchronous storage that blocks the main rendering thread
  • 5MB size limit, can contain only strings
  • Not accessible from web workers and service workers
  • Session storage is tab specific
• Cache storage
  • Cache for requests/response data for web/service workers; large size limit determined by browser
• IndexedDB
  • Asynchronous storage of structured data including files/blobs for web/service workers; large size limit determined by browser

Data Shared Between Sites

Ask the merchant these questions to help figure out what data needs to be shared between sites.

• Is the locale product assortment specific for country pricing and marketing?
• Is the content for each country/region in the native language?
• Are there country-specific features that include payment methods, social media, affiliate integration, or the implementation of certain legal restrictions?
• Is the content managed per country or is it shared across the countries and localized into different languages?

You can share these data objects between sites.

Document the Data Model

Your job is to document the data model and map it to the data. It’s a good idea to document all of the data in a mapping document as opposed to creating separate mapping documents per interface. To learn how, take the Salesforce B2C Commerce Client Analysis Trailhead module, the “Understand Your Client’s Data Model” unit.

Catalog Data

The merchant’s catalog structure should follow the B2C Commerce best practice, with a catalog divided into two separate catalogs.

• Product catalog: Provides the same structure as an external system of record for the merchant’s products. This catalog isn’t assigned to a site. It owns the products to be merchandised and mirrors the organization of the inventory, fulfillment, or product management systems.
• Storefront catalog: This is where you create categories that appear on the storefront. Products must be assigned to storefront categories to appear on the storefront. A storefront has just this one catalog. B2C Commerce uses the category structure for storefront navigation.

Each catalog is more robust because each can be reloaded separately without affecting the other in the event of an emergency. This approach makes it easy to create new sites that use the same product catalog.

Add a table like this to your technical spec.

Price Book Data

Document price book data.

Inventory Data

Admins typically import inventory data into the B2C Commerce system, instead of creating inventory records in Business Manager. Make sure you document the system that provides the inventory update files. The feed must be written in B2C Commerce schema for direct import into staging and production instances. 

Customer List Data

Document the customer list that will be created for the implementation.

Order Data

Document the system that contains legacy orders. This is where legacy orders will be imported from prior to when the site goes live. Document the prefix that will be used for production orders.

Content

Create a content matrix and link to it from the technical spec. See the Document Content Assets and Content Slots section in the Project Documentation for Salesforce B2C Commerce Functional Architects Trailhead module.

Shipping and Payment

Document the merchant’s shipping providers, shipping methods, and payment providers used for the implementation.

Custom, Localizable, and Site-Specific Attributes

Creating a custom attribute doesn’t add a column in the underlying object database table, for example, in the product database table. Custom attributes, localizable system attributes, and site-specific system attributes are stored in additional attribute values (AV) tables, for example in the PRODUCT_AV table. 

• AV table records contain a compound key of [corresponding SystemObjectID_attributeName_Locale/site] for each attribute.
• Database queries for custom attributes perform a table JOIN between main and AV tables, which bypass the ORM cache. It’s best to use nonlocalizable and non–site-specific system attributes for faster database queries.
• Custom Objects are handled the same way, so use them with care. The best practice is to always get/find the custom object by the value of its key attribute.

Legacy Data Migration

Migrating legacy data means moving data that’s currently handled by the merchant’s existing implementation into the B2C Commerce implementation. You need to scope the effort first, so you can plan the steps. Start by documenting the data you intend to migrate and its volume, including but not limited to the following.

Next, document the plan’s timeframe in a table like this.

Next Steps

In this unit, you learned how to document various settings and data types. Next, learn how to document the architectural landscape.

Resources

• Trailhead: Salesforce B2C Commerce Client Analysis
• Trailhead: Salesforce B2C Commerce for Merchandisers
• Trailhead: Project Documentation for Salesforce B2C Commerce Functional Architects