Piece of Content framework in WebSphere Portal is used by many components within the Portal to create direct user friendly URLs to specific pages, portlets on pages, content items ..etc and this nice feature can be extended by creating your own URL resolver which might have some custom behaviors when resolving URLs or just have the default Portal behavior but referencing your own pages or portlets.
URL to the POC framework should be in the following syntax:
Secured: http://[PortalHostName]:[Port]/[wpsContext]/mypoc?uri=[scheme]:[customUriCtx]¶m1=val1¶m2=val2 (for secured use mypoc instead of poc)
To Extend the POC framework you need to do three things:
1- Implement a resolution service class (a class that implements com.ibm.portal.resolver.ResolutionService)
2- Register your resolution service plugin, usually via writing a plugin.xml file and package it with your service EAR, WAR or JAR
3- Write a configuration file which contains all URI resolution configurations; e.g. which URL will be resolved to which page/portlet and what parameters to pass
Third step is the most important one as it is the configuration that drives the resolution service, if you don't need any custom behaviors then you can have one resolution service in place and extend the configuration file every now and then to resolve more URLs. or register the same service with different plugins to serve different schemas.
1- Implementing Resolver Service
In this step you develop a class that implements com.ibm.portal.resolver.ResolutionService and provides the implementation of its resolve method, the implementation of this class is pretty much reusable. You can refer to the attached project for sample implementation and you can reuse the same resolver after changing the packaging and namings as needed.
This project depends on com.ibm.content.operations.registry.jar this JAR is in WebSphere Portal extensions and you need to add it to class path for compilation. JAR location for Portal 8 is [PortalServer]\lwp04.infra\common.infra\contentoperationsregistry\portal\shared\ext
Important Note: You must NOT package this jar with your deployment artifacts, use it only in class path for compilation. This is because the JAR has some plugin configurations that will overwrite Portal's URL Resolver configuration and might corrupt the environment.
To register your resolver service you need to write a plugin.xml file to extend the Portal Resolution services framework. a sample file is below with description of key attributes..
<?xml version="1.0" encoding="UTF-8"?>
<plugin provider-name="Ascendant" version="1.0.0" name="BPM Taskdetails DeeplinkPlugin" id="bpm.taskdetails.resolver">
<contentLocationType title="DeeplinkLocationType" match.uri.scheme="taskdetailsresolver" class="com.ibm.portal.resolver.helper.cor.DefaultContentLocationFactory" id="bpm.taskdetails.deeplink.LocationType"/>
<serviceHandler class="bpm.resolver.DeeplinkResolutionService" locationTypeId="bpm.taskdetails.deeplink.LocationType" id="com.ibm.portal.resolver.ResolutionService"/>
This plugin file registers my custom resolution service class bpm.resolver.DeeplinkResolutionService to be used to resolve any URL within the schema name taskdetailsresolver.
3. configuration file
This is a sample configuration file for the resolution class, this is used to direct the service to which piece of content to redirect the url to and what parameters are expected and other behavioral configurations like portlet phase (render/action), portlet state (minimized, maximized ..etc)
<?xml version="1.0" encoding="UTF-8"?>
<!-- a sample configuration file for the deep link resolver -->
<deeplink linkname="bpm" page-uniquename="bpm.taskdetails.demo">
<portlet uniquename="bpm.taskdetails.demo.portlet" action="true" state="maximized">
<parameter name="action" allow-override="true">details</parameter>
<parameter name="taskId" allow-override="true">taskId</parameter>
<parameter name="workflowState" allow-override="true">workflowState</parameter>
- linkname attribute is the one identifies customUriCtx part of the URL, you can have multiple linknames each of which references diffrent portlets, pages, configurations ...etc
- it is clear from configurations where to add page and portlet uniquenames and what other portlet attributes to use
- parameters are passed as regular query parameters and registers parameters only are passed to the POC
- sample URL for this configuration: http://wps8.host.com:10039/wps/mypoc?uri=taskdetailsresolver:bpm&taskId=123&workflowState=1
Portal will resolve this URL and will navigate to page with uniquename bpm.taskdetails.demo and will fire an action url to the portlet on page with unique name bpm.taskdetails.demo.portlet passing three action parameters (action=details, taskId=123, workflowState=1).
Mahmoud Matouk is a Technical Architect and SME Portals and Social Business with 9 years of experience in this domain