Skip to Content

Portal development with Portal DCs

| Portal development is a hot topic since some time now. After the 6.0 release of the Portal each company has developed at least one custom iView with their custom functionality by using the integrated Enterprise Portal plug-in within the NetWeaver Developer Studio.

However what most of you probably don’t know is that except for the standard Portal Projects, there are also Portal Development Components. The same components that enable the reusability feature within Web Dynpro. In this blog I’ll show you how you can use development components in a Portal scenario and what benefit would this bring to your development lifecycle.

The most obvious advantage of using development components is their integration into the NetWeaver Development Infrastructure also known as NWDI. This peace of software acts as a central storage for your source files and each of the portal developers can get a current version of the project at any point of time just with a few synchronisation steps in NWDS. I am not going to concentrate on this feature since there a lot of other blogs in SDN that already underline this topic.

My task in this blog would be to show you how combining different development components, you can structure and speed up your own portal development by a minimum factor of 2 🙂

Out scenario includes 3 development components:

To simplify the whole procedure, we’ll restrict the functionality of the single components to only string output since the idea is to show the concept behind this development and not to invent a killer application for your portal environment. The reason is that you can do that later on your own using the explained technology.

Enough theory let us start with the application itself. First we’ll create a very simple portal component that will only display text in an iView. The creation process looks like this:








After that you should be able to open the Portal Perspective and see your component there:


You can switch between two views within this perspective. The first one “Package Explorer” shows you the complete structure of your project and this is also the view where you can create new files, packages and so on. The other view “Portal DC Explorer” is not less important. There you can build your components and also modify their DC Metadata. There you can define new public parts (part of the application that will be visible externally for other development components) or eventually add new Used DCs (public parts from other development components).

First our task is to develop a very simple portal component, so the first thing to do is to create a package and a class that will extend the AbstractPortalComponent class. After creating the package and the class “” in the “Package Explorer” view, you should see the following structure in the “Portal DC Explorer”:


Leave the “” empty for now. On the figure above you see one additional folder “dist”. This is the folder where we should update the portalapp.xml and also where we should create our JSP file. Creating the JSP is done in the “Package Explorer”. Give it a name “portal_test_page.jsp” and put the following code inside:

  • portal development component – includes our Abstract Portal Component class, the JSP to be displayed in the iView and the portalapp.xml descriptor


  • java development component – consists of helper classes that will be used in the portal component

  • J2EE library development component – deployable library containing our java classes. It is needed since a java component cannot be deployed on its own on the server. It needs a wrapper library, which in this case is this development component.


Then modify the portalapp.xml so that it looks like this:

<?xml version=”1.0″ encoding=”ISO-8859-1″?> <br /><application alias=”portalTestApp”> <br /><application-config> <br /><property name=”Vendor” value=””/> <br /><property name=”SecurityArea” value=”NetWeaver.Portal”/> <br /></application-config> <br /><components> <br /><component name=”Portal_Test_Application” alias=”PortalTestComponent”> <br /><component-config> <br /><property name=”ClassName” value=”de.ibsolution.portal.test.PortalTestClass”/> <br /><property name=”SafetyLevel” value=”no_safety”/> <br /></component-config> <br /><component-profile> <br /><property name=”AuthScheme” value=”anonymous”/> <br /></component-profile> <br /></component> <br /></components> <br /><services/> <br /></application>

The last step is to modify the “” and include the following line:

public void doContent(IPortalComponentRequest request, IPortalComponentResponse response) { <br />response.include(request, request.getResource(IResource.JSP, “pagelet/portal_test_page.jsp”));                                <br />}

Now build the portal component and export the PAR archive onto the Portal Server. After creating an iView for our portal application, in the preview window you should see the following result:


The truth is that so far we didn’t create anything spectacular and you’ve done that a minimum of thousand times before using a standard portal project and it was even a tick faster. Yes it was faster, but not any more from this point on. We are about to create an additional java component, where we can outsource some standard functions and make them easy to maintain. The java component is created exactly the same way as the portal one you just have to select Java for the component type. Those types of components are best viewed in the Java perspective, which also has a number of views. The “Package Explorer” is also present here and there you’ll create your new package and java class as shown below:


The contents of this class are as follows:

+public class PortalJavaTestClass { </p>bq. <p>public PortalJavaTestClass(){


public String getPortal(){

return “Portal Class from JAVA Development Component”;

} +

+} </p><p>In the next steps we have to include this class in the public part of the java component so that our portal component can later use it within its “Used DCs”. For that purpose we have to navigate to the “Java DC Explorer” view and there open the DC Metadata node of our component. Right-click “Public Parts” and select “New Public Part…”.</p><p>The public parts that you can create are two types. An “API” public part consists of only compiled classes and they are only used in build time within another development component, whereas the “SDA” public part is used for deployment on the server and contains both the class and the java files. In this example we need public parts from both types. Here is how to create the “API” type:</p><p align=”left”>!|height=469|alt=image|width=700|src=|border=0!</p><p>The “SDA” type is created exactly the same way, just check also the “as Source” checkbox.</p><p>After building the component you have two additional tasks – first to add the “API” public part to the portal component “Used DCs” and second to add the “SDA” public part to a J2EE Library development component and deploy it to the server. Since the first step is nothing special, I’ll just assume that you’ve done it and I’ll show you how to create the J2EE library component. In the development component window select the following: </p><p align=”center”>!|height=500|alt=image|width=415|src=|border=0!</p><p>The only thing left is to add the “SDA” public part to the “Used DCs” of the J2EE library. Build the component and deploy it to the server. Now we go back to our portal component, where we already included the “API” public part. We are going to change the code of our portal class so that it looks like this:</p><p class=”Stil1″>public class PortalTestClass extends AbstractPortalComponent { </p>bq. <p class=”Stil1″>private PortalJavaTestClass portal_class = new PortalJavaTestClass();

public PortalTestClass(){

} </p><p class=”Stil1″>public void doContent(IPortalComponentRequest request, IPortalComponentResponse response)


response.include(request, request.getResource(IResource.JSP, “pagelet/portal_test_page.jsp”));                               


public String writePortalInfo(){

return portal_class.getPortal();

} +

+} </p><p>Adding this code snippet, we are now able to call our java class within the portal component. To do so, we need to change our JSP file so that it looks like this:</p><p class=”Stil1″>de.ibsolution.portal.test.PortalTestClass testClass = new de.ibsolution.portal.test.PortalTestClass(); <property name=”PrivateSharingReference” value=””/>* *


This way the result after building and exporting our portal component would be:


You must be Logged on to comment or reply to a post.
  • Hi Todor,

    It’s a nice weblog and will definitely help anyone starting a portal development project. Only one thing:
    The PrivateSharingReference in the xml you showed is However the J2EE library DC you created was named portal/javalib.

    Doesn’t the PrivateSharingReference need to be


  • It’s a nice article.
    I’d have lost less time if I could read it before :)…

    A question thought, when creating a new DC, you can choose between :
    – Portal Application Module
    – Portal Application Standalone (Packed in SDA)

    For me, the first one is interesting for leting us upload the generated .par file directly and deploy it to the server.

    But the second one is way more useful, as it can be transported in NWDI.

    Do you confirm ?


    • Hi Arnaud,

      I am not really sure for the Packed in SDA type. I always use the module, since when you upload it to NWDI, the system is building an SDA at the end no matter what. So I guess it doesn’t matter.


      • Yes it does matter. Portal application modules are not deployable with SDM and therefore can’t be deployed on runtime systems by the NWDI without being wrapped in a deployable DC.
        I recommend using the DC type Portal application standalone, because the DC build produces a sdafile. For all developers not having a SDM password to any of there development systems, they can extract the par file with two clicks of the sda file and deploy it with the archive uploader.
        Cheers, Karsten