Introduction
The basic idea behind completeness checks of CMS objects is to deliver a control tool to measure possible pain points. By doing so, it brings problems to light that otherwise would have been undetected. Two things will be described in this text:
- a set of rules that are applied to locate potential problems in CMS objects
- a user interface that will show the results of the above rules inside the Intershop management application
The object validation framework provides the foundation necessary to perform completeness checks for all CMS objects (i.e. Pages, Page Variants, Components, Page/Component Templates and Includes).
Possible problems collected per CMS object do not yet have any influence on the CMS object in terms of its operational state or function. For instance, a page containing no visible page variant at a certain time can still be staged, published or exported. Problems are merely collected as is and do not have any consequences.
References
Rules
Mandatory Configuration Parameters
In principle, the creation of a new CMS object can leave mandatory configuration parameters without any value. Some customers may not want to let CMS instances with missing parameter values be part of further processing (i.e. rendering, publishing etc.). The decision concerning which configuration parameter is mandatory and which is optional must be made based on the model artifact (=development time) that defines the parameter instance.
The following kinds of CMS instances must be part of the input set processed by this rule:
- Pages with missing mandatory configuration parameters
- Page variants with missing mandatory configuration parameters; both, whether it is based on a model artifact or on a page template
- Components with missing mandatory configuration parameters; both, whether it is based on a model artifact or on a component template
- Includes with missing mandatory configuration parameters
- Slots with missing mandatory configuration parameters
- View contexts with missing mandatory configuration parameters
Page or component templates are not part of the input set because their configuration parameter values are only applied (during rendering) when there is no child-component or child-page variant specific value. The problem of a missing value of a mandatory configuration parameter is therefore virtually inherited to the leaf node of a pagelet inheritance tree (also known as: component or page variant).
The definition of a missing configuration parameter value is that the invocation of ParameterContainerOverloadingInfo.resolveConfigurationParameterValue(String,LocaleInformation) will return a null reference. A check like this must be done for every mandatory configuration parameter that exists in a repository domain.
Empty Slot and Placeholder
The basic problem is that, for a given time frame, Pages/Includes/Slots might have time periods where they either hold no or only unpublished / hidden components/page variants assigned to them. This defines them as empty during those time periods. This rule is to identify all time periods for all pages/includes/slots within a given validation context where they are either filled or empty.
An example of an empty slot can be seen in the figure below. The error marks represent those time periods where the slot is empty. 
The slots / placeholders of the following content elements (pagelets) will be inspected:
- Page Variants
- Page Templates (especially for empty placeholders with no outgoing placeholders)
- Components
- Component Templates (especially for empty placeholder with no outbound interfaces (aka outgoing placeholders))
The following types of pagelet entry points will be inspected for emptiness:
- Pages
- Includes
- Global Fallbacks of View Contexts
Gaps found in slots / placeholders are only reported locally for the directly affected Page Variant / Component / Page Template / Component Template. These problems are not propagated to any other indirectly affected items where this item is part of a composition path or content template inheritance chain.
User Interface
The UI consists of three different views showing statistical information about reported problems of the above rules.
- An overview providing general element count information about the kind of objects in question
- An overview providing count statistics of problems aggregated per object type and filtered by conditions
- A problems detail page per object type
Overview of General Element Count Information
This overview just contains the numbers of how many CMS objects are available in the selected channel or organization master. Depending on the type of staging environment in which the application server is running, users can update that information with a click on the 'Update' button. For application servers that are part of a live system the update action may have a bad impact on the system's average response time or throughput. Therefore object statistic recalculation in the content area along with other areas only shows the 'Update' button if the server is part of the editing system ( staging.properties).
If this does not suit your needs, there is always the possibility to schedule the job 'Update Shop Statistics' in the SMC.
Overview of Problem Statistic
The problems reported by the two rules can be exclusively switched on and off by the filtered search. Along with other data a filter can be configured to reduce the number of objects for which problems have been reported. As slots and placeholders do not have any visual representation in this overview, the produced validation results are shown in the context of the Component / Page Variant / Component Template / Page Template they belong to. The same applies to View Contexts which contain other Pages or Includes. Any problem reported for them will be visible in the context of the View Context they belong to.
Problem Details
Following a link in the above problem statistic will take you to the details of the selected CMS object type (Page, Include, Component etc.).
The number of CMS objects displayed in this detail view must be equal to the number shown in the previous problem statistic view. In the last column all problems reported for the CMS object will be mentioned. You can search CMS objects by ID or Name. Or you can search by problem type and language. Clicking on the mentioned problem will take you to the CMS object editing area where the problem is located. Leaving you with the possibility to fix the problem and safe your changes. After that the reported problem will disappear from the overview or details listing.