Our Blog > Blog Detail

Web Content Viewer- Asponte Custom Skin


Accessing Content in a Virtual Portal

  • Created By: Bryant Poole
  • Updated: June 3, 2016

Accessing Content in Virtual Portals using APIs

Virtual Portals have been around for a while, but the APIs needed to manipulate WCM objects from outside that Virtual Portal have not. Note that if your Java or JSP code is contained in a portlet in the Virtual Portal, then you don’t need any special APIs, simply access the objects as normal. However, if you need to access a Virtual Portal’s objects from outside that Virtual Portal, then you need a little setup first. Note that this requires at least Portal v8.0.0.1 CF13+.

Repository Interface

First, let’s look at some of the new methods in Repository.

getAllVirtualPortalContexts: as its name implies, this simply returns a VirtualPortalContext object for every Virtual Portal in the system, including the Base Portal. So you should always get at least one object back. The VirutalPortalContext object is mainly used to tell the executInVP method which Virtual Portal (or Base Portal) you are accessing.

generateVPContextFrom*: there are three methods here for creating a VirtualPortalContext object from HostName, ContextPath and ObjectId. Each method takes one parameter. Note that passing null to any of these will return the Base Portal.

executeInVP: this is the most interesting new method. It takes two parameters, the VirtualPortalContext retrieved from one of the above methods and a VirtualPortalScopedAction (explained below). You must implement the VirtualPortalScopedAction with all the action taking place inside the overridden run method.


This interface contains one run() method which you must override. Everything you want to do with the Virtual Portal must be executed inside this run() method. In this method, there are no special APIs needed. In general, you can assume the regular APIs will work.


The following class snippet implements the VirtualPortalScopedAction interface. I’ve overridden the run method and put all the activity in there. I did add a public getter method to return the libraries that were found in the run method.


public class VPScopedActions implements VirtualPortalScopedAction {


       // class level variable

       private Iterator libIter = null;

       // public constructor. Not doing anything in this example.

       public VPScopedActions() {


       // public method to retrieve libraries that were found in the run() method

       public Iterator getLibraries() {

              return libIter;




       public void run() throws WCMException {

      // Note these are the basic APIs, nothing special here.

      Repository repo = WCM_API.getRepository();

      Workspace workspace = repo.getSystemWorkspace();


      // Get the available libraries and set the class variable.

              libIter = workspace.getDocumentLibraries();






Now, to access the libraries contained in a Virtual Portal from another class, do the following:


//Get the repository as norma

Repository repo = WCM_API.getRepository();

//Create the required VirtualPortalContext using the repository.

// Use any of the generateVPContextFrom* methods.

VirtualPortalContext vctx = repo.generateVPContextFromContextPath(“myvirtualportalname”);

//Create VP Scoped Action object

VPScopedActions vpA = new VPScopedActions();

//execute the run method in the VPScopedActions class

repo.executeInVP(vctx, vpA);

//get the returned value

Iterator libIter = vpA.getLibraries();


Remember that all the action must occur within the run() method. This is a simple example, but a more complex example might pass parameters in the instantiation of the VirtualPortalScopedAction or have much more code inside the run() method.

Contact Form- Asponte Custom Skin


Contact Us


Call Us 888-926-9434
Complementary Content