Best Practices on database customizations in Clarity

Products

• Clarity PPM On Premise
• Clarity PPM SaaS

Issue/Introduction

Custom database objects in Clarity/Data Warehouse - Best Practices on database customizations

Is the creation of custom database views/functions/procedures is something that is possible and what Broadcom's official stance is on allowing this type of customization

Environment

Release : All Supported Clarity releases (On Premise)

Note: For SAAS customers database customizations are typically not allowed

Resolution

We do not support custom objects on Clarity or Data Warehouse database.

This means that whilst you can add them, the burden of testing and ensuring things work will fall on your developers. So our official stance is that adding those objects is allowed but not supported. We cannot help with adding them or approving them, or fixing them, or fix any issue caused by them.

If you would like to do it, it would be something you do and support.

Guidance on how to minimize any issues due to custom database objects:

• Please ensure you follow the convention of starting all custom database objects with Z_
• Prior to an upgrade, remove all custom objects from the database. After upgrade they can be readded
• Ensure you have fully documented the changes so the whole team is aware of them in case they need to remove anything in your absence
• Having a document shared with all the members of your team containing all the custom database objects on your environment is a best practice

For Clarity:

• Ensure the OOTB jobs run without any added time
• Ensure application performance is unchanged and no errors within the app

For Data Warehouse:

• Ensure the Load Data Warehouse jobs work as expected and there is no added time/errors etc.
• Ensure the reports are fast and there is no issue with them

Additional Information

The above is also valid for Oracle table partitioning, it is not a supported change and has to be reverted before Clarity upgrade