OCAPI Customization 23.1
You can customize Shop API resources that perform a modification on the server side, such as the
Basket resources. These resources provide extension points, or hooks, that enable you to augment server-side logic with your own script code.
Each customizable resource provides
modifyResponse extension points. Use the
after extension points to execute custom code before or after the server performs its processing, respectively. Use the
modifyResponse extension point to apply final changes to the response document. In addition, some special convenience hooks allow you to perform actions like basket calculations or special checkout steps. These convenience hooks let you place your basket-calculation code in a single place, instead of including duplicate code in multiple
after extension points.
For information on extension points and supported resources, see OCAPI Hooks for Data API 23.1 and OCAPI Hooks for Shop API 23.1.
Before 13.6, when the server received a request to modify a resource, it directly modified the resource and then sent a response directly to the caller. Starting in 13.6, you can augment the server's basic processing with your own custom code. The processing flow is as follows:
|Server receives a request to modify a resource||Instead of directly modifying the resource, the server checks for registered |
|Server calls your registered ||The server passes the request document and a Script API object (representing the resource that it will modify). Your custom code can manipulate both, but typically performs input validation on the request document.|
|Server modifies the resource||The server uses the request document processed by the |
|Server calls your registered ||The server passes the request document (after any modifications by the |
|Server creates the response document||The server copies values from the Script API object (after any modifications by the |
|Server calls your registered ||The server passes the previous response document (after any modifications by the |
|Server sends the response to the caller||The server renders the response document (after any modifications by the |
For state-changing HTTP methods (DELETE, PATCH, POST, PUT), the server executes any
after hook logic, plus the system logic, in the context of one database transaction. The transaction ensures that everything (or nothing) is committed into the database.
Don’t modify a Script API object in an HTTP GET request or a
modifyResponse hook, because they’re never executed in a transactional context. It can cause an ORMTransactionException and an HTTP 500 fault response.
For each extension point, your custom code must return a
Status object to the server. If the status is
OK, the server continues processing. If the status is
ERROR (representing a handled exception), the server aborts all further processing and responds with an HTTP 400 (Bad Request) fault. When an
ERROR occurs, the server returns an OCAPI fault to the caller, containing information like the error code, message, and details from the
Status object. Any uncaught script exceptions in your custom code cause an HTTP 500 (Internal Error) fault; in this case, the server rolls back the entire transaction.
Starting in 18.3, modify
Modify response hooks have the following characteristics:
- They support GET, POST, PUT, and PATCH methods to enrich the response document with custom information.
- They enable your customization code to change and unset document attributes and add, delete, and change custom attributes in the return document.
- They disallow database transactions within your customized script code, making it impossible for your code to change persistent data.
- If there’s caching, they’re only executed if the cache is empty or stale. But they aren’t executed for every GET or HEAD call.
The following example shows customization script code for the Shop API category method:
The extension point registration is built upon CommonJS features like modules and
package.json. You register extension points statically by creating a
package.json file, which you must place in the top-level directory of a cartridge. In the
package.json file, set the
hooks property to the path of a
hooks.json configuration file. This path is relative to the directory containing the
hooks.json file contains an array with mappings from extension point names to script files. Reference the script files with a relative path. The paths are relative to the directory where the
hooks.json file is located.
Register your cartridge to the appropriate site in Business Manager. To customize organization-level resources, such as libraries, register it to the Business Manager site.
An extension point (or hook) script is loaded as a CommonJS module. All hook functions must be exported. The exported name must match the name of the extension point function, without the package qualification. For example, the
dw.ocapi.shop.basket.billing_address.beforePUT extension point is exported as
The Hook Circuit Breaker feature protects the system from excessive Hook script execution failures. For more information, see Hook Circuit Breaker.
The Calculate hook (
dw.order.calculate) enables you to implement customized basket calculation logic. It can be used as the single place for basket calculation and recalculation. This hook provides a default implementation, which you can override at any time. The default logic of the following hooks implicitly calls this hook:
The following table shows how this hook supports customization:
|Extension point||Method detail|
calculate (basket: Basket): Status
Calculates (or recalculates) the basket sent in the request.
basket - the basket document to be calculated (or recalculated)
a non-null Status ends the hook execution
In this sample call, the parameters are:
"dw.order.calculate"- the extension point to call
- "calculate" - the script function to call
basket- the basket to be calculated
SiteGenesis uses the default implementation of the
dw.order.calculate hook for basket calculation logic.