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
Cheers,
ewH
Ramana.
Jagadish
Its really help full for starters like us. Good job Jana
regards,
Anandh
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.
Thanks,
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
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
Regards,
Ben
As a side note….in 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
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 🙂
Cheers,
Thomas Pham
Thanks for your time for this brief introduction about FPN. Is there any book from SAP about this in future ?
Thanks!
Rajavelu
thank you for the great blog.
It helped me significantly to get a basic understanding of Federated Portal Network.
Stefan
Thanks for providing good basics in a practical way.
Regards,
Navneet