Technical References
1-37
Cisco Prime Service Catalog 10.0 Reporting Guide
OL-31037-01
Chapter 1 Advanced Reporting Data Mart
Best Practices for Service Design and Reporting
•
Design guidelines for reportable objects
•
Configuring the data mart to support these design decisions
•
The effects of changes in dictionary and service design on the data mart
What does it mean to make items “Reportable”?
Any dictionary or service may be designated as reportable.
Dictionaries
A “reportable” dictionary appears as a query subject in the DictionaryData folder of the Service Catalog
data mart. Dictionary fields are listed in the dictionary dimension in the order in which they are specified
in the dictionary. Any fields exceeding the limits on the number of each type of field (character, date,
number) are excluded from the data mart. The names of the data mart query items will match the field
names specified when the dictionary is defined.
Making dictionaries reportable provides the maximum flexibility for reporting on dictionaries used in
multiple services. You can freely write reports containing data from the dictionaries, the desired fact
table and any relevant dimensions.
Follow these guidelines when naming reportable dictionaries and their component fields:
•
Standardize dictionary names and field names, since these names are now exposed to more people.
•
Develop and adhere to site-wide standards for capitalization and style.
•
Field labels for dictionaries used in multiple forms need to be consistent. In fact, the field label
should closely resemble the field name. The field name is exposed in the dictionary dimension. The
field label would be exposed in the service dimension, if used.
Follow these guidelines when constructing dictionaries to be reportable:
•
If a dictionary is reportable, all component fields appear in the data mart, including fields hidden in
various services. If a hidden field needs to be kept hidden from users in all contexts, place it in a
separate dictionary that is not reportable.
•
Be sure to configure the reserved dictionaries (Customer and Initiator) to contain only fields that are
used in your services. Any fields included in these dictionaries will appear in the data mart.
•
A field name should match its contents. For example, if a field is called “date”, it should be a Date
data type, with only valid dates or date-times allowed as the field values. Failure to do so could result
in a confusing user interface. For example, the presence of any nonvalid date value in the field means
that the Cognos reporting and query tools prevent users from applying date calculations.
•
Similarly, fields which contain numbers should be stored as a Number data type, and an appropriate
size and decimal precision applied. This ensures that numeric calculations can be applied and may
eliminate the need to format the field in the reporting or query tool to ensure a user friendly and
consistent display.
Once a dictionary has been made reportable, it will initially appear as noneditable in Service Designer.
You can change the “Reportable” value to “No” in order to edit the dictionary definition. This behavior
is a double-check, to ensure you are aware of the consequences of changing the definition of a dictionary
that has been made reportable:
•
Added fields are added to the dictionary data in the data mart. Any service requests submitted before
the field was added will simply have no values for the field.