<Client Name>

Technical Specifications Document

Commerce Cloud B2C

<Date>

Ver0.1
 Revision History
Date Description Author
1 Overview 6

1.1 Document Reference 6

1.2 SFCC data samples 7

1.3 System of records 7

1.4 Disclaimers 8

1.5 Open Items 8

1.6 Glossary 8

1.6.1 SFCC terms 8

1.6.2 Commerce Cloud Digital terms 14

1.6.3 <Client name> terms 14

2 SiteGenesis 14

2.1 Description 14

2.2 Responsive Design 15

2.3 Gap analysis 15

2.4 Best Practices 17

3 Development and build process 19

3.1 Build process 19

4 Site configurations 20

4.1 Site(s) 20

4.2 Catalog 21

4.3 Cartridge 22

4.4 Pricebook 22

4.5 Inventory 23

4.6 Shipping 23

4.7 Customer list 23

4.8 Order 23

4.9 Service Framework 23

4.10 Content 24

4.11 Redirect 24

4.12 SEO 24

4.13 WebDav and SFTP 25

4.14 Data Retention 25

4.15 API quota 25

4.16 Disaster Recovery 25

5 Legacy Data Migration 28

5.1 Customer 29

5.2 Order 29

5.3 Promotion 29

5.4 Payment instrument 29

6 Architecture and Data Flows 30

6.1 Architectural consideration 30

6.2 Data mapping 31

6.3 Custom attributes 31

6.4 Custom objects 31

6.5 Data feeds and replication schedule 31

7 Integrations 32

7.1 Third party integrations 33

7.2 ISD 34

8 Key customizations 34

8.1 Backend customization 34

8.2 Frontend customization 34

8.3 Business Manager customization 34

9 Security 35
10 Testing 36

10.1 UAT 36

10.2 Performance testing 37

10.2.1 KPI 37
1 Overview

This document describes the technical aspects of the SFCC implementation for <Client name>.com.
Specific sections in this document cover the SFCC SiteGenesis reference application, features used from
SiteGenesis, features from SiteGenesis that were omitted, additional custom functionality, integrations
with 3rd party vendors, and system topography and configuration.

This document serves as reference for determining scope for particular features throughout all aspects
of the implementation. This document serves as a technical reference for <Client name>.com and for
Commerce Cloud Digital .

1.1 Document Reference

Site Genesis documentation: https://xchange.demandware.com/community/roadmap-and-

releases/documentation

Confluence: <Project documentation>

SFCC Infocenter: https://documentation.demandware.com/DOC1/index.jsp

ISD: <TBD>

FSD: <TBD>

Data Mapping:<TBD>

Operating on SFCC worksheet:<TBD>

1.2 SFCC data samples

Commerce Cloud Digital will create a data sample file for third party feeds and provide the details to the
respective third parties. These XML input files will be validated against the SFCC XML
schema(https://documentation.demandware.com/DOC1/topic/com.demandware.dochelp/DWAPI/xsd/Schemas.html)

Feed Function File Location

Customer

Order

Catalog

Inventory

1.3 System of records

Data Type Location System of Batch/Real time Change Notes

Record Frequency

Products

Categories

Promotions

Images

Inventory

Order

Pricebook

Customers
 Content

1.4 Disclaimers

<TBD>

1.5 Open Items

Type Description Owner Date

1.6 Glossary
1.6.1 SFCC terms

Source: https://documentation.demandware.com/DOC1/index.jsp?topic=%2Fhelp%2FGlossary
%2FaGlossary.html&cp=0_19

Bookmarklet
Bookmarklets are a deprecated feature. The Storefront Toolkit offers improved functionality in the same
areas as the bookmarklets.
Business Manager
The primary tool used to configure Commerce Cloud Digital and customer storefronts.
Business Object
Represents data such as products, prices, customer names, addresses and credit card information that is
entered via or displayed on a storefront.
Cartridge
A collection of Digital resources that is used as a flexible deployment mechanism for new functionality. A
cartridge can contain customer data, product and catalog data, pipelines, pipelets, form definitions,
scripts, templates and server connection files.
Content Assets
The portion of storefront pages (for example, HTML snippets and images) that must be regularly
updated to keep the site fresh.
Content Slot
Content slots can be scheduled to display products, categories, content assets or static HTML in your
storefront. A content slot is tagged in storefront ISML templates using the <isslot> tag.
Content Delivery Network
Service used to manage content distribution for a site.
Control Node
UX Studio development element that modifies the execution path of a pipeline. For example, in creating
loops, calling other pipelines or creating alternative pipeline branches whose execution depends on
certain conditions. Control nodes include start nodes (where the execution path starts) and end nodes
(where the execution path ends).
Experience
An experience is a promotion, content slot, or sorting rule that is added to a campaign.
FQDN
FQDN is an acronym for Fully Qualified Domain Name. A complete domain name consisting of a host,
the second-level domain, and the top-level domain. For example, www.mystore.com is an FQDN. www
is the host; mystore is the second-level domain; and .com is the top level domain.
Geolocation
The store geolocation feature is a database of zip codes to identify store location for store locator
features on your storefront. Data must be imported per instance.
The IP address lookup geolocation feature is a database that maps the IP address of a logged in
customer to a geographical region. This feature can be used to create customer groups based on
geography. You can also use the IP address lookup via API for geotracking or other purposes. This
database is shared by all instances on a POD and can't be updated or changed.
Impression
For active data, a product impression is the number of times a product is viewed in minimal detail on a
page by a customer in your storefront. The specific interpretation of this is up to the merchant and
depends upon how the isobject tag is implemented in your ISML templates. Product impressions are
tracked and aggregated together. A product impression isn't used to calculate any other active data
values. See also View.
Interaction Continue Node
UX Studio development element that processes a template based on user action via a browser. Both the
Interaction Continue node and the Interaction node call templates that process requests from the
storefront. However, an Interaction Continue node uses a form definition to handle multiple types of
input from the storefront, while an Interaction node processes a particular storefront request such as
when the consumer clicks the mini-cart.
Interaction Node
UX Studio development element that generates responses to requests or interacts with the client.
Interaction nodes call templates to generate the response sent back to the client. Both the Interaction
Continue node and the Interaction node call templates that process requests from the storefront.
However, an Interaction Continue node uses a form definition to handle multiple types of input from the
storefront, while an Interaction node processes a particular storefront request such as when the
consumer clicks the mini-cart.
Internet Store Markup Language (ISML)
Digital proprietary extension to HTML that developers use to create Digital templates.
Jump Node
UX Studio development element that lets a pipeline forward a request to another pipeline.
Key-Value Pair
When a pipeline is processed, the Pipeline Dictionary accepts and stores parameters in key-value pairs.
These parameters are used to exchange data between pipelets. They are also used by the Template
Manager to display pipeline activity in the storefront (via the isprint tag).
Local Include
Use of the <isinclude url=""> syntax in an ISML template to include content from another template.
Model-View-Controller (MVC) Architecture
Software architectural model whereby the underlying data (model) is separate from the user interface
(view), so that changes to the user interface don't affect data handling, and data can be reorganized
without changing the user interface. The decoupling of data access and business logic from data
presentation and user interaction is facilitated by a controller.
Page Caching
Page caching is the temporary storage of data that is likely to be used again. Page caching improves a
site's overall performance and minimizes customer wait times, by storing key pages in the cache that
change little and need to be displayed immediately. The biggest challenge, when determining which
pages or portions of pages to cache, is to balance the need for personalized dynamic pages against short
response times.
Page Cache Management is configured and managed in the Business Manager. The Digital Web Server
maintains separate caches for pipeline requests and static content. Page caching can be enabled,
disabled or invalidated on a per web site basis.
Pipelet
Defines an individual business function within a Digital pipeline. Pipelets are part of the Digital API. You
can also define specific types of pipelets such as the following:
Script: to call your custom Digital script file
Eval: to evaluate data in the Pipeline Dictionary
Assign: To assign values within the Pipeline Dictionary
Pipeline
A pipeline is a logical model of a particular business process, similar to a flowchart. UX Studio provides a
visual representation of the process within the Eclipse Integrated Development Environment (IDE).
Pipeline Dictionary
Used as a data transport mechanism along the flow of a pipeline. It transports data that is entered via or
displayed on a browser from one specific business function to another.
Point of Delivery (POD)
A point of delivery is a collection of computing, networking, and storage services that combine to host a
multi-tenant SAAS application.
Primary Instance Group (PIG)
A primary instance group is the Production Instance, Development Instance, and Staging Instance for
each customer realm. A primary instance group enables full lifecycle support for testing and replication
for a customer storefront.
Realm
A realm is a collection of resources allocated to a customer storefront. Typically, this includes a primary
instance group and one or more sandbox instance groups.
Remote Include
Use of the <isinclude url=""> syntax in an ISML template to include content from another pipeline.
Sandbox
Digital instance used by developers when coding and testing the storefront.
Secondary Instance Group (SIG)
A secondary instance group is a collection of three or more sandboxes associated with a realm for a
specific customer or partner.
SiteGenesis
Digital's prebuilt application that merchants can use as a basis to develop their customized site.
Standard catalog
A catalog that isn't assigned to a site. Standard catalogs are usually organized to make it easy to manage
products. These catalogs can match the organization of inventory or ordering systems. See also
Storefront Catalog.
Static File
A file that doesn't change unless it's replaced, such as a product image, resource file or message file.
Static Page Content
Web page elements such as HTML headings and text, images called with HTML tags, and any other part
of the page that is unaffected by the ISML conversion process.
Stop Node
UX Studio development element that functions as an emergency break, comparable to an exception
within pipelets. If you want to stop all pipelines, use a stop node.
Storefront
Your online ecommerce site powered by Digital. A single instance can include multiple storefronts.
Storefront Catalog
A catalog assigned to a site. The structure of a storefront catalog determines the menu navigation
structure and search refinements for the storefront. A storefront catalog can be assigned to multiple
sites. However, a site can only have one catalog assigned to it. For SiteGenesis, this is the storefront-
catalog-en catalog. Salesforce recommends including "storefront" in the name of your storefront
catalog. You can also see which catalogs are storefront catalogs on the Catalogs page. Storefront
catalogs have one or more sites listed in the Site Assignments column of the catalog list. See also
Standard Catalog.
Template
Templates define how data and page information is transformed into the HTML that is rendered on a
browser, using Cascading Style Sheets (CSS) for page layout and styling and the forms model for data
display and verification.
Digital uses templates to generate dynamic HTML-based web pages for responses sent back to the
client. Templates are created in the Internet Store Markup Language (ISML), a Digital proprietary
extension to HTML.
User Session
A user session is the time that a user is logged on to the storefront. The session timeout is how long a
user is logged into the site before being asked to log in again. For Digital, the session times out
automatically after 30 minutes of inactivity. The automatic time out is set by Digital and can't be
changed or configured. If there is consistent activity, the session is canceled after six hours and a new
session is created for the user.
Digital uses templates to generate dynamic HTML-based web pages for responses sent back to the
client. Templates are created in the Internet Store Markup Language (ISML), a Digital proprietary
extension to HTML.
View
For active data, a product view is counted when a product detail page is displayed to a site visitor.
Product views are used to calculate Look to book ratio. See also Impression.
Workspace
Eclipse-specific local directory that contains a developer's project files.

1.6.2 Commerce Cloud Digital terms

<TBD>

1.6.3 <Client name> terms

<TBD>

2 SiteGenesis
2.1 Description
SiteGenesis is an out of the box standard Storefront implementation that comes with the SFCC
eCommerce platform. SiteGenesis features include, but are not limited to, the following:
 ● Global Header and Footer
● Global Navigation (driven by Site Catalog)
● Homepage
● Category Landing page
● Sub-Category landing page with product grid
● Search results page with product grid
● Refinements on Category landing pages or search results page
● Product Details page
● Mini-cart in global navigation
● Shopping cart page
● Shipping page (shipping address and shipping method)
● Billing page (billing address and payment details)
● Order Review page
● Order Confirmation page
● Order Status page
● Registration
● Login (login, checkout login, password retrieval)
● My Account (Profile, saved address, saved payment details)

2.2 Responsive Design

SiteGenesis uses responsive design as part of its mobile solution offering. Responsive design is a CSS
design pattern that allows the same HTML pages to look and behave differently depending on the size of
the viewport on which they are being viewed, i.e. the size of the device display being used to access the
site. The following viewports are included in scope for this implementation:

Small (Smartphones) - 320 px - 479 px (Fluid)

Medium (Hybrid, Small tablet & Smartphone) 480 px -767 px (Fluid)

Large (Tablet) 768 px - 959 px (Fixed)

Standard (Desktop) 960 px + (Fixed)

2.3 Gap analysis

ITEM DETAILS

Upload File Size Limits <TBD>

Dynamic Form Limit <TBD>

Text Area Character Count Limit <TBD>

Dynamic Display of Char Count below text area <TBD>

Countries and States allowed (Incl. AFP, APO) <TBD>

Validation of Zip Codes <TBD>

Display of Pricings (VAT, extended, wholesale, <TBD>

discounted)

Site Geo Location based Switching <TBD>

Site Login Session Timeouts - 30 minutes? <TBD>

404 Errors Page for Site(s) <TBD>

General Form Design Standards <TBD>

Order Numbers - Prefix configuration <TBD>

Display of States Vs Provinces <TBD>

Max Basket Item count needed - 999 or 9999 <TBD>

Max items visible in Mini cart <TBD>

Floating Headers ( if any) <TBD>

Date Picker (if used) - Default Date, Blanked Dates, <TBD>

 number of months to display

PDF downloads – location <TBD>

Replacement for Hardcoded Phone DW Numbers <TBD>

Data Retention Plan <TBD>

Pagination Requirements with performance consideration <TBD>

(if not already specified)

2.4 Best Practices

SFCC offers a number of best practices guidelines for developers. COMMERCE CLOUD DIGITAL always
makes the best possible effort to follow these guidelines. The latest best practices guidelines are located
here:
https://info.demandware.com/DOC1/topic/help/CodingStyles/SiteGenesisConventionsandCodingStanda
rds.html

The following are the general coding conventions:

All HTML pages, CSS and JavaScript must be valid. To ensure this, use browser plug-ins such as
HTMLTidy, validate HTML against XHTML schema).

No references to non-existing URLs in the HTML (no 404 errors due to non-existing CSS, JavaScript or
images).

The application must not throw errors for any valid storefront links.

No use of deprecated APIs (check deprecation logs).

Always generate URLs (to pipelines or static content) using platform methods (for example,
URLUtils,MediaFile.url, $url()$-syntax inMarkupText). Never hard-code URLs. SFCC reserves the right to
change the format in the future. Custom code cannot make assumptions about the format; i.e. it must
not parse the URL to extract values. For example, if URL Rules are enabled, the number of segments may
vary and URL parameters become part of the path information. The only safe operation (for example,
with client-side JavaScript) is to append additional parameters. Be sure to check if this is the first
parameter to append (i.e.url=url+"?param=value"orurl=url+"&param=value"). For convenience, use the
methodapp.util.appendParamToURL(url,name,value).

References to custom attributes must be robust; i.e. the definition of the attribute is checked before the
value is accessed.

Use XML syntax for ISML tags without a closing tag. For example, end the tag with"/>"(for
example,<isinclude template="foo"/>).

The prefix "dw" is reserved for use in URL parameters for system features (for example, SFCC form
handling). Do not use parameter names that begins with "dw" in custom code.

End all JavaScript/SFCCScript lines of code with ";" (semicolon), even if this is technically not required.

Pass URL parameterformat=ajaxfor AJAX calls with HTML response andformat=jsonfor AJAX calls with a
JSON response. This is needed to safely identify the type of request and return an appropriate response
in the global error handling pipeline.

Naming Conventions

Naming conventions make programs more understandable by making them easier to read. They can also
give information about the function of the identifier.

Type Description Owner

Classes, All identifiers are in mixed case with a capital first NavigationHelper
Namespaces letter.
Class names should not start with underscore _ or
dollar sign $ characters, even though both are
 allowed.
Functions All identifiers are in mixed case with a lowercase getBackground();
first letter. Internal words start with capital letters.
Variable
names should not start with underscore _ or dollar
sign $ characters, even though both are allowed.
Variables The variable name is followed by a colon and the var myName :
type definition. Note that the colon is enclosed by String;
blanks. var myWidth :
Number;

Development Best Practices

COMMERCE CLOUD DIGITAL uses SFCC certified developers and architects who are well-trained in best
practices regarding coding standards and site administration. Here is a small subset of best practices we
strive to follow:

● MVC design patterns

● 2-factor authentication for code deployment
● Loading of JS files in the footer, where possible
● Use of separate JS files for different sections of the site
● Code reusability
● Use of modules
● Use of remote includes to harness different caching strategies for different sections of pages
● Use of forms framework
● Use of AJAX to reduce initial page load times
● Use of Revealing Module pattern in JS
● Use of jQuery and jQuery UI
● Use of SCSS
● Uther SiteGenesis guidelines
● Error/exception handling and redundancy for communications with external vendors
● SEO and accessibility best practices
3 Development and build process
3.1 Build process

<Client name> project uses the Jenkins build server. The build process for the project is automated. The
following steps are performed during a build:

● Download the code from the GIT Repository

● Configure the build process on Commerce Cloud Digital Jenkins server
● The build process will create the cartridge and upload it to the staging server (2-factor
authentication is enabled)
● The build process will activate the version of the uploaded code
● The build process will send out emails about the new build

In order to have a complete code/data build on staging and development, site configuration must be
imported manually by the build responsible on staging and replicated to development daily.

4 Site configurations
4.1 Site(s)

An Instance contains a database instance and an associated codebase. The instance can be logically
divided into 1 or more sites. The database contains global data, accessible to all the sites, as well as site-
specific data. For example, a product catalog can be shared across multiple sites, or be specific to only 1
site. Code and data on SFCC platform is logically divided for an easy extended site created for multiple
Locales.
<Client name>.com project will have below sites configured :

Site Currency Locale Domain

4.2 Catalog

<Client name> catalog structure will follow SFCC best practice. The catalog will be divided into two
separate catalogs. This separation allows for increased robustness as each catalog can be reloaded
separately, without affecting the other one, in the event of an emergency.
Additionally, this approach allows for easier creation of additional storefront sites. The new sites can
leverage the same master catalog, without creating duplicate entries.

master catalog– contains all products (variation masters, variants, stand-alone products, bundles)

site catalog – contains all the remaining elements such as category definition, product to category
assignments, recommendations. The storefront catalog will drive site navigation.

Catalog Name Comment

<TBD> <TBD>

<TBD> <TBD>

This separation allows for increased robustness and scalability as each catalog can be reloaded
separately, without affecting the other one, in the event of an emergency. Additionally, this approach
allows for easier creation of additional storefront sites. The new sites can leverage the same master
catalog, without creating duplicate entries.

4.3 Cartridge

Cartridge path:<TBD>

Cartridge:

Cartridge name Link(Y/N) Integration Comment

<TBD>

<TBD>
4.4 Pricebook

Country name Pricebook id Site assignment currency

<TBD>

<TBD>

4.5 Inventory
<TBD> System is providing the Inventory Update files. Feed will be provided in SFCC schema for direct
import on SFCC staging and production environment:

Following Inventory lists will be used for <Client name>.com

Inventory List id Site assignment

4.6 Shipping
<TBD> is the shipping provider for <Client name>.com project. Following shipping methods will be used
for this implementation.

4.7 Customer list

Below customer lists will be created for this implementation:
<TBD>
4.8 Order
Legacy orders will be imported from <TBD> system. Following prefix will be used for production orders
<TBD>
4.9 Service Framework
Commerce Cloud Digital provides a web service framework that allows you to manage calls to
unavailable web services, cap the number of calls to a web service, and analyze web service
performance. Following services will be configured for this project:

<TBD>

4.10 Content
Content asset matrix for this project is as below
<TBD> provide link to a file or confluence page
4.11 Redirect
Host name alias and redirects will be setup using SFCC best practices, example of host name alias and
redirect is as below:
<TBD> Please provide the host name alias and sample redirect setup
4.12 SEO
Standard SFCC SEO features and best practices will be used when building the <Client name> sites.
<Client name> will be trained on how to use these features during MTS training, and will be responsible
for populating any SEO configuration & content <Client name> will utilizes internal resources for SEO
guidance.

SEO feature description

SEO Standard SEO attributes (Page Title, Page URL, Page Keywords, Page
Attributes Description) will be populated for all Products /
Categories / Content. Site wide rules will be used, with overrides at the
individual level being manually populated by <Client name> merchandising
team.
SEO SFCC URL rules will be used to render SEO-friendly URLs for all Products /
Friendly Categories / Content. <Client name> team will
URLs be trained on how to configure these rules, and how to override them for
individual products / categories / content.
XML Standard SFCC XML Sitemaps will be used, and <Client name> team will be
Sitemap trained on how to configure them.
Image Alt Image Alt tags will be rendered based on product names
Tags
Robots.txt Robots.txt will be configured using standard best practices. <Client name>
team will be trained on how robots.txt is generated and configured.
URL Standard SFCC URL redirects (301/302) will be used. <Client name> team will
Redirects be trained on how to create these redirects.

Canonical <Client name> team will use standard Site Genesis URL canonicalization to
URLs ensure products and categories have a canonical URL
 <H> Tags Standard <h1> tags will be used on the PDP / Category page

4.13 WebDav and SFTP

<Client name> will deploy an SFTP site to facilitate file transfer between SFCC <Client name> various
vendors and systems. The following login, home directory, and directory structure will be used.

Files will be imported per-site, and use a naming convention to distinguish one site from another.

<TBD>: Provide a screenshot or table for the SFTP folder structure.

4.14 Data Retention

Following data retention setting will be used for go live:

Data type Data purge policy

Orders <TBD>
Payment <TBD>
Customer Profile <TBD>

Files Clean Up:

Import and export files will be cleaned up.
Log files will be cleaned up.
All files will be cleaned up and purged every two weeks <TBD>.

4.15 API quota

<TBD>Please identify and mention about potential quota issues e.g. more number of HTTPClient call
during order Submit call etc.

4.16 Disaster Recovery

Code Backup Schedule: Periodic backup of GIT repositories for the purposes of disaster recovery.

In the current setup, the GIT repository does not need a rigorous backup schedule because every clone
serves as a backup of the remote.
User or provider must ensure that they have all external SFCC IPs in their firewall access rules for easier
disaster recovery implementation. Not having all external IPs in your firewall rules will delay disaster
recovery.

As a partner, we will guide the client to add all SFCC outgoing POD IP addresses for PODs in their region
to their firewall rules to allow for connections to back-end systems in case of a Disaster Recovery
Situation, not just those belonging to PODs they are currently associated with.

All the information is in the SFCC knowledgebase.

FAQ about the Digital Disaster Recovery (DR) Procedure from DWRE in case of a Server Outage

Source: https://support-demandware.force.com/customer/kA3a0000000XQ0X?
srPos=4&srKp=ka3&lang=en_US

Question: In case of a DR event, will the secondary POD be newly constructed or is it already existing
one? Our client is aware of the xchange page containing the POD IP's and have already included these in
their firewall rules.

Answer: The secondary POD is already existing in a different data center, as stated on page 5 of the
attached document (SFCC Grid DR Plan 02282012.pdf).

Question: Who's responsibility is it to change the DNS and on which end?

Answer: You / the customer is responsible to update DNS and notify 3rd party services of the new POD
IP.

"Recovery of any Customer’s externally integrated services such as dynamic name system (DNS) and
fulfillment systems are not included in this DR Plan. It is the Customer’s responsibility to insure the
operation of these integrated systems to the Secondary POD."
Question: What (third party) integrations would not work, for example and what is the process to get
them up and running on the secondary POD?

Answer: Each customer should know which 3rd party integration they use, and notify them about the
move to the secondary POD.

Question: Based on trainings or past experience, what is the usual time between identifying a DR event
and releasing the secondary POD for the

client after testing has been done?

Answer: A DR event is downtime without any known and reasonable recovery time. This determination
is somewhat subjective. For example, we may know within a very short period of time (i.e. < 1 hr) that a
POD will not be recoverable for a very long time (i.e. power/network at DC was physically cut
inadvertently by construction, etc.) and we will commence DR procedures immediately. However, we
will also wait a period of time (several hours) if the issues is known and reasonable recovery time in
known; i.e. if the time to recover is shorter than the time to move all realms on the impacted POD to
their respective DR locations.

Question: Please expand on what testing SFCC will perform before releasing the secondary POD realm
to the client?

Answer: We test the availability of the SFCC service to the PRD instance on the DR POD for all
customers. The customers are responsible to test their respective custom solution; including Site
functional and their unique external integrations/services. We work with all customers to verify and

resolve any latent networking connectivity issues (if any) specific to the DR POD.

Question: Do the customer data and catalogues get transferred by SFCC on the new POD by SFCC or
how does this process work?

Answer: Yes, this information is carried over as part of the database and file system replication process
that we use.
Question: Where can I find more information about what data is being backed up regularly by SFCC and
on which PIG environments, accordingly? What is the data being backed up that cannot be backed up
via Business Manager? Moreover, how long is it being kept by you and is

there any way to control this?

Answer: It is the customers responsibility to back up data.

Please use these guideline:

https://info.demandware.com/DOC1/topic/help/Admin/Schedulinginstancebackups.html

There is no backup from SFCC, just the explained DR-Process.

Question: How long does it take until the POD where we move to is up and working?

Answer: As disasters are typically complex events with compounding factors, a particular recovery
period is difficult to predict and therefore SFCC makes no representation that recovery is possible in a
set period of time. However, in most cases we would expect recovery within 24

hours and target recovery of the core serve at 8 hours.

5 Legacy Data Migration

<TBD>: Please provide a cutover plan for Legacy data migration including but not limited to the below

items:

Legacy data Sub items Estimated data volume

Catalog Variation Master/Variation Products

 Customer Customer Accounts

Orders Legacy orders

Wishlist Product Lists

Promotions

Any other data

5.1 Customer

<TBD>: Please provide a cutover plan

5.2 Order

<TBD>: Please provide a cutover plan

5.3 Promotion

<TBD>: Please provide a cutover plan

5.4 Payment instrument

<TBD>: Please provide a cutover plan

6 Architecture and Data Flows

6.1 Architectural consideration

The overall architecture was designed in a way to avoid any sort of performance scalability issues. These
include but not limited to the following:
Caching Consideration: Aggressive deployment of SFCC caching has been considered through the various
ISML templates to insure minimum “breaking” of the cache during light and heavy activity levels.

Service framework will be utilized for any external web service call

Batch-Based Transaction Flow: As much as possible data flows such as order history and order
submission to OMS is done in batch mode using SFTP to avoid web service traffic and performance
issues.

Design and development will take place to support future growth.

Although multiple sites is not in scope however solution will be designed to support multiple sites using
SFCC best practices.

General System Architecture as below <TBD: replace this image with implementation specific system
architecture>
6.2 Data mapping

<TBD>Please attach data mapping document or provide a link to it.

6.3 Custom attributes

<TBD> Please provide custom attribute matrix

6.4 Custom objects

<TBD>Please provide custom object matrix

6.5 Data feeds and replication schedule

Jobs would be scheduled in Commerce Cloud (Business Manager).

The table below shows the list of jobs and their corresponding details .

Name Schedule From To Full/Delta Resources

Catalog Import

Pricebook import

Order export

Inventory import

Order status
import
7 Integrations
Commerce Cloud Digital will coordinate all third-party environments including test, staging, and
production environments that directly integrate with the SFCC platform.
Client will be responsible for all business, legal, and financial coordination with third-party providers to
ensure timely availability of each environment complete with sample test data.
Commerce Cloud Digital will integrate all identified third-party systems and services to and from the
SFCC environment.

7.1 Third party integrations

List of all third-party integrations is as below:

Integration type Provider Credentials link Technology Input data Output data
format format

Order <TBD>
Management
 Payment <TBD>

Tax <TBD>

International <TBD>

Shipping <TBD>

<TBD> You may replace this diagram with the implementation specific one.

7.2 ISD

<TBD> Either provide the ISD document link here or provide the complete documentation including but
not limited to the Integration description, Code change details, Vendor details, Site preference,
Input/Output details, Sample request response etc.
8 Key customizations
8.1 Backend customization
8.2 Frontend customization
8.3 Business Manager customization

<TBD> Please provide details of key customizations except 3rd party integration as it will be covered in
the ISD document.

9 Security

The following security considerations will be made:

Deployment of new code and other WebDav access will use two-factor authentication as required by
SFCC. This is required to be in place by launch date.

Storage, transfer, and encryption of sensitive data (CC and Customer Data) Credit Card will be tokenized
via a third-party payment processor. Card CVV is never processed by SFCC infrastructure and instead
sent directly from the browser to the payment processor. No other deviation will occur from DW best
practices.

Elimination of unnecessary third-party access and privilege escalation. This will be completed as is
standard by launch date.

Ability to disable non-core integrations, where possible, as per recommended guidelines.

SSL Certificates are the standard storefront certificates required for HTTPS access to your site during
checkout. These must be signed by a valid signing authority. This process will be managed by the
Technical Architect.

For any external integration or customization built on top of the SFCC Commerce Platform the customer
is responsible for ensuring
PCI-DSS compliance. Common examples include:

External integration to OMS and other services: is it over TLS and with appropriate firewall restrictions?

In regards to firewall rules, customers are responsible for outbound ports they request to be open from
SFCC. Customers should take into account insecure ports and how this may affect their PCI compliance,
please consult with your QSA if there are questions.

Customers should review the need for the requested outbound ports to be open every 6 months and
notify SFCC if those ports are no longer necessary so they can be removed.

Customers are responsible for defining how long they are retaining payment data for. This can be
managed in Business Manager by defining the Payment Information Retention.

Custom exports are encrypted and treated appropriately.

Any customizations are done with an understanding of the possible security ramifications. The customer
is responsible for ensuring that their customizations do not capture credit card or other sensitive
information through insecure means. Clear text storage of credit card

information (including in log files) is never permitted and customers are responsible for complying with
this requirement Vulnerability and Penetration testing is done by an external QSA/ASV.

Maintaining custom logs specific to customer security and access control, i.e. customer using the SFCC
log framework, error, custom error, security or other logs. Custom logs and other security logs should be
downloaded within 30 days and archived by the customer according to the PCI DSS requirement.

Two Factor Authentication must be put in place for code updates (via SFCC Studio) to customers staging
system. This two factor certificate is managed by the customer and they can follow their own security
policies that have in place for code deployments to the SFCC service.
NOTE: This list is not comprehensive – you should consult with your PCI DSS assessor or consultant to
determine all requirements and responsibilities you have to maintain your PCI DSS Merchant
compliance.

10 Testing
10.1 UAT

Once the Commerce Cloud Digital project team certifies that the website is complete and has passed
QA testing, the site will be delivered to <Client name> for UAT. COMMERCE CLOUD DIGITAL will provide
core test scripts to <Client name> to test against on desktop, tablet, and mobile devices. Issues will be
recorded and defects logged into the Commerce Cloud Digital JIRA and are first triaged by our Business
Analyst, Technical Architect and Technical Team Lead to eliminate duplicates and any tickets deemed
not to be a defect (based on the finalized and approved requirements). UAT defects are assigned back to
the developers where the work is corrected, unit tested, re-tested by Commerce Cloud Digital QA and
finally re-tested and approved by the clients.

Standard Approach:

<TBD>: Please provide your standard approach for the UAT

10.2 Performance testing

SFCC requires all implementations to be load tested to ensure proper performance in their multi-tenant
environment. There are some exceptions for smaller clients, but the assumption should be that any
implementation is tested before launch.
Load testing will be performed on the completed build at twice the expected capacity to ensure the
platform scales as designed.

SFCC Requirements

Load testing guidelines:

Test to predicted load, not to capacity
We are not trying to find out at what point the system breaks down, but instead if it can handle the load
we expect. We are also only testing the SFCC instance itself, not the end to end timing with browser
loading all assets. No static resources are loaded or processed, meaning no images, css, javascript. Due
to the integration between Cloudflare and SFCC, this is deemed unnecessary, and we are really targeting
code, customizations, and integrations with this test.
Cached pages should load in under 250 milliseconds.
Cached pages generally include home, category landing, grid, product details, and static content (e.g.,
"about us").
Dynamic pages should load in under 3000 milliseconds.
These are your account and checkout pages
3rd-party integrations should be included in load testing.
Check real-time integrations to 3rd parties such as payment processor and sales tax providers to ensure
they withstand peak loads.

10.2.1 KPI
Metric Required <Client name>
    2017 Per Hour 2018 Per Hour
Number of Visits* yes  
Number of Page Views* yes  
Number of Orders yes  
Average Page Views no  
Order Conversion Rate no  
Cart Rate (visits with created carts) no  
Cart Size Distribution yes  
Number of Searches (per day) yes  
Ratio Guest and Registered Checkout yes  
User Registrations no  
Robot Visits no  
Robot Page Views no  

All these numbers are peak hour numbers. Average numbers or yearly numbers are not precise
enough, because the peak load on a site is about 10 times higher per hour than the average. A peak
hour is the most active hour of a year, season, or day.

11