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
15 Comments