• Consistent PPM code file system among all nodes on the same server.
• Centralized management of content and customization files.
• Easy restore of the out-of-the-box PPM code file system.

• Prevalidate before the upgrade to decrease the upgrade downtime.
• Upgrade PPM code file system and database independently.
• Avoid long classpath issue in Windows.

All the PPM nodes on the same server share a same set of PPM code files that are collected under the _common folder.

If you want to deploy multiple nodes on a single server, it helps solve the following issues:

• Save you from copying the whole PPM code file system to each node.

  If you want to add a new node, you no longer need to copy the PPM code file system. You just need to do the following.

  1. Update the server.conf file.
  2. Run kUpdateHtml.sh.
  3. Run kStart.sh -name<Node_Name>.
• Make sure all the nodes are always in sync with each other.

This is the folder where all your customizations are put.

The customization folder is structured the same as the <PPM_Home> folder.

If you want to share customizations among servers, you can move the folder to a shared place. Remember to update the com.kintana.core.server.CUSTOMIZATION_LOCATION parameter in the server.conf file to the shared place.

You can use the kSync.sh command to merge contents under this folder to the PPM code file system.

This is where you put your PPM content files (JSP for reports, Excel Report XLSX templates, etc.).

The content folder behaves in the same way as the customization folder, except that you’re supposed to store files that are not likely to break upon PPM upgrade in the content folder. This provides a convenient way to separate files that are considered to be “customizations” and thus more likely to cause trouble upon upgrade (modifications of built-in JSP files, Java classes that are accessing PPM database without using supported APIs) from “content” files which shouldn’t require any specific scrutiny or testing when upgrading PPM.