Skip to Content

How to Deploy SAP NetWeaver – Guidance for better System Landscape Designs




SAP NetWeaver supports a high level of flexibility, how to deploy main SAP NetWeaver capabilities within a system landscape. In the past SAP mainly just described the variability of those different deployment options, sometimes at least SAP provided some information about the pros and cons of each option.

What customers so far are missing, is a clear guidance, what might be the best landscape layout for most of typical use cases.


However, what is the best landscape layout ?


Of course this question can not be answered by a simple statement. There are lots of different aspects to be considered like

  •  the organizational setup of a company

  •  the architectural strategy of a customer

  •  the need for governance processes

  •  the expected speed of innovation for used applications

  •  specific security requirements

  •  individual performance & scalability requirements

  •  the needed availability and service level agreements

  •  operational costs

  •  etc.

One specific landscape layout might be the best one for a customer, whereas another customer would prefer a different setup. Nevertheless it should be possible to reduce the high number of technical possible combinations of different landscape setups to a set of alternatives, that fit well to most of the typical use cases.


How can SAP help to find the best landscape layout ?


In my opinion you can not optimize all aspects that have an impact on landscape designs by exactly one landscape layout. All these aspects might be assessed differently by different customers. So it is not about optimizing a landscape layout due to a few aspects, while completely neglecting some others. SAP will not be able to recommend exactly one landscape setup that is the best choice for all customers, and which is optimized for all important aspects.

But SAP should be able to recommend landscape setups, that

  • are the best trade-off between the most important design aspects,
  • find the right balance between the antagonists flexibility and simplicity,
  • are accepted by the majority of the customer base,
  • fit to SAP’s product strategy and
  • should not have to be changed every 6 months.

And now I want to explain, how we are going to achieve this (at least we are working on it).



The approach:



From my perspective 3 main factors are essential for having success with such a new approach:

  1. Ease of understanding:
    The recommendations should be quickly to consume and easily to find. Providing a first and comprehensive overview is the goal rather than providing a 100 pages document which can only be consumed by the individual topic experts. The information should be published at one central place, instead of distributing it in pieces across different topic areas within SDN.

  2. General adaptability to SAP products (not limited to some specific capabilities):
    A common methodology, how to describe recommendations for different SAP products or different building blocks within the products is key. The same methodology should be applicable for the main architectural building blocks like e.g. SAP NetWeaver Portal, SAP NetWeaver Process Integration or SAP ERP ECC Server. Even for smaller units like Adobe Document Services or System Landscape Directory the methodology should work, if these units are relevant for the landscape design.

  3. Consistency:
    Guidance requires a certain level of consistency and continuing significance. Recommendations should not be changed every 6 months from one direction to the complete opposite, and they should be consistently aligned within SAP. When changes occur – and of course this can happen – they should be made transparent as soon as possible in order for customers to react on them.


We tried to consider all three factors when developing the following approach:

  • We created a framework that clearly shows a “rating” of different deployment options by dividing them into three main categories:
    – general recommendation,
    – reasonable alternative,
    – possible exception

    Recommendation Framework


  • The same framework is applied to those building blocks of SAP products, which are the major entities within a landscape design (e.g. Business Warehouse, Application Portal, or Enterprise Services Repository).
    Shall those building blocks be implemented centrally or locally in the system landscape ?
    Shall they be deployed together with other building blocks in the same technical system or better deployed in a separate system ?
    The recommendations based on the framework will help to answer these questions.

  • In the first phase we will focus on building blocks of SAP NetWeaver 7.0 and 7.1 as part of SAP Business Suite 7 solution landscapes.
    Starting mid of 2008 with introducing the framework and providing some first generic recommendations regarding the usage of dual stack systems and SAP NetWeaver for the SAP Business Suite, we now published in addition to this recommendations, how to deploy SAP NetWeaver Portal, Adobe Document Services, SAP NetWeaver Business Warehouse and BEx Web, SAP NetWeaver Process Integration, System Landscape Directory, and Enterprise Services Repository & Services Registry within a system landscape.

  • All these recommendations are published in the same easy-to-consume format and are using the same kind of categorizations. They are providing a quick overview and are published at one central place within SDN: section Distribution Models

  • To achieve consistency, we do not just focus on the state of the current available release, but also take SAP’s product strategy for the upcoming releases into account based on the 3 year product roadmaps. Furthermore all recommendations are aligned within SAP across different areas and are approved by the SAP System Landscape Governance Board, a new unit within SAP, that focuses on system landscape related topics and drives landscape governance within SAP across our products.




To make it more concrete, let us have a short look at an example of the recently published recommendations. So let us talk about deployment recommendations for the SAP NetWeaver Portal. You can find all the details at the link mentioned above.


Especially for portal capabilities it is a very valid architectural question to decide, if you want to setup one central portal, shared by multiple different application backend systems, or if you rather prefer to setup multiple local portal systems, each portal serving one dedicated backend system, and all portal systems somehow connected (federated) with each other.
Another important question is, if the portal capabilities (or to phrase it in other terms, the SAP NetWeaver usage types EP or EP-Core) should be deployed as a separate technical system (SID) or combined together with the application backend system, meaning installed within the SAP Business Suite system (e.g. same SID like the ECC server of an ERP system).


In the past – without any strict guidance  – all these variants were technical possible and could be installed. Resulting to the situation that we noticed a high uncertainty at customer side  to determine the right setup.

Everything was possible, but does everything also lead to the right setup ?


How can a customer be sure that the chosen portal landscape layout is still aligned with SAP’s strategy two or three years later ?

With the new approach, we now clearly state to avoid any joint deployment of the portal with the SAP Business Suite backend system in the same technical system (same SID). Based on the framework our general recommendation is to target one central application portal as a separate technical system, which can be shared by multiple different SAP Business Suite backend systems to provide e.g. a central role-based and personalized access. In addition you can check whether to deploy WebDynpro Java-based application UIs on that central portal infrastructure, to avoid the setup of further additional local portal systems, which would have to be integrated into the central one.




General Recommendation for Portal


For certain use cases it might make sense for customers to setup an additional local portal, e.g. customers who want to have a dedicated HR portal, providing the infrastructure for Employee Self Services, and directly connected to one HCM backend system. Such landscape layouts are of course still possible and supported and are rated as a reasonable alternative. It has to be decided by a case by case evaluation, if this setup makes sense for a customer.


Reasonable Alternative for Portal


So the general idea is to start with the central portal approach and then decide,  if an additional local portal for certain applications or Web Dynpro Java-UIs would make sense to achieve a higher independency from the central portal infrastructure.



Let me conclude this example with a short comment on federation scenarios within a multiple portal landscape.

To be honest, SAP’s strategy within that area have been adapted during the last years. We learned from customers that going for a strategy which lead to landscapes of multiple different portal systems, which have to share data and which require complex federation scenarios, do not lead to the best-trade off between flexibility and administration costs. As a consequence we adapted our strategy and based on the new approach of  providing better guidance, we are also going to make this change visible immediately. So our current solution (Federated Portal Network – FPN) is still supported and might make sense for very specific use cases. However, we rate it as a possible exception, to make a clear point that we do not recommend to use FPN as the typical default setup within a portal landscape.


By using a central portal approach, other applications and UIs should be integrated via application integration (further details can be found in the portal related sections within SDN).



Possible Exception for Portal Deployment 




This example demonstrates that even when strategy changes occur – which of course can happen in order to reflect customer feedback or changed or new market trends – SAP is now providing more transparency for customers to get aware of the new situation as soon as possible.


Since changes for the deployment strategy often also have an impact on the product applications that are dependent on the landscape layout, not all already available & shipped applications might be able to make use of the new recommendations. So they will stick to the new recommendations for future releases, but might have some restrictions for the current available release (which was developed on the former strategy).

On the other hand we do not want to provide only deployment recommendations for upcoming new releases, letting customers run into a wrong direction, when planning their system landscapes for the current available release.


To solve that dilemma, we decided to publish recommendations, starting with the highest current available product version/release (which will be indicated within the individual presentations) to provide guidance as fast as possible and to show the direction SAP is moving to. For most of the use cases the recommendations fit well. Nevertheless – especially if some strategy changes have occurred – this can not be a guarantee for every individual application and possible restrictions have to be checked. The recommendations will make you aware of this as far as possible (e.g. when deploying WebDynpro-Java UIs in the central application portal, the version interoperability of the individual application has to be checked. Starting with SAP NetWeaver 7.0 SPS 13 major improvements have been achieved, so applications like e.g. Employee Self Services only require SPS 13 as a minimum SP stack in the portal system and the clear goal is that any update of the ESS application will not force further SP stack or EhP updates of the SAP NetWeaver Portal runtime. Details can be found in the SAP Notes for these applications).






Let me shortly summarize this blog by emphasizing the most important facts:

  1. SAP is going to provide a stronger guidance for landscape planning by publishing clear recommendations, how to deploy SAP NetWeaver within a system landscape.

  2. The recommendations reflect the best trade-off between simplicity and flexibility and consider SAP’s mid-term product strategy.

  3. All recommendations are based on a common framework and are approved by SAP’s System Landscape Governance Board to assure consistency across different SAP products.


I hope, you are as excited as me to make use of this approach. I am personally convinced that this is the right approach to ease the landscape planning process for customers and to help to  reduce complexity in many areas.

You must be Logged on to comment or reply to a post.
  • This is a good high level overview of the options, but maybe you can also include a use case suggestion for an external facing portal? In other words, if I want to use SAP NetWeaver Portal to provide both intranet and extranet access, should this be 1 portal instance or 2?
    • Hi Michael,

      valid point, I'll put it on the list for the next version. In the first version we wanted to focus only on the main use cases and therefore cover further SAP NetWeaver building blocks like PI, ESR, BI, etc.



  • Nice blog!
    We are currently running NW 7.0 portal and also interested in running BPM/BRM in NW CE 7.11 light-weight portal.
    In order to achieve central single access to portal, would that left us with the only option of using FPN? Any alternative?
    Should the CE be the producer portal or central consumer portal?
    • Hi!

      To my mind you should have CE as producer portal, BUT it has higher version of release and thats why some problems with integration per fpn may occur.

      Best wishes,

    • Hi,

      unfortunately there will be no general statement, how to integrate CE into a central portal. This will depend on the kind of "application" running on the CE system that should be integrated into the central application portal.
      For BPM we especially see the integration need for UWL tasks. With SAP NetWeaver 7.01 a UWL connector is released to integrate UWL tasks of the CE/BPM system into the central UWL of the SAP NetWeaver 7.01 application portal (this should be described in the help documentation of CE/BPM).
      Furthermore our portal experts are planning to provide a guide, how to integrate different technologies (e.g. Web Dynpro ABAP, Web Dynpro JAVA, BI JAVA web templates, etc.) into a central portal.



      • Hi Dirk,

        I'm looking into directing BPM tasks into central NW 7.01 Portal. You mentioned that a UWL connector is released to integrate UWL tasks of BPM into central UWL of NW 7.01 portal. However, I could not find any help documentation stating about this. Which UWL connector type are you refering to? Could you guide me on this?

      • Hi Dirk,

        We are also planning on adding a CE 7.1 environnemnt in our SAP landscape.
        In order to to integrate Java WebDynpros from CE in the central Portal (NW 7.01), we need to use iView Based on a Remote Application and thus to setup a FPN, according to sap docuemntation.
        Do you know if by any chance there is an alternative to the federated portal, considering that we're on the latests SP ?
        Thank you for your help.

        • Hi Raoul,

          unfortunately there is no general answer possible. You don't necessarily need to set up FPN to integrate your remote CE Web Dynpro application - however, this depends on a few application criteria. Our portal experts are planning to rollout more details about CE - central Portal integration within a few weeks on SDN. Sorry that we can't provide more detailed information today.



  • Hello Dirk,
    nice blog!

    one question tho: From a technical point-of-view, whats the difference between your "Reasonable Alternative" and your "Possible Exception"? Arent both setup based on FPN? Or how can i remotly integrate applications running on a "local" portal in a "central" portal without connecting both via FPN?


    • Hi Markus,

      The main difference is to clearly point out that FPN is only useful for a specific use case (where you really want to use content sharing between a producer and a consumer, e.g. because of some organizational needs). It is not the only and always best method to integrate remote applications into a central portal. There are alternatives.

      SAP Note 1140854 e.g. describes the alternatives, how to integrate BI JAVA (based on a portal) into a central application portal.

      Our portal experts are currently working on some more detailed documentation about integrating applications (which might run on a local portal) into a central portal.
      Some aspects have already been published in some TEchED presentations in 2008 (e.g. UP106).
      Here you can also find an overview about the different alternatives and some possible use cases, when to use what.



  • Hi Dirk,
    intersting informations.
    We are going to implement FPN with a central consumer portal and multiple application (producer) portals. The main reason is to avoid release dependencies. In the past we couldn't deploy the newest SPs to the central portal because the SP status of one backend system didn't allow it. An SP update of this backend system was inhibited by Business. Other backend systems required a higher SP level of portal. So there was no common approach between the different interests. And of course there is no possibility to deploy new SPs to all systems (portal and backend systems) at the same time.
    So we decided to use separated application related portals as producer portals and one common main portal. This structure is transparent to the users, there is no change in the look-and-feel.
    What do you think of this?
    How do you solve release dependencies in your approach?
    • Hi Olaf,

      good point. Of course the mentioned SP independency (and not only for SPS, but also for EhPs and releases)is a required prerequisite to make a central portal approach work in reality. I know that we had some issues in that area in the past, but this topic have been addressed within SAP. I tried to mention some aspects in the blog. So we made major progress with SAP NetWeaver 7.00 SPS 13. Starting with that SP stack we reduced dependencies for typical business applications running in a portal like ESS or Biller Direct. It is the clear goal to avoid such dependencies in the future and addressing that interoperability is one of the central tasks driven by the SAP System Landscape Governance Board.
      It is NOT SAP's strategy to resolve SPS or EhP dependencies by forcing customers to setup additional portal systems connected via FPN. This is not the use case for FPN.

      FPN would not even be the answer to solve dependency restrictions, because then you also have to ensure version independency between the consumer and the producer portal (and here we also had some issues in the past).
      So the interoperability topic has to be solved anyhow. And i am confident that we are on the right track.



  • Hello dirk,

    First of all, thank you for the blog, very helpful !
    I still have a question :
    We are about to install BI7, meaning to separates installations :

    * Business Warehouse : AS-ABAP with usage type BI
    * Bex Web : JAVA with usage type BI-JAVA and EP

    We already have an EP7 corporate portal.
    Our infrastructure will therefore look like your first schema : we'll have to manage an EP portal and a BI-JAVA portal.

    We would like that the users only connect to ONE portal to perform their reporting ; the corporate portal.

    We thought that the only way that to integrate the BI Portal with the Corporate Portal is to use the FPN feature. There are different ways to link both portals but only in a Federated Portal Network :

    *Remote role assignment
    *Remote delta link
    *Using producer BI iView in Portal Content Studio

    When I read your blog (firsts cneario : general recommendations), I have the feeling that the FPN is not mandatory ..
    I'm a little bit confused ... could you help me pelase ?

    Thank you in advance for your attention.

    • Hello Raoul,

      BI can be integrated in different ways into a central application portal. One way would be to use FPN (based on the former integration method), another way, and this is our recommended way, is to integrate BI via application integrator into the central portal. This is possible with SAP NetWEaver 7.00 SPS13. Details are described in SAP note 1140854.



  • Hi again
    I notice you mention EP-C for the central application portal. Is there some reason that EP (ie: KMC) is not in there as well?
    • Hi,

      the blog contains just some examples. The complete picture for portal deployments is contained in the presentation published at the mentioned link.

  • During the migration process problems have been reported for this blog. The blog content may look corrupt due to not supported HTML code on this platform. Please adjust the blog content manually before moving it to an official community.
  • Hi Dirk,

    This is really good stuff. I'm glad that SAP is taking this important step forward.
    One of the areas that I would like to see recommendations on is NWDI. For example the question I get often: "Can I have a central NWDI for all my SAP components that need it?". For example clients that do Java development using NWDI and also have WebDynpro BP's on their Portal (such as ESS) that require NWDI to apply fixes. It would be great if you could address that one.
    Anyway, great job and thanks again!

    • Hi Carlos,

      thanks a lot for your feedback. We are planning to provide the next phase of recommendations end of the 3.quarter of this year. I will try to put NWDI on this list.



      • Hi Dirk,

        I hope you don't mind this question here, but I'm looking for a best practice or any available recommendations for decision factors on whether to run internal and external portals together (on a single portal system) or separately. If there is any documentation you can point me, to that would be greatly appreciated.

  • Hi Dirk,
      I like the idea of SAP formalising the layout / landscape of complex systems in this way.  It's been a bit of a bug bear of mine that when Customers say "What do SAP recommend ?", we fall back on the "Our experience / best practice / it depends line".
      I didn't see any reference to multiple environments - i.e. Development, Quality Assurance, Regression Testing and Production. 

    Some real life examples that I have seen arguments about include:
    a) do I have an SLD for all four environemnts, or 2 SLD's or...
    b) how do I upgrade / add enhancements / support stacks to my NWDI system(s) ?  From a landscape perspective it makes sense to have at least two NWDI instances, even if the developers only see one of them ...
    c) Similar questions over Solution Manager systems, especially if they are actually being used (Service Desk etc) rather than just present for the magic number for the installation...

    and so on..

    • Hi Martin,

      so far we focus on recommendations regarding the production landcape. In some areas - like SLD - more detailed information considering also the development/test landcape can be found in the related topic areas (for SLD e.g. in the SLD configuration guide).