CSA: Maintain and Monitor CA PPM

Start and stop services, open server ports, disable IGMP snooping, run a health report, check log files, back up and restore your cappm installation, compile Oracle database objects, set the file directory size, and set GEL tag restrictions.
ccppmop151
Start and stop services, open server ports, disable IGMP snooping, run a health report, check log files, back up and restore your 
CA PPM
installation, compile Oracle database objects, set the file directory size, and set GEL tag restrictions.
2
Start and Stop Services
Follow these steps:
  1. Log in to CSA.
  2. Click Home, All Services.
  3. Select the check box next to each service that you want to start or stop.
  4. To start the services, click Start.
  5. To stop the services, click Stop.
Open Server Ports
CA PPM
 requires several open network ports for client-to-server and server-to-server communications. Ports are often closed by default or are blocked by firewalls for security reasons. Any ports that you select during the installation or configuration must be open.
Open the necessary ports using the documentation that is provided for your operating system or firewall. The following information lists the default value, type, and description for each port that is used in 
CA PPM
.
In UNIX systems, port numbers below 1024 are typically reserved for the root user.
Best Practice
: If you are using a software firewall, provide an exception at the executable level instead of the port level. This action ensures the dynamic ports that get allocated are open for the proper multicast communication. See
ephemeral ports
in the following list for more information.
  • 80 or 443
    Defines the HTTP or HTTPS port number that the default CA PPM Application (app) service uses.
    Type:
    Client to the 
    CA PPM
     application server
  • 8090
    (Apache Tomcat application server only) Defines the HTTP port number that CSA uses.
    Type
    : Client to the 
    CA PPM
     application server
  • 1433 (MS-SQL) or 1521 (Oracle)
    Defines the JDBC port number that is used to communicate with the database.
    Type:
    Server to Database Server
  • 23791
    (Apache Tomcat application server only) Defines the RMI port number that the CA PPM Application (app) service uses.
    Type:
    Server to the 
    CA PPM
     application server
  • 23792
    (Apache Tomcat application server only) Defines the RMI port number that CSA uses.
    Type:
    Server to the 
    CA PPM
     application server
  • 9090
    Defines the Multicast port number that CSA uses.
    Type:
    Server to the 
    CA PPM
     application server
  • 9091
    Defines the RMI port number that the Beacon service uses.
    Type
    : Server to Server
  • Ephemeral Ports
    Defines the ephemeral (short-lived) port range. All operating systems specify an ephemeral port range by default. The traditional BSD range is 1024 through 4999, though the IANA suggests 49152 through 65535. The range varies between operating systems, and it is possible to disable. You can use any range values in 
    CA PPM
    . However, you must enable a range. This port is primarily for multicasting to function.
    Type:
    Server to Server
IGMP Snooping
For multicast traffic to be delivered properly with Cisco Catalyst Ethernet switches, disable IGMP Snooping (or enable both IGMP Snooping and IGMP Querier) for the VLAN to which the 
CA PPM
 servers belong. Previously, IP multicast was treated much the same as IP broadcast, and Ethernet switches flooded multicast traffic to every interface. By default, Cisco Catalyst switches take the opposite approach and do not flood multicast traffic to all interfaces. 
With IGMP snooping, layer 2 switches can make intelligent multicast forwarding decisions by examining the contents of each frame layer 3 IP header. The switch maintains a multicast group list so that it only delivers multicast packets to interfaces belonging to a particular group.
Run Health Reports
You can run a health report to validate your 
CA PPM
installation. Any errors in this report can reveal the solution to known or undiscovered problems in the system. The CSA overview page contains a health overview report that covers multiple servers in the cluster. This report shows only errors or warnings for selected servers.
Each server has its own health report that is accessible from the server health report page. Unlike the health overview report, the health report shows all health check results: success, warning, or error. The status indicators provide the following information:
  • Green
    Indicates that the item has valid status.
  • Red
    Indicates that a software version is not compatible with the current supported versions for 
    CA PPM
    .
Health check results are updated only when you run the report. The results are not dynamically updated. Run the report after any significant system changes.
Follow these steps:
  1. Log in to CSA
  2. Click Home, Servers.
  3. Click the name of the server.
  4. Click Health Report.
  5. Click Run.
    If the health report was run before, the previous results display first.
  6. Click Run again to update the health report with the latest status associated with installed 
    CA PPM
     components such as db, app, bg, and beacon services.
Tip: You can also run a new health report. See CA PPM System Health Report.
 
Check Log Files
Check log files when an installation, upgrade, or usage issue arises to find an explanation and to troubleshoot. By default, 
CA PPM
 writes only error messages to the log files. If CA Technical Support helps you with an issue, you may be asked to configure the system to display detailed debugging messages. The log files are stored by default in the logs directory under the 
CA PPM
 home directory. Each server has its own logs directory. You can also select an alternate logs directory in CSA.
You can use a text editor to view the log files. If you have a cluster of 
CA PPM
servers, the log files for each server apply only to that server. You can configure the logs to add more detail or to update or remove entries. You can have the log file configuration changes take effect immediately. Otherwise, you must restart the CA PPM Application (app) and
CA PPM
 Background (bg) services before the changes take effect.
The following table contains the list of default and common log files. For each log, the file name, format, and contents are listed.
Each cloned instance of a service has its own log files. For example, app2, bg3, and so forth, have a matching set of log files delineated by id. The initial app and bg instance does not have an id.
Log File Name
Format
Contents
admin.log
Plain text
A record of administrative activities. These activities are driven through the
admin
command or an equivalent CSA operation.
app{id}-access-{date}.log
Plain text
Session activity (http/s requests) for the foreground service.
app{id}-bootstrap-ca.log
Plain text
ODF Bootstrap activities, typically occurring during an upgrade and patch operation.
app{id}-ca.log
Plain text
The primary log for all activities in the foreground service.
app{id}-dwh.log
Plain text
Data warehouse-specific activity in the foreground service.
app{id}-process-engine.log
Plain text
Events that are recorded by the Process Engine Monitor in the foreground service.
app{id}-system.log
Plain text
System-level output that is written directly to the console (STDOUT) for the foreground service. This output is typically service start-up messages or OS messages.
beacon-system.log
Plain text
System-level output that is written directly to the console (STDOUT) for the beacon service. This output is typically service start-up messages or OS messages.
bg{id}-bootstrap-ca.log
Empty
This file is automatically generated, but is typically empty.
bg{id}-ca.log
Plain text
The primary log for all activities from the background service.
bg{id}-dwh.log
Plain text
Data warehouse-specific activity in the background service.
bg{id}-process-engine.log
Plain text
Events that are recorded by the Process Engine Monitor in the background service.
bg{id}-system.log
Plain text
System-level output that is written directly to the console (STDOUT) for the background service. This output is typically service start-up messages or OS messages.
completion.log
Properties
A record of installation or upgrade steps that have been completed for each component. Do not modify this log without the assistance of CA Support.
dbtools-bootstrap-ca.log
Empty
This file is automatically generated, but is typically empty.
dbtools-ca.log
Plain text
Activity from DBTools. DBTools is the tool that modifies database entities and data during an upgrade or patch process.
dbtools-dwh.log
Empty
This file is automatically generated, but is typically empty.
dbtools-process-engine.log
Empty
This file is automatically generated, but is typically empty.
nsa-access-{date}.log
Plain text
Session activity (http/s requests) for the system administration service.
nsa-bootstrap-ca.log
Empty
This file is automatically generated, but is typically empty.
nsa-ca.log
Plain text
The primary log for all activities from the system administration service.
nsa-dwh.log
Empty
This file is automatically generated, but is typically empty.
nsa-process-engine.log
Empty
This file is automatically generated, but is typically empty.
nsa-system.log
Plain text
System-level output that is written directly to the console (STDOUT) for the system administration service. This output is typically service start-up messages or OS messages.
odf-bootstrap-bootstrap-ca.log
Empty
This file is automatically generated, but is typically empty.
odf-bootstrap-ca.log
Empty
This file is automatically generated, but is typically empty.
odf-bootstrap-dwh.log
Empty
This file is automatically generated, but is typically empty.
odf-bootstrap-process-engine.log
Empty
This file is automatically generated, but is typically empty.
upgrade-bootstrap-ca.log
Empty
This file is automatically generated, but is typically empty.
upgrade-ca.log
Plain text
Messages from individual
CA PPM
upgrade scripts that are executed during an upgrade process.
update-dwh.log
Empty
This file is automatically generated, but is typically empty.
upgrade-process-engine.log
Empty
This file is automatically generated, but is typically empty.
xogAdmin-bootstrap-ca.log
Empty
This file is automatically generated, but is typically empty.
xogAdmin-ca.log
Plain text
Activity from the XOG Admin client. XOG Admin client is the tool that inserts or modifies data during an upgrade or patch process.
xogAdmin-dwh.log
Empty
This file is automatically generated, but is typically empty.
xogAdmin-process-engine.log
Empty
This file is automatically generated, but is typically empty.
Edit the Logger Configuration
The primary log files are the
ca
log files. Most information that the product logs goes to one of these files. This information includes system errors and information messages such as debug messages. You can configure which log messages appear in the ca log files.
Two important log message attributes include:
  • Category
    Indicates the location in the product from which the message was logged.
  • Level
    Indicates the severity of the message.
You can adjust the logger configuration to filter log messages that are based on the category and level. The product reports all messages that fall under the com.ca category with level error or above (Fatal). You can add extra categories with information, or can add debug levels to get more information when troubleshooting a problem.
If you have more than one
CA PPM
Background (bg) service running and have enabled debugging to troubleshoot a
CA PPM
Background (bg) service issue, it is useful to turn off all services except the one that is configured for debugging. This process ensures that all jobs or processes go through this
CA PPM
Background (bg) service and generate the desired debug messages. Restart the
CA PPM
Background (bg) service so that the changes take effect, and then check the log file (bg-ca.log).
Follow these steps:
  1. Log in to CSA.
  2. Click Home, Servers.
  3. To edit the log information, click the Properties icon for the server.
  4. Click the Logs tab.
  5. Click the Edit Configuration sub tab.
  6. In the Properties section, complete the following fields:
    • Detect Log Configuration Changes Automatically
      Indicates if the log configuration changes take effect immediately. Select this check box to have changes you make take effect immediately. This option applies to
      CA PPM
      Background (bg) and CA PPM Application (app) services that are running in Apache Tomcat.
      If you select this option, restart any affected services to ensure that the change takes effect.
    • Alternate Logs Directory
      Defines the alternate logs directory for this server. This path must be a valid absolute path to a directory on the server. For example, /niku/logs (Unix) or E:\logs (Windows).
    • Default Trace Threshold (Seconds)
      Specifies the basic threshold over which trace information for a given request is written. This value overrides the logger.xml category levels.
  7. In the System Logging section, complete the following fields:
    • Maximum number of system logs (per service)
      Indicates the number of system log files that you want to keep for each service. Changing this value requires restarting the services. The default value is five.
    • Maximum size of each system log
      Indicates the size of the system log files for each service in megabytes. Changing this value requires restarting the services. The default value is 5 MB.
  8. In the Kettle Logging section, complete the following field:
    • Kettle Log Level
      Indicates the level of log activity you want to see when the Load Data Warehouse and the Load Data Warehouse Access Rights jobs run. The log data is stored in the Data Warehouse logs in CSA.
      Values
      : Nothing, Error, Minimal, Basic, Detailed, or Row level.
  9. In the Trace Thresholds section, click Add Threshold, and complete the following fields:
    • Threshold (Seconds)
      Specifies the number of seconds after which the actions that are identified by the action patterns are traced. A value of -1 means no threshold is set for the given actions. This value is useful for disabling thresholds for long-running actions.
    • Patterns
      Identifies the actions that are traced when the threshold is exceeded. Enter the pattern in a comma-delimited format. For example:webRequest/npt.overview, xogRequest/XOG::project::read, or serviceRequest/*.
  10. In the Categories section, complete the following fields:
    • Name/Other Name
      Defines the category for adding or changing. Select from the drop-down. To enable a category that is not listed in this list, enter the category in the Other Name text field.
    • Appender
      Directs logging output to a different destination. To direct a category to a separate file, add a STDOUT appender with a unique file name and associate the category with the new appender.
    • Priority
      Defines the debug level. The higher the level, the higher the priority.
      Values:
      • Fatal. Indicates that a critical service is not running.
      • Error. Indicates a problem that can restrict system functions.
      • Warn. Indicates that 
        CA PPM
        encountered a problem, but continues to run.
      • Info. Indicates the system status (such as service start) and does not always indicate a problem.
      • Debug. Displays detailed information that helps you or CA Technical Support resolve a problem.
      • Trace. Displays low-level technical information. This level produces large volumes of data. Use this value only when requested by CA Technical Support.
      • All. Displays all messages.
    • Additive
      Indicates if new messages are appended to the logs. To append messages, select this check box. If this check box is clear, logs are occasionally overwritten with new information.
  11. Save the changes.
  12. Restart the affected services.
Logging can decrease system performance, especially higher priorities such as Debug and Trace. Only enable the additional logging when it is necessary or when you are instructed to do so by CA Technical Support. Disable the additional logging as soon as it is no longer required.
User-Specific Logging
You can enable some logging categories for specific users. To enable logging for a specific user, append the user name to the end of the standard logging category. For example,
trace.server.user.jsmith
enables the server-side performance logging for the user jsmith. The user keyword indicates that the last category segment is the user name. The user name is used as a filter for logging events on the category. In this case, the trace.server category. Changes to SQL logging settings for a specific user only take effect when the user logs in. Therefore, the user must log in again after each user-specific logging configuration change.
Action Tracing
Perform Action Tracing (previously known as SQL trace) only at the request of and with the guidance of 
CA PPM
 Technical Support. Only perform this activity for short amounts of time to troubleshoot particular actions. Action Tracing must then be disabled.
Video: SQL Trace Activation
The following video is provided by CA Technologies.

To play this video in full screen, click the YouTube logo to the right of Settings at the bottom of the video. 
Back up a 
CA PPM
 Installation
Whenever you plan a significant update to the production system, back up the current system so that you can restore it. To store the database backup, use the backup directory.
Follow these steps:
  1. Log in to CSA, and verify that all services are stopped except the database. If the database service is not installed, do not be concerned.
  2. Open a command line on the CSA application server, and issue the following command:
    admin backup
  3. To accept the default values, press Enter.
    The backup command copies the 
    CA PPM
    installation directory into a backup directory.
Back up an Oracle Database
Follow these steps:
  1. From the database server command line, use the Oracle Database Export utility
    expdp
    .
    See the Oracle documentation for the detailed steps to use this utility. The following example shows an export command:
    expdp clarity/password FULL=y DIRECTORY=data_pump_dir DUMPFILE=clarity.dmp LOGFILE=myclarityexp.log SCHEMAS=clarity
  2. Copy the .dmp and the init<SID>.ora files to the backup directory that the backup command created.
Back up a Microsoft SQL Server Database
Back up a Microsoft SQL database using the SQL Server Enterprise Manager. See the Microsoft documentation for details.
Restore a 
CA PPM
 Installation
The operation to restore an installation uses the backup of the file system and database that was made before the upgrade process was started.
Best Practice:
Only restore a 
CA PPM
 installation after you have exhausted all other options.
Follow these steps:
  1. From the command line, stop all services.
    service stop all
  2. Restore the database using your standard database management tools and the backup that was taken before you started the upgrade process.
  3. Restore 
    CA PPM
    using the restore script from the backup directory:
    (
    Windows
    )
    restore.bat
    (
    Unix
    )
    restore.sh
    See
    Back up a 
    CA PPM
     Installation
    .
  4. When complete, restart all services:
    service start all
  5. (Optional) Reinstall older reports.
    See
    Installing and Upgrading
    that corresponds to the version for which you installed reports.
Compile and Analyze Existing Oracle Database Objects
Compile and analyze the database in the following circumstances:
  • When you export and import the database to another server to perform test upgrades
  • When you reorganize the database on your production server
Compiling and analyzing ensures that all database objects are valid. If database objects are not compiled before upgrading the 
CA PPM
schema, upgrade failures can occur.
Follow these steps:
Open a command line on the CSA application server, and issue the following commands:
admin db compile admin db analyze
The database objects are compiled and analyzed.
Set File Directory Size
In CSA, you can specify a file storage size limit at the directory level. If a limit is specified, a new sibling directory is automatically created for storing subsequent files once the limit is reached. The size limit also applies to documents that you import into 
CA PPM
 using the XML Open Gateway (XOG).
Setting the directory size limit does not affect the size of pre-existing folders.
Follow these steps:
  1. Log in to CSA.
  2. Open Home, and click Servers.
  3. Click a server name.
  4. Click the Documents and Search sub tab.
  5. In the Document Manager Options section, in the File Store Directory Size Limit field, specify the file storage size limit for a directory.
Set GEL Tag Restrictions
To control the GEL tag restriction, use the following commands:
admin general restrict-gel-tags
Sets the value of the gelTagRestriction property to
on
.
admin general allow-gel-tags
Sets the value of the gelTagRestriction property to
off
.
The property gelTagRestriction is referenced to determine whether gel tags are restricted. The property is on the system element. The element is optional.
Use the values
on
or
off
to set GEL tag restrictions for the environment. Specifying any value other than
off
enables the GEL tag restriction. GEL tag restrictions are off by default.
Altering GEL tag restrictions requires that you restart the app and bg services.
Examples
Properties.xml file with no GEL tag restriction:
<system online="true" multiCurrency="false" licenseTypes="old" singleTenantMode="true"/>
<system online="true" multiCurrency="false" licenseTypes="old" singleTenantMode="true" gelTagRestriction="off"/>
Properties.xml file with GEL tags restricted:
<system online="true" multiCurrency="false" licenseTypes="old" singleTenantMode="false" gelTagRestriction="on"/>