Comm-Dev-101 Exam Questions & Answers

The service credential is the correct B2C Commerce configuration object for an environment-specific service endpoint. Service credentials can hold connection information such as the URL and, where applicable, authentication credentials. This allows administrators or developers to change the sandbox endpoint through Business Manager without modifying cartridge code.

Salesforce's Service Framework documentation describes the service configuration as being associated with a service profile and credential, and the credential contains the service URL used to connect to the remote system. The API representation ofServiceCredentiallikewise exposes the URL as part of that configuration.

Creating a custom global preference for the endpoint would duplicate functionality already provided by the platform and would require additional application code to read and apply that preference. Option C also confuses service monitoring/status functionality with endpoint configuration. The service-status area is intended for operational information and service behavior rather than being the canonical storage location for the configured endpoint.

Using the credential URL field keeps connectivity information externalized from source code and allows different URLs to be maintained independently in development, staging, and production environments.

Study Guide reference:B2C Commerce Setup --- Service Framework configuration, services, profiles, credentials, and environment-specific endpoints.

A cartridge that registers B2C Commerce hooks traditionally uses apackage.jsonfile at the cartridge root and points its"hooks"property to the hook registration file located under the cartridge's scripts directory. The correct relative path is therefore:

"./cartridge/scripts/hooks.json"

Salesforce's SFRA documentation describes the hook-registration pattern as a root-levelpackage.jsonaccompanied byhooks.jsonundercartridge/scripts. The cartridge containing the implementation must also participate in the relevant site's cartridge configuration for the extension to be available.

Option B is not valid JSON syntax because JSON property names and string values must be quoted. Option C uses the wrong relative location;scriptsis below the cartridge directory, not directly below the package root.

Thehooks.jsonfile then maps extension-point names to implementing script modules. Runtime code can invoke those extension points through mechanisms such asHookMgr.callHook(), while the registration metadata tells B2C Commerce which implementation is associated with each hook.

Study Guide reference:Application Development --- hooks,package.json,hooks.json, extension-point registration, cartridge structure, and extensibility architecture.

dw.svc.LocalServiceRegistry.createService()is the supported API for creating and configuring a Service Framework service instance from a service definition established in Business Manager.

Salesforce's Script API states thatLocalServiceRegistryis responsible for managing Service instances and documents the method:

createService(serviceID, configObj)

The method takes the configured service ID and a callback/configuration object, then returns the corresponding Service instance.

The callback object can define functions such ascreateRequest,parseResponse,filterLogMessage,mockCall, or other service-type-specific behavior. Application code subsequently invokes.call()on the returned service.

There is nodw.svc.LocalServiceInstanceclass providing the method in option B. Likewise,getDefaultService()is not the standard LocalServiceRegistry creation method represented by the current Service Framework API.

The LocalServiceRegistry design keeps the service object local to the script invocation while relying on Business Manager for service, profile, and credential configuration. This separates deployable integration code from environment-specific URLs, authentication credentials, timeout values, and operational policies.

Study Guide reference:Application Development ---dw.svc.LocalServiceRegistry,createService(), Service Framework, callbacks, service profiles, and remote integrations.

The controller passes the form object tores.render()under the property namenewsletterForm. SFRA merges render data into the response ViewData, and the resulting information is made available to the ISML template throughpdict. Therefore the correct template reference is:

pdict.newsletterForm

The resulting expressions become:

pdict.newsletterForm.attributes

and

pdict.newsletterForm.email.attributes

The form'sattributesproperty contains generated form-level HTML attributes, while theemailfield exposes its own generated attributes and state.

Option B uses the form-definition name rather than the property name chosen by the controller. Option C omits thepdictaccess expected in the supplied ISML pattern.

Study Guide reference:Application Development --- SFRA forms,server.forms.getForm(), ViewData,pdict, form attributes, and controller-to-template data binding.

WARNis the appropriate logging severity when an operation completed but produced an unexpected condition that may warrant investigation. It communicates that the application has encountered an abnormal or potentially consequential situation without falsely classifying the request as a complete processing failure.

Salesforce's B2C Commerce logging guidance identifies warning logs as appropriate for custom jobs, payment integrations, imports, and application code conditions that can affect users. WARN output is also normally available in operational logging, making it more appropriate than DEBUG for a potentially significant production condition.

DEBUGis intended for detailed development-oriented diagnostics and is not available as persistent debug file logging on production in the same manner.ERRORshould generally be reserved for an operation that actually failed, an exception, or another state requiring error-level treatment.

For Service Framework integrations, logs should contain useful but sanitized diagnostic context. Salesforce strongly recommends filtering requests and responses so credentials, payment data, tokens, and personal information are not exposed.

Study Guide reference:Application Development --- Logger severity, WARN messages, Service Framework diagnostics, secure service logging, and troubleshooting external integrations.