Salesforce-B2C-Commerce-Cloud-Developer Practice Test Questions

Explanation:

The Open Commerce API (OCAPI) is a RESTful API, and like all RESTful services, it relies on HTTP methods to define the type of operation being performed.
To retrieve product information, the correct method is:

GET /dw/shop/v18_3/products/(creative-zen-v,namco-we-ski-wii)?client_id=aaa...

Why GET is correct:
- The GET method is used to read or retrieve resources from the server.
- It is safe and idempotent, meaning it does not alter server state.
- OCAPI expects GET for reading product data, catalog info, prices, availability, etc.

Why the other options are incorrect:

A. Changing the URI to /dw/shop/v18_3/products/creative-zen-v would retrieve a single product, not multiple. It’s valid but doesn’t match the intent of the original request.

B. PUT is used to create or update resources, not retrieve them. It’s not allowed for product retrieval.

D. Including an authentication token is not required for public product data if the client ID has proper OCAPI permissions. This is not the root cause of the issue.

Explanation:

To allow customers to refine product search results by a custom attribute like weightCapacity, the developer must:

Define a search refinement for the attribute in Business Manager.

Rebuild the product search index so the new refinement becomes active on the storefront.

This ensures that the attribute appears in the refinement bar on search results and category pages, allowing users to filter products based on that value.

🔧 Steps to Implement
Create the custom attribute weightCapacity on the Product system object.

In Business Manager, go to: Merchant Tools > Search > Search Refinements

Select the relevant category or root catalog.

Add weightCapacity as a refinement definition.

Go to: Merchant Tools > Search > Search Indexes

Rebuild the product index to apply the changes.

❌ Why the other options are incorrect

A. Define a sorting rule for weightCapacity Sorting rules affect result order, not filtering. This won’t display a refinement.

C. Define search-suggestion buckets Buckets are used for autocomplete suggestions, not refinements.

D. Clear the page cache segment for Search-Show Cache clearing may help with display issues, but it won’t activate a new refinement without rebuilding the index.

Explanation:

The log file name is derived from the first parameter passed to Logger.getLogger(). Here’s the breakdown:

Code Analysis:
var log = Logger.getLogger("xyz", "export"); // First param: "xyz", second param: "export" log.info("This is important information");

"xyz": Defines the log file name prefix (e.g., custom-xyz.log).

"export": Specifies the log category (unrelated to the filename).

Business Manager Log Configuration:

The active log category is root (irrelevant here; filename depends on the first parameter).

Log level is info, so the message will be written (since log.info() matches the configured level).

Log File Naming Convention:

Log files follow the format: custom-{firstParameter}.log.
Example: custom-xyz.log.

Why Not Other Options?

A (xyz): Missing the custom- prefix.

B (custominfo-blade): Incorrect; not based on the code.

C (custom-export): Uses the second parameter (category), which doesn’t affect the filename.

Explanation:

To grant access to an OCAPI resource in a sandbox or production instance, you must define the required permissions inside the **OCAPI settings JSON file** (typically found in Business Manager under: Administration > Site Development > Open Commerce API Settings).

Two critical fields required to enable access are:
Resource_id: This specifies the path to the OCAPI resource (e.g., /products/*, /baskets/*). Without this, the system doesn’t know which endpoint the permissions apply to.

Client_id: This defines the specific client ID (from Account Manager) that will have access. This ties the permissions to the external application making the API call.

Other optional fields include:

- read_attributes: Controls what fields are returned when reading data (optional, unless you need attribute filtering).
- version_range: Limits what versions of the OCAPI this config applies to (defaults if not specified).

Explanation:

In SiteGenesis or similar B2C Commerce implementations, adding a new custom attribute like "order comments" to the checkout flow involves both frontend and backend changes. However, system object schema changes (like adding a new attribute to the Order system object) are often avoided for temporary or optional data.

Instead, to include such data in the order export, developers typically:

- Capture the comment in the checkout form (already assumed complete).
- Store the comment in a temporary medium (e.g., CSV in WebDAV or a custom object).
- Customize the export job or process to read from this medium and merge the data into the export.

This approach avoids modifying the core order schema and keeps the export pipeline loosely coupled, which is preferred in many B2C Commerce environments.

Explanation:

To create a cache partition specifically for the home page (ensuring only the home page cache is cleared when edits are made), follow these steps in Business Manager:

Navigate to:
Administration > Sites > Manage Sites > [Your Site] > Cache

Configure the Partition:

Add a new cache partition (e.g., home_page).
Set the path to the home page (e.g., /home).
Assign a clear trigger (e.g., "Clear on content changes").

Why Option A?

Cache partitions are managed under Administration > Sites > Manage Sites > [Site] > Cache.
This allows granular control over which pages/URLs are grouped into partitions.

Why Not Other Options?

B/C: Incorrect paths. Cache partitions are not under Operations.

D: Site Preferences manage global cache settings, not partitions.

Explanation:

Salesforce B2C Commerce (SFCC) uses custom logging to capture debug, info, warn, and error messages from custom code. Log files are capped in size (typically 10 MB per file). Once this limit is reached:

✅ Logging is suspended for the day.
When a custom log file exceeds the size limit, SFCC stops writing further entries to that log file for the rest of the day. This is done to prevent excessive disk space usage and to maintain system performance.

Logging resumes automatically the next day.
SFCC does not roll over or create a new custom log file.
Developers must ensure proper log levels (info, debug, etc.) to avoid hitting this limit too soon.

❌ Why not the others?

A. The log file is deleted and a new log file is created.
🔴 Incorrect — SFCC does not delete custom log files automatically once the size limit is reached.

C. The current log file is archived and a new log file is created.
🔴 Incorrect — Unlike some logging frameworks, SFCC does not perform file rotation for custom logs.

D. The log file Rolls over and the oldest log messages are overwritten.
🔴 Incorrect — There’s no built-in log rotation or rollover mechanism for custom logs.

Explanation:

To create a content slot that can be included on homepage.isml and configured in Business Manager, you use the ISML tag. The minimal required attributes for a global slot are:

id: A unique identifier for the slot (e.g., "my_banner")
description: A human-readable label for Business Manager
context: Set to "global" for slots that appear across pages or on specific templates like the homepage

This tag tells B2C Commerce to scan the template and register the slot so that a slot configuration can be created in Business Manager.

Example: < isslot id = " my_ banner " description = " for home page " context = " global " >

This will allow merchandisers to assign content assets, product carousels, or promotions to the slot via Business Manager.

❌ Why the other options are incorrect

A. Includes an invalid context-object for global context — not required and may cause errors.

B. Missing required context-object if context="homepage" were valid — but "homepage" is not a valid context value.

D. Uses context-object with global context — only required for category or folder contexts.

Explanation:

When working in UX Studio, cartridge upload issues can arise if configuration settings are incorrect or out of sync with the B2C Commerce instance. Let’s review why each correct answer matters:

✅ A. The Auto-Upload setting is enabled for the server connection.

This ensures that whenever you make changes to files in the cartridge, they are automatically uploaded to the server.

Without this, changes remain local and will not execute on the server.

✅ D. The cartridge is for the current version of B2C Commerce.

Cartridges may include APIs, methods, or structures compatible only with certain platform versions.

If the cartridge isn’t compatible with the current version, the system may ignore it or behave unpredictably.

✅ E. The server is configured to accept incoming connections.

If the B2C Commerce instance is not allowing connections (e.g., firewall, IP restriction, maintenance), UX Studio cannot push code.

This results in cartridges not uploading even though UX Studio may appear correctly configured.

❌ Why not the others?

B. The Active Server setting is enabled for the server connection.
🔴 This setting is important for previewing or debugging, but it doesn’t impact whether cartridges are uploaded.

C. The credentials for the server connection are correctly entered.
🔴 While credentials must be correct to establish a connection, if they were wrong, the connection itself would fail — and this would be more immediately visible with a connection error. It’s not a top issue when cartridges are not executing properly after uploading.

Explanation:

✅ ProductSearchModel.getProductSearchHits()
This method is the recommended way to iterate over search results. It returns ProductSearchHit objects, which are lightweight and optimized for performance. You can then selectively load full product data only when needed.

Efficient for large result sets

Avoids loading full product objects unnecessarily

Supports refinements, sorting, and pagination

Salesforce explicitly states:

“Avoid using getProducts() directly on the search model — it’s expensive. Use getProductSearchHits() instead.”

✅ Category.getProducts()
This method is efficient when you need to retrieve products directly assigned to a category. It returns an iterator and supports pagination, making it scalable for storefront use.

Ideal for category landing pages

Efficient for merchandising and product listing

Avoids full catalog traversal

❌ Why the other options are less efficient

A. ProductMgr.queryAllSiteProducts()
This method retrieves all products across the site, which is extremely expensive and not scalable. It should be avoided in storefront logic.

B. ProductSearchHit.getRepresentedProducts()
This method is used for variation groups and bundles, but it’s not efficient for general product listing or search. It also requires that you already have a ProductSearchHit.