How to identify and fix the hidden product catalog issues

Structural nuances can be difficult to detect through the standard Siebel UI because they are distributed across hundreds or thousands of product definitions.

Siebel product catalogs usually do not break all at once. As catalogs grow over the years, teams add products, reuse old structures, extend models, and carry forward relationships that once made sense but no longer do. The result is a catalog that still works, but not as efficiently as it should. Configurator load times go up, ordering performance starts to drag, and finding the reason becomes harder with every release. Here are few examples of common structural issue patterns:

• Inefficient relationships. Missing or incorrect class configurations that expand the search space unnecessarily.
• Oversized domains. Large or growing domain lists that slow down configurator load times.
• Redundant rules. Duplicate constraints that add processing overhead.
• Inactive structures. Deactivated child products still referenced in active parent hierarchies.

The tricky part is that these issues are rarely obvious in the Siebel UI. They are spread across products, classes, relationships, promotions, and rules.

This is exactly where the eScript-based Product Analyzer Toolkit helps. It gives Siebel administrators a practical way to inspect product hierarchies, apply rules, and find the parts of the catalog that need attention. Because it runs natively in Siebel, it is a strong fit when you want in-environment diagnostics without standing up additional infrastructure.

How the toolkit identifies and analyzes catalog issues

Imagine a Siebel administrator trying to understand why a high-priority product family has become harder to configure over time. The symptoms are clear, but the cause is not and manual review is slow and unreliable.

The eScript-based Product Analyzer Toolkit simplifies this process using the three core components: the PMA Engine, the PMA Product Broker, and Rule Definitions.

In simple terms, the PMA engine walks the selected product hierarchy, the Product Broker pulls and caches the catalog data needed for analysis, and the rules check for known structural patterns that tend to affect performance. Instead of reviewing definitions manually, teams get a more structured way to see where the issues are and how far they reach.

The complete analysis flow is straightforward:

1. Select the scope. The administrator selects a root product and the set of rules to evaluate.
2. Traverse the hierarchy (PMA Engine). The engine scans the product hierarchy top-down, mapping products by depth to understand the structure.
3. Apply rules bottom-up. Rules are executed from the deepest level upward, allowing issues in child definitions to roll up and reveal their impact on parent structures.
4. Retrieve and optimize data (PMA Product Broker). The Product Broker queries the Siebel data model, builds structured product objects, and caches them to avoid redundant lookups during traversal.
5. Evaluate conditions (Rule Definitions). Each rule checks for specific issues, such as oversized domains, anonymous classes, or invalid relationships, and returns violations.
6. Generate actionable output. The toolkit produces summary statistics and a structured list of violations with full path context, helping teams quickly identify what needs to be fixed.

In practice, this reduces the time spent searching through the catalog and increases the time spent resolving issues that impact performance.

The predefined rules cover some of the most common catalog issues. They can highlight oversized domains, anonymous classes, class relationships with only one domain product, product relationships that incorrectly include a class, and searches for specific class IDs in the hierarchy. These checks are useful because they focus on the patterns that quietly build up in long-lived catalogs and often sit behind avoidable performance overhead.

Prerequisites and dependencies

• Siebel Tools or Siebel Web Tools access with a development workspace.
• Sufficient Siebel application server resources during analysis runs – recursive traversal of large hierarchies consumes application server memory and CPU proportional to hierarchy depth and breadth.
• Siebel REST API access with a valid session token.

Predefined rules in the toolkit

Key benefits

One of the biggest strengths of the eScript toolkit is how naturally it fits into a Siebel team’s normal way of working. It runs inside Siebel, works with live data, aligns with existing access controls, and can be called through multiple mechanisms such as REST, workflow, simulator, or eScript. It is also relatively quick to deploy through a SIF import and workspace delivery.

That said, it is not the right answer for every case. Recursive analysis of large hierarchies can increase application server load, and catalog-wide analysis is not really its sweet spot. The output may also need some post-processing if teams want more polished reports. So this toolkit is best viewed as the practical, in-environment option: fast to start, useful for targeted analysis, and easy to extend when the team has eScript skills.

Getting started

A good way to begin is to run the predefined rules against your highest-priority product families and treat that as a baseline. From there, triage the issues by severity, assign fixes to the catalog administration team, rerun the analysis, and compare results before and after the cleanup. Doing that before major catalog releases turns analysis into part of release hygiene instead of a one-time exercise.

To access the eScript-based Product Analyzer Toolkit, log a Service Request with Oracle Support under Siebel CRM and reference Patch ID 39161569 in the SR summary. The patch includes sample payloads and detailed documentation to help you configure and extend the toolkit for custom rules.