The following sections give a brief overview of the RF's built-in extensions that can be used by RF clients. The built-in repository managers
SFSRepositoryManager and CmRepositoryManger are not covered here, since a client should not rely on the specific implementations.
However, a client could use the /etc repository to retrieve application data (for example, configuration data) and might as well configure a
repository instance where it can store its data.
Table of Contents
Repository services supply additional aspects that are not known to the RF, but are related to a repository (see RF Extensions).
Application properties behave like resource properties. In addition, application properties can be dependent on resource and user, whereas resource
properties are assigned to the resource only.
However, while the resource properties are stored by the repository manager (and only available if the repository support them), application properties are
stored in a separate database table and can be configured for any repository.
The default implementation of an IApplicationProperties repository service, as provided by the RF, stores the application properties in
a separate database table - it does not rely on the repository's ability to handle resource properties. It is therefore independent of the repository
implementation used and can be attached to any repository. However it relies on events to delete application properties when a resource is deleted.
For further information see the Javadoc package description for
com.sapportals.wcm.repository.service.appproperties
Service ACLs can be used by an application or extension to store additional ACLs that define the specific permissions for that application. For example, the subscription service introduces a new permission "subscription allowed" and uses this service to store the ACEs with these permissions.
The registration of new permissions has to be carried out on start-up by the application, using the IResourceAclManager's
addSupportedPermission() method. The service ACL's IResourceAclManager is provided by the IAclService's
getAclManager() method.
ACEs are created or modified by an administrator who uses the KM's ACL editor to define the ACLs of resources (see Concepts).
Whenever an application wants to perform an operation that requires a specific permission (one of those registered at start-up) on a resource, it uses the
IAclManagers isAllowed() method to check for the required permission, the given resource, and the current user from
the context.
The RF's default IAclService repository service implementation uses a database to store its ACLs and ACEs. As it is independent of the
repository implementation, it can be attached to any repository, but it relies on events to delete ACLs of resources that are deleted.
Global services offer additional operations on resources (see RF Extensions).
MIME types are used by applications to determine the "type" of a resource's content and information about that type.
Since not all repositories support the correct MIME type for their resource's content, and because an application might need to determine the content type
to be created for a resource that is still empty, the IMimeHandlerService is used: It returns the MIME type information in an
IMime object for a given resource's RID, based on the RID's extension. It retrieves the information from its configuration: An administrator
specifies which extension should map to which piece of MIME type information.
The IMime object contains information on which icon to display in the navigation and what description should be displayed.
For example, the extension .GIF might be mapped to the MIME type image/gif using image.gif stored in
/etc/public/mimes/images as an icon, and .HTML to text/html using html.gif in the same folder.
The MIME type handler's mapping mechanism of translating file endings into mime types is required, for example, when the Netscape browser is used, because it only recognizes MIME types and not file endings. For this reason, a resource can only be opened with the Netscape browser if its extension has been translated into a MIME type by the UI with the help of the MIME type handler service.
Notifications are predefined forms that an application can send to users. For example, the subscription service uses notifications to inform users that a document has changed.
In order to use the INotificatorService, an application must implement its own notifications. This is achieved either by implementing
the INotification interface anew or by extending the AbstractNotification, which already implements a property-based
XML-/XSLT-handling: The application provides the properties that represent the data to be sent. The XML files represent the language-specific texts to be used
for the notification. The XSLT specifies how the properties and the content of the XML are merged to build the content for a certain output channel (for
example, for an email message).
To send a notification, an application then uses the INotificatorService's send() method.
For further information see the JavaDoc package description
for com.sapportals.wcm.service.notificator.
The object type handler allows IActions to be defined for resources. The actions for a resource are selected by using a combination of RIDs
(with wildcards) and/or resource type as criteria.
An application developer specifies the IActions in an .oth XML-File in the /etc/oth collection, together with the
selection criteria. Each XML file specifies an IObjectTypeHandler.
The application then retrieves the IActions by getting the appropriate IObjectTypeHandlers that match the specified criteria
using the IObjectTypeHandlerService's getObjectTypeHandler() methods.
For example, the action inbox uses these IActions to determine the available actions for the several types of action inbox items.
The publishing pipeline service IPipelineService enables the general transformation of resource content from one format to another
format or from one layout to another:
IProducer is responsible for providing the content of a resource, stream, or string to the publishing pipeline as a
RequestData object.
IProcessor applies the transformation to the RequestData, for example, adds a new XML element to an XML document.
IFormatter finally converts the RequestData back into a specific output format, for example, into a stream
again.As well as the publishing pipeline, the IXsltPipelineService offers certain convenient methods, for creating a pipeline for processing XML with
XSLT.
For further information, see Javadoc package description for com.sapportals.wcm.service.notificator
and the How-to guide "How to Publish XML Files as HTML files"
The relation service IRelationService stores relations between RF objects in a separate database. Relations belong to a relation type
that defines what type of objects are related to each other, and the roles of the source and target of the relations. For example, the relation type
"attachments" links two resources, where the source is the document to which the target is attached.
The operands are represented as IRelationOperands, and their type as IRelationOperandType. Currently supported types are
IResourceOperandType, which represents resources as operands and IStringOperandType, which can be used for non-resource objects,
identified by a unique key.
Each tuple for such a relationship (for example, "document A is attached to document B") is represented as an
IRelation object.
The relation service offers methods for the fast retrieval of relations for a resource or an object ID and the ability to manage the relations for specific resource operations (for example, a relation might be automatically deleted if its source operand is deleted).
As discussed in Concepts, the RID of a resource can change over time. If an application requires a unique ID that does
not change and also identifies a resource, the IUriMapperService can be used. These unique IDs do not change when a resource is moved or renamed.
The service offers just three methods:
getCreateConstantID(RID rid): Tries to retrieve the mapped unique ID for a given RID and creates a new mapping between a new unique ID and the
RID if it does not already exist.
getConstantID(RID rid): Retrieves an existing mapped unique ID for the given RID.
getRIDFromConstantID(String constID): Retrieves the RID for the given unique ID if such a mapping between the given unique ID and RID
exists.The service stores the mappings in a database table and uses the event mechanism to update the mappings when a resource is moved or renamed. It also
deletes the mapping if the resource is deleted. An application will therefore only be able to retrieve a mapped unique ID for an undeleted resource - it should
register itself for the PRE_DELETE and DELETE event if it also needs to remove references to the unique ID of the deleted
resource.
KMC applications and components usually access resources through their RID.
If an application needs an HTTP-URL to address a resource outside the KMC platform, in the portal (for example, in order to send an e-mail that includes a link to a specific
resource), the IURLGeneratorService provides methods for resolving the URLs of the relevant KM applications.
These URLs can be included in e-mails or Web pages, for example.
For further information see the Javadoc package description for
com.sapportals.wcm.service.urlgenerator
The basic services are additional services that are not related to resources but are also provided as global services for now.
If an application or extension wants to log logging information, it can use the IAppLogService to write its logging information into an
IAppLog.
The IAppLog is similar to the logging and tracing API, described in RF Components and their Runtime, and will be replaced by the APIs described there. For now,
its implementation allows applications to write the log and it offers a log viewer that can be used by an administrator.
The ICacheService offers getCache() for retrieving an configured implementation of an ICache (package
com.sapportals.wcm.util.cache). This cache can be used by an application or extension to cache frequently requested objects. It is configured
using KM's configuration UI.
When an object is added to the cache, a pointer referencing the object is set. The object itself resides in the memory. Setting the pointer
protects the object against the garbage collection mechanism which deletes any objects that are not referenced by a pointer from the memory.
The caches implement local caches and are not cluster-aware. The application is therefore responsible for handling the proper cache invalidation in a clustered environment.
Since the RF's main task is to integrate various backend systems, the applications and extensions might require information about the systems they should
connect to. This is handled by the ILandscapeService.
It enables applications to store and manage information about systems and the credentials required to log on to these systems. For example, if resources
are stored in WebDAV, Lotus Notes, and Exchange servers, each of these is a system with certain attributes and each can have its own access policy
that states requirements that have to be fulfilled before a user is granted access. These access requirements are referred to as credentials.
It is the task of the system landscape service to store these credentials and information about the corresponding systems.
Credentials are defined and stored for a particular system type. They specify information that is required to permit access to a system type. Typically, access is restricted to people who are correctly authenticated, that is, people whose user and password prove that they are allowed to access the system. However, these requirements can be extended to include further data such as the specification of a start directory, the use of a particular access protocol, or information about the logon mode. The system landscape service therefore allows the definition of individual access requirements that go beyond authentication with user and password.
A system's type determines its ICredentials, which specify the logon credentials required to log on to a system of that type and to carry out
the user mapping between the portal and the backend system.
The system landscape service offers the method isClusterInstallation() for determining whether the entire system is running in a clustered
installation. The method getSystemFactory() retrieves the ISystemFactory, which is used in turn to retrieve information about a
specific system. A system is identified by its ID, whereas the information about it is represented as ISystem.
For further Information see the JavaDoc package description for
com.sapportals.wcm.service.landscape.
The scheduler service ISchedulerService supports ISchedulerTasks that represent tasks that have to be executed
periodically. An application or extension has to define its own scheduler tasks in the configuration in order to have them configured to run at a certain
time.
The scheduler service then manages the execution of the tasks the application registered. It ensures that the tasks are started at the correct time and monitors their execution. For example, the KM's subscription service uses the scheduler service to make sure that directories containing relevant
documents are crawled at regular intervals.
The ISchedulerService's method createSchedulerEntry()creates a task that has to be registered again at the next
start-up.
An implementation of a ISchedulerTask is instantiated by the scheduler at the start-up of the RF. Its run() method is then called periodically as specified
by its ISchedulerTimeTable.
For further information, see the Javadoc package description for com.sapportals.wcm.service.scheduler.
In order to support the sourcing out of "large" time-consuming computations, an application can use the scheduler to perform batch tasks at times when only a few users are logged in. The task queue offers another method for separating those batch tasks from the application that is useful especially in a load-balanced clustered installation, where several instances of KMC run on different cluster nodes: An application places a task in a task queue on one node. A background task (for example, started by the scheduler) on another node retrieves this task from the task queue and executes it.
The application retrieves an ITaskQueueWriter for a specific namespace and an ID from the ITaskQueueService and uses them to place
ITasks into an ITaskQueue. The ITaskQueue stores the tasks and distributes them to the
ITaskQueueReaders.
On the other side, the application batch job retrieves the appropriate ITaskQueueReader (for the application's namespace and ID) from the
ITaskQueueService and uses it to get the ITasks sent by the application from the ITaskQueue.
For further information, see the Javadoc package description for
com.sapportals.wcm.service.scheduler.