SAP Landscape Strategy

Contents

Introduction Environment Strategy SAP System Instance Strategy SAP Application Transport & Client Strategies SAP NetWeaver Component Strategies BASIS Naming Standards

Introduction The SAP Landscape Strategy defines key design decisions for distributing the SAP applications across servers, at a level of detail which allows the BASIS team to begin installations. The Environment Strategy lists the system environments that the project will create, such as Development, Test, and Production. The System Instance Strategy lists the SAP runtime engines that will be installed in each environment, and which SAP applications or modules will run on each engine. Each engine is called a system instance. The Client Strategy specifies a list of copies to be created in each system, and how project team members and end users will use those copies to do their work. The client strategy also shows the Transport Strategy, which maps how code and configuration changes will flow from one client and system to the next. Several NetWeaver Component Strategies outline key decisions that will drive the design of cross-system technical configuration, including the SLD Strategy (SLD = System Landscape Directory). Finally, BASIS Naming Standards provide rules for the BASIS team to follow during the installs in order to deliver systems that are more userfriendly and robust in the face of future technology changes.

Contents

Introduction Environment Strategy SAP System Instance Strategy SAP Application Transport & Client Strategies SAP NetWeaver Component Strategies BASIS Naming Standards

Principles for Defining SAP Environments At minimum, 3 environments are required on the development track for separation-of-duties around code and configuration changes
As dictated by change management best practices and PCI DSS

Development in production-track systems should be tied to an approved change

The develop-for-production pathways (Develop Test Production) should not entertain code or config changes from research or learning activities, so that development systems are reasonably representative of production systems. Balance the risks and costs of separate environments for projects and minor production fixes so that major project schedules arent disrupted by production support changes Balance the costs of additional testing versus the service-level risk from development errors making it to production, including testing of transport procedures and automated regression tests In larger projects, errors in transported objects are the most common cause of service-level hits in production Problems with a user-facing system hurt adoption, including training scripts that fail during training classes because of concurrent development in the trainees system

Production support and project release activities must be supported

Service-level requirements affect environment design

Balance cost with end-user perception

Provide business continuity in the event of a disaster

5

SAP Environments and Development Pathways (Logical View)

Most, not all, applications will follow this pathway

SAP System Refresh Pathways (Logical View)

Key System Refresh Design Considerations: The IT change audit trail must be maintained
Relevant history lost in a refresh should be verified to be in Solution Manager

Information security risks must be evaluated and addressed Production outages should be avoided (or of minimal duration) for the extract

Most, not all, applications will follow this guidance

Contents

Introduction Environment Strategy SAP System Instance Strategy SAP Application Transport & Client Strategies SAP NetWeaver Component Strategies BASIS Naming Standards

SAP System Instances

SID SAP System Instance
xEC xBW xBI xBA xBX xPF xIN xSM xGR xDI xJV ERP Core financials business app BI-DW Data warehouse EP-BI Portal for analysis & reporting BIA Data warehouse accelerator BEx Broadcaster Report distribution EP Federated portal for user logon PI Integration middleware SolMan TTS business app GRC Governance, Risk, Compliance NWDI Source control and build for J2EE and EP development WebAS Java Custom development

SAP Modules
FI, MM, IS-Retail, FSCM, GRC agents, SLD NetWeaver BI ABAP components, POSDM NetWeaver BI Java components, SLD BIA BEx Broadcaster svc, Microsoft Office NetWeaver EP, SLD NetWeaver PI, Conversion Agent, SLD Solution Manager, Solution Manager Enterprise Edition, SLD Access Control & Process Control NWDI NetWeaver WebAS Java, SLD

Notes

BPC may eventually be needed, but will not be built in Phase 1.

Intel Linux appliance; no database Windows Server only; no database Not yet in scope

All 4 Access Control components Not yet in scope Not yet in scope

A separate BI (Data Warehouse) standalone system for POSDM may be needed, but appears unlikely at this time. This decision depends on NetWeaver BI sizing. It will not be needed for the Phase 1 rollout. = Will not be installed at the present time 9

SAP Applications (System Instances)

SAP System Instance SAP ERP SAP BI Data warehouse system SAP EP/BI Portal SAP BIA Business Intelligence Accelerator SAP BEx Precalc service Business Purpose Most of the financial transaction processing: G/L, A/P, A/R, Treasury, etc. SAPs data warehouse, financial planning transactions, and cleansing & aggregation of point-of-sale data Many of the reporting features for SAP Business Intelligence A network appliance that speeds up queries against the SAP data warehouse by ~100x. The application that interacts with Microsoft Office to generate spreadsheet-based reports. This runs on a Windows Server. Integration middleware, used to expose SAPs interfaces as services so that non-SAP systems can be integrated. An application management server required by Solution Manager, SAP PI, and SAP EP. Pulls a sampling of data from SAP ERP and SAP BI, scrubs the sensitive data, then feeds the subset to the development, test, and staging systems for support and testing against real production data. Serves up context help for user interfaces 10

SAP PI SAP System Landscape Directory SAP TDMS

SAP online help

SAP Applications (System Instances)

SAP System Instance SAP Solution Manager Business Purpose Manages and helps automate several TTS processes across the SAP applications, including project documentation, change controls, and system monitoring. Central point of integration between the other systems and many of TTSs infrastructure tools. Workflow management server for the SAP Governance Risk & Compliance module, which centrally manages authorizations and other SOX controls. Source control and build server for custom development in SAP EP and any custom J2EE development that we do on SAPs Java application servers. Most of this work will be done in WebSphere, but there will likely be some oneoffs that, for tactical reasons, need to be deployed on SAP. Application server to run any custom J2EE development that has to be deployed (for tactical reasons) on the SAP platform. Federation server for linking multiple SAP EP servers and making them appear as one portal. Still possible, but appearing unlikely. Depends on the portal strategy.

SAP GRC

SAP NWDI

SAP WebAS Java

SAP EP federated portal

= Will not be installed at the present time 11

SAP System Instances Environment Matrix

SAP System Project Test Project Dev Training Sandbox MDHA/DR Production Stage Funct. Test Develop Extras

xEC xBW xBI xBA xBX xIN xSM xGR --

SID

ERP Core financials business app BI-DW Data warehouse EP-BI Portal for analysis & reporting BIA Data warehouse accelerator BEx Precalc Service Excel PI Integration middleware SolMan TTS business app GRC AC & PC server components SAP online help

*1 *1 *1 *1 *2 -

*1 *1 *2 -

*4 -

1. Available blades will be allocated as determined by appliance location and project need 2. Two shared instances; one for the production path; one for the projects path. 3. This system will be used for manual manipulation of integration connections when source and target systems dont align or are changed outside of the official transport paths (mux/demux system) 4. A separate GRC instance treated like production will be used for security in non-production systems.

= Will not be installed at the present time

12

SAP Software Version Strategy

SAP ships software with 4 levels of implied change: Major release (ECC 6, NetWeaver 7) Minor release (NetWeaver 7.1) Enhancement Pack (ECC 603) or Support Package Stack (NetWeaver 7.0 SPS 21)
Numerous, well-documented functional enhancements and fixes from SAP Notes are incorporated in the SPS and Enhancement Packs. These units are fully regression tested as a single package by SAP development, to reduce incompatibility risks Staying (relatively) current on NetWeaver SPS releases once in production is a best practice; Capgemini generally recommends applying every 3rd SPS when there is active development in a system.

Patch (NetWeaver 7.0 SPS 21 component PI-TOOLS patchlevel 3)

Patches are issued at the component level and only serve to include fixes from SAP Notes (typically 1-2 fixes per patch) Functionality is not enhanced in patches SAP does not test patches against other components; occasionally, conflicts arise
13

SAP Software Version Strategy

The installation and patching of SAP software will follow these guidelines for the Phase 1 rollout: No major release, minor release, Support Package Stack, or Enhancement Pack will be applied until it has had Generally Available status from SAP for at least 8 weeks. All installations will plan to use the most recent GA release at January 4, 2009 for Development through Production.
This date is 8 weeks prior to the first day of realization (March 1, 2009) As quickly as reasonable, around March 1, development systems will be installed/patched/upgraded as needed to bring them up to the January 4, 2009 release. All major releases, minor releases will be fixed as of that date. Only an Act of God as determined by the SAP project managers will justify a major/minor upgrade. SPS and Enhancement packs may continue to be applied after that date with approval from the TGT architecture team Changes to software versions after that date will follow the then-current change-request process requiring approvals from the TGT$100 architecture team and/or the PMO as appropriate.

All software versions will be locked down 4 weeks prior to FIT 1

14

Contents

Introduction Environment Strategy SAP System Instance Strategy SAP Application Transport & Client Strategies SAP NetWeaver Component Strategies BASIS Naming Standards

15

Purpose of Transports & Clients in SAP

Transport A Transport is the container SAP uses to package modified code and/or configuration. SAPs change management tools move this container from development to test to production.
One transport may contain multiple development objects as well as configuration entries Once deployed, it cannot be undeployed. Backing out a transport requires a new transport to undo the change (or a restore from backup).

Client A Client creates multiple logical business applications inside of a single running ABAP engine, all using the same underlying code.
ABAP code is the same across all clients Business process configuration is client-specific; the system can execute a business process differently in two distinct clients User security is client-specific Business data is client-specific. A G/L entry posted in one client cant be displayed when youre logged into another client.
16

Initial Transport Process for the ECC Development System

ABAP development will take place in Client 110 or Master Data Client 210, and transports will be released from that client Configuration will be performed in Client 110 or Master Data Client 210, and transports will be released from those clients Transaction SCC1 may be used to move the config to Client 100 or Master Data Client 200 for unit testing
Only functional staff with > 1 year SAP configuration experience will be given access to SCC1 to reduce the occurrence of human error The transport process will subsequently overwrite the SCC1 config with the transported config

Client 130 or Master Data Client 230 will be open to config for any prototyping, unit or negative testing that requires config changes where the need to transport is uncertain
No transports or SCC1 transfers will be permitted against these clients If the prototyping works, re-enter the config manually in Client 110 / 210

Absolutely no transports will be sent from the Sandbox system

Transaction SCC1 will be locked once the config is locked down in Realization 17

Transport Strategy

Transport objects (code and config) will only be created or changed in Development and Sandbox systems. Transport objects will only be exported from defined Development Systems. Absolutely no objects will be transported from any Sandbox systems. The Solution Manager Change Request Management process (ChaRM) will be used for all transports in the SAP landscape
This includes ECC, BI, EP, PI, Solution Manager, SLD, TDMS, and custom development deployed on WebAS Java This includes development, SAP configuration, and where possible, support package stacks, patches and technical support fixes Exception: Standalone engines not supported by CTS+ will leverage custom script-based transport mechanisms. (None identified thus far.)

Standalone CTS+ will be used as a temporary solution for transports until the ChaRM process is in production
Transports will be executed centrally from a TMS domain controller for this purpose
18

Transport Strategy (cont.)

Transport paths are not relevant for certain appliances and standalone rendering engines that contain no custom code:
xBX NetWeaver BEx Information Broadcasting service xBA NetWeaver BI Accelerator xDI NetWeaver Development Infrastructure

Transport paths for ABAP systems are documented in the client strategy Transport paths will follow the normal development pathways for the following systems:
xBI NetWeaver EP portal with BI analytics components xPF NetWeaver EP portal federation server xJV NetWeaver WebAS Java custom-developed applications The pathways are documented on the slide titled SAP Environments and Development Pathways (Logical View) Client strategies are not relevant for these systems

Note: CTS+ transports and complete synchronization of System Landscape Directory configuration (SLD) are brand new features. SLD transport strategy (system xLD) will require prototyping to determine the appropriate process. 19

Client Strategies

The client strategies shown are for the TGT$100 project implementation. Only a subset of these clients will stay after go-live. Client strategies are only relevant for systems running SAP NetWeaver WebAS ABAP:
xEC ERP financials xBW NetWeaver BI data warehouse xIN NetWeaver PI integration server xTD Test data migration server xSM Solution Manager NetWeaver EP and other Java based systems (including BI and PI) sometimes require an ABAP engine with 1 client for some backend integration. Where that occurs, the Java engine will always integrate to client 100 for the application processing and user security. GRC AC/PC will also follow this model.

Technical clients 000 (for installation) and 066 (for SAP EarlyWatch) are present in all ABAP systems, but only SAP technical support and BASIS roles will be granted access to those clients
20

See also: Master Data clients next page

XEC Sandbox
100 Sandbox

Client Strategy: Core SAP ERP

DEC Develop / Unit Test
100 Unit Test 110 Config & Dev Golden Client 120 Unit Sandbox

REC Training
100 User Practice 110 Training Image 121 Training 1 122 Training 2 123 Training 3 124 Training 4

QEC Test
100 E2E (Permanent FIT) 110 Golden Client (Locked) 120 FIT 1 130 GRC PC FIT (Open) 140 FIT 2 150 Data Refresh

SEC Stage
100 Permanent Regression Test

PEC Production
100 ERP Production

140 Conversion Unit Test 150 Data Refresh

Transports not permitted

000 / 066 BASIS 000 / 066 BASIS 000 / 066 BASIS 000 / 066 BASIS 000 / 066 BASIS 000 / 066 BASIS

Client 100 is assigned to the client that most users log into, as its easier to remember = Transport Path 21

Client Strategy: Core SAP ERP

XEC Sandbox REC Training
200 User Practice 210 Training Image 221 Training 1 222 Training 2

DEC Develop / Unit Test

200 MDM Unit Test 210 MDM Config & Development Golden Client 220 MDM Sandbox

QEC Test
200 MDM E2E (Permanent FIT) 210 Golden Client (Locked) 220 MDM FIT 1

SEC Stage
200 Permanent MDM Regression Test

PEC Production
200 MDM Production

Use client 100 (no MDM client)

240 Conversion MDM Unit Test 250 MDM Data Refresh

240 MDM FIT 2 250 MDM Data Refresh

Transports not permitted

The only crossover in transport paths between Financials and MDM is ABAP code, which is clientindependent. MDM-related ABAP code will still be developed and released in Client 110. = Transport Path 22

XEC Client Usage

XEC Sandbox
100 Sandbox

Client 100 Used by configurators and developers to do research and prototyping of how to fulfill project requirements, and to experiment to hone their skills. There are controls on administrative tasks, but once Blueprint is complete, people with SAP configuration, development, or administrative roles are encouraged to use this system to learn how SAP works. This client will be infrequently refreshed from development or another production-track system in order to get a realistic (but not necessarily complete) snapshot of Targets production configuration. This system tends to break periodically due to user misconfiguration, so a backup should be taken and set aside for long-term storage after each refresh and after user security is configured.

Clients present in all ABAP systems: Transports not permitted

000 / 066 BASIS

Client 000 This is the default client, created during installation. It is used (very infrequently) by the BASIS team for system-wide administrative tasks. Client 066 This client is mandated by SAP in order to receive their EarlyWatch Go-Live Check service, which is part of Targets maintenance agreement. SAP monitors and tests the server performance from this client during their check, so that they have no access to the business data in other clients.

23

DEC Client Usage

DEC Develop / Unit Test
100 Unit Test 110 Config & Dev Golden Client 120 Unit Sandbox

Client 100 Most unit testing for the functional and development teams is done here. This client will be used by the most people both during the project and after go-live. Client 110 The Golden Client is where the functional teams perform configuration and the ABAP developers write code. This is a pristine image of config and user security only. Transactions and master data are not entered in this client, except for rare cases where theyre required to record scripts as part of development. Client 120 Sandbox used by the development and functional teams to unit test PRICEFW objects after they have tried testing in 100, if they need to modify configuration to troubleshoot an error or to test an error case. Config will be open in 120, closed in 100. Client 140 Used by the Data Conversion team for the unit testing of transactional data conversion load programs. (Master data will be loaded in the MDM clients) Client 150 - Contains master data and is used by the BASIS team for refreshing other development clients

140 Conversion Unit Test 150 Data Reimage

000 / 066 BASIS

24

DEC Master Data Client Usage

DEC Develop / Unit Test
200 MDM Unit Test 210 MDM Config Golden Client 220 MDM Sandbox

Client 200 Most unit testing of master data management for the functional and development teams is done here, including master data entry, configuration, and workflows. This client will live on for production support. Client 210 The Golden Client is where the functional teams perform configuration and create their transports. This is a pristine image of config and user security only. Transactions and master data are not entered in the client; only the functional configurators have access to make changes. Client 220 Sandbox used by the development and functional teams to unit test master data PRICEFW objects after they have tried testing in 100, if they need to modify configuration to troubleshoot an error or to test an error case. Config will be open in 220, closed in 200. Client 240 Used by the Data Conversion team for the unit testing of master data conversion load programs. Client 250 - Contains master data and is used by the BASIS team for refreshing other development clients

240 Conversion MDM Unit Test 250 MDM Data Refresh

25

QEC Client Usage

QEC Test
100 E2E (Permanent FIT) 110 Golden Client (Locked) 120 FIT1 130 GRC PC FIT (Open) 140 FIT 2 150 Data Refresh

Client 100 Permanent integration testing client for production support (excluding master data processes). Also used for E2E testing, so that at the end of E2E the client is already prepared for production support. Client 110 The Master Backup Golden Client is used to house the configuration master and is the only client from which configuration and objects (programs, authorization objects, or roles) will be promoted to the R/3 staging instance. Client 120 Used by the project for FIT 1 test cycle. Client 130 Used for executing all GRC Process Control test cases. This client is a copy of Client 120 that is open to config (but not development), so that the GRC PC team can break config for their negative testing. Client 140 Used for FIT 2 test cycle. Client 150 Used by the Basis team to refresh Client 140 with a clean set of data so that the data conversion loads can be repeated independently of the other test cycles. This client will be a copy of Client 120 taken immediately before the data loads begin during cutover simulation.

000 / 066 BASIS

26

QEC Master Data Client Usage

QEC Test
200 MDM E2E (Permanent FIT) 210 Golden Client (Locked) 220 MDM FIT 1

Client 200 Permanent integration testing client for production support. Also used for E2E testing, so that at the end of E2E the client is already prepared for production support. Client 210 The Master Backup Golden Client is used to house the configuration master for master data processes and is the only client from which configuration and objects (programs, authorization objects, or roles) will be promoted to the R/3 staging instance. Client 220 Used by the project for the FIT 1 test cycle. Client 240 Used for the FIT 2 test cycle. Client 250 - Used by the Basis team to refresh Client 240 with a clean set of data so that the data conversion loads can be repeated independently of the other test cycles. This client will be a copy of Client 220 taken immediately before the data loads begin during cutover simulation.

240 MDM FIT 2 250 MDM Data Refresh

27

SEC Client Usage

SEC Stage
100 Permanent Regression Test

Client 100 Permanent regression testing client; usage will be directed by the TTS Quality Assurance group and the formal TTS change management process. The performance test cycle will be executed in this client. The client may be refreshed from client 150 as needed.

000 / 066 BASIS

28

SEC Master Data Client Usage

SEC Stage
200 Permanent MDM Regression Test

Client 200 Permanent regression testing client; usage will be directed by the TTS Quality Assurance group and the formal TTS change management process. The performance test cycle will be executed in this client. The client may be refreshed from client 250 as needed.

29

REC Client Usage

REC Training
100 User Practice 110 Training Image 121 Training 1 122 Training 2

200 User Practice 210 Training Image 221 Training 1 222 Training 2

Client 100 The User Practice After Training client is used by newly trained users of the application. This client is tightly controlled and provides only the ability to perform specific business transactions. This and the other training clients will be created when needed and typically toward the end of integration testing to ensure the latest, viable configuration is included in the initial copy. Client 110 Training image for all processes except master data. Used to refresh clients 121, 122, after each training class so that the same training exercises can be used in the next class. No training is conducted from this client. It is built using tested configuration as well as master and transaction data specific to the training scenarios. This and the other training clients will be created when needed and typically toward the end of integration testing to ensure the latest, viable configuration is included in the initial copy. Client 121-12x Training clients for all processes except master data. Each training class gets its own client for performing scripted exercises in the system. These clients are created and refreshed from client 110, generally after every class. Client 200 User Practice After Training client for master data processes Client 210 Training image for master data processes. Used to refresh clients 221, 222, after each training class Client 221-22x Training clients for master data processes. Each training class gets its own client for performing scripted exercises in the system. These clients are created and refreshed from client 210, generally after every class. 30

000 / 066 BASIS

PEC Client Usage

PEC Production
100 ERP Production

Client 100 The main business application in production, for all processes except master data Client 200 The main business application in production, for master data processes

200 MDM Production

000 / 066 BASIS

31

Client Strategy: Other ABAP Systems

Xxx Sandbox 100 Sandbox Rxx Training 100 User Practice Dxx Develop / Unit Test 100 Unit Test Qxx Test 100 Functional Test Sxx Stage 100 Regression Test Pxx Production 100 Production

000 / 066 BASIS

000 / 066 BASIS

000 / 066 BASIS

000 / 066 BASIS

000 / 066 BASIS

000 / 066 BASIS

Functional test system strategy: Subject to requirements imposed by ChaRM, a backup image of the Qxx and Sxx system will be taken after post-installation and system checkout is complete. That image will be used to rebuild the system to simulate cutover for FIT 2 and FIT 3. 32

Contents

Introduction Environment Strategy SAP System Instance Strategy SAP Application Transport & Client Strategies SAP NetWeaver Component Strategies BASIS Naming Standards

33

Central Admin Services Architecture

Analytics Layer
Performance & Service Level Reports & Trends
ABAP

SAP NetWeaver BI (on SM box) Performance statistics

Monitoring Layer
Technical & KPI Monitors and Notification Services

ABAP + J2EE

SAP Solution Manager

CCMS GRMG

SNMP Network Monitoring

Application Systems
Central Administration

ABAP/J2EE Engines

......

EarlyWatch Alerts (KPIs)

CCMS Agents (errors)

NetWeaver Administrator

......
34

Strategy: System Landscape Directory

SLD = System Landscape Directory

Contains a description of the technical landscape, similar to HP CMDB SAP EP, Solution Manager, PI, and NWDI critically rely on it at runtime

Recommendation: Master/Slave configuration

System Landscape Directory design is covered by detailed design documents outside the scope of this strategy.

Decision Tree Source: SAP 35

Strategy: SAP Interactive Forms by Adobe

SAP Interactive Forms by Adobe is an add-on from SAP which can be used to:
Generate PDF reports Accept electronic data from end-user PDF fill-in forms

This add-on is required to use certain standard reports in SAP GRC and SAP NetWeaver EP
It is not yet known whether those reports are in scope Usage of the standard reports in GRC is common among customers

Customized reports or forms are likely to require an additional license from SAP
No such scope has been identified, yet

Recommendation:
Because of expected light usage, the Adobe Document Services (ADS) server component required to enable SAP Interactive Forms will be installed on the Java stack of applications which require its use A standalone ADS server will not be maintained

36

Strategy: SAP NetWeaver BI Architecture

SAP NetWeaver BI can run on one dual-stack instance or be split into separate ABAP and J2EE instances
Dual stack requires less maintenance, but makes less-efficient use of RAM Our BI system is projected to be extremely large in Phase III; splitting up the load of the stacks reduces performance risk.

Recommendation:
BI data warehouse will be installed on a standalone WebAS ABAP instance BI Java/EP components and content will be installed on a standalone WebAS Java instance

37

Strategy: SAP Online Help

Microsoft Compiled HTML Help will be used

Two options are supported: Web-based HTML help or native Microsoft Windows help Microsoft Windows help is the only option which supports search. It is only supported on SAP GUI for Windows.

A single Windows server on VMWare ESX 3.0 will serve help for all SAP systems/environments
Disaster protection (availability in the backup data center) is preferred, but only if the current VMWare infrastructure makes it reasonably easy to do so

Inter-DC communications is a low risk for this low-volume feature

We will design to allow the help system to run in a different DC than the SAP business application
Disk mirror

SAP WebAS
(Solaris)

SAP Help
(Windows)

SAP Help
(disaster) SAP GUI

SAP WebAS
(Solaris)

TTC

TTC-E
Diagram is conceptual
38

Strategy: Archiving & Content Management

A 3rd party content management system will manage archived data and unstructured content
Go-live estimated Summer 2010 ArchiveLink, ADK, and the relevant EP-KM API will interface archiving and content management to the 3rd party system Operating system scripts will interface application/security logs to the 3rd party system For Go-Live 1, unstructured attachments will be stored in the ERP database For Go-Live 1, archived data will be stored on a filesystem, and archiving will be kept to a minimum (DART + SAP NetWeaver PI)
DART IRS archives Archived Database Data Archived attachments & image files Archived log files

ADK

SAP WebAS
(Solaris)

ArchiveLink O/S Scripts

Content Mgmt
(non-SAP)

39

Contents

Introduction Environment Strategy SAP System Instance Strategy SAP Application Transport & Client Strategies SAP NetWeaver Component Strategies BASIS Naming Standards

40

SAP System Naming Standards

System naming and presentation standards are defined to make systems easier to remember for users and to reduce the risk of performing work in the wrong system. These standards include: Hostname
Virtual hostnames are defined to identify the systems, and to allow them to be moved between physical servers without affecting end-users or other systems. These hostnames are discreetly displayed to end-users in browser URLs and other places.

System ID
A 3-character ID that uniquely identifies the server in the landscape. The SID is the common name by which all members of the SAP team generally refer to the system within the team.

System Number
A 2-digit number that is used to define what group of TCP/IP ports the systems internal components will listen on

Client Number
A 3-digit number that provides a logical separation of business uses within a single SAP system. End-users enter this number (or use the configured default) in addition to their username and password when they log on to SAP GUI.

41

Standard: SAP System Hostnames for WebAS Applications

fss<SID><System_Type><System_Type_Number>
fss = Target Technology Services 3-letter code for the TGT$100 finance applications <SID> = 3-character SAP system ID <System_Type> is one of the following <none> - SAP central services instance (SCS) user logons point here ers SAP enqueue replication service for high availability db SAP database instance ap SAP application server (WebAS ABAP, WebAS Java) wd Standalone SAP Web Dispatcher <System_Type_Number> starts at 1 and differentiates multiple database systems or dialog systems in a cluster. The first database instance will be blank; when clustered database technologies are introduced in the future, the 2nd database instance will use the number 1. <none> - SAP central services instance (SCS) or enqueue replication service (ERS) <none> - SAP database instance <none> SAP application server central instance (CI) 00..N SAP application server instance (CI or DIs) or clustered database instance

Examples:
fsspsm fsspsmers fsspsmdb00 fsspsmap00 fsspsmap01 fsspsmap02 Production Solution Manager SCS instance Production Solution Manager enqueue replication service Production Solution Manager database instance Production Solution Manager CI Production Solution Manager DI #1 Production Solution Manager DI #2

Hostnames are lowercase Maximum length of the unqualified hostname is 13 characters. Separate virtual hostnames must be defined for the SCS, CI, DB, and any DIs, even when co-located on a single logical server. Multiple hostnames may point to the same virtual IP. System-to-system connections, URLs, and SAP GUI logon files must use these hostnames.

42

Standard: SAP System IDs

<Environment><Application>[<Sequence number>]

Exactly 3 characters

<Environment> = 1 character identifier from the following list X Sandbox D Development (for production support or projects) Q Functional testing (Quality Assurance for production support or projects) S Staging, onsolidation, pre-production R Training P Production <Application> = valid 2-character or 1-character codes listed on next page. The 2-character code is used by default and represents the ongoing production support landscape; the 1-character code is only used if a sequence number is required to denote a separate project system. In the case of a Web Dispatcher instance, the <Application> code is the load-balanced systems 1 character code plus a W. <Optional_Sequence_Number> starts at 1 and is used primarily to denote parallel project landscapes, such as a project development system or project functional testing system

Examples:
PEC XIN CBA QPF PSM DI1 QE1 PIW Production ERP system Sandbox PI integration server Pre-production BIA server Functional testing Enterprise Portal federation server Production Solution Manager Additional development system for PI integration server to support a project Additional test system for the core ERP system to support a project Production Web dispatcher for load-balancing PI integration server

Additional 1-character environment codes may be added to this list if new environment needs arise.

43

Standard: Application Codes for SAP System IDs

SAP System ID Application codes:
2-character-code (1-character-code in parentheses) SM (S) Solution Manager AC (A) Adaptive Computing Controller (ACC) EC (E) SAP ERP for TTS Finance PF (P) Enterprise Portal entry point (federation server) FM (F) SAP Interactive Forms by Adobe (only if on a standalone system) BI (B) Enterprise Portal reporting components of Business Intelligence (or BW+EP all-in-one) BW (W) Business warehouse component of BI BX (X) BEx Broadcaster component of BI BA (I) Business Intelligence Accelerator (BIA) component of BI GR (G) GRC Access Control & Process Control IN (I) Process Integration / Exchange Infrastructure LD (L) Central (standalone) System Landscape Directory TD (T) Test Data Management DI (D) NetWeaver Development Infrastructure TR (R) tREX search engine JV (J) Standalone WebAS application server for custom developed apps W* - Web dispatcher, 3rd position only (so as not to confuse with Business Warehouse)
Additional application codes may be added to this list when new application uses arise. None of these codes, when used with the listed prefixes, conflict with SAPs reserved names. See any SAP installation guide for the list of reserved names.

44

Standard: SAP System Numbers

All SAP application servers will use the same system numbers: 00 (double-zero) for the application server (CI & DI) 10 for the Central Services Instance (SCS) 20 for SAP Web Dispatcher
This standard infers (and enforces) a non-functional requirement that all SAP systems will be installed on dedicated virtual hosts. Multiple system instances (multiple SAP System IDs) will not share a host. The use of the same set of easy-to-remember port numbers also reduces the burden on administrative staff as they try to remember what port a given service is listening to. System number 00, for example, means the HTTP servers for all systems are listening by default on ports 8000 and 50000. If the system number were 37, administrators would have to remember that the system is listening on ports 8037 and 53700.

45

Standard: SAP Client Numbers

Clients in core ERP, BW, and PI 100 = Production 100 = Client used by the most end users (unit test, enduring FIT, sandbox, ) 1xx = Other clients in ECC

Master data clients in ERP 200 = Production 200 = Primary end-user client (unit testing, enduring FIT, etc.) 2xx = Other clients in ECC
Master data clients subject to final determination of MDM approach

The Client concept only exists in SAP WebAS ABAP systems. Defining client numbers is a tradeoff between keeping numbers that are easy to remember for users (mostly the SAP professionals), eliminating a time-consuming BASIS step when doing a system refresh, and increasing the probability that someone knows when theyre accidentally trying to log in to the wrong system. Additional steps on the introduction screen and in the splash window after logging in will be used to help users recognize that theyre in the correct client. Systems will be configured to default to the most-frequently-used client (e.g. Client 100 in production).

46

47