Skip to main content

Salesforce Commerce Cloud Hooks - SFCC Hooks



Hooks in SFCC is a CommonJS script module. Hooks can be configured as a piece of functionality to use it in a specific point in your application flow or at a specific event.

You can use these hooks with a Salesforce B2C Commerce storefront application

OCAPI hooks


B2C Commerce provides extension points to call scripts before or after specific OCAPI calls

Custom hooks


You can define custom extension points and call them in your storefront code using the B2C Commerce script System package HookMgr class methods. You can then access the hook in either OCAPI or your storefront code. This flexibility makes them useful for functionality in a multichannel set of applications based on the same site.

Hook Definition


The package.json file will have the hook file entry for a cartridge. The hook file definitions shown as below

{
   "hooks": "./hooks.json"
}

The hook file defines a uniquely named extension point and a script to run. As the hook scripts are CommonJS module, this approach ensures that the script identifier is a module identifier. The value of this identifier can be a relative path or any other valid module identifier

Hook Example

The hook.json file defines a dw.ocapi.shop.basket.calculate hook that calls the calculate.js script. These hooks are located subdirectories of the scripts/hooks directory

{
    "hooks": [
        {
            "name": "dw.order.calculate",
            "script": "./cartridge/scripts/hooks/cart/calculate.js"
        },
 {
            "name": "dw.order.calculateShipping",
            "script": "./cartridge/scripts/hooks/cart/calculate.js"
        },
        {
            "name": "dw.order.calculateTax",
            "script": "./cartridge/scripts/hooks/cart/calculate.js"
        },
        {
            "name": "app.payment.processor.default",
            "script": "./cartridge/scripts/hooks/payment/processor/default"
        },
        {
            "name": "app.payment.processor.basic_credit",
            "script": "./cartridge/scripts/hooks/payment/processor/basic_credit"
        }
    ]
}


These hooks will be loaded during cartridge initialization and will be ready to be called in storefront module’s code.

Calling Custom Hook


           {
            "name": "dw.order.calculate",
            "script": "./cartridge/scripts/hooks/cart/calculate.js"
        }

This example calls the hook from calculate.js.
Sample code from storefront module. The code calls the hook dw.order.calculate’s calculate method by sending basket as a parameter in calculate.js


var HookMgr = require('dw/system/HookMgr');

function calculateTotals(basket) {
    HookMgr.callHook('dw.order.calculate', 'calculate', basket);
}

Running Multiple Hooks for an Extension Point

In a single hooks.json file, you can register multiple modules to call for an extension point. However, you can't control the order in which the modules are called. If you call multiple modules, only the last hook returns a value. All modules are called, regardless of whether any of them return a value.
At run time, B2C Commerce runs all hooks registered for an extension point in all cartridges in your cartridge path. Hooks are executed in the order their cartridges appear on the path. Each cartridge can register a module for the same hook. Modules are called in cartridge-path order for all cartridges in which they are registered.
Note: Hooks are executed in the order of the cartridges on the path. Therefore, when you change the order of the cartridges, you also change the order of hook execution.

Error Logging

Controller and script logging is available.
·         Custom error log: Contains the hierarchy of controller and script functions and the line numbers related to exceptions thrown. Intended for developers to debug code.
·         System error log: Primarily used for Commerce Cloud Support.

Example: Custom error log

    Error while executing script 'test_cartridge_treatascustom/cartridge/controllers/TestController.js': Wrapped com.demandware.beehive.core.internal.template.ServletAbortException: Requested template 'controller/testController' not found! (test_cartridge_treatascustom/cartridge/controllers/TestController.js#21)
    at test_cartridge_treatascustom/cartridge/controllers/TestController.js:21 (isml)
    at test_cartridge_treatascustom/cartridge/controllers/TestController.js:52 (anonymous)
    


Labels:

Comments

Post a Comment

Popular posts from this blog

SFCC Development environment setup-III Create a Storefront Project

Creating a storefront project depends on whether you are using SFRA or SGJC. SFCC recommends SFRA for new implementation In this section we will see how to create a storefront using SFRA Create Custom SFRA cartridges Implementing a site requires at least one custom cartridge. However, if you intend to create multiple sites, we suggest you create multiple custom cartridges. Each cartridge can separate functionality specific to a brand or locale, so that you can reuse most of your cartridge stack for a new site Cartridges can be created using  sgmf -scripts   This script is useful for creating Storefront Reference Architecture overlay cartridges. All of the scripts are executable through CLI [ https://www.npmjs.com/package/sgmf-scripts ] Follow the steps to install  sgmf -scripts globally and use the script to create new custom cartridge 1.   Update the node by using below command D :\ SFCC \ temp \ demo - site > npm   install - ...
Post a Comment
Read more

Salesforce Commerce Cloud Create Custom Job Step-I Task Oriented Script Module

Creating custom task oriented job steps involves the following steps, 1.   Create a  CommonJS module that  exposes a function to be called as the main function for the job step 2.   When administrators create jobs using Business Manager, they set parameters that are available as scriptable objects for the module's function 3.   The  dw.job.JobStepExecution object allows read-only access to information about the current step execution and job execution.  4.   To control the exit status, the script module's function can return a  dw.system.Status object 5.   If the script finishes with an unhandled exception, the exit status code is ERROR, and the error status flag is true by default 6.   If no status object is returned and no exception occurs, the status code is OK by default.  Consider the following use case to explain the Task oriented job steps.  The system want to update the profile information...
Post a Comment
Read more