Entering content frame

Function documentation Navigation Connector Locate the document in its SAP Library structure

The behavior of the navigation model is independent of the data source from which it retrieves the navigation data. A backend repository can serve as data source. The backend repository can be for example a database, a file system, a text file, a XML file or any other repository. The navigation service interacts with the backend repository over a defined interface that represents the navigation nodes as tree structure. The navigation service needs a plug-in, the navigation connector, that understands the hierarchy structure of the repository. The navigation connector registers itself during the Portal initialization and responds to the requests of the navigation service.

The Portal supplies the Roles Navigation Connector that serves as main navigation connector. The navigation connector retrieves its navigation nodes from the Portal Content Directory (PCD) and has a tight relation to the navigation tree structure and the Role structure. Custom navigation connectors can be implemented and used instead of or in addition to the Roles Navigation Connector.

Navigation Redirector

The communication between the navigation model and the navigation connector is based on the fact that the navigation connector only handles targets that have a prefix similar to the connector key that is declared at the connector registration. The redirector concept enables the navigation connector to extend the list of acquainted prefixes, without changing the navigation connector implementation.

Every navigation target has its own prefix that is equivalent to a new redirector implementation. The redirector translates the navigation target with the new prefix to the default navigation target with the original prefix. This way the navigation connector can handle the navigation target without having to implement a support for every different presentation.

Example

We have following valid entry in the navigation hierarchy:

ROLES://dir1/dir2/role1/page1

When navigating to this location, the Roles Navigation Connector will handle the request; because of the ROLES prefix.

We assume that one of the clients of this navigation connector would like to use a shortcut for every PCD location. Regular address:

dir1/dir2/role1/workset1/dir3/dir33/page1

Shortcut:

sdfjkuh2sf4v5

In the example we also assume that the client has a data structure that contains both addresses – regular address and shortcut - and that the navigation connector knows the data structure.

For the shortcuts we define the prefix <xxx> and write a new redirector. The redirector object is an implementation of the interface INavigationRedirector. The redirect method for this object should return the translated navigation target with the prefix that suits the returned presentation. If the returned prefix does not match any connector key, the navigation target must be translated once again.

The redirector object looks like that:

public class pcdhRedirector implements INavigationRedirector {
  final static String PCDH = "pcdh";
  final static String ROLES = "ROLES";
 
  public INavigationRedirectorResult redirect(String url, Hashtable env)
   throws NamingException {
// translate the shorten name (url parameter) to the full one.
  String translatedUrl=PCDManager.getInstance().getFullLocation(url);
  return new RedirectorResult(ROLES,translatedUrl);
  }
}

The RedirectorResult is an implementation of the INavigationRedirectorResult interface. The RedirectorResult has two methods:

·        getPrefix()

·        getURL()

The Roles Navigation Connector

The Roles Navigation Connector is usually the only navigation connector used by the Portal clients. This connector reflects the Role structure, therefore uses the PCD as its backend repository. As a result the Roles Navigation Connector will return only the navigation connector nodes that are located under one of the roles that the user is allowed to see.

The key of the Roles Navigation Connector is ROLES, therefore every navigation target that is an entry in the PCD and should be handled by the Roles Navigation Connector has to have the following syntax:

ROLES://<pcd address, without pcd prefix>

Example

ROLES://portal_content/content_user/welcomePage

The Roles Navigation Connector registers two redirectors, when the Portal initializes.

The first redirector translates pcd hash code representation navigation targets to roles address representation (with ROLES prefix). The key of this redirector is pcdh, so every pcd hash code navigation target should have the following syntax:

pcdh://<hash_code>

Example – referring to the example mentioned before

pcdh://sdfjkuh2sf4v5

The second redirector translates navigation target from pcd addresses to Role addresses. The difference of the two addresses is the prefix. The key of this redirector id is pcd, so every pcd target must be sent in the following syntax:

pcd:<pcd address>

Example

pcd://portal_content/content_user/welcomePage

As long as the navigation hierarchy reflects exactly the pcd hierarchy, the redirector should not translate the URL. The only reason for creating this redirector is to declare that the navigation connector is acquainted to the pcd prefix.

Writing your own Navigation Connector

A self implemented navigation connector should expose a navigation hierarchy taken from a repository that maintains the application data efficiently or that was built in run time using a dynamic allocation.

Following steps are necessary to create your own navigation connector:

...

       1.      Create the navigation hierarchy based on the repository type.

       2.      Implement the INavigationConnectorNode interface. A navigation connector node exposes the provided content element. This object should contain all the attributes that appear in the getter methods of the interface, for example, title, launchURL, priority, mergeID. Additional attributes can be defined. Additional attributes can be retrieved from the navigation connector node by calling the getAttributeValue(attributeName) method. The navigation service ignores unknown attributes, but they can be used by your own navigation iViews.

       3.      Implement the INavigationConnector interface. This interface includes three methods that represent the main relation between the navigation service and a navigator connector implementation:

¡        getInitialNodes(Hashtable environment)

This method returns a list of all nodes that should be the root nodes of the navigation. The first level of the Top Level Navigation (TLN) is based on this list.

¡        getNode(Hashtable environment, String connectorNodeName)

This method returns an object of type INavigationConnectorNode. The input parameter connectorNodeName specifies the name of the object which is searched for in backend repository. This object contains all the attributes relevant to the navigation node.

¡        getNodes(Hashtable environment, Vector connectorNodeNames)

This method returns a javax.naming.NamingEnumeration instance enumerating several objects of type INavigationConnectorNode. Every element in the list represents a URL entry in the connectorNodeNames object.

The Portal Development Kit (PDK) contains a navigation connector implementation to navigate to the content of the PDK.

Leaving content frame