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. externaldns.company.com:80). 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.
7 Comments
