AD0-E722 practice question 3 of 10

An Architect needs to integrate an Adobe Commerce store with a new Shipping Carrier. Cart data is sent to the Shipping Carrier's API to retrieve the…

Full set: 50 questions
An Architect needs to integrate an Adobe Commerce store with a new Shipping Carrier. Cart data is sent to the Shipping Carrier's API to retrieve the price and display to the customer. After the feature is implemented on the store, the API hits its quota and returns the error "Too many requests". The Shipping Carrier warns the store about sending too many requests with the same content to the API. In the carrier model, what should the Architect change to fix the problem?
Answer options
A: ln_doShipmentRequest()f call canCollectRates() before sending request to the API.
B: Override getResponse, save the response to a variable, check if the response exists, then return.
C: Implement _setCachedQuotes() and _getCachedQuotes(), return the data if the request matches. Correct answer
Correct Answer:
C. Implement _setCachedQuotes() and _getCachedQuotes(), return the data if the request matches.
Explanation

The core issue is redundant API calls for the same cart data, leading to rate limiting. The Adobe Commerce framework provides a built-in caching mechanism for shipping rates within the abstract carrier model to prevent this. By implementing the getCachedQuotes() and setCachedQuotes() methods in the custom carrier model, the results of a shipping rate API call can be cached. The parent collectRates() method first checks for a cached response using getCachedQuotes(). If a valid cached response for the current request exists, it is returned immediately, avoiding another API call. If not, the API is called, and the new response is stored using setCachedQuotes().

Why Incorrect

A. In doShipmentRequest(), call canCollectRates() before sending the request to the API. This is incorrect because doShipmentRequest() is typically for shipment creation, not rate collection. Furthermore, canCollectRates() is a simple check to see if the carrier is active and does not prevent redundant calls based on request content.
B. Override getResponse, save the response to a variable, check if the response exists, then return. This is an ineffective caching strategy. Saving the response to a local variable within a single method execution will not persist the data across different HTTP requests, which is necessary to solve the problem.

References

1. Adobe Commerce Source Code: The logic for rate caching is defined in the collectRates method of the abstract carrier class. It explicitly shows the check for cached quotes before making a new request.

Source: vendor/magento/module-shipping/Model/Carrier/AbstractCarrier.php

Section: collectRates(RateRequest $request) method, lines approx. 125-150.

Content: The method first calls $result = $this->getCachedQuotes($request);. If a result is found, it is returned. If not, it proceeds to fetch the rates and then calls $this->setCachedQuotes($result); to cache the new result.

2. Adobe Commerce Developer Documentation: The documentation on creating custom shipping methods outlines the required classes and inheritance from AbstractCarrier, which contains the caching logic.

Source: Adobe Commerce Developer Documentation

Section: Create a shipping method > Carrier model.

Content: The documentation specifies that the carrier model must extend \Magento\Shipping\Model\Carrier\AbstractCarrier and implement \Magento\Shipping\Model\Carrier\CarrierInterface. The caching functionality is inherited from AbstractCarrier.

Scroll to Top