1 2 Previous Next


26 Posts


This blog is meant to summarize discussions I have had with dozens of customers and colleagues. While all the answers are written down and updated in the SLD Planning Guide, it might be useful to start with a short blog to get the big picture first and then check the much more comprehensive guide for details and exceptions.

There are three things that define your SLD strategy: Some general things like the separation of development and production, the SAP applications you use and the way SLD systems exchange information.

SLD Topology

SLD topology decribes the required number and area of installation of SLD systems in IT landscapes and the connections between them.

Reasons to Have more than One SLD

Many applications rely on SLD data. Among these are - most prominently - SAP NetWeaver Process Integration (PI), Web Dynpro for Java, and the SAP Solution Manager. Reasons to have more than one SLD system are manifold:

  • Areas in front of and behind a firewall: If something needs to be available in front of and behind a firewall, you need at least two systems.
  • Separation of development, quality assurance, and productive systems: Most easily and most importantly this can be explained for PI - Business Systems are developed before they are meant to be used productively. The easiest way to separate non-productive and productive state is to separate the development and productive SLD.
  • Separation of managing and managed systems: The SAP Solution Manager does not recommend to have runtime dependencies to productive systems but on the other hand recommends to have a "local" SLD activated on the SAP Solution Manager system: Since SLD data are crucial for all applications mentioned earlier, at least one more SLD is required if any other SLD client application is used
  • Having 24/7 business hours does not allow for maintenance causing downtime: A backup SLD system is needed to ensure the availability of SLD data.
  • Having extremely high security requirements, where certain SLD systems need to be isolated from the net may also require isolated SLD systems.

Therefore, there is only one scenario where one SLD would be enough: This you find in landscapes where of all client applications of the SLD only the SAP Solution Manager is used, but neither PI, nor Web Dynpro for Java, etc... If that is your landscape, activating the SLD on your SAP Solution Manager system is sufficient. If not, I hope the following will help you

Mechanisms of Data Exchange between SLD Systems

Once you have found out that you need more than one SLD, you should define how to transfer data from one SLD to the other to address the needs of all client applications of the SLD and minimize the manual effort.plan your SLD strategy.

There are three mechanisms of data exchange between SLD systems:

Transport Mechanisms of the SLD

Figure 1: Mechanisms of Data Exchange between SLD Systems and their use cases.

From this table you can see that in a landscape more than one mechanism will be used, because there are different advantages in all of them.

  • Automatic forwarding (also name bridge forwarding) transfers all technical systems' data a (source) SLD gets from the data suppliers unaltered to any target SLD. Since this data is sufficient for most clients and cannot be retrieved otherwise, this method is very important in each landscape
  • Export/Import allows transporting all kind of data and provides full control of the point in time when changes become available in the target system. It is therefore mainly used in PI scenarios, where Business Systems and Products/Software Components are developed in the SLD to be available in time - not too late, but not too soon either! - in the productive system. Better Manage SLD Exports and Imports Using CTS+. Another use case for export/import of SLD data is the high security settings mentioned earlier. In extreme cases, a special user can personally walk to a SLD carrying the update with him.
  • Full Automatic Synchronization Demo: The Full Automatic Sync Feature in the SLD of SAP NetWeaver 7.1 without bothering you with messages, which is excellent - in many but not all cases: For example, it helps in How-to Manage House-Cleaning in the System Landscape Directory - Duplicate System Entries, because among all other data also deletions are transported. This, however, is also the reason why this sync method cannot be used for all SLD data transfers: It does not provide control of any kind (apart from activating and de-activating the sync all the time). Full automatic synchronization is therefore not to be used for the PI scenario described under Export/Import - I mentioned that the sync would also transport deletions for example - and think of a Business System deleted erroneously in the Dev-SLD and ceasing to exist in production seconds later... Therefore, there remain two main use cases for this mechanism: 1st is creating a hot-backup SLD [LINK to Maintenance-BLOG] to avoid gaps in SLD data availability caused by a planned downtime and 2nd is the initial "data load" of a newly installed SLD system to prepare the migration of SLD data.
    (Note that an SLD of SAP NetWeaver 7.0 based on SP Stack 12 and above can (only) be used as the source system for uni-directional synchronization.)

Note: In your landscape, these mechanisms will be combined (as shown in the default landscape below). Nevertheless, you must not use several synchronization mechanisms for the same SLD data on the same synchronization path (for example, you do not set up fully automatic synchronization from SLD A to SLD B and configure automatic forwarding from SLD A to SLD B because both mechanisms would synchronize landscape data.

However, you could supplement automatic forwarding with regular export/import of manually entered data from SLD A to SLD B. Attention: Using export/import for automatically delivered data can lead to problems if the data is read by the LMDB, so DO NOT use export for technical systems data sent via a data supplier.


For details and the availability of these mechanisms, see the SLD Planning Guide.


Default SLD Topology - SLDs in a Typical IT Landscape

From the things said so far, we get the following recommendation for a typical landscape where several SLD client applications are used - figure 2a shows the situation with SAP Solution Manager 7.0, 2b with SAP Solution Manager 7.1:


Default SLD Topology

Figure 2a: Default SLD topology in a landscape with SAP Solution Manager 7.0 where Process Integration is used



When comparing the following topology in figure 2b, where SAP Solution Manager 7.1 is used with 2a (SAP Solution Manager 7.0), you see that in DEV/QA/PRD areas everything is unchanged (SLD sync in gray arrows is the same as content sync shown in gold color) - the only change is, that in Solution Manager 7.1, the SLD reads SLD data from the central PRD SLD, so that the local SLD in Solution Manager 7.1 becomes optional:


Figure 2b: Default SLD topology in a landscape with SAP Solution Manager 7.1 where Process Integration is used.


Recommended SLD topology in a default landscape (as shown in figure 2a for SAP Solution Manager 7.0 and 2b for SAP Solution Manager 7.1):

  • The (runtime) SLD of the productive systems' area acts a central SLD gathering all technical systems' data via SLD Data Suppliers. It forwards this data to all other SLDs. This SLD can run standalone on a dedicated server or, for example, on the PI server.
    In many cases a high-availability setup is used for this SLD.
  • A separate (design time) SLD exists in the development area and if PI is used an SLD can also be set up in QA, additionally. Business Systems and Products/Software Components created here are exported from and imported into the productive SLD - preferably using CTS+ to manage exports and imports centrally.
  • Optionally, a backup SLD can be added to the landscape and kept up-to-date by full automatic synchronization with the central SLD.
  • Client applications (such as PI, NWDI, or front ends like Browsers or the Developer Studio) access the SLD of their area or according to their function.
  • SAP Solution Manager

QA and sandbox SLD systems can also be added; these would be part of the non-productive area (such systems are not shown in the picture).


Sizing of SLD Systems

In all landscapes sizing of systems is a topic. You'll find details regarding this topic in the Blog on Sizing a System for the System Landscape Directory of SAP NetWeaver.


SLD Topology in Big Landscapes

Generally speaking, the design of the SLD topology in big landscapes in principle works as for the default landscape: The needs of the client systems are the same; therefore the data transfer mechanisms stay the same. Nevertheless, some new challenges may appear, such as the existence of more than one set of PI-systems or the wish to have more than one full automatic sync connection between SLD systems. While the design of such a landscape cannot be describes in one blog and needs a project to identify and address all business needs, some hints might help.


Special Use Cases in SAP NetWeaver Process Integration

Business Systems' names need to be unique. In very big landscape with separated PI systems - or after a merger with another company also using PI - you could run into trouble, when identical Business System names "collide" in one SLD. The only solution here is to ensure the uniqueness of these names organizationally.

Topologies of SLDs with Full Automatic Sync Connection

Usually, full automatic synchronization is used to keep backup SLDs in sync. It is not recommendable using a full automatic sync connection to sync SLDs of DEV and PRD area; you cannot update the SAP Solution Manager's SLD and - as described earlier - this is not necessary either.


A new point is that in big landscapes more than 2 SLDs might have a full automatic sync connection. Many topologies are valid, but the "unique path principle" must be fulfilled: From any SLD to any other there must only be 1 path for messages to guarantee that messages are handled in the correct sequence.

Unidirectional circular connections are supported: A message is only accepted once in any SLD so the transport of messages stops at the origin.

The following figure shows examples of valid topologies of SLDs in full auto sync. Only SLDs with full automatic sync connections are shown; more SLDs with other connection types can be added:

Valid Topologies for SLDs in full automatic synchronization

Legend of SLD full automatic sync topologies

Figure 3: Valid topologies in SLDs using full automatic synchronization

  • Bi-directional full automatic synchronization connection between two systems (SLD 1 and SLD 2) - use case "backup". (This is the only bi-directional circle allowed, because there only is one other SLD. Of course a uni-directional connection would be valid in any case where a bi-directional connection is allowed.
    More SLDs can be added, as long as there are no circles introduced.
  • Star topology (SLDs 1-4); SLD 1 would act as a master SLD here.
    This can also be combined with a linear connection (see SLD 5) or other "stars" as long as the unique path principle is valid.
    (The part SLD 1 <-> SLD 2 <-> SLD 5 is a longer variant of the backup topology.)
  • Valid circular topology (SLDs 1-4) can be used with uni-directional connections. Introducing bi-directional connections (even 1) would violate the unique path principle. This also only works with all connections going in the same direction (clockwise or anticlockwise): Changing the direction of less than all connection will invalidate the setup (see "invalid topologies".

Valid topologies can be combined with other topologies, as long as the unique path principle is valid. For example this would be a development SLD receiving data via bridge forwarding from an SLD being in full auto sync with others and sending back data by import and export.

In all invalid topologies there exists more than one path for messages between two SLDs - this should mainly happen in circular topologies:

Invalid Topologies of SLDs in Full automatic Sync

Legend of SLD Topologies in Full Automatic Sync

Figure 4: invalid topologies in full automatic synchronization

  • Invalid circular uni-directional topology (SLDs 1-4) with 4 uni-directional connections.
    This example shows that there also is a way to create invalid topologies with uni-directional sync connections: here, a message X in SLD 4 can reach SLD 2 via SLDs 1 and 3 - successor message Y in SLD 1 might reach SLD 4 earlier than message X, resulting in incorrect data.
  • Invalid circular bi-directional topology (SLDs 1-4) with 4 bi-directional connections.
    A message X in any SLD can reach any other SLD clockwise and anticlockwise - successor message Y in SLD 1 might reach SLD 4 earlier than message X, resulting in incorrect data.

Other Hints for SLD Data Distribution


Related Information




In the first blog of this short series of blogs you could watch the How-to Implement SAP NetWeaver Functionality? – Installation Made Easy. Installation of the system, however,  is only one step. When it’s finished, both SAP NetWeaver AS ABAP and AS Java of this dual stack installation are up-and-running and can be accessed with administrator users such as DDIC for the ABAP stack and J2EE_ADMIN for the Java stack.

But configuring the system is just as important and will include as many steps. In this part of the demo series the configuration of the new system is shown.

SAP NetWeaver System Configuration – the Demo

For quite some time automated configuration is available. Not all of you, however, may have seen it in action or in one of its latest versions… so here you are: My demo shows the configuration of SAP NetWeaver Process Integration 7.1 including SAP enhancement package 1 for SAP NetWeaver 7.1. The PI system has been installed already; both stacks are up-and-running, and very basic user management is in place – so you could start to do the configuration manually – but stop: Have a look of what’s included in the task before you start. The automated process handles a lot of single steps and is less error-rpone and definitively faster.


The demo content:

  • The demo starts with checks if you can log on to both stacks that have been installed.
  • Configuration itself begins when you open the configuration tool “Configuration Wizard” in the SAP NetWeaver Administrator running on the Java stack and choose the required configuration task.
  • In the first phases of the configuration you take some decisions on what to configure – especially, in this case, whether to use an existing or create a new System Landscape Directory (SLD) and what passwords you want initially to apply.
  • After you made your settings, all steps will run automatically without user interaction, but can be monitored in the configuration tool -  I did that for this demo to show you all the configuration steps.

Click here to start the demo of the automated configuration of an SAP NetWeaver system using the Configuration Wizard.


SAP NetWeaver Administrator: Configuration Wizard

This screenshot shows the SAP NetWeaver Administrator's Configuration Wizard. The task to initially configure a SAP NetWeaver system is chosen.

Related Information

There is a lot of information on SAP NetWeaver capabilities available at SDN, but once you have decided to implement a new system you may ask yourself how much effort that might be? Surely, installing an SAP system is a single task in its life-cycle and over years of operation the administrative effort of running the system will surely be higher than this one step. Nevertheless, when a system is well known the recurring efforts are a familiar part of your daily work, while the first hurdle might be felt to be the biggest one and you may ask yourself exactly how big it is…

Of course, there are the master guide and installation guides, providing an excellent source of information, which you should read carefully to prepare for the installation. (For details see SAP Service Marketplace > Quick Link “instguides” – SMP login is required.)


 Guide Finder


SAP's Guide Finder under SAP NetWeaver "instguides" page 


But to get an idea of the most recent installation process, a demo might be even nicer – so here you are…


SAP NetWeaver System Installation - the Demo

As you will have heard without doubt, starting with releases based on SAP NetWeaver 7.0 SAP ships updates of functions with SAP enhancement packages. You might not have heard, however, that these release states can be installed directly. My installation demo shows the installation of SAP NetWeaver Process Integration 7.1 including SAP enhancement package 1 for SAP NetWeaver 7.1 – if you have a look into system details you would find it referred to as SAP NetWeaver PI 7.1 EHP 1 or shorter even as “7.11” when it comes to software components.

The demo content:

  • The demo starts with opening the installation tool “SAPinst”, preparation of system and installation have been done. All required sources have been copied to a file share.
    (To find the sources for tool and content, please read the installation guide for the specific release you are going to install; usually both CDs/DVDs and SAP Service Marketplace download are available)
  • In the first phases of the installation you take some decisions on what to install, where to install it, and what passwords you want initially to apply. I concentrate on a “typical” installation. You can choose to have more customizing than shown here. The phases asking for user input end with a summary of your decisions, which is the last chance to alter your entries. These phases also include a check, if your system fulfills the requirements.
  • After you confirmed your settings, all steps apart from one will run automatically: The SAP Solution Manager key needs to be provided during installation. The generation of this key in SAP Solution Manager is demonstrated as well.
  • All following steps run without user interaction, but can be monitored in the installation tool, which I did for this demo. Should an error occur you can retry the failed step, notify SAP or stop the installation, get rid of the cause and restart the installation where it stopped.

Click the link to start the demo of SAP NetWeaver PI 7.1 incl. EHP1 installation:


SAPinst - Installation options

The screenshot shows the SAPinst UI used in the demo - you can choose between several installation options or start other software life-cycle tasks, such as de-installation of a system.

After the Installation – Configuring the System

Installation of the system is one step and, as you have seen, a highly automated one. When it’s finished, both SAP NetWeaver AS ABAP and AS Java of this dual stack installation are up-and-running and can be accessed with administrator users such as DDIC for the ABAP stack and J2EE_ADMIN for the Java stack.

Configuring the system is just as important and will include as many steps. In the next part of this short blog series How-to Implement SAP NetWeaver Functionality? - Configuration Made Easy using the highly automated processes of the Configuration Wizard of the SAP NetWeaver Administrator.

Related Information

Why Do House-Cleaning in the SLD - and how?

Few people would regard this task fun, and if systems update their data regularly in the SLD using SLD data suppliers, and three mechanisms of data distribution between SLD systems (forwarding of data supplier data, export/import of data Better Manage SLD Exports and Imports Using CTS+ and Demo: The Full Automatic Sync Feature in the SLD of SAP NetWeaver 7.1) then why do you have to do it at all?


Is this "TE2" system entry a duplicate that needs to be removed or not?

Fact is, that data suppliers are an excellent way to gather new data and data updates – the push mechanism triggered by the systems themselves significantly simplifies the work of the SLD administrator – but are not used to remove data of systems that no longer exist. The reason behind this is simple: Should a system be removed only because its data-supplier didn’t report to the SLD last time it was normally scheduled? This cannot be done, simply, because this “date” might have been missed during system maintenance. Is the second missing report sufficient? We don’t think so: when the system is still in use, business processes based on PI messages or Web Dynpro (Java) based UIs would fail unnecessarily…
On the other hand no-longer-existing systems but still visible in the SLD might be assigned to business processes erroneously, which will not work then, and that’s why you as the SLD’s administrator have to take care of outdated systems data. Keep in mind: Most or all of the manually created data such as business systems should be updated be development and therefore should not be your problem.


House-Cleaning in Your SLD – Best Practices


Consistent Deletion of Managed Systems -- System Decommissioning


The SCN Wiki document Delete_Managed_Systems (http://wiki.scn.com/wiki/display/SMSETUP/Delete_Managed_System) describes the steps necessary for consistent handling of deletion of technical system data depending on your version of SAP Solution Manager. This needs to be considered first if a system has ever been used in SAP Solution Manager.



Data Changes in the SLD


Let’s see how you can recognize and deal with outdated data in various releases of the SLD.

Note: You will have to clean up technical systems’ data in all your SLD systems independently of their release: Even if you are using a “central” SLD as a target for all data suppliers and forwarding data to other SLD systems in your landscape, deletions will not be forwarded. Full automatic synchronization would do that, however, I do not recommend using it for that purpose instead of connections where forwarding of landscape data is proposed since it does not provide filtering and would also replicate unneeded or misleading data such as productive data for business systems into development.

Recognizing Outdated Data

If a technical system used as a business is uninstalled, in many cases it will be replaced. If it is re-installed on a different host, it might get the same SID (three character system identifier). This will not cause a problem for the SLD because with a different host name the record is still unambiguous.
Does that help to remove such data automatically? No, it does not: the second identical SID might for example be the result of a merger and also valid. Therefore, a decision of a human being is required.

SLD UIs of SAP NetWeaver 7.0 and Earlier

In these systems, all data of technical systems need to be updated manually after a system was moved. Outdated system data need to be deleted, if the old system – or the old host respectively – can no longer be reached.

Note: All data using technical systems‘data such as business systems and JCo destinations need to be associated manually with the updated data or newly created.

There are two ways to get rid of outdated data:

  • You can directly remove technical systems from the list under SLD Home / Landscape / Technical Systems
  • It’s easier, however, to choose SLD > Administration > Automatically Updated Data or in later releases > Administration > Maintenance > Automatically Updated Data:

    Displaying automatically updated SLD data

    You’ll find an overview of all SLD data suppliers ordered by Name, Type, and Date of last update of system’s data in the SLD:

    This view allows sorting and filtering and directly supports deletion of selected system data (button Remove) and thus simplifies the manual part of data maintenance – if TE2 on tewdf232933 was moved or deleted you can remove it here – note that it didn’t report to the SLD for more than 2 weeks
SLD UIs of SAP NetWeaver 7.1 and Higher

As of SAP NetWeaver 7.1 situation in the SLD is as follows:

  • Obviously , the same mechanisms to delete outdated data described  above also work and for deletions of systems that are not replaced, this is still the way to handle this situation
  • Additionally you’ll find a function to deal with systems, which have been moved especially:
    Under SLD / Home > Technical Systems > Details choose button Move:

    This view allows sorting and filtering and directly supports the move - its assignment to a new host - of selected system data (button Move) and thus simplifies the manual work.

    Also see 1817310 - Double Stack System automatic move functionality

  • Enter the new host:

    All associated data will be updated for example JCo destinations when new data is saved. If for example TE2 was moved from tewdf232933 to tewdf231930 it could be corrected here easily.

The benefit of the latter approach is that all data associated with technical systems’ data are updated automatically: No further manual work is necessary.

Final Remark

So no matter what release of the SLD you run: In addition to regular updates of imported SLD data (CR Content and CIM model updates are described in SAP Note 669669) also ensure that you provide clean landscape data as a basis for flawless performance of all your SLD’s client applications. If changes in systems are done on a regular basis in your company and the updated functions are important read in another blog "How to Get an SAP NetWeaver 7.1 System Landscape Directory??".

Additional Reading

More information on the topic of removing unwanted data from the SLD can be found in SAP Notes:

  • Note 1160192 - System description in SLD contains obsolete elements
  • Note 1159969 - System description in the SLD contains duplicate elements
  • Note 1747926 - Dealing with duplicate technical system names (older SLD)
  • Note 1694004 - Dealing with duplicate technical system names (SIDs)
  • Note 1727294 - AS Java/ABAP System move functionality

SLD Data Distribution in the System Landscape 

A typical SLD topology in a landscape can be described as follows: There are three main landscape areas with an SLD system of their own:  

  • One SLD in the non-productive area
  • One SLD in the productive area
  • One SLD for the SAP Solution Manager, which manages systems in the landscape

The following figure shows the SLD systems in such a landscape:


SLD systems in_a landscape and their mechanismsof sychronization 

SLD systems in the landscape and the main pathes of data exchange between them. The “selective transport” from design-time SLD of the development area to runtime SLD in the production can be improved by using CTS+ 

You may also have additional instances for backup, as sandbox systems or to distribute the work load. For details, please always refer to the SLD Planning Guide on the System Landscape Directory (SLD).

SLD systems in the landscape share information with each other. Typically, there is forwarding of technical systems data from the productive SLD to all the others, there may be Demo: The Full Automatic Sync Feature in the SLD of SAP NetWeaver 7.1 when an How to Ensure that SLD Data is Available during Maintenance is used, and – very important for SAP NetWeaver Process Integration - the export and import of SLD data. The latter specifically is needed to transport content used by the SAP NetWeaver Process Integration from development to production. When transporting manually developed SLD content from the development into the productive SLD, full control of content and point in time when it is shipped makes the export / import procedure the appropriate mechanism to distribute information.

When and Why Use CTS+?

However, this is a manual procedure; therefore many steps are not explicitly handled by the SLD - e.g. the storage and transport of the export file. However, with SAP NetWeaver 7.0 SP 12 the Change and Transport System (CTS) learned to transport Non-ABAP content also, and is therefore often referred to as "CTS+". It is now the preferable transport mechanism for many types of SAP content and further on SAP will add support for new applications. You will find an overview of transport options with CTS+ in the SAP Help Portal.

As of SAP NetWeaver 7.0 SP 14 SLD content is also integrated with CTS+. Things run in a more controlled way when using this transport landscape:
  • Exported file(s) is (are) directly attached to a transport request
  • Transport routes clearly define source and target systems
  • Logs clearly show the state of each request for developers and administrators
  • Imports are shown in the CTS+ system with all other requests
  • Imports can be triggered, scheduled, and monitored centrally

SAP NetWeaver Software Change Management can be found in the SDN.

One hint might be helpful when using CTS+ in this scenario: Import of business systems does require that software components and technical systems used in the imported business systems are available in the target SLD. Usually the technical systems are available in the SLD of the production area (see SLD Planning Guide). This is not the case for the freshly software components developed. If anything is missing in the target SLD all required content can be transported in one transport request. If you choose this option, make sure to add the different export files to the transport request in the correct sequence: first add the objects that are a prerequisite for the import of the other.

System Demo

In the system demo two SLDs are used. The CTS+ system is fully configured and so are the SLD systems, including settings needed to use CTS+ for SLD transports: The source SLD has got a connection to the CTS+ system, and both source and target SLD have been made known to the CTS+ system and connected with a transport route.

The following is shown in the demo:

  • In the 1st SLD - let's say the development SLD business systems have been created.
  • These business systems are exported. When exporting them a transport request has been created automatically, to which the export is attached.
  • The developer checks and releases the request in a Web UI.
  • In the CTS system source and target SLD are shown.
  • In the target system the import is triggered by the system administrator.
  • When checking the content of the target system, the business systems that have been exported from the source SLD are shown.

To start the system demo, click Transporting SLD content using CTS+.

Installing SAP EHPs on Business-Critical Productive SAP NetWeaver Systems

SAP enhancement packages allow functional updates of systems without a system upgrade. Using the SAP Enhancement Package Installer (SAPehpi) allows installing EHPs with significantly reduced downtime. The installation process can be aligned with downtime planning in SAP Solution Manager. SAPehpi seamlessly integrates with the application life-cycle management processes of SAP Solution Manager.

As we can see - and you probably already found out - in business processes typically more than one tool is involved. In this blog series we want to span whole use cases in life-cycle management including demos of tools and procedures involved.

The Demo Scenario 

Initial Situation

Let's consider the following scenario:

  • An SAP system is already in productive use 
  • New functions are requested
  • Downtime must be short 


In the analysis phase a solution is searched for that fulfills the new business needs without compromising other requirements.

  • The process used so far does not fit into the maintenance window
  • SAP NetWeaver Enhancement Package Installer (SAPehpi) offers a new way of deployment
  • SAP EHP1 for SAP NetWeaver is to be installed on the system used for software change management hosting SAP NetWeaver Software Change Management


In the solution phase the findings from the analysis phase are implemented. In our scenario, the system is updated using SAPehpi:

  • Start update process for the change management system well before the maintenance window
  • Apply SAP EHP1 on a shadow system created by SAPehpi
  • Use scheduled system downtime system to perform the downtime step
    System will become available
  • Risks are minimized by application on a shadow system SP application is done on clone system and does not affect the productive system in case of failure; also preparation steps are separated from system downtime, so the maintenance window can be used most efficiently
  • ESS/MSS updates can be achieved in time.

Demo story line


So our initial system is an SAP NetWeaver 7.0. In SAP Solution Manager the preparation of the system update starts: The next downtime is scheduled and the download stack for the system update is prepared. Roughly a week before the downtime the administrator of the system to be updated starts the run of SAP NetWeaver Enhancement Package Installer (SAPehpi). When the downtime begins he triggers SAPehpi downtime processing, which will finish in about half the time of a "classic" update procedure with transactions SPAM and Saint. After the downtime processing the system starts automatically.

Our demos show all the tools involved in the overall process

  1. Downtime planning in SAP Solution Manager (demo running automatically)
  2. Sending downtime notification from SAP Solution Manager (demo running automatically)
  3. Preparation of the download stack in SAP Solution Manager Maintenance Optimizer (MOPZ) (press "Enter" to go to the next demo step)
  4. Installation of SAP enhancement package 1 for SAP NetWeaver using SAPehpi (demo running automatically)

To start the 4 demos, just click the steps 1 to 4 from downtime planning to EHP installation below to see the process in action...

Demo's big picture

 step 0 step 1 step 2 step 3 step 4finished 

(Note that the parts of the demo have been taken from different update processes so that systems and versions may differ but will work very similar in any such case.)

This use case - adding functionality to a system by installing an SAP enhancement package - will work along the lines for SAP EHPs for ERP systems as well but be sure to read the official guides thoroughly before you before you start the update.

Note that after the installation of an SAP EHP for SAP NetWeaver - other than for SAP ERP - no switches are used, so all functions become active after the installation immediately.

Availability of SLD Data

System Landscape Directory (SLD) data is used throughout most of the life-cycle of SAP’s applications such as SAP NetWeaver Process Integration or system monitoring in the SAP Solution Manager, and many of these uses can be business critical. This naturally puts high demand on the availability of SLD data. While a high-availability (HA) setup can avoid gaps caused by unplanned downtime, those caused by planned downtime – e.g. during maintenance of the SLD system – are hereby not addressed. This can, however, be achieved by the setup described in the following:During the last few months a new procedure has been used for SAP’s main SLD instance to come very near to the goal of continuous availability of SLD data. It consists of the following steps:
  • Two SLDs run on two instances on SAP NetWeaver 7.1. They mutually update their content with bidirectional full automatic synchronization.
  • All communication with the SLD from systems that register their data in the SLD or clients that read that data use a virtual IP address, which is assigned to one of the SLDs (naturally only one) and, in case that there is maintenance of that system required, it is manually switched to the other.
  • To be armed against unplanned downtime these steps need to be combined with an HA setup, but can, of course, be used independently of HA techniques.

The Demo-Story

First Part: Full-Automatic Sync
The first part of the demonstration showing how to set up SLD's full automatic sync

has been published before. It shows the setup of the full automatic synchronization of two SLDs. It ends with both of them being coupled in bidirectional full automatic sync.

Just one hint: the changed look of the second SLD is achieved by using another Web Dynpro theme in the browser and does not indicate any difference between the two SLDs themselves.

Second Part: Using a Virtual IP Address
The second part starts where the first ended. The optical differentiation, however, is no longer used: The whole setup is done to make it feel like one system.
  1. As a client simply the UI of the SLD is called to show the setup of the SLDs.
  2. Then a reserved (virtual) IP address is assigned to SLD 1 manually. This is done on the host of SLD 1 directly.
  3. The UI of SLD 2 is closed and for the remaining UI the virtual IP address is used – it still shows the content of SLD 1 – proved by opening the server details showing the SLD’s host.
  4. To prepare a switch between the SLDs…
    1. The virtual IP address is entered for SLD 2 but not yet activated – using it on more than one system at a time would cause network errors.
    2. Now, the virtual IP address is removed from SLD 1 (a ping is used to simulate the downtime that would be experienced in any client trying to connect to the SLD.
    3. The virtual IP address is now activated on SLD 2 (only 3 pings timed out until this was done)
  5. As before the SLD UI using the virtual IP address is used to prove that now clients connect to SLD 2 automatically.

    SLD 1 can go safely into any kind of maintenance procedure – when its over administration can switch back to SLD 1 and, for example, update SLD 2.
  6. In the last steps switching back to SLD 1 is demonstrated.
    Again, take care that the virtual IP address is never active on more than one SLD instance at a time.

One huge advantage of this procedure is that once set up on SLDs and clients switching will only require changes on SLD systems.


 Figure 1 shows the final setup used in the demo: ABAP and Java stack of host pwdf2308 register themselves in two different SLDs (just to show it doesn’t matter where they do). SLD 1 and SLD 2 are connected with a bidirectional full-auto-sync so data is identical in both SLD instances.

What is new is the use of a virtual IP address for the clients – shown as applications and tools. To round things off the virtual IP address should also be used when configuring the data suppliers of ABAP and Java stacks. This is demonstrated in the new part 2 of the demo.


SLDs with full auto sync acessed via virtual IP address


Figure 1: Using a virtual IP address you can switch between two synchronized SLDs during maintenance in a few seconds without any changes needed in the client applications

How to Use the Demo:
This is quite easy: The demo runs as a self-contained exe file including a narration. It will start in a full screen mode. To pause and restart the demo use the space bar or the menu bar of the demo. To start the demo of switching between SLDs, click here. Note that the demo is silent.

What You Need to Know

  • This scenario is valid as of SAP NetWeaver 7.1; if SLD’s name reservation is also needed, SP 2 of SAP NetWeaver 7.1 EHP1 is required (see How to Get an SAP NetWeaver 7.1 System Landscape Directory?How to Get an SAP NetWeaver 7.1 System Landscape Directory?”).
  • A virtual IP address for the DNS host name has been reserved and is used.
  • Both systems must be configured identically using:
    • Identical ports for productive and backup system.
    • Identical users on both systems. (You can also use one LDAP user store for both systems.)
    • Note that having identical SIDs is not required and would cause problems when the use of CTS+ is intended with SLD content
  • Object Server Names:
    • Different object server names for both SLDs are required.
    • Beginning with 7.1 EHP1, SP2 you use identical external object server names to use name reservation also from the backup system SLD 2. Internal object server names must be different.
  • Productive and backup system must be in the same IP subnet.
  • Set up the full automatic content sync as follows:
    • Use the physical address of the systems.
    • When configuring the rank of the systems (used to solve any conflicts) the rank of the productive system should to be higher than the rank of the backup system.
The Switch Procedure

Switch Steps

  • Note: Before you can start the switch procedure you need to wait for the initial “Full Sync” to have finished. To check this, in the SLD choose Administration à Content Synchronization. The sync connection between the productive system SLD1 and the backup system SLD2 must show the Incremental Sync link.
    • Remove the virtual IP address on the productive system (Host1).
    • Apply the virtual IP address on the backup system host (Host 2).
  • After IP switch is done please note: Before shutting down the productive system SLD 1 ensure that all “pending changes” have been completed. To check this, in the backup system SLD 2 choose Administration à Content Synchronization à Incremental Sync (choose Incremental Sync link on the content sync connection).
  • After the maintenance is over switch back virtual IP to the productive system SLD 1.

Switch Options

  • The IP switch can be realized by several hard or software products
  • The SAP web dispatcher and standalone RFC gateway can be used as alternative system switch.
Combination with an HA Setup

The key features of the scenario described here are the full automatic sync of SLD systems and the usage of a virtual IP address. As indicated in the beginning, it can be combined with an HA setup (in principle, it doesn't matter who does the switch, any process or a human administrator). To get things right, however, discuss your individual approach with an HA expert to take care of web dispatcher settings, port ranges to be used, etc. Since details may vary in diffrent landscapes, they cannot be discussed here.

Tips and Restrictions
  • Name reservation requires an external object server name. Therefore prior to SP2 of SAP NetWeaver 7.10 EHP1 the use of name reservation is not possible in this setup
  • Continuous data supply to other SLDs with data from productive SLD
    • Delta exports are always specific to an SLD – in other words they contain the individual data changes and thus the SLD internal object server name. For this reason the delta exports are disrupted during use of backup system SLD 2.
    • If you switch permanently to the backup system SLD 2, a new “Full Export” is required to continue the export lines.
    • Content sync connections reference the change log of the individual SLD. Therefore always use the physical host address to configure the content sync connection. This will avoid erroneously using the change log of the backup system
    • After switching from SLD 1 to SLD 2 any external content sync connection should be removed from SLD1 and configured against SLD2 instead. In this way external content sync processes are not harmed by the maintenance process of SLD 1. The only drawback is the full sync run against SLD 2, which is initiated during reconfiguration.
    • During maintenance (e.g. upgrade) of the productive system SLD1 we recommend to switch off (deactivate) the content sync connection. Just to avoid error logs while the system is not available several times during upgrade process. The deactivation should be restricted to the maintenance time to avoid too much loading of the content synchronization after reactivation.
  • Log each configuration change in both systems to ensure that their state is equal.
Further Information

As usual, further information is available under quick link nw-sld in SDN (System Landscape Directory (SLD))

With SAP NetWeaver 7.1 "full automatic synchronization" becomes available as a new feature of the System Landscape Directory (SLD). It allows setting up SLDs so that all their content is replicated from the source to the target SLD. All SLD data is to be taken seriously: All landscape data (such as technical systems), all data from the software catalog (provided by SAP or added for NWDI-based development), all manually added data (such as the business systems), and even the CIM Model is sent. (Note that an SLD of SAP NetWeaver 7.0 based on SP Stack 12 and above can be used as the source system for unidirectional synchronization.)

This makes the full automatic sync a mighty tool to propagate and backup SLD data and reduces manual synchronization effort. However, the full synchronization also includes deletions so pick your strategy wisely when using this feature. One thing especially should be taken into account: You can set it up to work one way or in both directions when connecting two SLDs.

The Story: 

As a prerequisite for this demonstration, we have two SLDs both running on SAP NetWeaver 7.1 - to learn where you can find this type of installation see How to Get an SAP NetWeaver 7.1 System Landscape Directory? Just to have some data, in each SLD an SAP NetWeaver AS (one ABAP, one Java) is registered. Without the synchronization each application server is only known to the SLD its data supplier is connected to.

  1. In the first part of the demo full automatic synchronization is set up unidirectional: In this type of setup the target SLD gets all the data from the source SLD. This is shown by the technical systems data.
  2. In the second part of the demo a bidirectional setup replaces the unidirectional. It is demonstrated using the technical systems information and of newly created manual information - a business system and description.
    Note that in this setup both SLDs are source SLD for each other really, when in both data is changed.

How to Use the Demo:

This is quite easy: The demo runs as a self-contained exe file including a narration. To pause and restart the demo use the space bar or the menu bar of the demo. Apart from the system you'll see very few slides also, which will introduce the demo scenario and its two parts.

To start the demo of SLD full automatic synchronization click here.

SAP enhancement packages for SAP ERP are available for quite a while now with the latest version being SAP EHP4 for SAP ERP 6.0. (For further information regarding SAP enhancement packages for SAP ERP see SAP Service Marketplace under http://service.sap.com/ERP-EHP - SMP login required). But - at least - with respect to its installation this version marks a new phase in the history of EHPs for SAP ERP:

  • First, this is the first enhancement package that makes using SAP Enhancement Package Installer (SAPehpi) a must for 64 Bit systems for the majority of use cases.  
  • Second, this is the first EHP for SAP ERP that is partially based on SAP enhancement package 1 for SAP NetWeaver 7.0. (It is not allowed to install enhancement package 1 for SAP NetWeaver 7.0 in previous SAP ECC 6.0 systems including enhancement package 1-3). 

"Is that good news?" you might ask yourself. Well, to put it in a nutshell: Using SAPehpi, most of the changes you apply to your ERP system are performed on a cloned system, while business continues without interruption. Only the system switch affects the system downtime - a big step forward compared to the process used before. And this procedure is available for EHP4 installation for all customers (for 64 bit systems), while for SAP EHP3 for SAP ERP still a The specified item was not found. exists.
For the second part, it simply means that you can now use the updated features of SAP NetWeaver EHP1 in your ERP system, while this could not be installed together with SAP ERP EHPs 1-3.

Installation Scenarios for EHP4 of SAP ERP 6.0

Things said until now apply to 64 bit systems. In that case the simple rule is: Use SAPehpi wherever possible. This means that you need not prepare the system before you apply enhancement package 4 using SAPehpi, because the complete stack of EHP4 and any other required software is automatically calculated by the SAP Solution Manager Maintenance Optimizer and installed together with EHP4 by the SAPehpi. This applies to any SP stack and previous EHPs that are required but not already present in the system. The scenarios we can distinguish then are those of updating the underlying SAP NetWeaver for both the ABAP and the Java stack or for the ABAP stack only. The two pictures should picture summarize this:


In both cases you download all objects you need from SAP Service Marketplace: SAP EHPs, Support Package stacks, and SAPehpi. The download stack of SAP EHPs and SPS must be defined and calculated in the SAP Solution Manager Maintenance Optimizer. You can update your SAP ERP 6.0 for both stacks and you can decide whether you update the underlying SAP NetWeaver for ABAP and Java or for AS ABAP only. The first case is simple: Use SAPehpi. In the second case, if you do not plan to update the underlying AS Java of SAP NetWeaver 7.0 use JSPM to deploy the Java part of SAP EHP4 for SAP ERP 6.0. You will use SAPehpi for ABAP stack also here.

As said before, these are the installation scenarios for 64 Bit installations. SAPehpi does not support 32 Bit systems. (Just to mention this: Note that for dual stack systems with SAPehpi it is only possible to update both stacks together.)

Further Reading 

SAP NetWeaver features the System Landscape Directory (SLD). For those of you not familiar with the SLD only so much: SLD gathers information on system landscape and software catalog (for details, see our SLD presentation).
The latest version of the SLD is running on SAP NetWeaver 7.1. The most important new feature of this version perhaps is the full automatic content sync, which allows setting up two or more SLDs – see the presentation for reasons to have more than one SLD and other details – in a way that all content of one SLD is copied automatically into another. Since this type of synchronization can be set up as well in both directions between SLDs, they can be kept identical content wise:


This figure shows two SLDs set up with bidirectional full automatic sync. All system data from SLD data suppliers plus any manually added data will be kept in sync automatically in both SLDs.

Besides that the UI was given some attention and minor bugs in content sync have been fixed in SAP NetWeaver 7.10 SP5 (this will also be part of the SLD as part of SAP enhancement packages for SAP NetWeaver 7.1). 
So you might ask yourself: “How do I get an SLD of SAP NetWeaver 7.10?” – Well, there are always two ways to install an SLD in the system landscape: Use a dedicated server for the SLD or install SLD together with another application. Also with SAP NetWeaver 7.1 there will be these options, namely:

  •  Installing the SLD together with another application will be possible with
    - SAP NetWeaver 7.1 usage type PI (SAP on DB2 for Linux, UNIX, and Windows)
    - Adaptive Computing Controller (Adaptive Computing) of SAP NetWeaver 7.1
    - SAP NetWeaver 7.1 CE and Enterprise Services Repository & Registry (Enterprise Services Repository&Registry)
  • Installing the SLD on a dedicated server is planned to become available with SAP enhancement package 1 for SAP NetWeaver CE 7.1. Its availability will be announced in SDN.

For details how to assess the pros and cons of these options and our recommendations regarding SLD in your system landscape see SLD presentation and SLD Planning Guide.
To find out about SAP enhancement packages for SAP NetWeaver in general and how to install them see SDN article SAP Enhancement Packages for SAP NetWeaver.

With SAP enhancement package 1 for SAP NetWeaver 7.0 SAP's enhancement package concept also becomes available for the SAP NetWeaver platform. If you install it you will find updates of many usage types, including SAP NetWeaver AS ABAP, AS Java, BI, BI Java, DI, etc.

SAP enhancement packages are developed according to rules that also apply to Support Packages. Therefore, you can update a selection of systems in your landscape - depending on the usage types you want to update - without compromising the interoperability with those systems you leave untouched. There are three ways to get a system with the capabilities of SAP NetWeaver 7.0 including enhancement package 1: Install it directly, upgrade an existing system of SAP NetWeaver 2004, or update an existing SAP NetWeaver 7.0.

To update an existing SAP NetWeaver 7.0 system you use the SAP Enhancement Package Installer (SAPehpi), which will become available together with SAP enhancement package 1 for SAP NetWeaver 7.0: It provides a guided procedure, leading you through all update steps and lets you install the SAP enhancement packages with minimized downtime. SAPehpi will be used for both for SAP NetWeaver and SAP ERP.

If all this sounds interesting, go on reading the in-detail article "SAP ENHANCEMENT PACKAGES FOR SAP NETWEAVER - What IT Professionals Need to Know About Enhancement Packages for SAP NetWeaver and the SAP Enhancement Package Installer".

SAP enhancement package installation life at SAP TechEd 2008:

  • LCM207 SAP NetWeaver Enhancement Package Switch Installer (Lecture)


  • LCM360 Implementing SAP Enhancement Packages - A Complete View (HandsOn)
SAP TechEd '08 picture

For more information visit the SAP Enhancement Package Installation in SDN also available under quick link /softwarelogistics.


Filter Blog

By date:
By tag: