Configure eCDN for Staging
Learning Objectives
After completing this unit, you’ll be able to:
- List the steps you need to take to configure eCDN for Staging.
- Explain how to list the zones for zone management.
- Explain how to create an eCDN zone and certificate.
- List the steps you need to take to migrate site traffic.
What’s the Plan?
Linda Rosenberg, Cloud Kicks admin, has all the tools she needs to configure eCDN for B2C Commerce on a development or production instance. But she needs to run and test eCDN on the staging instance. That’s where she pulls the storefront data and code together before pushing it to production. Business Manager only supports the configuration and management of eCDN on development and production, and eCDN settings are not transferred via replication.
That’s where eCDN for Staging comes in!
eCDN for Staging is an API-based product, so Linda asks Vijay Lahiri, Cloud Kicks developer, for help. He uses the CDN Zones component of the B2C Commerce API (SCAPI) to:
- Upload customer certificates to test a SCAPI implementation.
- Configure and manage zones on staging.
- Configure vanity host names for staging instances on eCDN.
Vijay creates a task list so he knows exactly what he has to do to implement eCDN for Staging.
| Step | Task |
|---|---|
|
1 |
Generate a shortcode. |
|
2 |
Obtain the API authorization token. |
|
3 |
Create an eCDN Zone and Certificate. |
|
4 |
Migrate site traffic. |
Once the eCDN is up and running, Vijay needs to manage eCDN on the staging instance, and renew certificates when they expire.
Generate a Short Code
Vijay starts by generating a short code, an eight-character string that’s assigned to a realm for routing purposes. It applies to the entire realm, across all instances. Here’s how to find it.
- Open Business Manager on your instance.
- Log in using your Account Manager credentials.
- Select Administration | Site Development | Salesforce Commerce API Settings.
- If you’ve never used the Commerce API in your realm, click Request Short Code to request one. It looks like this:
{shortcode}
A realm is merchant-specific. It contains instances on which to develop, test, and deploy a B2C Commerce storefront application
API Authorization Token
Authorization for the SCAPI resources is handled through client permissions. A client for the SCAPI can be anything from an online storefront to custom merchandising tools. To authorize this wide range of client types, Salesforce defined a set of scopes based on the OAuth 2.1 standard. They give you control over exactly what clients are authorized to do with the Admin APIs and Shopper APIs.
Once Vijay has the API authorization token, he ensures that the <tenant_id> matches the instance. For the eCDN staging process, it’s <realm>_stg.
Create an eCDN Zone and Certificate
Vijay’s staging instance has a custom SSL certificate installed. But if you don’t have one installed or the one that’s installed to the POD doesn't cover the host name, you must upload the required certificate. For each domain name, you must create an eCDN Zone and upload the certificate. For example, Vijay wants to create two zones for these hostnames.
staging1.cloudkicks.com
comstaging2.cloudkicks.com
comStaging.cloudkicks.co.uk
To create an eCDN zone for each domain name, he calls the POST storefront-zones endpoint for each of these zones.
{"domainName": "cloudkicks.com"}
{"domainName": "cloudkicks.co.uk"}
The response contains the back-end zone name and the zone IDs that he uses to certify each host name. For example:
stg-abcd-cloudkicks-com.cc-ecdn.net
Stg-abcd-cloudkicks-co-uk.cc-ecdn.net
The backend zone names use this format.
stg-<realm_id>-<dashed-domain-com>.cc-ecdn.net
Migrate Site Traffic
Once Vijay has configured eCDN for Staging, he needs to move traffic to it so he can test properly. Here are the steps he needs to take.
| Step | Task | Details |
|---|---|---|
|
1 |
Pre-validate the hostname. |
This step is required if you want to:
|
|
2 |
For each host name, validate control over the domain by submitting the TXT records to your DNS provider. |
TXT record, host names, and targets are listed in the response of a GET certificates call for a host name that isn’t validated. Here’s an example TXT validation record: If Salesforce engineering completed the eCDN configurations, they provided you with the TXT validation record. It’s important that you submit validation records as soon as possible. After the configurations are created, automated validation checks are performed up to 4 hours apart for 7 days. If you don’t complete the validation within 7 days, you must request Salesforce engineering to manually restart the validation checks. |
|
3 |
Send traffic directly to eCDN by updating DNS to the CNAME values. |
The CNAME target uses this format: Here’s an example CNAME record: If you don’t pre-validate the hostname, pointing traffic directly to the eCDN serves as validation. However, this approach results in downtime for the time between when DNS is updated and the next validation check. |
|
4 |
Stack a third-party eCDN (optional). |
This step requires a validated host name. Make sure the connections to eCDN use server name indication (SNI), an extension to the transport layer security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. SNI is required for eCDN configurations.
|
|
5 |
Delete the TXT validation records (optional). |
Before you delete the records, confirm that the host name is validated and that traffic is flowing through the eCDN. |
Manage eCDN on Staging
As Vijay knows, he can’t use Business Manager to manage the zones he created to support eCDN on his staging instance. The added configurations aren’t visible on the eCDN page in Business Manager when using his production and development instances—just as the eCDN page isn’t enabled on his staging instance.
Vijay can list the zones and zone IDs using the GET /zones/info endpoint. He can use the offset or limit query parameters to see all the zones. For example, for each host name, he uploads a certificate using the POST certificate endpoint with the host name, certificate, and key in the payload. Here are some tips.
- Format the certificate and key with
\nfor the new lines. Replace new lines with\nwith a shell command.
For example, on a MAC,cat cert.crt | perl -pe 's/\n/\\n/g' - Upload a certificate for each host name. This applies to certificates that cover multiple hostnames and wildcard certificates. You can upload the same certificate multiple times. This is important!
Renew a Certificate
Eventually, the staging zone certificates will expire and Vijay will need to renew. He uses the
CDN Zones API for certificate rotation. Here’s how to renew certificates for eCDN for Staging.
- Obtain a new certificate via your certification authority (CA) of choice.
- Use the CDN Zones API to:
- Retrieve the staging zone ID: use the GET /zones/info endpoint..
- Get the ID of the certificate that you’re rotating: use the GET/zones/{zoneId}/certificates.
- Use the PATCH /zones/{zoneid}/certificates/{certificateId} endpoint for each custom host name to which the certificate is installed.
Let’s Wrap It Up
In this module, you learned how to configure and manage an embedded or external content delivery network for your B2C Commerce implementation--whether for a development, production, or staging, instance.