AEM Portals and Portlets

This document describes the following:

• CQ Portal architecture
• Administering and configuring CQ as a portal
• Using CQ as a portal
• Installing, configuring, and displaying CQ content in a portlet (for example, a web server)
  

CQ portal architecture includes definitions of portals, portlets, and the CQ Portal Director.

A portal is a web application that provides personalization, single sign on, content integration from different sources, and hosts the presentation layer of information systems.

You can run JSR 286-compliant portlets in CQ. The portlet component lets you embed a portlet on the page. See Administering the CQ Content Portlet.

Portlets are web components deployed inside of a container that generate dynamic content. The portlet interface is packaged and deployed as a .war file inside of a portlet container. If you are running CQ as a portal, you need the portlet's .war file to run the portlet.

To configure CQ content to appear in a portal, see Installing, Configuring, and Using CQ in a portlet.

The CQ5 Portal Director provides a content portlet that lets you display content from the publish instance, preview content from the author instance, and provides a link within the content to open the corresponding page in a new browser window. The portlet is located at /crx-quickstart/opt/portal after the quickstart is extracted.

The content portlet is based on the JSR 286 (portlet API 2.0) and can run in any compliant portal.

The CQ portlet has the following features:

• Displaying content in a portlet. The portlet displays content, which can be either an entire page or part of a page, from CQ WCM. The template that is used in combination with the provided selectors, defines how you see the content. In particular, the portlet can show content from just one page or provide a whole substructure of a site and show the corresponding navigation. The portlet supports different display modes such as the normal view and the maximized view.

• Configuring the portlet. You configure the portlet to point directly to the publish CQ5 instance by using a URL that either points directly to the content or to the portlet content map within CQ WCM. If it points to the portlet content map, then the configured URL contains a key for the content and the configuration maps the key to the actual content to be displayed, which allows CQ5 to adjust references, for example if someone moves pages within CQ WCM. .The portlet itself does not know if it points directly to the content or if a configuration map is used. For editing, the base URL to the CQ WCM author instance is configured as well.
  

• Layout. The portlet respects portal design/themes. The design (CSS files) are added by the portlet to the portal page, which you can configure. As this is an optional portlet API 2.0 feature, for portlet containers not supporting this feature, you manually add the CSS files to the portal server.

• Security. User and group information are shared with the portal. CQ WCM respects user information for personalization and access control. The user information from the portal (current user) is forwarded to CQ WCM. The user is already logged into the portal, so the portal is the driving authentication mechanism. CQ WCM (and therefore CRX) receives enough information to handle this properly. SSO scenarios are supported through existing and/or custom authenticators. As the portlet can connect to different CQ WCM instances (especially publish and author for display and editing), potentially different user information needs to be properly handled. Because this handling can be very specific to a given environment, a mechanism is provided that allows for plugging diverse authenticators. In addition to this proper user handling, it is also possible to configure the portlet to just use one technical user.
  

• Multi-Language. Content from CQ WCM respects the portal language. The portlet standard specification requires that available languages for a portlet are configured per portlet. The portal forwards the preferred language of the user to the CQ portlet which, in turn, forwards this to the CQ WCM server. The mechanism to provide the correct language uses structural information about the site, that is, the request is mapped to language specific URLs inside the portlet. This mechanism is pluggable to allow for customization.

• Links. All links in the portlet must be rewritten properly.

• Caching. The portlet can be configured to point to the dispatcher instead of directly pointing to the CQ server. In this scenario, the dispatcher cache is used. The portlet also has its own cache. The implementation of the cache can be replaced by a custom implementation if needed.
  

• Editing Content. The CQ portlet provides links to configure the portlet and edit its content. The CQ WCM part of the configuration determines how to handle the content that is shown in the portlet. You edit in the CQ WCM authoring environment. If necessary, you can also access the Websites tab through an additional link in the tree instead of directly editing a page. It might still be necessary to go to the Websites tab instead of directly editing a page. The editing functionality is only available if the current user has the credentials to edit a page. By default, the CQ5 author instance is queried to detect if the user is an author.

• Non Functional. Wherever possible, portlet integration is based on standards (in particular JSR 286), so it is generic for all portal environments that support this standard. Setups with one portal and multiple CQ WCM instances as well as multiple portal instances and one CQ WCM instance are supported.

The CQ content portlet enables you to display CQ content in a portal. The portlet is available at /crx-quickstart/opt/portal, and can be customized in various ways. For example, you can customize the SSO/Authentication handling by deploying your own authentication service generating the required authentication information for CQ to overwrite the default behavior. The plugins use a defined API that lets you add your own functionality by building the plugin against the API. The plugin can be deployed into the running portlet. To function properly, it needs a configuration of the CQ author and publish instance together with the content path to display on startup.

Some of the configurations can be changed through portlet preferences and others through OSGi service configurations. You change these configurations using config files or the OSGi web console.

Porlet preferences can be configured at deployment time in the portal server or by editing the WEB-INF/portlet.xml file before deploying the portlet web application. The portlet.xml file appears as follows by default:

The portlet can be configured with the following preferences:

Assuming the portal server runs on host localhost, port 8080 and the CQ portlet web application is mounted in the web application context cqportlet, the url to for the web console is http://localhost:8080/cqportlet/cqbridge/system/console. The default user and password is admin.

Open the Configurations tab and select Day Portal Directory CQ Server Configuration. Here you specify the base URL to the author and the publish instance. This procedure is described in Configuring the Portlet.

To support automated deployments and configuration provisioning, the CQ content portlet has built-in configuration support that tries to read configurations from the classpath provided to the portlet application.

On startup, the system property com.day.cq.portet.config is read to detect the current environment. Usually, the value of this property is something like dev, prod, test and so on. If no environment is set, no configurations are read.

If an environment is set, a config file is searched in the classpath at com/day/cq/portlet/{env}.config where env is replaced with the actual value for the environment. This file should list all configuration files for this environment. These files are searched relative to the location of the config file. For example, if the file contains a line my.service.xml, this file is read from the classpath at com/day/cq/portlet/my.service.config. The name of the file consists of the persistence ID of the service, followed by .config. In the previous example, the persistence ID is my.service. The format of the configuration file, is the format used by the Apache Sling OSGi installer.

This means, for each environment, a corresponding config file needs to be added. A configuration that should be applied to all environments needs to be entered in all these files - if it is just for a single environment, it is just entered in that file. This mechanism ensures full control over which configuration is read in which environment.

It is possible to use a different system property to detect the environment. Specify the system property com.day.cq.portet.configproperty containing the name of the system property to use instead of com.day.cq.portet.config.

The portlet, in its default configuration, caches the responses it receives from CQ WCM in a user-specific cache. The caches need to be invalidated when changes occur in the content of the publish instance. For this purpose, in CQ WCM a replication agent must be configured on the author instance. The cache can also be flushed manually. This section describes both of those procedures.

The portlet can be configured with its own cache, so that the content in the portlet displays without requiring access to CQ. The portal is available as content in /libs/portal/director. To access the content, start a CQ instance and download, using CRXDE Lite or Webdav, the file from that location.

You can either deploy this bundle at runtime or add it to the portlet web application at WEB-INF/lib/resources/bundles before the deployment.

After the cache is deployed, the portlet caches contents from the publish instance. The portlet cache can be invalidated with a dispatcher flush from CQ. To configure the portlet to use its own cache:

1. Configure a replication agent in author that targets the portal server. 
2. Assuming that the portal server runs on host localhost, port 8080 and the CQ portlet web application is mounted in the context cqportlet, the url to flush the cache is http://localhost:8080/cqportlet/cqbridge/cqpcache?Path=$(path). Use GET as the method.
   Note: Instead of using a request parameter, you can send an http header named Path.

Just like the normal dispatcher invalidation, a replication agent can be configured to target the portal's CQ5 portlet cache. After you configure the replication agent, every regular page activation flushes the portal cache.

If you operate several portal nodes running the CQ portlet, you need to create an agent for each node as described in this procedure.

To configure a replication agent for the portal:

You can manually flush the portlet cache by accessing the same URL configured for the replication agent. See Flushing the Cache for the form of the URL. In addition, the URL needs to be extended with a URL parameter Path=<path> to indicate what to flush.

For example:

http://10.0.20.99:10040/wps/PA_CQ5_Portlet/cqbridge/cqpcache?Path=* flushes the complete cache. http://10.0.20.99:10040/wps/PA_CQ5_Portlet/cqbridge/cqpcache?Path=/content/mypage/xyz flushes /content/mypage/xyz from the cache.

The portal is the driving authentication mechanism. You can log into CQ either with a technical user, the portal user, a group, and so on. The portlet has no access to the password for the user in the portal, so if the portlet does not know all the credentials to successfully log in a user, an SSO solution must be used. In this case, the CQ portlet forwards all required information to CQ, which in turn forwards this information to the underlying CRX. This behavior is pluggable and can be customized.

This section describes the available authentication modes the portlet can use in communicating with the underlying CQ WCM instances.

By default no user information is sent to the publish instance of CQ; the content is always displayed as the anonymous user. If user specific information should be delivered from CQ or if user authentication for publish is required, this has to be turned on.

Authentication configuration options that the portlet uses in CQ WCM instances are available in the Web console (OSGi configuration).

To access the portlet's authentication configuration:

In default mode, all requests issued by the portlet for the CQ WCM author instance are authenticated using the same technical user, regardless of the current portal user. Technical User mode is enabled by default. You enable/disable this mode in the respective configuration screen in the OSGi management console:

The technical user specified must exist on the CQ WCM author instance and on the publish instance if Authenticate on Publish is enabled. Be sure to give the user access privileges sufficient for authoring work.

The portlet supports SSO with CQ5 out of the box. The authenticator service can be configured to use SSO and transmit the current portal user with format Basic as a cookie named cqpsso to CQ. CQ should be configured to use the SSO authentication handler for path /. The cookie name needs to be configured here as well. 

The crx-quickstart/repository/repository.xml for CRX needs to be configured accordingly:

The portlet can authenticate for CQ WCM using the Single Sign On (SSO) scheme. In this mode, the user currently logged in to the portal is forwarded to CQ WCM in the form of an SSO cookie. If SSO mode is used, all portal users with access to the CQ portlet must be known to the underlying CQ WCM instances, most commonly in the form of CQ WCM being connected to LDAP, or by having manually created the users beforehand. Also, before enabling SSO in the portlet, the underlying CQ WCM author instance (and the publish instance, if Authenticate on Publish is enabled) needs to be configured to accept SSO-based requests.

To configure the portlet to use SSO authentication mode, complete the following steps (described in detail in the following sections):

• Enable CQ WCM's CRX to accept trusted credentials.
• Enable SSO authentication in the CQ WCM.
• Enable SSO Authentication in the CQ portlet.

Before SSO can be enabled for CQ WCM, the underlying CRX instance needs to be configured to accept the trusted credentials provided by CQ WCM. To do this, you configure CRX's repository.xml.

To enable SSO in CQ WCM, access the relevant configuration entry in the CQ WCM's Apache Felix Web Management Console (OSGi):

For every request CQ WCM receives, first the SSO-based authentication is attempted. Upon failure, a fallback to the usual basic authentication scheme is performed. As such, normal connections to CQ WCM without SSO remain possible.

In order for the underlying CQ WCM instance to accept SSO requests, the portlet’s authentication mode has to be switched from Technical to SSO.

To enable SSO authentication in a CQ portlet:

After performing this procedure, requests are authenticated using SSO. A typical snippet from the HTTP communication reveals the presence of the following SSO and Portlet specific headers:

If you are not using the default inline editing features of the CQ content portlet, but want the authoring and administration part of the portlet outside the portal directly in the CQ author instance, you should enable PIN authentication. You also need to change the configuration of the management buttons.

To open the website administration page or to edit a page from the portlet, the CQ content portlet uses the new pin authentication. By default, the pin authentication is disabled, therefore, the following configuration changes have to be made in CQ:

Some functions of the portlet are protected by privileges. The current user needs to have this privilege in order to be able to access this function. There are the following privileges pre-defined:

• "toolbar" : This is the general privilege to see/use the toolbar in the portlet.
• "prefs" : If the user has this privilege, the user is allowed to see/change the preferences of the portlet.
• "cq-author:edit" : With this privilege, the user is allowed to invoke the edit view of the content.
• "cq-author:preview" : With this privilege, the user is allowed to see the preview.
• "cq-author:siteadmin" : With this privlege, the user is allowed to open the siteadmin within CQ.

The best approach to manage the privileges is to use portal roles and assign roles to these privileges. This can be done through an OSGi configuration. The "Day Portal Director Privilege Manager" can be configured with a set of roles for each privilege. If the user has one of the roles, the user has the corresponding privilege.

In addition it is possible to define this role based access on a per portlet instance base. The preferences dialog of the portlet contains an input field for each of the above privileges. For each privilege a comma-separated list of portlet roles can be configured. If a value is configured, this overrides the global configuration from the "Day Portal Director Privilege Manager" service and it might be required to add the same roles from this global setting as the roles are not merged! If no value is specified, the global configuration is used.

The provided CQ portlet application starts an OSGi container inside the web application just as CQ5 does. This architecture lets you make use of all of the benefits of OSGi:

• Easy to update and extend
• Provides hot updates of the portlet without any interaction of the portal server
  
• Easy to customize the portlet

The toolbar and its buttons are configurable and can be customized. You can add your own buttons to the toolbar or define which buttons are displayed in which mode. Each button is an OSGi service configurable through an OSGi configuration.

The OSGi web console lists all button configurations on the Configuration tab. For each button, you can define in which mode this button is displayed. This lets you disable a button by removing all modes for example.

By default, the CQ content portlet uses the inline editing functionality. However, if you prefer to switch into the CQ author instance for editing, enable the SiteAdmin Button and the ContentFinder Button, but disable the Edit Button. In this case, make sure to correctly configure the PIN authentication in CQ.

The portlet's toolbar layout can be customized by installing a bundle through the portlet's Felix Web Console, which contains custom CSS/HTML at a predefined location.

The following is an example bundle structure:

The META-INF folder contains the MANIFEST.MF file required by OSGi to identify it as a bundle. It appears as follows:

The fact that the HTML/CSS/images are within the /com/day/cq/portlet/toolbar/layout folder is mandated by the portlet and cannot be changed. Along the same lines, the Import-Package and Export-Package headers in MANIFEST.MF must be called /com/day/cq/portlet/toolbar/layout as well. The Bundle-SymbolicName must be a unique, fully qualified package name.

You can build it using a tool such as maven or manually create such a jar file with the relevant header set as shown in this section.

The portlet's toolbar basically has two view states. Each view and associated buttons can be customized with a respective HTML file.

The publish view only has one button that switches the toolbar to the Manage view. The publish view is represented by the publish.html file in previous bundle. In the HTML, you can use the following placeholders, which are replaced by the portlet with the respective contents when rendered:

The manage view has four buttons: Edit, Websites tab, Refresh and Back. The manage view is represented by the manage.html file in the previous bundle. In the HTML, you can use the following placeholders, which are replaced by the portlet with the respective contents when rendered:

Buttons, on whichever view they appear, use the same common HTML, defined in button.html.

In the HTML, you can use the following placeholders, which are replaced by the portlet with the respective contents when rendered:

Example of a button.html file:

To install a custom layout, access the portlet’s OSGI Web console Bundles section and upload the bundle.

If you need to upload, or create, packages for your installation, then see Package Manager in the CRX documentation for detailed instructions.

All links are rewritten to work within the portal context. By default links with render parameters are used. The Day Portal Director HTML Rewriter can be configured to use action links instead.

You can also define additional request parameters to be queried for the content path to be displayed. This is useful, for example, if there is a link from the outside to specific content.

In addition, the Day Portal Director HTML Rewriter can be configured with a list of regular expressions defined excludes for link rewriting. For example, if you have relative links to external systems, you should add them to this exclude list.

The CQ content portlet has a built-in localization feature, which ensures that the content from CQ is in the correct language.

This is done in two steps:

1. The Day Portal Directory Locale Detector detects the locale of the portal user by getting the locale setting from the portal. This service must be configured with the list of available languages in CQ.
2. The Day Portal Director Locale Handler handles the localization of the current request. It takes the path of the requested content, for example /content/geometrixx/en/company.html and according to the configuration, it rewrites the en with the actual locale of the user.
   

The Day Portal Director Locale Handler can be configured with the paths to check for locale information - usually this includes everything under /content and with the position of the locale information in the path. By default, the locale handler follows the recommondation of structuring multi-language sites within CQ.

If your site has no strict rule for handling the locale information within the path, it is possible to replace the locale handler with your own implementation.

Optional OSGi services can be implemented to customize various parts of the portlet. Each service corresponds to a Java interface. This interface can be implemented and deployed through a bundle into the portlet.

The following services have a default implementation in the content portlet (with a corresponding Java interface). To customize, a bundle containing the new service implementation needs to be deployed into the portlet application.

When implementing such a service, make sure to set the service.ranking property of the service to a positive value. The default implementation uses the ranking 0 and the portlet uses the service with the highest ranking.

The portlet API (JSR-286) specifies portlet events. The CQ content portlet has an integrated bridge, distributing portlet events for the CQ portlet as OSGi events - this makes handling of portlet events pluggable.

If you want to handle specific events, declare these as receiving events in the deployment descriptor (or configure it through your portal server) and implement an OSGi service declaring the EventHandler interface (see OSGi EventAdmin specification).

Whenever a portlet event occurs, a specific OSGi event is sent invoking your handler. The handler gets all context information and can update the status of the portlet accordingly or sent new events. Basically, inside the handle method all functionality of the portlet event phase can be used.

Use the Portlet component to add portlet windows to CQ pages. Shared libraries that you install to the application server enable the Portlet component to detect deployed portlet applications.

To use CQ as a portal, perform the following tasks:

1. Install the Portlet component and shared libraries.
2. Add the Portlet component to Sidekick.
3. Configure and deploy the web application that contains the portlets that you want to appear in the Portal component.
4. Add the Portlet component to a page and select the portlet to display.

The CQ5.5 Quickstart JAR file contains the portlet component files. To obtain the files (cq-portlet-components.zip), you can either execute the Quickstart, or extract the contents. 

1. Execute or extract the contents of the Quickstart JAR file, and locate the cq-portlet-components.zip file accordingly:
   • Execute Quickstart: crx-quickstart/opt/portal
   • Extract Quickstart contents: static/opt/portal
2. Open Package Manager of the CQ5 author instance that is deployed to the application server. (http://appserverhost:port/cq5author/crx/packmgr)
3. Use Package Manager to Upload and install the cq-portlets-components.zip package.

   The package installs the cq-portlet-director-sharedlibs-x.x.x.jar in the /libs/portal/director folder in the repository.

4. Copy cq-portlet-director-sharedlibs-x.x.x.jar to your hard drive. Use any means to obtain the file, for example FileVault or a WebDAV client.
5. Move the cq-portlet-director-sharedlibs.x.x.x.jar file to the shared library folder of your application server so that the classes are available to deployed portlet applications.

Add the portlet component to the paragraph system so that it is available to authors. 

1. In Sidekick, click the ruler icon to enter Design mode.
2. Beside the Design of par heading above the first paragraph, click Edit.
3. In the General component category, select the check box next to the Portlet component and click OK.

Deploy the portlets to the application server web container so that they are available to the Portal component. Before you deploy the portlet application, you need to configure the application so that it loads the CQ portal container servlet. This configuration enables the Portlet component to access the portlets.

Use the Portal component to add a portlet window to your web page. Use the component properties to specify the portlet to display.

To access content provided by CQ5 WCM, the portal server needs to be fitted with the CQ5 Portal Director Portlet. You do this by installing, configuring, and adding the portlet to the portal page by using the steps provided in this section.

By default, the portlet connects to the publish instance at localhost:4503 and to the author instance at localhost:4502. These values can be changed during deployment of the portlet. The portal director is available as content in the repository under /libs/portal/directory. You will need to download the application war file before using it.

To install the portlet:

After you install the portlet, you need to configure it so that it knows the URLs of the underlying CQ5 instances (author and publish). You also can configure other options.

To configure the portlet:

When content is requested from CQ, the portlet uses the current display mode (publish or author) and the current path to assemble a complete URL. With the default values, the first url is http://localhost:4503/content/geometrixx/en.portlet.html. The value of the htmlSelector is automatically added to the URL before the extension.

If the portlet switches to the help mode and the appendHelpViewModeAsSelector is selected, then the help selector is appended as well, for example, http://localhost:4503/content/geometrixx/en.portlet.html.help. If the portlet window is maximized and the appendMaxWindowStateAsSelector is selected, then the selector is appended as well, for example, http://localhost:4503/content/geometrixx/en.portlet.max.help.

The selectors can be evaluated in CQ and a different template can be used for different selectors.

Usually the start path points directly to the content in CQ. However if you want to maintain start paths in CQ rather than in the portlet preferences, you can point the start path to a content map in CQ, like /var/portlets. In this case, a script running in CQ can use the submitted information from the portlet to decide which url is the start url. It should issue a redirect to the correct url.

To add the portlet to the portal page:

1. Be sure you are in the administration window of your app server and navigate to the location where you manage pages. (for example, in WebSphere 6.1, click Manage Pages).

2. Select the name of the portlet and then select an existing page or create a new page.
   

3. Edit the page layout.

4. Select the portlet and add it to a container. 

5. Save your changes.

To access the page you added to the portlet:

1. In the portlet's personalization menu, configure the portlet as you configured it in the portal.

2. Open the configuration (The portlet displays the publish start URL configured in the portlet’s configuration) and make edits as necessary, then save them.