LINK Certification Guide

Updated June 2019

Getting Started 3

Training Requirement 3

Git 3

Starting Development 3
SiteGenesis Integrations 4
Storefront Reference Architecture (SFRA) Integrations 4

LINK Integrations Best Practices 4

LINK Cartridges Development Guidance 5

Versioning 5
Log Files and Logging 5
Deprecated API Report 5
Governance Quota Violations 5
Web Services 6
Jobs Framework 6
Custom Objects 6
Enabling & Disabling the Cartridge 6
Metadata 7
Code Documentation 7
Externalization 7
Cartridge Path Ordering 7
SGJC Integrations 7
SFRA Integrations 7
Code in the Header & Footer 7
SGJC Integrations 7
SFRA Integrations 8
Pipeline Usage is Discouraged 8
Web Analytics Architecture 8
Payment Integration Architecture 8
External Authentication 8
Ratings & Reviews Architecture 9
Firewall Rules 9
Minimizing Vulnerabilities 9
PCI Compliance 9
Close All Readers and Writers 9

Documentation 10

© 2019 salesforce.com, inc.. All rights reserved. 1

 Integration Guide 10
Test Case Documentation 10

Certification Process 11
Getting Access to the GitHub Repositories 11
Creating a GitHub account 11
Access to Partner Repositories 11
Getting Access to the Partner Community 12
Prerequisites to Certification 12
Submitting for Certification 13
Cartridge Demo 16
Certification Testing 16

Officially Certified! 17

Bug Fixes 17

New Features 17

Cartridge Expiration 17

FAQ / Questions? 17

© 2019 salesforce.com, inc.. All rights reserved. 2

Getting Started
The purpose of this document is to outline the process that LINK Technology Partners and
Solution Partners are required to follow to develop and submit LINK cartridges for
certification by B2C Commerce. The goal of having a well-defined process is to enable
cartridges to be certified as rapidly as possible while maintaining high quality standards.
Any questions regarding this process can be sent to ​LINK_Certifications@salesforce.com​.

Training Requirement
Any partner submitting a cartridge for certification must have a certified B2C Commerce
Developer on their team. A partner may use a certified B2C Commerce SI (Systems
Integrators) to satisfy the requirement.
If a partner does not want to use an SI, they will need to have one of their technical staff
acquire the Salesforce Certified B2C Commerce Digital Developer credential. Information
about the credential can be found here:
http://certification.salesforce.com/commerceclouddigitaldeveloper​.
If the individual earned their credential on or before April 8, 2018, they can take the B2C
Commerce Digital Developer Maintenance Exam to have an updated and valid credential.
More information about the maintenance exam can be found here: ​https://sfdc.co/rF03f​. To
confirm the credential is valid, this verification tool can be used:
http://certification.salesforce.com/verification​.

Git
LINK Technology Partners and Solution Partners should read the ​LINK Git Instructions
document, which can be found in the Salesforce Partner Community (search for
#CC_Cartridge​) before starting development. The ​LINK Git Instructions​ ​document outlines
the workflows that must be followed by partners when developing and submitting their
cartridges. B2C Commerce ​will not review​ any cartridges that are submitted without
correctly following the​ LINK_[partner]​ workflow as outlined in the​ ​LINK Git Instructions
document.

Starting Development
B2C Commerce LINK partners should develop integration cartridges in the sandbox they
requested upon joining the program. A standard SiteGenesis or SFRA storefront should be
created and used for integration. The integration model that B2C Commerce LINK cartridges
should follow is to place as little code into the SiteGenesis storefront cartridge as is
necessary and absolutely no changes in the SFRA base storefront. The vast majority of the
code in the integration should reside in the integration cartridge. This makes the rollout of
future versions of the cartridge to customers as streamlined as possible.
As of August 1, 2019, any cartridge submitted for certification will need to be
SFRA compatible​. Until then, a controllers only cartridge is acceptable. It is also currently
acceptable to have a SFRA only cartridge if preferred.

© 2019 salesforce.com, inc.. All rights reserved. 3

SiteGenesis Integrations
Partners should be using the latest version of SiteGenesis that shipped with the most recent
platform update at the time they start their development. This can be obtained using the
latest commit from this repository:
https://github.com/SalesforceCommerceCloud/sitegenesis

Storefront Reference Architecture (SFRA) Integrations

Below is a list of required items for all certifications with SFRA:
● Every submitted cartridge needs to have a complete set of unit tests for any models
that they implement. These unit tests should be based on the unit test framework
that comes bundled with SFRA.
● The LINK SFRA cartridge should be plug and play. ​Modifications of the base
cartridge is not allowed​, so testing should be as easy as:
○ run the unit tests and verify that they are running without errors
○ load the cartridge onto the server
○ add it to the cartridge path
○ configure it in the Business Manager
○ test it - it should run all the tests correctly without any code modifications.
● The code should be developed using the eslint code style checking supplied with
SFRA. Please adopt the code styles supplied in the built-in eslint files
● Newly added visual elements should be built as so they can be overridden by the
customer's customization layer.
● Documentation should be updated to reflect the new integration model. A new SFRA
guide can be added to the repository, but the LINK Certification Team will also accept
both the controllers and SFRA guide combined in the same file.
● A package.json file must be provided in the repository to allow the cartridge to be
compiled properly.

LINK Integrations Best Practices

For more in-depth information about all best practices relating to building a LINK cartridge,
refer to ​LINK Integration Best Practices

© 2019 salesforce.com, inc.. All rights reserved. 4

LINK Cartridges Development Guidance

Versioning
The version number of all integrations will be the year in which the certification was
completed and the number of versions released that year. For example, if the first certified
version of a cartridge is in 2019, the version would be 19.1.0. Any subsequent certified
versions of the cartridge in 2019 would be 19.2.0, 19.3.0, etc. Minor bug fixes or
documentation changes will be noted with a minor release number such as 19.1.1. Overall,
the version naming convention is [year].[certified version of the year].[update].
Note: there is no correlation between the B2C Commerce platform release and the
integration cartridge version. If a partner submits their first certification request in 2019
when the current platform release is 19.3.0, the version of the integration will still be
19.1.0.

Log Files and Logging

Developers should execute all test cases and verify that no errors or extra data is being
written to log files.
Developers must remove any logger messages or use only debug logger messages to
prevent any messages from being written in production environments.
To do this, verify that .debug(), .info(), .warn(), .error(), .fatal() logging:
● Does not have data that is considered PCI or PII (PCI compliance and GDPR/Privacy
regulations compliance)
● Does not have data that can be used to identify the customer on its own without
usage of the data that is stored on our platform or clients back-end systems

Deprecated API Report

Developers should execute all test cases to check that their integration does not contain any
deprecated API usage. To verify that there are none, go to the Business Manager >
Administration > Site Development > Deprecated API Usage.
Note: there may be some related to SiteGenesis; these can be ignored.
For more information, refer to:
https://documentation.b2c.commercecloud.salesforce.com/DOC1/topic/com.demandware.d
ochelp/SiteDevelopment/DeprecatedAPIs.html

Governance Quota Violations

Developers should execute all test cases to verify that their integration does not contain any
B2C Commerce governance quota violations. To verify that there are none, go to the
Business Manager > Administration > Operations > Quota Status.
For more information, refer to:
https://documentation.b2c.commercecloud.salesforce.com/DOC1/topic/com.demandware.d

© 2019 salesforce.com, inc.. All rights reserved. 5

ochelp/Quotas/GovernanceandQuotas.html

Web Services
B2C Commerce requires that all web service calls be implemented using the web service
framework located in the Business Manager. This includes any use of HTTPClient, FTPClient,
SFTPClient, or WebDAVClient.
For more information, refer to:
https://documentation.b2c.commercecloud.salesforce.com/DOC1/topic/com.demandware.d
ochelp/WebServices/Webservices.html
With integrations that handle PCI or PII data, ensure that additional callbacks have been
implemented using filterLogMessage or both getRequestLogMessage and
getResponseLogMessage.
For more information, refer to:
ttps://documentation.b2c.commercecloud.salesforce.com/DOC1/topic/com.demandware.doc
help/DWAPI/scriptapi/html/api/class_dw_svc_ServiceCallback.html

Jobs Framework
B2C Commerce requires that all jobs be implemented using the jobs framework that is part
of the B2C Commerce platform release 17.1. This framework has replaced the previous
jobs framework and integration framework.

Custom Objects
Custom objects should only be leveraged to store configuration data and not transactional
data. Data from objects such as baskets, orders, page views, etc. should never be stored in
custom objects. Operations that generate a high volume of objects created and deleted
should also be avoided even if they do not violate the quota for the total number of custom
objects.
The reasons for this are:
● There is a quota of 400,000 custom objects per realm which is shared among all
sites and integrations in the realm. If this quota is exceeded no more custom
objects can be created.
● Custom objects, unlike System Objects, are not optimized for database access.
Relying on custom objects for high-performance access will cause database churn
and a poor customer experience
Custom objects are most efficiently employed for holding static data which is referenced
only occasionally (once per session, for instance).

Enabling & Disabling the Cartridge

The cartridge must have the ability to be enabled or disabled without altering code. This
can be accomplished using a custom preference value that is a checkbox or has the option
of “Enabled” or “Disabled.” When it is disabled, there should not be any items related to the
cartridge on the storefront.

© 2019 salesforce.com, inc.. All rights reserved. 6

Metadata
All metadata necessary for the cartridge should be in a zip file created by Site Import &
Export in the Business Manager. Verify that it only contains metadata relating to the
cartridge and that importing it into the Business Manager causes no warnings or errors.

Code Documentation
All .ds and .js files must contain a summary at the top of the file that outlines the
functionality included in the script. Longer script files should contain brief summaries for
each function.

Externalization
All strings in templates should be externalized in properties files. There should not be any
static text appearing in templates.

Cartridge Path Ordering

SGJC Integrations
In order to ensure that upgrading LINK cartridges does not override a customer custom
storefront, the LINK cartridge must be after SiteGenesis in the cartridge path. In other
words, installing a LINK cartridge in the cartridge path shouldn’t be overriding higher-level
customizations.

SFRA Integrations
One of the implications of having models produce JSON data which is consumed by views is
that the SFRA cartridge (app_storefront_base) can truly be a “base” cartridge that serves as
a foundation for additional layers of customization cartridges.
This means that instead of modifying the reference application as was done with
SiteGenesis, ​SFRA expects that the app_storefront_base cartridge will NOT be
modified by LINK partners or clients​. The expectation is that all customizations take
advantage of the cartridge hierarchy and overlay functionality on top of the base cartridge.

Code in the Header & Footer

SGJC Integrations
Any code snippets that need to be placed in the header should instead be placed in the
footer. By doing so, this allows the storefront to completely load before the partner’s
cartridge.

© 2019 salesforce.com, inc.. All rights reserved. 7

SFRA Integrations
The defer attribute should be used when loading scripts from the header so that it allows for
the html to be fully parsed before the script is executed. An example can be found in
app_storefront_base/cartridge/templates/default/common/scripts.isml

Pipeline Usage is Discouraged

As of January 1st, 2017, cartridges must be built using only controllers. There are no
pipelines allowed in the cartridge except for import & export jobs because this is not yet
supported with controllers. All Business Manager extensions should also be built using
controllers and not pipelines.

Web Analytics Architecture

B2C Commerce requires any partners implementing a web analytics or tagging solution to
follow a specific architecture. This architecture is outlined below:
1. Data gathering performed in server-side code should not result in additional API calls
to the B2C Commerce platform. The code in the third party integration should use
data that is already present on the page being rendered.
2. The transmission of data should always be from the browser to the third party
service and not from B2C Commerce to the third party service.

Payment Integration Architecture

All payment integrations should follow the model demonstrated by the BASIC_CREDIT.js
payment method/script in SiteGenesis. The payment processor should be defined in the
business manager and the appropriate payment method should be linked to the payment
processor. The purpose of this is to allow one payment processor to be compatible with
other payment processors that follow the same architecture.
Any payment integration that requires redirection to a third party site should use the
security demonstrated by ​COPlaceOrder.submitPaymentJSON() method​ in SiteGenesis. B2C
Commerce provides the ​order.orderToken​ that should be passed to the third party service
and used to validate the origin of the redirect back to B2C Commerce.

External Authentication
Any solution providing external authentication for logins to a B2C Commerce merchant site
should implement OAUTH as documented here:
● http://oauth.net/2/
● https://documentation.demandware.com
B2C Commerce will not certify any integration that includes any of the following techniques:
● Resetting the user’s password on each login
● Storing the user’s password in an external location
● Using an algorithm to generate a password that is not stored in an external location
but can be calculated for each login

© 2019 salesforce.com, inc.. All rights reserved. 8

Ratings & Reviews Architecture
The preferred architecture for ratings and reviews in LINK integrations is to use an Ajax call
to retrieve the content from the review provider. The JavaScript running in the browser
should populate an empty div container that is in the page. B2C Commerce will not certify
an integration that uses a web service call from B2C Commerce to an external system with
each page request to retrieve ratings and reviews data.

Firewall Rules
LINK integrations requiring firewall rule changes for outgoing traffic from a merchant’s B2C
Commerce instance should limit their IP ranges to a reasonable number of addresses. B2C
Commerce will not permit whitelisting entire blocks of IP addresses or many different IP
addresses.

Minimizing Vulnerabilities
Cross-Site Scripting (XSS) is an OWASP identified security flaw present in many modern
websites. One way to minimize the vulnerability of a website is to properly encode any
output that a user might have entered such as names, addresses, etc.
In B2C Commerce, a common defense is accomplished by never allowing encoding=”off” in
an <isprint> statement in ISML files. encoding=”off” should be replaced by an appropriate
encoding type as seen in
https://documentation.demandware.com/DOC1/topic/com.demandware.dochelp/ISML/isprin
t.html
For more general defense against XSS and XSRF (Cross-Site Request Forgery), refer to the
following documentation:

● https://xchange.demandware.com/docs/DOC-33873
● https://xchange.demandware.com/docs/DOC-33798

PCI Compliance
B2C Commerce reviews all LINK integrations for PCI DSS best practices. B2C Commerce
does not make any claims regarding PCI DSS compliance in LINK integrations. PCI DSS
compliance in LINK integrations is entirely the responsibility of the LINK technology partner
that owns the integration and the merchant implementing the integration on their site.

Close All Readers and Writers

All readers and writers such as FileWriter, CSVStreamReader and SeekableIterators should
be closed. If they are not closed, they will use up resources and will stay there until a
garbage collector finds it.

© 2019 salesforce.com, inc.. All rights reserved. 9

Documentation

Integration Guide
B2C Commerce requires documentation to be submitted with all LINK cartridges prior to
review by B2C Commerce for certification. The ​LINK Integration Documentation Template
may be used by partners and can be found in the ​Salesforce Partner Community
(#CC_Cartridge).
B2C Commerce does not require that partners use the standard template; however, all
relevant topics in the document must be included in the documentation that is submitted by
partners with the cartridge. The cartridge will be rejected if B2C Commerce considers the
documentation inadequate or incomplete.
The integration steps should be very detailed so that it is clear for someone without prior
knowledge of the cartridge to perform the integration.
Partners should take particular note of the following documentation requirements:
● The version number should be the same as the cartridge version using the version
naming convention [year].[certified version of the year].[update].
● The documentation should include all necessary steps to setup the cartridge with
minimal help from the partner. The four main steps should be:
○ Adding the cartridge to the cartridge path
○ Importing the metadata
○ Updating settings for credentials, enabling the cartridge, etc
○ Updating and adding code to the storefront
● Any code added to the storefront must be clearly explained as to where to place it.
B2C Commerce recommends taking a screenshot of where the code is added to the
file and including it in the guide.
● Clearly identify any limitations or known issues so that they are clear to B2C
Commerce customers who are evaluating the cartridge for use in their storefront.
● If the cartridge is a payment cartridge, there should be a bullet point list of all
supported payment types included in the functionality section.

Test Case Documentation

In addition to the integration guide, there should be a separate document that includes
basic test cases to ensure the main functionality is operating correctly. This ensures that:
(1) the B2C Commerce team is testing the right items, (2) customers know what tests have
been performed as part of the certification process and (3) customer can also test their
integrations against the supplied test cases to verify their implementations.
B2C Commerce recommends including screenshots of the storefront, Business Manager, or
3rd party sites showing what steps to do and what items to look for.

© 2019 salesforce.com, inc.. All rights reserved. 10

Certification Process

Getting Access to the GitHub Repositories

Creating a GitHub account

1. Create an account at ​http://github.com/join
2. Enable two-factor authentication for the account:
https://help.github.com/articles/configuring-two-factor-authentication-via-a-totp-mo
bile-app/
3. Navigate to ​https://cc-community-authmgr.herokuapp.com/​ and use XChange
credentials to log into the app (if there is an active session on Xchange already, this
may occur automatically)
4. Select the Github tab and follow the steps provided to link the account with Github.
5. Upon successfully linking the account with Github, the app will provide a link to the
Salesforce B2C Commerce Github organization and all available repositories to the
account will be accessible.

Access to Partner Repositories

To get write access to a partner’s repository, contact the LINK Certification team to create a
repository or to get added to their existing repository. This can be done by submitting a
request through the Partner Community and providing the GitHub ID for the individual who
needs access. Use the instructions in the Submitting for Certification section below and use
the following format for the ticket. Keep in mind the LINK team can no longer create
repositories themselves, so please allow 2-3 days for a repository to be created and to get
access.

© 2019 salesforce.com, inc.. All rights reserved. 11

Getting Access to the Partner Community
● Log into the Partner Community here: ​https://partners.salesforce.com/
○ If access to the Partner Community is needed, sign up here:
http://p.force.com/signup​ (following the B2C Commerce specific instructions).
○ If someone is already logged into the Partner Community from your
organization, they can add you by following instructions here:
https://sfdc.co/PartnerCommunityAdmin

Prerequisites to Certification
This a list of items that need to be done prior to submitting for certification. If any of these
items are missing, the LINK Technology will deny starting the certification until they are
finished:
● Present the certification of the required B2C Commerce Developer.
○ The way the LINK team verifies the developer is by using
https://trailhead.salesforce.com/credentials/verification​. Please provide the
email address associated with the certification
○ If the email address is correct, but is not showing up in the verification site,
ensure that "Verification Opt-In:" is set to yes on the Webassessor account
profile
● Update the Salesforce hosted LINK_[partner] repository with the latest version of the

© 2019 salesforce.com, inc.. All rights reserved. 12

 cartridge and commit it to the master branch.
● Include a test document within the LINK_[partner] repository that provides basic test
cases to verify the cartridge is working. An explanation of what we are looking for is
in the Documentation section of this document.

Submitting for Certification

1. After logging into the Partner Community, select the “Support” tab:

2. This leads to the “Support” page where new cases can be filed and all previously filed
cases can be seen. Select the “New Case” button to file a new case

3. On the “New Case” page, locate the “LINK Technology Partners” link in the
“AppExchange Partners (ISV)” section.

© 2019 salesforce.com, inc.. All rights reserved. 13

 4. Clicking this link brings up a tooltip with a “Create a Case” button. Select that
button to start the case creation:

© 2019 salesforce.com, inc.. All rights reserved. 14

 On this page, please fill in the following fields:
● Subject - For Certification requests, make sure to enter [Cartridge Name]
[version]
● Subtopic: Choose the most relevant subtopic from the drop down list.
● For LINK Cartridge Certification Requests: Make sure you enter all needed
information about the certification request in the Description field which
should include:
○ Provide one of the following reasons for submitting the certification
request:
■ New Certification: [Cartridge Name]
■ Recertification: [Cartridge Name]
○ Provide the type of certification for the integration to be tested against
(i.e. controllers, SFRA, etc)

© 2019 salesforce.com, inc.. All rights reserved. 15

 ○ B2C Commerce certified developer on the team (be sure to state the
email address that was used for their certification) or the SI that
worked on the cartridge for the certification
○ Additional email addresses of people that should be attached to this
ticket
○ The URL to the repository containing the cartridge
○ Settings in the Business Manager related to the cartridge that can be
used by the LINK Technology Team’s sandboxes such as Custom
Preferences, Service Credentials, etc (if there are a lot of settings,
attach the settings to the ticket in a separate file after creating the
ticket)

Cartridge Demo
As of June 2019, the demo will consist of the partner both setting up the cartridge and
demoing the functionality.
For a complete guide on how to schedule, prepare, and present for the demo, please read
the ​LINK Certification Demo Guide​.

Certification Testing
During the demo, a sprint date will be given as to when the LINK Technology Team will
begin the certification process. Until this date, the partner does not need to do anything
further with certification unless specified in the demo or ticket. The LINK Certification Team
will add a comment that will note the week the certification will begin.

To make sure that all communications between the B2C Commerce team and the partner
are visible and not lost in emails, please use the ticket for all communications during the
certification process. Email is unhelpful because the B2C Commerce team consists of
several individuals who all need to access the message stream. For instance, to see the
status of a certification, this is captured in the ticket.

The LINK Technology Team will perform the following steps to certify the cartridge:
1. B2C Commerce will perform a full functional test of the cartridge based on the test
cases in the test case documentation provided by the partner. B2C Commerce will
request support from the partner if any of the use cases cannot be successfully
completed.
2. B2C Commerce will review the code to verify that it follows the requirements in the
development style guide. B2C Commerce will provide feedback to the partner via the
ticket if any changes are necessary.
The partner should be available for technical support if required. B2C Commerce reserves
the right to move the cartridge back to the start of the certification queue if the partner
does not respond promptly to technical or business questions during certification testing.
Please note: the LINK Technology Team does not receive updates when the repositories are
updated, so comment on the ticket if a new commit or fix is available.

© 2019 salesforce.com, inc.. All rights reserved. 16

Officially Certified!
The LINK Technology team will create a release tag in the LINK_partner repository and
create a link to this tag in the partner’s space in the LINK Marketplace. The partner’s space
in the LINK Marketplace will also be updated to reflect the fact that B2C Commerce has
certified the integration.
If a partner does not have a marketplace page, they will need to contact their partner
manager.

Bug Fixes
If a small bug is found, the fix must be submitted in the repository in the master branch.
Then, a new ticket can be created using the following fields:
● Severity
● Subject - [Cartridge Name] Bug Fix
● Subtopic: LINK Technology Program Support
● Description:
○ Enter all bugs found and how they were fixed
○ B2C Commerce certified developer on the team or the SI that helped with the
fix
○ The URL to the repository containing the cartridge

New Features
Any new features a partner would like to add to the integration must go through another
certification. The LINK Certification Team highly recommends including as many new
features as possible within a certification to avoid having to certify the entire integration
again for each new feature.

Cartridge Expiration
A cartridge that is certified by B2C Commerce shall be considered ‘certified’ for a period of
one year from the date that the certification is completed and the integration is posted to
the marketplace. The cartridge certification shall be considered ‘expired’ exactly one year
after the certification is completed. The partner must either repeat the certification process
with an existing version of a cartridge or provide a new version to be certified in order to
have a cartridge listed in the marketplace once a cartridge certification has expired.
The fields in the partner’s space in the marketplace will be modified to reflect the fact that
the integration is not certified by B2C Commerce and is not currently available for download
if the cartridge is beyond its expiration date.

FAQ / Questions?
1. Use the ​Salesforce Partner Community​ to ask questions and see all the documents
referenced in this guide.

© 2019 salesforce.com, inc.. All rights reserved. 17

 2. Ask the partner account manager (PAM)
3. Contact ​LINK_certifications@salesforce.com

© 2019 salesforce.com, inc.. All rights reserved. 18