Skip to Content

In my  experience, there is a quite prevalent misconception about how the portal works with regards to integration of ‘backend’ SAP web applications (BSPs, BW Reports, ABAP or Java WebDynpros, transactions using WebGUI, IACs). Specifically, the expectation is that the portal acts as a proxy to this content, so that all communication from the browser will be to the portal server, which then contacts the backend server directly to retrieve the content and returns it to the browser. Therefore (the theory goes), as long as the user’s browser can resolve the hostname of the portal (or of a proxy or load balancer in front of it) then all backend content should be accessible from the Internet, even if the backend content server (WebAS ABAP / WebAS Java / ITS) is not accessible from the Internet. The network diagram for this imagined behaviour looks a little like this:


The scenario is tested from inside the LAN, and everything works fine, but shortly before going live to external users, the administrator discovers that the backend content is not in fact accessible from outside the LAN … and gets a very unpleasant surprise. The aim of this blog is to set out how the portal actually integrates backend content, and what you can do about it – and hopefully help avoid such unpleasant surprises at an advanced stage in the project planning. 

In fact, the portal does not act as a proxy to backend content (the one exception is BW reports of the 2.x/3.x variety, where the portal can be configured to proxy the content). Instead it performs a redirect to the content, and the browser connects directly to the backend content server. So the network diagram should look like this:


I should note that we are talking specifically about web applications integrated using appintegrator iviews here. If your iview is based on a portal component that retrieves data from the backend via JCO/RFC, then that communication does take place from the portal server, of course.

The requirement for direct access between the client and the backend is flagged in the documentation … though perhaps not prominently enough. You can check out the Portal Security Guide, specifically the section “Network and Communication Security“: ‘Neither the portal nor the AS Java provides a proxy function. […] If you have set up a network architecture with one or more firewalls, and your portal integrates iViews that initiate client-backend communication, you must set up access for the client through the firewalls to the application server in the back end.‘ This page also provides a table detailing the kind of connections that are established for each iview.

The bottom line is that, if you need your applications to be accessible from your Intranet and from the Internet, you need to ensure that the host maintained for this system in the portal system landscape can be resolved both internally and externally (and also is not blocked by any firewalls). Of course, you can put a web dispatcher (or any reverse proxy) in front of your backend content server, just as you would do for your portal – depending on the proxy you use, you may even reuse the portal proxy for this purpose. This means that the content server is not directly exposed to the Internet. The network diagram now looks like this:


Of course, if you decide to access the backend server via a proxy, you should update the host maintained in the system object referenced in the ‘System’ property of the iview. You can update the host by editing the relevant system object (at portal menu path System Administration > System Configuration > System Landscape), and setting the relevant hostname property to a host and port that is publicly accessible (e.g. For BW, BSP and WebDynpro applications you should adjust the Web AS Host Name; for Transactions using WebGUI and IACs you should adjust the ITS Host Name property instead. You may also need to update the relevant property specifying the potocol to use also.


That’s it! However, in my Accessing Backend Content through the Enterprise Portal from the Internet – Further Considerations I’ll look at some more advanced considerations for integrating backend content – for instance, where you want the backend content to be accessed via reverse proxy for users accessing it from outside your LAN only.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Ivan Milkovic
    I’m about to configure a Portal that access ECC content both from intranet and internet, thus I found this information quite useful. Thank you for sharing!
  2. Daniel Da Vinci
    Excellent write up on a common misconception of how the Portal functions in it’s framing vs. retrieval of back end content.

    I’d like to include the point that this isn’t only relevant to external content, but many companies have internal security zone policies that expect the portal to be proxy back end content also which simply isn’t the case.

    I found this point a reducing factor to the overall improvement of the Integrated ITS solution where the most secured stack was now also responsible for rendering content.

    Anyhoo – good effort on the blog.


  3. Sergio Ferrari
    Thanks for clarify one really common misunderstanding about SAP Portal acting as a Reverse Proxy.
    I would suggest to say something also about dear old SAP Web Dispatcher but it’s fine.
  4. Alexander Türk
    we went also through all the suffer process until we setup a sap web dispatcher before the portal and another one before the abap systems. Helped us with loadbalancing, bringing port to 443 and securing the whole environment. Main problem for us (sap basis) was, that application development didn’t understood these structure and in the beginning bypassed our sap web dispatcher by accessing direct to the abap systems.
  5. Sean M
    Hoo boy, that brings back memories. This misconception lead to me being called in to a project AFTER the planned go-live date. No names…

Leave a Reply