Skip to Content

TCO reduction for application distribution

You have decided to separate your applications from your corporate portal. There are different reasons that may have lead you to this track. When you try to find out how to accomplish that, they’re telling you to use the Federated Portal Network (FPN) capabilities.

You then may wonder why? I mean, in NW 04 you could separate almost all applications from various backends and integrate them nicely into your corporate portal. So what happened? Well, in SAP’s new releases powerful capabilities were added to applications such as BI and WebDynpro Java, which in turn requires the dependency to the Portal. More accurately the EP stack.

This means that you have to run BI or WebDynpro Java on an EP stack. You may not want to run it on your corporate portal, so you run it on a separate EP stack.

The Federated Portal Network offers great capabilities allowing you to share and reuse content, maintaining applications once and using in multiple portals and lower TCO by consolidating multiple portals from different departments or subsidiaries. So let’s use FPN to integrate these remote applications. Great idea, right? FPN is designed to share content, so before we do this, we need to create it on that separate installation. But content creation means additional maintenance. Maybe we need another content admin for that secondary portal. What if we want to split up BI to one system and WebDynpro Java applications from ESS to another? More content and more maintenance…

Ok, maybe not such a great idea to abuse FPN for that. But what are the alternatives? There’s URL integration, but who’s going to take care of session management? Theme integration?

Well, Portal development has heard you. You may already know this, but in NW 7.0 SP13 a new template for BI was introduced. With it, a new way of consuming BI 7 applications came. It enabled creating content directly on your corporate portal, which runs a remote BI application from the remote EP stack. OK, you connect two EPs so this means you need to create a producer object rather than a system object. A three step wizard rather than finding and filling in the fields of the system object? Doesn’t sound that bad.










So you can actually treat the BI portal as an application server. No content management and basically, not really a portal. But why stop with BI? In Enhancement Package one (EhP1) of NW7.0 you get this cool feature where you can also create iViews directly over remote WebDynpro Java applications! In NW 04 we could have done this using a template iView where we filled in the application name etc, but until EhP1, there was no way to do that with the new, powerful WebDynpro Java applications in NW7.0.






























An additional bonus is that there’s no need to fill in manually the name, namespace and all those application parameters. Simply choose the remote EP and browse through its deployed applications, then choose the application and create the iView so no more typos.


Be the first to leave a comment
You must be Logged on to comment or reply to a post.