This modification policy letter describes the difference between
customizationsand the scope of technical support regarding both.
This policy applies to all active releases of
Classic PPMOn-Premise and
Classic PPMSaaS including 15.x, 14.x, 13.x, and older releases.
Configurationsare the use of documented features to modify the behavior of the as-shipped product. Examples of documented features you can use to create configurations are: process flows, Studio portlets, and XOG integrations. Documented features are supported by CA but the related configurations themselves are not. For example, the Studio feature used to build a graph portlet is supported, but the particulars of the underlying NSQL code to supply data to the portlet, is not. In these situations, CA will verify that documented features are operating as expected given the specific configuration change, but CA will not troubleshoot the configuration itself. In addition to NSQL, other examples of configuration changes not supported are GEL scripts, changes made to the Business Objects universes, domains, or reporting attributes, and custom XOG integrations which may/may not result in performance issues. CA will work with the customer to isolate problems experienced when using documented features to confirm that they are a result of incorrectly performing product features (and not incorrectly designed or implemented configurations).
Customizationsare the use of undocumented means to modify product behavior. Examples of customizations include database schema additions, triggers, and code modifications. All code customizations should be prefixed with Z_ to assist both the customer and CA identify where customizations exist in the system.
The customer should understand that, whereas configurations will upgrade from version to version with the modifications intact (insofar as they are still valid in the new version), customizations will not. Customizations must be at least re-applied to upgraded systems and in many cases may need to be redesigned and re-implemented to work with changing product functionality. CA will support a customized system excluding only the portions that are directly impacted by the customizations. Support will commonly ask the customer to remove a customization for diagnostic reasons when it is potentially contributing to, or obscuring, the product issue being diagnosed. The customer must comply with this request to receive product support.
CA may, at its discretion, review customizations and may recommend alternatives; in some cases Support may inform the customer that they will not support the system at all if that customization is used. Customizations are not accepted in
ClaritySoftware-as-a-Service (SaaS) environments under any circumstances.
To reduce the risk of CA denying support for a particular problem caused by modifications, apply the following guidelines:
- Do not add fields to stock databases tables. Instead, create new tables to hold custom data that can be joined with the stock table.
- Direct access to stock tables should be read-only; to update stock tables, use the XOG capabilities.
- Triggers should fire conditionally, and the conditions should be uncommon. Triggers should only read stock data. They should be simple and be written to avoid deadlocks. Triggers should be disabled during upgrades.
- All custom database objects should be removed prior to product upgrades and then added back afterwards.
- Do not modify source code, including Java, XML, XSL, XBL, PMD and all other such system files provided with the product.