With Federated Portal Network, SAP offers organizations a technology to create content on one portal that can then be accessed (that is consumed) from another portal.
This gives you quite some possibilities, because you can provide a central access to content provided by different organizational units. If for example your Human Resources (HR) department runs an HR-Portal with Employee Self Services and your Finance Department has a BI 7 system with a BI-Portal that provides some analytical reports on it, you can integrate these two completely unrelated content types into your corporate portal giving your users a central access point so that they do not need to logon to different systems. And this is, after all, the major driver for a portal in the first place.
Of course the decision what content a user can access, is still completely at your fingertips because FPN puts no restrictions on user rights management at all.
What is a Federated Portal Network?
In a Federated Portal Network we always speak about two partners, the content provider (where you actually create the content), called the producer, and the consumer of the content (the one people access the provided content on) consequently called the consumer.
Take a look at this picture, to see the general concept of an FPN:
As you can see there are three systems here. One central (maybe corporate) portal and two producer systems each with it's own portal. The central portal consumes content from both producer systems and also provides it's own content.
An example for this could be a Collaboration Portal (with Knowledge Management) that consumes an ESS scenario from an HR-Portal and some analytical applications from a BI-Portal.
Secondly, what is shown, is the BI-System (on the lower left) consumes some Collaboration content from the central portal.
Content vs Portal Federation
As the picture shows, your users are not forced to only use the central portal to access the content, but can also logon to the producer portal (if you allow this) and use the content directly. Wether or not you want to allow your users to access only the consumer or the consumer and the producer portal is totally up to you.
You can also see a second concept in FPN in this picture: Portal vs. Content Federation.
The difference here is that in Portal Federation there are (at least) two completely different portals that each provide parts of their content to the other portal while also providing their own content. In such an environment, the users can logon to each of the portals to access the relevant content. One possible scenario for this would be geographical separate locations each with their own IT and landscape that just want to share some content to each other.
In Content Federation there is one central portal that consumes content from one or more producer portals providing a central access for all users.
In my opinion in the future a mixture of both scenarios will be more the common case than either one or the other.
Content Sharing Modes
At the moment there are four different variants on how content can be provided and consumed in a portal.
- Remote Role Assignment
- Remote Delta Links
- Remote Application Integration (for BI Content)
- WSRP - Web Services for Remote Portlets
Remote Role Assignment
With RRA - the earliest available content sharing mode, you create the complete content on the so called producer portal and then just assign users on the consumer to the roles (which of course in turn contain the pages, worksets, iViews and so on).
Remote Delta Links
With RDL you create the pages, iViews or worksets on the producer and then in the consumer create the roles and using a delta link to include the remote content from the producer in this role on the consumer. Thats the reason why it's called Remote Delta Link.
Remote Application Integration
This is the newest content sharing method and it's currently only available for BI applications. The idea behind RAI is to move the content administration from the producer to the consumer. This means you create the iView on the consumer but integrate applications (that is BI apps) from the producer BI system.
Web Services for Remote Portlets
WSRP is a compatibility content sharing mode - if you accept such a strange word crafting by me.
What I mean with this is, that WSRP is the only standards based content sharing mode provide by nearly all software vendors. In theory it should give you the possibility to integrate non-SAP applications in an SAP iView on the NetWeaver portal or, vice versa, making use of an SAP application on a non-SAP portal.
But, before you excitedly jump on this idea to e.g. integrate your SAP ESS scenario in an iFrame on MS Sharepoint Portal server, be warned, it is far from being complete!
You would definitely have to testrun ANY application to see if this can really work for you. This is because an application on a portal is much more than a simple web page and has a lot of dependencies. I'm not saying, it won't work, I just say, you have to test your specific application to see if it can be provided in a foreign (3rd party) portal.
HTTP-Connection and packet flow
There is one last thing I'd like to mention, because I was asked it so many times by clients, and that is the way a client accesses the portals involved in an FPN.
A lot of customers came up to me with this question: Can I use an FPN to "hide" my producer portal(e.g. my HR-Portal) from the client by providing access to it's content only through a central consumer portal???
The short answer is NO. The client always, at some point in the communication, also accesses the producer portal!
The long answer is this. In content sharing mode WSRP, the consumer portal acts actually like some kind of a proxy by completely consuming the provided application and in turn providing it on it's own to the client. So in theory it should be possible to use this content sharing mode to hide a producer portal, but keep in mind what I said earlier about this content sharing mode.
If you want to hide the existence of a producer portal, say as a some security measure, then the only valid option, at the moment at least, is to place a reverse proxy in front of your whole portal installation landscape and make all clients only connect to the reverse proxy. This will be the topic in a different blog.
The Wiki-Entry
In this just released wiki entry on SDN you find a step by step guide on what to do to setup an FPN between two SAP NetWeaver Portal 7 systems and then use Remote Role Assignment to consume content on the consumer from the producer.
You can find it here: Implementing a Federated Portal Network on SAP NetWeaver...
Have fun,
Christian Guenther
6 Comments
