Return to main navigation Page
Increasing Performance on a Site with Large Quotes
dict(“String”) instead of
The speed for processing and storing
dict(“string”) is faster than
dict(“string”). In general, a simple structure is faster.
Eliminate Revert to Default on line item attributes if you have any for those actions.
They run X times, and they invoke the line item advanced default script every time they run.
Eliminate line item summation attributes.
They also run X times every update.
If you need to loop through line items, store them into temporary variables such as a string or a float dictionary.
After you store them, use the temporary variables instead of looping through line item documents collection.
When building the result string, use a temporary result string in loops in order to minimize the number of large string concatenations.
For more information, see: http://vbforum.bigmachines.com/showthread.php?t=685.
Ensure that the first main doc always has
document number=1 instead of
Use the Run Once For All Line Items option on advanced line item default if you have any loops.
Confirm the final results are correct. If you do not select run once, the advanced default will run for each line item added. If you have many recommended items you are adding at once, this can cause a significant performance penalty.
Rather than calling the same Data Table multiple times with slightly different queries, get table data once, put it into an array, and process the data as you loop through the array.
The size of the Data Table and the number of will influence the impact of this change.
Minimize the number of RTE fields on line item attributes.
There should be no more than 5, as a general rule.
Do not put large text area attributes on the page.
These will be submitted back to the server when an action is performed on the page, even if the action has "leave value unchanged" for the attribute.
Regarding hiding rules, do not loop over line items to determine hiding behavior.
Configuration Performance Best Practices
Minimize number of attributes per flow.
It will be faster to use multiple flows than one flow with many tabs.
Minimize array sets.
Do not use image menus; these need to be loaded on the page.
The larger the images, and the greater the number of images, the more performance will suffer.
Avoiding redundant lists
Having a list of items that repeats a word(s) in all the names is inefficient. Take advantage of labeling your groups more appropriately to avoid redundant content that distracts from the true distinct differences of the items.
Identify words that are used in every line of a group of labels. Many groups of labels have one word that appears in all of them; it draws the eye away from what makes each line unique, and it creates clutter. Remove this word and incorporate it into the group header.
Using the word "Total" on every line of the following list is unnecessary because they're all totals. Instead use a useful group label.
|Good List||Bad List|
Eliminate redundant attribute choices. It is common to have repeated words in the options listed for an attribute. Pinpoint the word being used in all of them and make each one look more unique.
The longer, redundant aspects of the names do not need to be repeated. All of the items in this list are memory of type "DDR SDRAM". We could label this Attribute as "MEMORY (in GB of DDR SDRAM)" or something similar and our list could simply be numbers.
Hiding irrelevant content for different user types
Using Boolean attributes
Boolean attributes are designed to handle true/false and yes/no choices. It is recommended that you use a Boolean attribute instead of a two-option single select menu. It is considered best practice to be mindful of what you are asking the user:
Example: If you are asking the user if they are a student...
|Make a Boolean attribute that asks “Currently a Student”? The user will know to select the box next to it.||Make a Text Attribute with a drop-down or radio button list with the choices “Yes” and “No”.|
An internal property gives CPQ Cloud customers the option to prevent Commerce read-only fields from being posted back to the server after a Commerce action is invoked.
While enabling this property will have nominal impact on performance, it is recommended not to post information back to the server when the data will not have changed since it was last posted.
To enable this property, open a ticket on My Oracle Support.
Desktop Transaction Caching
When a desktop user opens a Transaction, its data will now be cached to reduce the need to access the database. As the user views and edits the Transaction, the data is accessed from the cache, not the database. When the Transaction is saved, the changes are written to the database and are then accessible to other users.
Desktop Transaction caching also allows faster processing of Ajax calls. Ajax is used throughout the Commerce module, such as in AJAX Hiding/Constraint Rules, Auto Update Advanced Modification, and AJAX Formulas. Therefore, faster processing can have a broad impact.
The Desktop application’s auto update behavior is the same whether the Desktop Transaction caching is on or off.
By default, desktop Transaction caching is enabled for both new and existing customers. Work with your Customer Success Manager to discuss how this feature can be most effectively used for your specific implementation.
Although we highly recommend using Desktop Transaction, this feature can be disabled by opening a ticket on My Oracle Support.
Optimized Data Request Size
If Commerce attributes are not on the layout being viewed, or are hidden by a Participant Profile, they will be removed from the generated HTML sent to the browser. This reduces the amount of content that has to be delivered from the server.
If an attribute is affected by hiding rules, and not by the layout or the Participant Profile, the data will still be sent to the browser.
If you need access to attributes not on the layout, see the section Reading Commerce Attributes not on the Layout in the topic Commerce Attributes for more information.
By default, this feature is enabled for both new and existing customers. Although we highly recommend using the optimized data request size feature, it can be disabled by opening a ticket on My Oracle Support.
If you have questions about this feature, contact your Customer Success Manager. On upgrade, they can assess the impact of this feature and disable it if necessary.
This feature depends on Desktop Transaction caching functionality. Turning Desktop Transaction caching off disables this feature.
Line Item Grid (LIG) Pagination Modes
Several Line Item Grid (LIG) pagination modes exist in the Commerce desktop layout, giving you more control over when data is sent to the browser and displayed to the user.
By enabling Grid Paging, the Line Item Grid will display the line items on a page by page basis when a Transaction is opened. The user can then page through the Line Item Grid to display the next page of line items.
In previous versions of CPQ Cloud, you could choose whether or not to enable pagination for a Line Item Grid. Now, you can also choose the way pages are retrieved.
Accessing Pagination Options
To enable or modify pagination for a Line Item Grid:
Click Process Definition under the Commerce and Documents section.
The Processes page appears.
The Layout Editor appears.
The Line Item Grid dialog box opens.
You can choose from the following options:
The Line Item Grid displays all of the line items upon opening the Transaction. This is the default pagination mode for new Line Item Grids.
All of the pages of line items are retrieved from the server when the Transaction is opened. This could mean a longer loading time initially, when opening the Transaction, but allows for faster display when paging through the line items.
This setting is recommended if the load time is acceptable for Transactions with a typical number of line items. This is usually when a typical Transaction has fewer than 200 line items, but because the number of line items columns vary between implementations, your site may have different results..
Only the first page of line items is retrieved from the server when the Transaction is opened. This allows for a shorter loading time initially, when opening the Transaction, but could mean a short delay when paging through the line items.
This setting is recommended for sites with more than 200 line items in a typical Transaction. However, because line items columns vary in size, depending on things like the number of Sub Document attributes, your site may have different results.
This setting can also be useful for sites where typical Transactions have fewer than 200 line items, if users would like a faster load time when a Transaction is opened or an action is completed..
For this setting to take effect, Desktop Transaction caching must be enabled. Desktop Transaction caching is enabled by default.
The appearance of the Line Item Grid will be the same for both Preloaded pages or On demand loading of pages pagination modes. The only difference is invisible to the user: how and when line item information is retrieved from the server.
To enable pagination for a Line Item Grid, navigate to the Commerce desktop Layout Editor, and click the cog icon in the Line Item Grid. A Line Item Grid dialog box opens. Change the setting for Enable Grid Paging and click Ok.
As in previous releases, regardless of which pagination option you choose:
If Grid Paging was previously On demand loading of pages, Grid Paging will be disabled. In all other cases, Grid Paging behavior will be unchanged.
If you open the Line Item Grid dialog box and click Save (whether any changes were made or not) then the pagination behavior would revert to Preloaded pages.
For all pagination modes, the Page Navigation buttons have changed. The increase/decrease page size ([+-]) links, shown below, (previously visible for the Preloaded pagination mode) are no longer available.
The following screen shot shows the new page navigation functionality. The look and feel of the new pagination functionality is similar to existing mobile functionality. Use the Go to drop-down to navigate directly to any page of line items.
SSO Performance Tracing
The duration of each step during a SAML SSO from an external application (such as Oracle Sales Cloud) into CPQ Cloud is now measured. This information can help troubleshoot the source of any delays.
If this is enabled, you can see this information in your log files.
For more information, or to enable this feature, open a ticket on My Oracle Support.
When printing a large Transaction, the Print XML is only generated once and updated as needed.
In previous versions, the Print XML was regenerated during printing when data was requested, even though that data already existed in the Print XML. For example, when another page was printed after the first page, the information that appeared on every page was requested again and the Print XML was regenerated.
Now, the XML recognizes that the data already exists and does not request it again.
This feature depends on Desktop Transaction caching functionality. Turning Desktop Transaction caching off disables the optimization.