How To Implement a Property Filter

Introduction

Repository filters allow the manipulation of repository framework objects as they are passed through the repository framework. Property filters hide or modify existing properties of resources, or add virtual properties to resources.

Relevant Repository Framework APIs and documentation

A prerequisite for developers starting repository filter implementation is an understanding of the concepts described in Repository Framework Concepts (RCO).

This tutorial describes the usage of the following repository framework APIs that are relevant for implementing your own repository filters (for example, a property filter).

• com.sapportals.wcm.repository.filter.*
  Contains interfaces and classes for defining repository filters.
• com.sapportals.wcm.repository.*
  Contains the repository framework interfaces and classes for handling framework objects.

Coding in Detail

Developing a filter means implementing a filter manager and the filter itself. The minimum requirement is that you implement the read filter feature. The example deals with a property read filter. It manipulates the system's createdby property by returning a virtual property value for every resource passing this filter.

Implementing an IPropertyFilter

The important method signature to implement is the filter()method. This method is called by the framework when applying the filter to a certain resource:

  public IPropertyMap filter() throws WcmException {

Because a filter cascade could be applied, you should retrieve the predecessor's filtered property map:

    IPropertyMap map = this.predecessorFilter.filter();

Create the property name of the property you want to manipulate. In this example, the createdby property ({http://sapportals.com/xmlns/cm}createdby) is manipulated:

    IPropertyName createdByPropertyName
                  = new PropertyName(
                                    IWcmConst.SAP_WCM_NAMESPACE,
                                    IWcmConst.PROP_CREATEDBY
                                    );

The property can only be manipulated if it is in the retrieved property map. You therefore have to ensure that the property name is contained, as shown below.

    if (map.containsProperty(createdByPropertyName)) {

To change the property, you have to get a mutable version of the property representation:

      IMutableProperty mutableCreatedByProperty
                       = map.get(createdByPropertyName).getMutable();
      mutableCreatedByProperty.setStringValue("admin");

The result map of the filter method must also be changeable. You therefore have to get the mutable version of the map before storing the changed property:

      IMutablePropertyMap mutableMap = map.getMutable();
      mutableMap.put(mutableCreatedByProperty);

All other methods of the IPropertyFilterinterface should return the predecessors or any other valid value, such as getResource()method

  public IResource getResource() throws WcmException {
    return this.predecessorFilter.getResource();
  }

Or more general:

  public I<Object> get<Object>() throws WcmException {
    return this.predecessorFilter.get<Object>();
  }

Methods to be implemented by an IPropertyFilterimplementation:

filter()	Returns an IPropertyMapcontaining the manipulated property information.
get<Object>()	Every get<Object>()method should return the predecessors or any valid value.

Extending AbstractPropertyFilterManager

The filter manager is the control object for every filter. Every filter implementation needs its own filter manager that provides the filter objects to the repository framework. Within your filter manager implementation, you decide whether you want to implement a read or a write filter.

This example implements a filter manager that handles read filters, so the getFilterForRead()method has to be implemented. It must return a valid filter object, otherwise you run into exceptions:

  public IPropertyFilter getFilterForRead(IPropertyFilter predecessorFilter)
                                   throws WcmException {
    return new SimplePropertyFilter(predecessorFilter);
  }

Even if you implement only a read filter, make sure that the getFilterForWrite()method of the filter manager does not return null. It must return the passed filter object to be valid.

  public IPropertyFilter getFilterForWrite(IPropertyFilter predecessorFilter)
                                    throws WcmException {
    return predecessorFilter;
  }

The following methods from AbstractPropertyFilterManagershould be overridden or implemented:

getFilterForRead()	Return a valid instance of a read filter object
getFilterForWrite()	Return a valid instance of a write filter object

Configuration & Deployment

The repository filter implementation needs to be registered as a configurable object in the configuration framework. This allows the repository framework to access the configuration for the repository filter and pass it to the implementation. For this reason, a new class definition and an instance file have to be created during the development phase.

The class definition (com.sap.bc.rf.filter.SimplePropertyFilter.cc.xml) for this repository filter should look like this example:

<ConfigClass name="com.sap.bc.rf.filter.SimplePropertyFilter"
             extends="RepositoryFilter">
  <attribute name="class"
             type="class"
             constant="com.sap.bc.rf.filter.SimplePropertyFilterManager"/>
</ConfigClass>

Additional properties such as the following can be specified in the XML structure:

<attribute name="myProperty" type="string" default="anyValue"/>

They can then be evaluated by the repository filter manager implementation. The properties (attributes) are passed during start-up time and can be fetched within the startUpImpl()method.

The instance (com.sap.bc.rf.filter.SimplePropertyFilter.co.xml) of the defined classes above can also be specified during the development phase:

<?xml version="1.0"  encoding="UTF-8" ?>
<Configurable configclass="com.sap.bc.rf.filter.SimplePropertyFilter">
  <property name="name" value="com.sap.bc.rf.filter.SimplePropertyFilter" />
  <property name="active" value="true" />
  <property name="description" />
</Configurable>

If the filter is deployed in any KM it is activated by default. Changes to the configuration of the filter and filter manager can be done using the standard KM configuration iView.

The class definition and the instance file have to be bundled with the deployable unit of the filter implementation.