SAP CPQ Performance: When Quoting Is Slow

We start by making the slowness repeatable. Someone has to name the action, because slow is not a measurement: opening a quote, adding a product, changing a quantity, refreshing and saving each run different parts of the pipeline. With the action fixed, we open the Developer Console from the Setup side menu, press Clear, repeat the action once and read the result. The console captures up to 100,000 traces per request, where a request is one click in the application, and every action is listed with its duration. Two cautions from SAP's own documentation shape how we read it. The time shown is server side processing time only, not what the user experiences in total, and having the console open can itself add overhead. It tells us where the server spent its time. It is not a stopwatch for the whole screen.

Then we use the breakdown SAP recommends: database, scripting, formulas and external API calls. Each shows a count, a total time and the slowest entries, and usually one of the four dominates. If scripting dominates, we move to Script Performance, which covers the last thirty days and shows each script's longest and average run time and how many times it ran. SAP documents a script execution limit of 900 seconds for existing tenants and 300 seconds for new ones, and scripts that come close are highlighted. A script does not have to approach that limit to be a problem for a user waiting on a click, though. One that takes a few seconds on every quote change is slow long before anything turns yellow. To test whether scripting is responsible at all, we use the Disable Iron Python Script Execution option, which stops both global and local scripts for as long as the console is open.

Inside a slow script, the same few patterns keep turning up. SAP advises if and else over try and except for performance reasons, and its own example of a loop running 100,000 times shows roughly half a second for the first against five and a half seconds for the second. SAP also advises avoiding the OnEveryTimeQuoteChanged event for time consuming work such as querying Custom Tables or calling a web service, and notes that the AddNewRow method of a container triggers rules by default unless you tell it not to. Loops placed in OnItemAdded deserve suspicion for a simple reason: that event runs for every item separately. None of this is exotic. It is ordinary scripting done under deadline, and it adds up. When a tenant needs that cleanup done next to other changes, it usually falls under customization and optimization work on the existing setup.

If the console points at formulas or queries rather than scripts, the question becomes what the quote is being asked to compute. Formula time grows with the number of items it touches, which is why a large quote exposes problems that a small test quote never showed. In Quote 2.0 there is a discounts option that calculates discounts only for changed items, and an option to make Variant Configuration and Pricing calls on demand instead of on every configurator change. For quotes that use SAP Variant Configuration and Pricing, SAP recommends restricting a quote to 100 items and finding a balance between the number of items and the complexity of the pricing procedure. That figure belongs to that service, and we treat it that way rather than as a general limit for every SAP CPQ tenant. SAP also notes that audit data tables are large because they log every activity, and that querying them directly should be avoided, which is worth remembering when a custom report or script reads from them.

Sometimes the measurements point outside SAP CPQ, and that is a legitimate finding. When the external API section carries most of the time, the fix belongs with the connected system or with the place in the flow where the call is made, and our SAP CPQ integration work is the natural place to review it. Tax calculation is a common example of a service that a quote ends up waiting on, and where that call sits in the architecture is covered in our article on tax calculation patterns in CPQ architecture.

When a slowdown will not yield, or when it is intermittent, we prepare the case for SAP support the way SAP asks for it: the exact user action with screenshots and the data used, the ID of the user who saw the problem, the timestamp, an HTTP trace from the browser in HAR format and the Developer Console trace exported as an XLSX file. A report with those attached moves faster than one that says quoting is slow. If you would rather learn first whether your setup has structural problems, an SAP CPQ health check reviews the configuration before it turns into an incident, and the same method can be handed to your own team through training built for internal administrators.