Cisco Cisco Prime Service Catalog 10.0 Technical References
5-11
Cisco Prime Service Catalog 10.0 Configuration Guide
OL-31034-01
Chapter 5 System Administration
Performing Application Housekeeping
•
ETL process is normally scheduled to run on a frequent basis. Hence requisition data would have
been captured into Datamart prior to their migration to the historical tables. To ensure there is no
data loss in the Datamart, always set the historical requisition retention period to be greater than the
frequency of the ETL process. For example, if ETL is set to run every 30 days, the historical
requisition retention period should be set to 31 days or more.
been captured into Datamart prior to their migration to the historical tables. To ensure there is no
data loss in the Datamart, always set the historical requisition retention period to be greater than the
frequency of the ETL process. For example, if ETL is set to run every 30 days, the historical
requisition retention period should be set to 31 days or more.
•
The process that migrates historical transaction data is automatically put on hold when it detects that
the most recent ETL process timestamp is earlier than the cutoff date. For example, if the last ETL
execution was on May 1st 12pm and the migration is going to select requisitions completed before
May 1st 12:30pm, the migration process will exit immediately. This ensures that data are kept in the
current transaction tables for extraction into Datamart before they get migrated.
the most recent ETL process timestamp is earlier than the cutoff date. For example, if the last ETL
execution was on May 1st 12pm and the migration is going to select requisitions completed before
May 1st 12:30pm, the migration process will exit immediately. This ensures that data are kept in the
current transaction tables for extraction into Datamart before they get migrated.
•
If your organization has the need to rebuild Datamart occasionally to capture backdated data (for
example, making a dictionary or service reportable after the fact), the changes will not take effect
on historical transactions by re-running the ETL process. In fact, the historical data will not be
recoverable in the Datamart once they have been purged. To ensure such Datamart rebuild process
is still possible, configure the data retention period to a duration that has provisions for backdated
changes. In addition, the Datamart should no longer be emptied in a rebuild process for the reason
above. Only the portion of data that are still available in the current transaction tables can be deleted
and re-inserted into the Datamart during the re-execution of ETL.
example, making a dictionary or service reportable after the fact), the changes will not take effect
on historical transactions by re-running the ETL process. In fact, the historical data will not be
recoverable in the Datamart once they have been purged. To ensure such Datamart rebuild process
is still possible, configure the data retention period to a duration that has provisions for backdated
changes. In addition, the Datamart should no longer be emptied in a rebuild process for the reason
above. Only the portion of data that are still available in the current transaction tables can be deleted
and re-inserted into the Datamart during the re-execution of ETL.
Key Settings for Historical Requisition Processing
1.
newscale.properties file (located in the RequestCenter.ear/config directory)
–
reqArchival.poller.cron - This controls the frequency of the background process that migrates
historical data. It uses the standard cron syntax and is scheduled to run every 30 minutes.
historical data. It uses the standard cron syntax and is scheduled to run every 30 minutes.
–
reqArchival.process.maxRecords - This controls the maximum number of requisitions to be
processed in each run. A higher number may be set if the process is intended to be run for a
longer period of time during scheduled maintenance.
processed in each run. A higher number may be set if the process is intended to be run for a
longer period of time during scheduled maintenance.
–
reqArchival.cutOffDate.days - This controls the retention period of completed requisitions in
the current transaction tables. By default, the retention period is set to 365 days.
the current transaction tables. By default, the retention period is set to 365 days.
–
reqArchival.process.batchSize - This controls the number of historical requisitions included
during each database commit. A larger batch size will shorten the processing time but will
require higher amount of temp space or rollback segment in the database server.
during each database commit. A larger batch size will shorten the processing time but will
require higher amount of temp space or rollback segment in the database server.
2.
support.properties file (located in the RequestCenter.ear/config directory)
–
reqArchival.poller.enable - This controls whether the application instance can be used to run the
historical requisition migration process. In a clustered Request Center environment, only one of
the nodes will be used to execute the migration process at any time. One or more of the nodes
may have this property set to "false" if the server is a less powerful machine or is meant for
disaster recovery purpose.
historical requisition migration process. In a clustered Request Center environment, only one of
the nodes will be used to execute the migration process at any time. One or more of the nodes
may have this property set to "false" if the server is a less powerful machine or is meant for
disaster recovery purpose.
Other settings in the above files should remain unchanged under normal circumstances.