What is SAP Portal – FPN?
It is a way of sharing content between different portals. To simplify it, FPN provides functionality which is comparable to linking between portals but with some additional benefits like improved session management for remote portal content, theme integration (everything will look similar in the end for the end user), easier and more standardized administration.WebDynro java objects developed in SAP Netweaver platform can be accessed through portals.

A producer portal is the portal which contains portal content and where applications are executed. A consumer portal links from its own content offering to remote content located on the producer. Each portal might be producer and consumer at the same time (of course for different content) – so you don’t have to choose during installation which role your portal will take one day.

Why to use FPN?
Here are some reasons for it-

  • Number of portals in organizations is increasing
  • Users have to access more than one portal.
  • Allow users to access services and applications located on various portals.
  • Increase user productivity by providing one login portal per user.

The general idea of a portal is to integrate content centrally and web-based. It serves as the central entry point for end users in order to find information they require. However, in reality quite often various portals evolve in a company: different internal and external information sources and portals exist in parallel, often due to different owners of those systems. The end users have to know where they can find the specific information they need and how to find it.
FPN could provide an option to increase end user productivity by defining one central login portal which serves as an entry point for users to content which is spread over various portals.

How to use?
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.

How it is beneficial

  • Seamless access for end users to content located on different portals (SAP and non- SAP).
  • Content persisted once – accessed from other locations.
  • Different content sharing modes suitable for different administrative setups.
  • For connected portals FPN handles centrally.
  • FPN handles some essential services centrally:
  • Session Management – of course, when you log off from your central consumer portal, all connected sessions for producer portals should be closed as well.
  • Eventing: iViews residing on remote portals might have some interaction defined with other iViews. If you integrate content via FPN, these functionalities will still be able to run as desired.
  • Themes & Languages – when displaying content from remote, all content should be rendered seamlessly for the end user into
    one common user experience. Thus the theme and the language setting of the consumer portal should be applied to content coming from remote portals as well (however, the theme has to be available too in the producer portal to render the content correctly)


  • Administrator of one portal cannot modify the content in a remote role, cannot merge local content or remote content from other producers in a remote role.
  • When an administrator on a producer portal modifies a role that serves remote consumer portal, then he must be sure that the content is applicable to the business users on the remote sites.
  • Once remote delta links are created on the consumer, the source content on the producer portal must not be deleted or moved; otherwise the remote delta link objects on the consumer will not function.

In case you would like to decide for yourself, whether a federated portal network would be an appropriate portal landscape in your company, you should thoroughly evaluate the pros and cons of this solution. One central productive portal implementation of course causes a lot less administrative effort than a federated landscape with multiple portals that have to be monitored, administered & configured. However, a federated portal network can offer you some other benefits, which might make it desirable: You can have multiple portals exchanging content that could run on different releases, SPS and service-level agreements. Moreover, business units can own autonomous portals and create content (the delegated content administration sometimes is too restricted for organizational requirements). Thus you should decide for yourself whether organizational or technical requirements demand a federated portal landscape or whether you should stay with one central portal.

Please send us your questions, comments or assistance, and our team would be glad to assist you.

By Nikhil Joshi. (on behalf of SAP Consulting Team)

SAP :: Streamlined

We offer variety of services including SAP ECC ,SAP HR,SAP BW,SAP CRM, SAP SCM,SAP BPM, Business Objects, SAP ABAP DevelopmentSAP BASIS and SAP NetWeaver consulting. We have expertise in providing implementation,development, SAP Migration and SAP support services to SAP customers across diverse industries at a global level.
Have a question on SAP? Write to our SAP Architect.

(We promise a no-obligation consulting reply)