Technical References

1-42
Cisco Prime Service Catalog 10.0 Reporting Guide
OL-31037-01
Chapter 1 Advanced Reporting Data Mart
Best Practices for Service Design and Reporting
• If your requirements for the number of fields per dictionary (or service) exceed the defaults,
multiply the number of fields of each type times the size allocated to the data type (the
DATA_STRING_MAX_SIZE for character data, 7 bytes for each date field and 20 bytes for each
numeric field). If the result exceeds the row size limit for the target database, review your
requirements.
• Note your settings and ensure that the system administrator has access to this data when installing
Advanced Reporting.
Changing Dictionaries (and Services)
The service design methodology must also consider how best to accommodate changes to previously
deployed dictionaries and services. These considerations need to include both the effects on the Service
Catalog transactional system and effects on the data mart.
Assume that:
• A dictionary is reportable and has been used in a service that has been ordered, and
• The data mart (and its metadata) has already been built and populated for those requests.
What are the effects of changes to the dictionary on the configuration of the data mart? These effects
manifest in two ways:
• Changes to the reporting metadata, that is, the dictionary and service-based dimensions, and their
component fields, available as query subjects and query objects in Ad-Hoc Reports and Report
Designer.
• Changes to the data loaded into the data mart via the Extract-Transform-Load (ETL) process.
Adding a field to a reportable dictionary
The next time the data mart load process is run, the job which builds the reporting model (the metadata)
adds the field as a query item to the query subject corresponding to the dictionary. The ETL process will
now include that field. The field value is populated for requisitions submitted after the change to the
dictionary was made, and blank for all requisitions submitted before the date the change was made.
The only caveat with this scenario is that the field cannot be added if the dictionary now exceeds the
maximum number of fields allotted for each data type in a dictionary or service-based dimension.
(The number of fields is specified when Advanced Reporting is installed. System administrators may
customize default values of 60 character fields, 10 date fields, and 10 numeric fields for each dictionary,
and 80 character fields, 20 date fields, and 20 numeric fields for each service. Be sure to check with the
system administrator if in doubt.)
In both cases, the current software would add the field as the last query item in the query subject
representing the dictionary or service. This will probably not correspond to where the field appears on
a service form.
Adding a new reportable dictionary
The dictionary becomes a new query subject, and all its fields, query items, as expected. Data is loaded
into the dictionary as of the date it was made reportable.
A possible difficulty comes in reporting on requests for an existing service over a time period that spans
the addition of the dictionary. If you include fields from the new dictionary in the report, only
requisitions that contain that dictionary are included. You would be forced to use the service-based query