Skip to Content
Author's profile photo Scott Braker
Scott Braker
Posted on June 20, 2006 2 minute read

What is a Federated Portal Network?

Follow RSS feed
0 Likes 158 Views 4 Comments
What is a Federated Portal Network? So then… If you have been to any of the events this year (WIS BW Portals, ASUG, SAPPHIRE etc.) you have most likely seen or heard the term “Federated Portal” or “Federated Portal Network”. At first glimpse into the Federated Portal scenario it may simply appear to the typical IT Systems Administrator that they will be responsible for more machines and a more widely spread out landscape than the one that they already have. Great! More work right? Not necessarily in this case. Actually, I believe that you will find that when you dig down into the Federated Portal Network Scenario you will realize that it is a much more logical landscape than you might have previously thought. It also will put the administration of the content producing portals back in the hands of the people that are responsible for those systems. For instance, the BI administrator will publish content that can be consumed directly from their portal instance rather than you having to copy content to your portal instance. Yet you still have access to the content that you need from a content consuming point of view. If you are a global company the biggest obstacle that you have from a portal point of view is really multiple offices, customers, data centers etc. A Federated Portal Scenario will Have to allow you to set up an “IT Infrastructure” that is spread out or dispersed over a true global geography instead of just a single data center instance or location. Some of your basic needs and/or technical prerequisites in this environment that will need to be addressed for a Federated Portal Network to be a success are things along the lines of the following:

  • Secure connections throughout your worldwide portal infrastructure
  • Multi language support
  • User Stores and Role based architecture(s) that ensures users to access only their needed content
  • Dynamic content access to repositories and applications specific to the user(s) day to day business needs

Now then, that all sounds pretty straight forward from a needs point of view. Everything else should be nice and easy to achieve correct? Well not exactly. We really need to take a look at what all this means to us on a global IT scale and as a company. Due to constant company merges and acquisitions we may have many different types of SAP Portals and non SAP portals out there in our landscape. We may have a variety of different needs from a content point of view also. This also means that the administration of the content on any variety of available portals may need to be maintained separately at each site. Therefore, we as a global company in an ever changing environment may need to maintain user roles, rights, access to and creation of content and applications. image Achieving symmetry between global organizations that are potentially separated by many IT centers dispersed worldwide is the advantage of a Federated Portal Network. By integrating individual portal instances that are spread throughout your worldwide infrastructure you are essentially creating one single interactive portal network that can be customized not only from a content standpoint but also from a business centric strategic viewpoint. As I move through this blog series I will walk you through the key features of the Federated Portal Network available within the SAP NetWeaver product. Next Step: Intro to Implementation of a Federated Portal Network (FPN)

Assigned tags

Similar Blog Posts

    Related Questions

      /
      image
      4 Comments
      You must be Logged on to comment or reply to a post.
      • Author's profile photo Christopher Solomon
        Christopher Solomon
        Nice intro. There was actually 1 or 2 questions about Federated (and Global) Portals on the EP cert. exam back in Oct. 2004. Seems SAP is still "getting there" but it is a huge task...."how do you eat an elephant?" one bite at a time.(haha)
      • Author's profile photo Steve Ledwith
        Steve Ledwith
        I am very interested in following this.  Technically, we are getting our arms around this.  Strategically, I am curious how other companies are governing these multiple portals that are popping up - that are application specific (portal fir BI, portal for xPD, etc.)  These are not true enterprise portals, they are Producers.  What kind of governance, methods & procedures are others using?  Does an enterprise portal team take a "hands-off" approach, and consider these Producer portals as part of the application?  Or, a much more hands-on approach?  Thanks for your comments !
      • Author's profile photo Former Member
        Former Member

        Hi, Scott.  Good Blog...thought I would pose a question in it to you.  I am currently in the process of architecting an extranet & intranet SAP Netweaver portal solution for my company.  We have many identified requirements & several options seemingly available that will address/handle our requirements.  One main security requirement is that it be deployed over a 3-schema security model (3 different networks <DMZ, Middle Layer & Inner Corporate Layer> isolated from each other via various firewalls & other devices.  And we also have 2 separate ADs (one for the outside & one for the inside).  Ideally, we would prefer having 1 single Portal on the inner layer for both intranet & extranet usage and utilize a reverse proxy device on the DMZ & web dispatcher (or similar component) on the middle layer.  But we may need to separate the 2 types of portals having one for intranet usage deployed on the inner layer and the other for extranet usage deployed on the middle layer along with an appropriate reverse proxy / load balancers on the DMZ (& middle layer as well).  This scenario obviously would require more basis & portal admin support and more resources so we are wondering if there would be any value in a 'hybrid' portal approach, where we utilize federated portals...one on the inner layer & one on the middle layer with some shared content between them.  Is this a valid use of the federated portal concept or is it only meant for distributed portal implementations by location &/or by business application (like CRM & BI, etc...)?  I would greatly apreciate your comments on this within this Blog or off-line via email.  Thanks.