Skip to Content

An Introduction to Federated Portal Network (FPN)

To give you an idea, why the concept of FPN has been established, let’s start with a simple portal setup: one central portal exists inside a company. The general idea of an enterprise portal is the integration of all relevant information of a user into a web based user interface. This should then serve as the central entry point for the end user to his daily work. The benefits for end users are obvious: They have one user interface where they can find all relevant information without having the need of connecting and authenticating to a bunch of different systems (an example is illustrated in the following image).


However, in many real life implementations we can see that it’s not always straightforward to set up one central portal serving all users needs. This could be the case due to various reasons: e.g. different authorities within a company are responsible for different portals – various departments or business units own portals and autonomously create content there. Other reason might be: there are needs for different portals that run on different releases or SP Stacks and according applications running on the server. There would be a couple of other scenarios that we could list here. In essence, we can see quite often a mushrooming of portals which forces users again to know how to access which portal and where to find the required content. In order to increase efficieny of the end users and ease the daily work within those distributed portal setups, SAP offers means to implement a federated portal network. The functionality with all its tools is fully available since SAP NetWeaver 7.0 SPS 10.

Within my blog series in July, I will focus on some of the key topics for implementing a federated portal network and the development team of FPN will give you some more insights on the latest ideas and developments in this area.

To start with let’s have a look at the question “What is a Federated Portal Network?” It is a way of sharing content between different portals. To oversimplify it, FPN provides functionality which is comparable to URL linking between portals but with some additional benefits: 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 … I would like to emphasize that FPN does not offer any functionality for synchronizing or transporting content in a portal landscape and it does not provide means to improve performance considerably over long distances.

In the context of FPN, we should introduce the terms “producer” and “consumer” portal. 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. You can configure this in the portal and I will show you in the next blog of this series how to do so.

Well then, which kind of landscapes could you implement with the federated portal network? Basically this really depends on your specific use case. As a general rule: Setting up only one central portal is a common landscape and for sure the most straight-forward solution from administration perspective. We usually see 2 basic options on how to set up a federated portal network:
1. You could have one single consumer portal that serves as the entry point for all end users in your company. The portal content and the applications (like for example Business Packages) themselves are distributed to different producer portals, and the administrators can act autonomously on those producer portals. It is possible to keep the consumer portal pretty lean so that it basically provides a central navigation to remote content (but this is not a must, you can have content on your consumer portal too).
2. The other option might be especially useful when there are already portals existing in parallel inside an organization with different user groups accessing them as main portal (e.g. after mergers & acquisitions). Each portal is consumer and producer at the same time and they exchange content relevant for both organizations – the content has to be created and persisted only once in one of the portals.

Ok, so far this was the foundation on the general idea of FPN. Within my FPN Part II – Configuring a Federated Portal Network I will focus on the setup of a federated portal network.

Overview Blog Series FPN:

FPN Part I: An introduction to the Federated Portal Network (FPN) – this blog
FPN Part II – Configuring a Federated Portal Network
FPN Part III – Sharing Content between SAP NetWeaver Portals

You must be Logged on to comment or reply to a post.
  • Jana, thanks for the great overview.  We are thinking of implementing a federated portal, so I am looking forward to reading your upcoming series.


  • Hi Jana,

    It would be useful, if your blogs provide more detailed information on new features and functionalities of Federated portal network instead of information which is already there in Marketplace, SAP Help and SDN Wiki sites.


    • Hi Ben,

      of course I and the colleagues from development plan to publish more detailed information in the course of this month (and ongoing after that). We are setting here the basis for some more advanced features and outlooks on FPN - so stay tuned.

      Best regards

      • I agree with Jana.

        As far as a blog series is concerned, I think it's useful the series starts with a general overview, which gathers the necessary basic information one needs to fully understand the next more advanced blogs in the series.

        Cheers, Davide

        • Reference links to FPN overview pages (in Service Marketplace or Wiki)should have been appropriate in this case than publishing seperate blog itself.


  • Jana....really looking forward to this series! I have been waiting for FPN to come along for a while now. Good start to kick things off!

    As a side the early EP6 certification classes (mine was with Jose Martinez in 10/2004! Big shout out to Jose! haha), there was brief mention of TWO kinds of global portal strategies...Syndicated or Federated portals. It was explained that Syndicated portals were "one central portal with several remote portals and the central portal keeps everything synchronized.". A Federated portal environment was explained as "ALL portals acting like syndicated portals". However, over the time sense, it seems to idea of "synchronization" was abandoned (all together?) and the idea of the FPN was changed a bit. Any reasons for this? Is the idea of "syndicated portals" still alive or has SAP dropped that? I can imagine the technical challenges involved in synchronizing content...even among portals on the same version/SP level and hardware! Until now with FPN becoming viable, all my past projects involving global portal landscapes pretty much came down to manually reproducing content (ie. moving custom packages around) across all portal CI's. I am hoping FPN will be the solution to that manual maintenance nightmare! haha

    • Hi Christopher,

      you are right, Federated Portal Network is really only about linking one portal with another one and not about synchronizing portals. The formerly known "Syndicated Portal" approach has always been only a custom solution where SAP delivered some recommendations. However, as you already stated, the topic is rather complex if you want to keep the whole Java Stack in sync all the time. Thus there are investigations ongoing on that topic. From my point of view it is unlikely that it will be covered by "Federated Portal Network itself" one day since the required underlying technology is quite different. But you can be sure: As soon as there are some news, we will bring them to SDN 🙂

  • I recall from early EP6 days it was branded Global Portal, but SAP has since changed the direction to Content Federation and Portal Federation focusing more on the content installed in the Portal. I believe this move is to accommodate the different levels of SP Stacks and add-on components tied to NW release levels.  Will SAP ever deliver a true Global Portal Strategy?


    Thomas Pham

    • During the migration process problems have been reported for this blog. The blog content may look corrupt due to not supported HTML code on this platform. Please adjust the blog content manually before moving it to an official community.