Skip to Content
Author's profile photo Simon Kemp

What does that funny URL do?… it bypasses the document hooks… huh?

If you’ve ever developed any custom portal components you might have wondered where all that extra HTML/CSS/JavaScript comes from that surrounds what you generate in our own code. Over the years I have often wondered if there was a way to tell the Portal Runtime to just give me back what I added to the HTTP response body and not all that extra stuff 😀 .

Recently I came across a way to do this, sort of by accident whilst looking into how some of the new Portal on Device features worked and speaking with Dong Pan from SAP. I looked around but didn’t find much in the way of documentation on this, so I wanted to at least start off by sharing what I could.

What I’d like to do in this blog is show you what I mean in more detail and also explain why this is a useful feature and one that is used in Portal on Device. So by way of example I have written a very simple “Hello World” portal component that just writes out that age old text to the response body. I want to compare the markup that is returned when I call this component in the “normal” way vs. what is generated when called with the prtrw URL.

Here is the simple code:


Well I won’t be winning any awards for that 😆 … but bear with me here. I deployed this to my 7.3 Portal and created an iView in the PCD. When you run this component by calling the following URL:


you get this back:


and here is the source you can see in the browser if you view the source (quite a lot more stuff then I added):


Now for the interesting bit… if I call the same component but replace the /irj/servlet/prt/portal/prtroot/ in the URL… with /irj/servlet/prt/prtrw/prtroot… the output is significantly different:



And this time you get this when you view the source:


So when you use the prtrw in the URL instead of portal, this apparently tells the Portal Runitme to bypass all the so called document hooks and avoids all the extra HTML, CSS and JavaScript that gets added by default.

So now you might be asking…So why is this useful???… well one reason is that if you wanted to write a Portal Component that produced a JSON or XML or oData response you don’t want all that other markup getting in the way. This was the use case I saw in the Portal on Device example – Portal Components were used to generate JSON responses and were being called from the client using JQuery AJAX calls.

Anyway I hope you find this interesting. Perhaps you have come across this little trick before? I noticed in my research that Visual Composer seems to use it too, but mostly it seems to be a well kept secret 😯 . Thanks for taking the time to read this post. Let me know what you think below.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi Simon

      Interesting, but my standard way to return raw output is to use something like:

      protected void doOnNodeReady(

      IPortalComponentRequest request,

      IEvent event) {

      HttpServletResponse response = request.getServletResponse(true);


      response.setHeader("Content-disposition", "filename=\"test.htm\"")

      try { out = response.getWriter();

        response.setContentType("text/html; charset=UTF-8");

              out.print("Hello world");


      } catch (Exception e) {




      and an empty

      public void doContent(IPortalComponentRequest request, IPortalComponentResponse response)



      That way there is no mucking around with URLs etc

      Author's profile photo Simon Kemp
      Simon Kemp
      Blog Post Author

      Thanks for sharing Michael, does that method also avoid all the document hooks? There is probably some subtle difference between the two methods, but good to know that there are (as usual) more than one way to achieve the same result.

      Author's profile photo Former Member
      Former Member

      Possibly a PRT internals person would know the difference! I just know that when I want to return a plain response I need to use doOnNodeReady...

      Author's profile photo Tobias Hofmann
      Tobias Hofmann

      On 7.0x this works as well:

      public void doContent(IPortalComponentRequest request, IPortalComponentResponse response) {

        try {

          HttpServletResponse servletResponse = request.getServletResponse(true);

          PrintWriter out = servletResponse.getWriter();

          out.write("<h1>Hello World</h1>");

        catch (IOException e1) {}


      The trick is to do the request.getServletResponse(true). This gives full control over the output.

      Author's profile photo Simon Kemp
      Simon Kemp
      Blog Post Author

      Thanks for sharing this Tobias. Does this only work on 7.0x systems not 7.3?

      Author's profile photo Tobias Hofmann
      Tobias Hofmann

      I guess it also works on 7.3 systems, but as I do not have a 7.3 system around to test it, I can only say that it works for 7.0x 🙁

      Author's profile photo Former Member
      Former Member

      Yep, it works with 7.3. I just tried it on one of our training systems...

      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer

      hmmm, could this be the technique used by the NetWeaver Business Client, when integrating portal content?

      Author's profile photo Simon Kemp
      Simon Kemp
      Blog Post Author

      Hi Tom, thanks for your comment. Yes perhaps you are right I am not that familiar with how NWBC integrates portal content.

      Author's profile photo Former Member
      Former Member

      Very well!

      Now that I can call a portal component by its url, the problem now would be getting access to the component with the guest user from a client app.

      Or some how the portal component now should be public ?

      Author's profile photo Simon Kemp
      Simon Kemp
      Blog Post Author

      Hi Felipe,

      You can of course access a portal component anonymously (without needing to login), if you set the iView property "Authentication Scheme" to "anonymous" and also set the permission on the iView to allow Guest to have "End User" access (do this via the permissions of the iView).

      Doing both these things will give you anonymous access directly via the URL.



      Author's profile photo Former Member
      Former Member

      Hello again Simon and thanks for answering, I don't usually hope for a quick answer!

      This is what is happening:

      I have no problem accessing the url through the web browser, I get a clean "hello word". But when a access the url through an URL java object within a "public void main" program, I get a access denied for the guest user.

      But why, what is the diference, isn't the same thing ?

      At this point, should be necessary to make an iView and set the propperties you are saying ?


      Hello, I had not realized that when I use the browser the portal also asks me for authentication. And this is why I need an  URL iView! Thanks Simon.