Planning Guide Landscape Directory Document Version 1.1 June 2005
Copyright 2004 AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of AG. The information contained herein may be changed without prior notice. Some software products marketed by AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iseries, pseries, xseries, zseries, z/os, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation., R/3, my, my.com, xapps, xapp, NetWeaver, and other products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by AG and its affiliated companies (" Group") for informational purposes only, without representation or warranty of any kind, and Group shall not be liable for errors or omissions with respect to the materials. The only warranties for Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix s, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. Library document classification: PUBLIC Disclaimer Some components of this product are based on Java. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java Source Code delivered with this product is only to be used by s Support Services and may not be modified or altered in any way. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. Documentation in the Service Marketplace You can find this documentation at the following Internet address: service.sap.com/sld MaxDB is a trademark of MySQL AB, Sweden.
Planning Guide Contents 1 Introduction... 4 2 Landscape Scenarios... 5 2.1 Central Organization (One Single Central )... 5 2.2 Hierarchical Organizations (One Central with Decentralized Sub-s)... 6 2.3 Fully Separated Organizations (Multiple Standalone s)... 7 2.4 Distributed Organization (Multiple Coupled s)... 8 3 Best Practices Scenario... 10 3.1 Central for All Applications... 10 3.2 Separate for / and for uction... 11 3.3 Separate for NWDI... 12 3.4 for Distributed XI Landscapes... 13 3.5 for Distributed elopment... 14 4 Best Practices for the NetWeaver Landscape... 15 4.1 Support Infrastructure and Central Administration and Monitoring... 15 5 Summary of All Connections... 16 5.1 ABAP Data Supplier (1)... 16 5.2 J2EE Data Supplier (2)... 16 5.3 External Data Supplier (3)... 17 5.4 J2EE Client (4)... 17 5.5 ABAP Client (5)... 17 5.6 Standalone ABAP Client (6)... 17 5.7 to Message Forwarding (7)... 17 6 Network Access Scenarios... 18 6.1 Intranet Scenario... 18 6.2 Extranet Scenario... 19 Appendix... 20 Related Documentation... 20 June 2005 3
Planning Guide 1 Introduction Today s system landscapes consist of multiple distributed software components with different platform dependencies, different interfaces, and different requirements placed on installation and change management. An overall concept is required that facilitates the implementation, upgrade, and maintenance of your system landscapes including the NetWeaver system landscape you are installing. This is where Landscape Directory () comes into play. is the central directory of system landscape information relevant for the management of your software lifecycle. It contains a description of your system landscape (that is, the software components that are currently installed) and a repository of software components that can theoretically be installed in your landscape (such as the software components available from ). Since this data gets updated automatically, provides reliable and up-to-date system landscape information with as little effort for you as possible. In this way, acts as a central information provider for and third-party tools that use this data to deliver the services you need to keep your landscape up and running. 4 June 2005
Planning Guide 2 Landscape Scenarios The most straightforward scenario is the use of a single. However, depending on organizational, operational, or security reasons, it is also possible to have more than one distributed over the system landscape. Automatic message forwarding as well as sophisticated data export and import functions are provided to support the operation of multiple s. 2.1 Central Organization (One Single Central ) The best and easiest scenario is the central. All data is collected and maintained in a single. All requests are routed to this single, which contains information about the whole system landscape. All clients must be enabled to access the central. The use of DNS aliases to address makes it possible to switch hosts very easily. This may be necessary for maintenance (updates). Extranet Intranet Intranet June 2005 5
Planning Guide 2.2 Hierarchical Organizations (One Central with Decentralized Sub-s) This organizational form incorporates several fully separated divisions headed by the headquarters. The local division s serves all local needs. Automatic forwarding of landscape data from all divisions accumulates as the complete system landscape in the headquarters. The following picture shows a hosting scenario with lots of separate customer system landscapes. Each customer landscape incorporates its own containing this customer s landscape only. The hosting provider itself must have access to the system landscape of all customers. Hosting Provider Customer 1 Customer 2 Automatic forwarding of landscape data Another use case is an application development landscape comprising development, test, and production systems. The data is forwarded from the development system to the test system and then to the production system. 6 June 2005
Planning Guide 2.3 Fully Separated Organizations (Multiple Standalone s) Multiple s can be used for fully separated management of data. Extranet Intranet Intranet June 2005 7
Planning Guide 2.4 Distributed Organization (Multiple Coupled s) Global or widely distributed IT landscapes may require more than a central. It is then expected that an is locally available but that it provides a more than local view. This can be achieved by coupling multiple distributed s. The following two kinds of coupling between s are possible: Automatic forwarding of landscape data Export and import of landscape data To keep other s informed about changes of specific landscape data, the bridge can be configured to forward data to other instances. You can even set up a mutual exchange of data between two instances, and circular references involving multiple systems are also possible. In this way, the allows direct server-to-server synchronization. The following data can be synchronized: ABAP system data (transaction RZ70) J2EE system data ( data supplier service) Host data (OSCOL) Other system data (sldreg) Manual changes and entries cannot be forwarded and stay within the local only. The same restriction applies for data written by other applications such as XI or Solution Manager. Extranet (World Wide Company Network) Region 1 Region 2 Automatic forwarding of specified landscape data (one-way or mutual) 8 June 2005
Planning Guide Simple export and import functions allow landscape data to be exported from one and imported into another. To ensure proper distribution of data, one should be designated as the master. This master is then used to update the other s. The content is divided into the following three categories: Landscape data (LD) Component data (CR) Name reservation data (NR) The export and import functions of support the transport of content for each sub-category as well as for all data. After an initial full export, only changes are exported. These are called delta exports. We recommend that you transport all three categories together (select export line: ALL in administration). Extranet (World Wide Company Network) Region 1 Region 2 Export and import of data When you transport all data from one instance to another, you also update the component data delivered by. Thus, the CR delta archives have to be imported into the first only. June 2005 9
Planning Guide 3 Best Practices Scenario The following sections outline some typical use cases for the Landscape Directory. 3.1 Central for All Applications Simplicity is often the key to robust and easy to handle system landscapes. The use of only one central for an entire system landscape is shown below. Possible clients are the Exchange Infrastructure ( XI), Solution Manager, Web Dynpro applications, and the NetWeaver elopment Infrastructure (NWDI). These systems may consist of several instances for development (), quality assurance (), and production (). Nevertheless, all instances are bound to one central. This imposes high demands on the regarding availability and stability. High availability concerning operation, maintenance, and upgrade of the is crucial for clients that depend on data. HA Cluster (Central Master) Solution Solution Manager Solution Manager Manager NWDI Web Dynpro Web Dynpro Web Dynpro XI XI XI JCO / RFC ABAP ABAP Back End ABAP Back End Back End 10 June 2005
Planning Guide 3.2 Separate for / and for uction To separate and safeguard the production systems, an additional system can be introduced. This is used for the development and systems. Access to the production systems can be restricted to technical administration users running the production systems. elopment and systems, as well as the respective staff for development and, are only allowed to access the for development and. So, the for development and does not contain any information about production systems. Therefore, it is not possible to inadvertently access production systems during development or testing. elopment and Quality Assurance s uction s Solution Solution Manager Manager for and Transport of all data for Overall Landscape Solution Manager XI XI Web Dynpro Web Dynpro Web Dynpro XI NWDI JCO / RFC ABAP ABAP Back End Back End JCO / RFC ABAP Back End June 2005 11
Planning Guide 3.3 Separate for NWDI The NetWeaver elopment Infrastructure makes use of as a name server during design time. But development normally requires a high level of changes and updates of data as well as upgrades to the most recent release of the system. These development requirements conflict with the requirements of the production systems. This is why a separate name server for NWDI makes sense for large development divisions. NetWeaver elopment Infrastructure (NWDI) uction, and s NWDI NetWeaver elopment Infrastructure CMS Name Server for NWDI Transport of all data Master Solution Solution Manager Solution Manager Manager CBS DTR NWDI eloper PC Web Dynpro Web Dynpro Web Dynpro JCO / RFC ABAP ABAP Back End ABAP Back End Back End XI XI XI 12 June 2005
Planning Guide 3.4 for Distributed XI Landscapes The NetWeaver Exchange Infrastructure makes use of in several ways: As a server for business system names Transport targets for directory content transports Management of software component versions End-to-end monitoring of Runtime Workbench Transfer of adapter configuration data from the XI directory to the adapter CPACache The best solution is to have a single (see also section 2.1 or 3.1). If this is not possible due to legal constraints, company policies, or network implications, a distributed landscape is inevitable. But even in the distributed landscape, you should designate one master that contains the data required in all landscapes. The handling of distributed s is explained in section 2.4 The key principles of distributed operations are: 1.) All system data that is crucial for global operation must be transported (export/import) to the master. That means all necessary landscape data is consolidated in the master. 2.) The master s data is transported to all other s on a regular basis. This manual step includes the export of master data and the decentralized import of this data. Extranet (World Wide Company Network) Region 1 1 Transport (export/import) of individual landscape objects Region 2 Master 2 2 Transport (export/import) of all master data XI XI XI XI Always transport in one direction to prevent mismatches. Transport targets of system information must have the same version as the source system or a higher version. For more information, see How To and XI in Service Marketplace at: service.sap.com/netweaver Media Library How-To Guides June 2005 13
Planning Guide 3.5 for Distributed elopment Large and multinational companies tend to spread development departments all over the world. This may be due to cost effectiveness (offshoring) or organizational reasons. Nevertheless, it is essential for each regional development department to have data locally available. The availability of a local in each region enables quick responses and saves network traffic. Forwarding of landscape data can be used to provide global back-end access in distributed Web Dynpro development landscapes. Extranet (World Wide Company Network) Region 1 Region 2 Back-End s Automatic forwarding of data for back-end systems Back-End s PCs running IDE PCs running IDE PCs running IDE PCs running IDE 14 June 2005
Planning Guide 4 Best Practices for the NetWeaver Landscape The following points constitute the best practices for the system landscape: One central is used. Administration and monitoring components are grouped together on one host. This central monitoring and administration system must have high availability (HA). Solution Manager is installed on the same host as the central monitoring and administration system but in a separate Web AS. can act as a data source for landscape data for Solution Manager. 4.1 Support Infrastructure and Central Administration and Monitoring The Solution Manager represents the support infrastructure and the central administration and monitoring comprises the following elements: NetWeaver Administrator Landscape Directory SLM Software Lifecycle Manager CUA Central User Administration CPH Central Performance History ERP CRM SRM Web AS Web AS Web AS HA Cluster Support Infrastructure and Central Administration and Monitoring Optional enhancements of Solution Manager infrastructure CUA CPH NetWeaver Administrator SLM SolMan Diagnostics Refresh of Landscape Information Solution Manager Solution Manager Solution Manager Web AS Web AS Web AS Web AS June 2005 15
Planning Guide 5 Summary of All Connections The following figure gives you an overview of all communication paths to and from the. On the right side (bullets 1 to 3) it shows data suppliers. They simply send actual system landscape data to. clients on the left side are capable of interacting with the. This means they can retrieve, send, and update system landscape data with. The following sections give a short explanation of all communication paths depicted below (see bullet points). Clients Data Supplier 5 J2EE Application Client LCRAPAB-API JCO RFC ABAP Application 4 5 HTTP/S (WBEM) RFC J2EE Server Client LCRAPAB-API Bridge JCO RFC Gateway HTTP/S HTTP/S RFC 3 2 sldreg C++ Program J2EE Application Application not based on Web AS ABAP Application 6 RFC HTTP J2EE 1 ABAP Application 7 Server Client Bridge 5.1 ABAP Data Supplier (1) ABAP data suppliers must send their data to the Bridge. ABAP suppliers use RFC to do this. The destination is a Java Connector (JCO), which is registered with the Gateway and provides the connection to the Bridge running in the J2EE environment. 5.2 J2EE Data Supplier (2) J2EE data suppliers send their data directly to the Bridge using the HTTP / HTTPS protocol. 16 June 2005
Planning Guide 5.3 External Data Supplier (3) Applications not running on the Web Application Server may use sldreg to supply their landscape data. It can be used as an interface to send the data to the Bridge using the HTTP / HTTPS protocol. 5.4 J2EE Client (4) The J2EE client is able to directly interact with server using the HTTP / HTTPS protocol. 5.5 ABAP Client (5) An ABAP client cannot communicate with the server directly. The first communication step is with an RFC server (LCRABAP-API) registered with an Gateway. The LCRABAP server interfaces with the client, which communicates with using the HTTP / HTTPS protocol. 5.6 Standalone ABAP Client (6) Standalone ABAP systems cannot run the J2EE client software. Therefore, the ABAP client needs to connect to the Gateway of a system running the J2EE client. This may be the Gateway of the system of any other system running the J2EE client and an LCRABAP-API registered RFC server. 5.7 to Message Forwarding (7) Data suppliers send their messages only to the Bridge they are connected to. But each Bridge can be configured to forward all incoming data supplier messages to other Bridges. This forwarding mechanism can be used to update or synchronize multiple s in large IT landscapes. See section 2.4.1 for details. June 2005 17
Planning Guide 6 Network Access Scenarios This section shows scenarios with special respect to networking aspects. 6.1 Intranet Scenario Intranet means the use of Internet techniques within a corporate network. Although corporate networks incorporate different kinds of networks, e.g. LAN, WAN, VPN, or leased lines, the existence of company wide naming and addressing rules ensures direct addressing and communication between all servers. The non-existence of barriers like firewalls and NAT (Network Address Translation) allows both of 's load balancing solutions to be used, the Message Server redirect mechanism as well as the new Web Dispatcher. Business s located within the company s network Business s located within the LAN Business Load balancing using Message Server redirection Web Dispatcher or Reverse Proxy Load balancing XI Integration XI Integration Server Server (multiple servers) Business Business Business Business 18 June 2005
Planning Guide 6.2 Extranet Scenario Extranets extend the range of the Intranet. Well-known systems for example, systems of business partners get access to certain servers within the Intranet. These business systems are normally connected over point-to-point access through VPN or leased lines but not over public networks. Nevertheless, these systems are not allowed to access the whole corporate network but only a few dedicated servers. This restriction is normally accomplished by employing some kind of reverse proxy within the DMZ (Demilitarized Zone). This proxy forwards the requests to permissible servers. provides the Web Dispatcher for use as HTTP reverse proxy and load balancer. router can be used to check and forward RFC connections. Well known Business s located in remote networks DMZ (demilitarized zone) Business s located within the LAN Business with HTTP based communication VPN Tunnel Business Leased line Leased line Access Router Web Dispatcher or Reverse Proxy router Load balancing Firewall XI Integration XI Integration Server Server (multiple servers) Business Business with RFC based communication VPN Tunnel Business June 2005 19
Planning Guide Appendix Related Documentation in Service Marketplace Landscape Directory: service.sap.com/sld Platform and Technology Information Center: service.sap.com/platforms R/3 Security Guide: service.sap.com/security Guidelines and Audits Sizing: service.sap.com/sizing 20 June 2005