Implementing a Federated Portal
Network
Organizations can implement a federated portal network using the SAP NetWeaver platform to share content between portals.
A federated portal network allows organizations with distributed portal installations, both SAP and non-SAP, to provide a single portal access point per user to portal information, services and applications distributed on portals throughout the entire organizational network. This implementation allows existing content and configurations to be utilized, and to minimize administration.

§ This scenario is not intended to improve performance issues between remote sites. However, some federated portal landscape configurations combined with certain content types may yield better performance compared to landscapes that have not implemented a federated portal network.
§ This scenario does not offer any manual or automated functionality to synchronize portals and their content.
§ This documentation may contain references to functionality that is not fully supported in this release. For information on where to find SAP Notes describing known issues and limitations related to this scenario, see Limitations, Known Issues, and Workarounds.
The major benefits of implementing a federated portal network are:
● Reuse of content and applications throughout the network
● Increased autonomy of business units
● Integration of non-SAP portals into the SAP NetWeaver platform, allowing the exchange of WSRP-compliant applications within SAP NetWeaver Portal
● Higher return on investment (ROI) achieved by optimized reuse of human capital and hardware resources within the company
This scenario applies to two major use cases:
● Content federation: A network comprising two or more portal installations—one functions as the logon portal for all users and the remaining portal installations function as content providers. This allows you to separate application execution and rendering from the main portal server.
● Portal federation: A network comprising two or more portal installations—each portal installation can function as an autonomous entity serving its own content and users, but also exposing and consuming content to and from other portals in the federation. Portals can also rely completely on remote content from other portals, thus avoiding the need to create and maintain local content.
Before implementing a federated portal network, you should understand the business requirements and technical conditions of your landscape and the benefits offered by SAP NetWeaver.
Each use case supports different business scenarios. For more information, visit the Federated Portal Network area on SAP Developer Network at www.sdn.sap.com/irj/sdn/nw-portal.
Each portal in the federation can be a producer, consumer, or both, depending on whether it exposes its content for other portals or uses remote content exposed by other portals.
● Producer portal: A portal installation that provides other portals (consumers) with remote access to its locally-deployed applications.
● Consumer portal: A portal installation that accesses remote applications provided by another portal (a producer).
Each portal can support both local and remote users.
SAP NetWeaver Portal provides consumers with different tools for using remote content exposed by SAP NetWeaver and non-SAP producers in the federated portal network. A decision to choose one tool over the other depends on several factors, such as the vendor of the producer portal, the type of remote content, and what the consumer intends to do with the content once it has been created on the portal. For more information, see Content Usage Modes.
The following is a list of the portal features used to implement a federated portal network:
User persistence |
All portals in the federation connect to a global user repository. |
Remote role assignment |
● User administrators on a consumer portal can search for and assign users to roles on a remote portal (producer). ● The role is executed on the remote producer portal at runtime. ● The remote roles are defined, configured, and maintained solely on a producer portal, thereby minimizing content maintenance by the consumer. |
Create content as remote delta links |
● Content administrators on a consumer portal can browse the Portal Catalog of a producer portal, and then create remote delta links to iViews, pages, worksets, and roles residing on the producer portal. ● The remote delta link content can be reused and customized locally on the consumer portal, while maintaining the ability to keep unmodified content synchronized with their source objects on the remote producer portal. |
WSRP-based application sharing |
● Content administrators on a SAP NetWeaver consumer portal can integrate WSRP portlets from remote non-SAP portals into SAP NetWeaver Portal. ● SAP NetWeaver developers can create WSRP compliant iViews that can be consumed in non-SAP consumer portals. |
Dedicated caching |
A portal-based caching service for the federated portal scenario can be used to reduce network traffic by storing semantic objects on the consumer portal for reuse. |
Consistent user experience |
● End users can personalize remote iViews the same way they personalize local iViews, for example, configuring iView properties. ● End users can personalize remote pages in a manner similar to the way they personalize local pages, for example, removing iViews from a page and changing the page layout. In some cases, limitations apply (see Personalizing Content). ● Users on the consumer portal can personalize themes and languages. ● The portal look-and-feel can be consistent for all integrated content. |
The federated portal network tools are optimized for content sharing across portals. The tools are not designed to enable remote site management or global monitoring.