CPQ Ecommerce Integration: Batch Multi-Product Line Conversion via submitConfig() restart and product Parameters

Note: Oracle does not specify the release version that introduced these capabilities. The source URL and title contain no version indicator. Verify availability in your account by checking the installed version of the CPQ Ecommerce Integration SuiteApp bundle.

What changed

The CPQ Ecommerce Integration scheduled script (customscript_cpqe_sc_bcl, script ID CPQE-SC-BCL) now supports batching multiple product conversions within a single invocation. Previously, each call to the scheduled script could only handle one product and required all logic in a single action, with an explicit recalcRulesets() call to refresh building blocks. Each separate call corresponds to one transaction save, so multi-product conversions were expensive.

Two new mechanisms eliminate that constraint:

1. submitConfig() with restart and product parameters

Passing restart: true to submitConfig() causes the processing flow to loop back to the first before-event action after submission, re-running building-block refresh and after-event actions. Adding a product parameter (the internal ID of the next product) switches the active product on the next iteration. This enables a single script call to iterate through a task queue of different products and submit each one sequentially without additional transaction saves per call.

2. restartConfig() function

A new restartConfig() function restarts the processing flow without submitting the current configuration. This is designed for a “dedicated product” pattern: a lightweight product whose sole action loads and analyzes transaction lines, builds a task list, and then hands off to the first real product via restartConfig({ product: <id> }). This separates preparation logic from submission logic at the cost of one additional product launch (a few seconds, negligible on large transactions).

Recommended patterns

Common Action pattern (preferred for most cases)

• Create a Common Action in CPQ Configurator and assign it to every product. The common action initializes a window.tasks array (built from getData() against transaction lines) and a window.counter index.
• Subsequent actions read the current task via the counter, set question/answer values (e.g., setValue('MATERIALS', component)), and write transaction column data.
• The final action increments the counter and calls submitConfig({ afterSubmitAction: 'new', restart: haveMoreTasks, product: nextProduct }).
• The User Event script that launches customscript_cpqe_sc_bcl can start with any product—the common action ensures the correct task list is built regardless of which product is first.

Dedicated Product pattern (alternative)

• Create a product whose only purpose is to load transaction lines, build the task queue, and call restartConfig({ product: tasks[0].product }).
• The UE script always calls this dedicated product. It never submits a configuration itself—it delegates to the real products.
• Use this pattern when you want strict separation between analysis and submission logic.

Legacy single-product pattern (not recommended)

• Without restart/product parameters, all logic must fit in one action, you can only process one product per script call, and you must explicitly call recalcRulesets() to refresh building blocks before each submitConfig().
• Mixed-product transactions require multiple script calls, each triggering a separate transaction save.

Key API surface

• submitConfig({ afterSubmitAction: 'new', restart: <boolean>, product: <internalId> }) — submits the current configuration. When restart is true, loops back to the first before-event action. When product is set, switches to that product on restart.
• restartConfig({ product: <internalId> }) — restarts the processing flow without submitting. Used by dedicated preparation products.
• getData({ type, filter, sublists, loadapi, async }) — loads transaction/sublist data for analysis.
• setValue(question, answer) / reset(question) — manipulates CPQ question-answer state.
• recalcRulesets() — forces a building-block refresh. Required only in the legacy single-action pattern; the restart flow handles this automatically.

What to do

1. Audit existing CPQ Ecommerce scripts. If you have UE scripts launching customscript_cpqe_sc_bcl with one product at a time, you are likely incurring unnecessary transaction saves on mixed-product orders.
2. Refactor to the Common Action or Dedicated Product pattern. Move your line-analysis logic into a common action (assigned to all products) or a dedicated orchestrator product. Replace per-product UE calls with a single call that iterates the task queue using restart/product.
3. Remove explicit recalcRulesets() calls if you migrate to the restart-based flow—the automatic before-event and after-event cycle handles building-block refresh.
4. Test with large mixed-product transactions to confirm reduced transaction-save count and overall processing time improvement.
5. Verify SuiteApp version. Confirm that your installed CPQ Ecommerce Integration bundle version supports restart, product, and restartConfig(). Oracle does not specify the minimum version in this documentation.