WebCenter Portal - Sitemap Customization

Sitemap customization within WebCenter Portal is a lot easier than it may seem.

Within web.xml the sitemap servlet is defined as per below.

Conveniently, there is also a method available to retrieve the default sitemap. This sitemap is generated from the default-navigation-model.xml.

import oracle.webcenter.portalframework.sitestructure.preference.PortalPreferences;

String siteMap = "";
siteMap = PortalPreferences.getInstance().getSiteMap();

As such all you need to do is perform a find and replace within the siteMap string in order to manipulate your result or return your own customized sitemap from the servlet.

A sample of the full servlet is below:

package test_portal.portal.servlet;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;

import oracle.webcenter.portalframework.sitestructure.preference.PortalPreferences;

public class SiteMapServlet extends HttpServlet {
 
    transient ServletConfig config = null;

    public void init(ServletConfig config) throws ServletException {
      this.config = config;
      super.init(config);
    }

    public void doGet(javax.servlet.http.HttpServletRequest httpRequest, javax.servlet.http.HttpServletResponse httpResponse) throws IOException {

        httpResponse.setContentType("text/xml");

        PrintWriter out = httpResponse.getWriter();
        String siteMap = "";
        siteMap = PortalPreferences.getInstance().getSiteMap();
        siteMap = siteMap.replaceAll("/faces/testNav","http://sample.com");
        siteMap = siteMap.replaceAll("/faces/home","http://sample.com/");
        siteMap = siteMap.replaceAll("\\?wcnav.model=%2Foracle%2Fwebcenter%2Fportalapp%2Fnavigations%2Fdefault-navigation-model","");
        siteMap = siteMap.replaceAll("</loc>","</loc> \r <changefreq>weekly</changefreq>");

        out.println(siteMap);

        out.close();

    }
 
}

Side by Side Deployments (Rolling/Hot/InPlace Deployments)

One of the great features of ADF/Weblogic is side by side deployments. This allows you to deploy two different versions of an application to a Weblogic server without the need for an outage. Weblogic is smart enough deal with current and new session. Once the new version of the application has been deployed to the server the old version of the application set in to "Retired" status and the new version is set to "Active". The retired version of the application maintains any active sessions until they end (also has the option to expire all sessions immediately or after a set time period). Whilst the new active version of the application handles all the new sessions, this is quite a cool feature. I've used this a fair bit and it seems to work quite well. This only catch is if you are a deploying a large ear file the response times of the server do suffer.

Anyway, here is how you do it.

Firstly create a two test applications.

Create a MANIFEST.MF file and paste the following details inside. Take note of the Archive-Version, this is the version number that weblogic looks for when it decides to retire or promote the new application. 

You will need to create a new deployment profile.

Then define your new manifest file.

Then do the same as above but increment the Archive Version and do the above two steps to the second application.

In order to test that the side by side deployment worked. Deploy the first application and it should appear as 'Active' in the weblogic console, then deploy the second application and the first application should get set to 'Retired' and the new application will be set to 'Active'. 

To ensure that you don't have an outage you can test the site with a load testing too such as LoadUI as I did below. You can see an increase in response time when the second application is being deployed. In reality, it is Oracle's recommendation that you have the Admin Server running on a separate machine to your managed servers. So when you do a side by side deployment in "theory" you shouldn't see an increase in response times as you can in the below test.

Modifying Web Service Endpoint at Runtime

Recently, we came across an issue where we had to modify the end points of several previously generated web service proxies for a application with the requirement to run on a number of different environments.

The initial thought was that we could do this through an ANT script. However, this became very messing, very fast. So after a bit of think I realised the endpoint was in the request and the request could be modified.

Hence the below code refers the to the ENDPOINT_ADDRESS_PROPERTY property key for the request. Allowing you to modify the endpoint at run time before the request is sent. Opening the door to modify the endpoint to a string specified within a database or property file.

 TestWebService webservice = testWebServiceServiceagent.getTestWebserviceSOAPHTTPEndpoint();  ((BindingProvider)webservice).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "new end point");