SAP Landscape Design - V24

SAP Landscape Strategy

2

Contents

Introduction

Environment Strategy

SAP System Instance Strategy

SAP Application Transport & Client Strategies

SAP NetWeaver Component Strategies

BASIS Naming Standards

3

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 user-friendly and robust in the face of future technology changes.

4

Contents

Introduction






5

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 (DevelopTestProduction) should not entertain code or config changes from research or learning activities, so that development systems are reasonably representative of production systems.

• Production support and project release activities must be supported– Balance the risks and costs of separate environments for projects and minor production

fixes so that major project schedules aren’t disrupted by production support changes

• Service-level requirements affect environment design– 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

• Balance cost with end-user perception– Problems with a user-facing system hurt adoption, including training scripts that fail during

training classes because of concurrent development in the trainees’ system

• Provide business continuity in the event of a disaster

6

SAP Environments and Development Pathways (Logical View)

Most, not all, applications will follow this pathway

7

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

8

Contents

Introduction






9

SAP System Instances

SID SAP System Instance SAP Modules Notes

xEC ERP – Core financials business app FI, MM, IS-Retail, FSCM, GRC agents, SLD

xBW BI-DW – Data warehouse NetWeaver BI ABAP components, POSDM

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

xBI EP-BI – Portal for analysis & reporting NetWeaver BI Java components, SLD

xBA BIA – Data warehouse accelerator BIA Intel Linux appliance; no database

xBX BEx Broadcaster– Report distribution BEx Broadcaster svc, Microsoft Office Windows Server only; no database

xPF EP – Federated portal for user logon NetWeaver EP, SLD Not yet in scope

xIN PI – Integration middleware NetWeaver PI, Conversion Agent, SLD

xSM SolMan – TTS business app Solution Manager, Solution Manager Enterprise Edition, SLD

xGR GRC – Governance, Risk, Compliance Access Control & Process Control All 4 Access Control components

xDI NWDI – Source control and build for J2EE and EP development

NWDI Not yet in scope

xJV WebAS Java – Custom development NetWeaver WebAS Java, SLD 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

10

SAP Applications (System Instances)

SAP System Instance Business Purpose

SAP ERP Most of the financial transaction processing: G/L, A/P, A/R, Treasury, etc.

SAP BI – Data warehouse system SAP’s data warehouse, financial planning transactions, and cleansing & aggregation of point-of-sale data

SAP EP/BI – Portal Many of the reporting features for SAP Business Intelligence

SAP BIA – Business Intelligence Accelerator

A network appliance that speeds up queries against the SAP data warehouse by ~100x.

SAP BEx Precalc service The application that interacts with Microsoft Office to generate spreadsheet-based reports. This runs on a Windows Server.

SAP PI Integration middleware, used to expose SAP’s interfaces as services so that non-SAP systems can be integrated.

SAP System Landscape Directory An application management server required by Solution Manager, SAP PI, and SAP EP.

SAP TDMS 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.

SAP online help Serves up context help for user interfaces

11

SAP Applications (System Instances)

SAP System Instance Business Purpose

SAP Solution Manager 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 TTS’s infrastructure tools.

SAP GRC Workflow management server for the SAP Governance Risk & Compliance module, which centrally manages authorizations and other SOX controls.

SAP NWDI Source control and build server for custom development in SAP EP and any custom J2EE development that we do on SAP’s Java application servers. Most of this work will be done in WebSphere, but there will likely be some one-offs that, for tactical reasons, need to be deployed on SAP.

SAP WebAS Java Application server to run any custom J2EE development that has to be deployed (for tactical reasons) on the SAP platform.

SAP EP federated portal 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.


12

SAP System Instances – Environment Matrix

SID

SA

P

Sys

tem

Extras

Develo

p

Fu

nct. T

est

Stag

e

Pro

du

ction

MD

HA

/DR

San

db

ox

Train

ing

Pro

ject D

ev

Pro

ject T

est

xEC ERP – Core financials business app -

xBW BI-DW – Data warehouse -

xBI EP-BI – Portal for analysis & reporting -

xBA BIA – Data warehouse accelerator - *1 *1 *1 *1 - - *1 *1

xBX BEx Precalc Service – Excel - *2 - - *2

xIN PI – Integration middleware - -

xSM SolMan – TTS business app - - - - -

xGR GRC AC & PC server components *4 - - - -

-- SAP online help - - - - - - - - -

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 don’t 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.


13

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

14

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

• All software versions will be locked down 4 weeks prior to FIT 1– 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.

15

Contents

Introduction






16

Purpose of Transports & Clients in SAP

Transport• A “Transport” is the container SAP uses to package modified code

and/or configuration. SAP’s 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 can’t be displayed when you’re logged into another client.

17

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

18

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

19

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.

20

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

21

Client Strategy: Core SAP ERP

DECDevelop / Unit Test

QECTest

PECProduction

XECSandbox

SECStage

110Config & DevGolden Client

100Unit Test

120Unit Sandbox

000 / 066BASIS

000 / 066BASIS

000 / 066BASIS

000 / 066BASIS

000 / 066BASIS

100Sandbox

100E2E

(Permanent FIT)

120FIT 1

110Golden Client

(Locked)

100Permanent

Regression Test

100ERP

Production

RECTraining

100User Practice

110Training Image

121Training 1

000 / 066BASIS

140Conversion

Unit Test

150Data Refresh

122Training 2

See also: Master Data clients next page

•Client “100” is assigned to the client that most users log into, as it’s easier to remember

140FIT 2

150Data Refresh

= Transport Path

Transportsnot

permitted

123Training 3

124Training 4

130GRC PC FIT

(Open)

22

Client Strategy: Core SAP ERP


QECTest

PECProduction

XECSandbox

SECStage

210MDM Config

& DevelopmentGolden Client

200MDM Unit Test

220MDM Sandbox

200Permanent MDMRegression Test

200MDM

Production

RECTraining

240Conversion

MDM Unit Test

200MDM E2E

(Permanent FIT)

220MDMFIT 1

210Golden Client

(Locked)

240MDMFIT 2

250MDM

Data Refresh

200User Practice

210Training Image

221Training 1

222…Training 2

Use client100

(no MDMclient)

250MDM

Data Refresh

= Transport Path

• The only crossover in transport paths between Financials and MDM is ABAP code, which is client-independent. MDM-related ABAP code will still be developed and released in Client 110.

Transportsnot

permitted

23

XEC Client Usage

• 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 Target’s 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:

• 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 Target’s 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.

XECSandbox

000 / 066BASIS

100Sandbox

Transportsnot

permitted

24

DEC Client Usage

• 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 they’re 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


110Config & DevGolden Client

100Unit Test

120Unit Sandbox

000 / 066BASIS

140Conversion

Unit Test

150Data Reimage

25

DEC Master Data Client Usage

• 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


210MDM Config

Golden Client

200MDM Unit Test

220MDM Sandbox

240Conversion

MDM Unit Test

250MDM

Data Refresh

26

QEC Client Usage

• 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.

QECTest

000 / 066BASIS

100E2E

(Permanent FIT)

120FIT1

110Golden Client

(Locked)

140FIT 2

150Data Refresh

130GRC PC FIT

(Open)

27

QEC Master Data Client Usage

• 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.

QECTest

200MDM E2E

(Permanent FIT)

220MDMFIT 1

210Golden Client

(Locked)

240MDM FIT 2

250MDM

Data Refresh

28

SEC Client Usage

• 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.

SECStage

000 / 066BASIS

100Permanent

Regression Test

29

SEC Master Data Client Usage

• 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.

SECStage

200Permanent MDMRegression Test

30

REC Client Usage

• 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.

RECTraining

100User Practice

110Training Image

121Training 1

122…Training 2

200User Practice

210Training Image

221Training 1

222…Training 2

000 / 066BASIS

31

PEC Client Usage

• 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

PECProduction

100ERP

Production

200MDM

Production

000 / 066BASIS

32

Client Strategy: Other ABAP Systems

DxxDevelop / Unit Test

QxxTest

PxxProduction

XxxSandbox

SxxStage

100Unit Test

000 / 066BASIS

000 / 066BASIS

000 / 066BASIS

000 / 066BASIS

000 / 066BASIS

100Sandbox

100Functional

Test

100Regression

Test

100Production

RxxTraining

100User Practice

000 / 066BASIS

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.

33

Contents

Introduction






34

Performancestatistics

SNMPNetwork

Monitoring

ABAP/J2EE Engines

EarlyWatchAlerts(KPIs)

CCMSAgents(errors)

ABAP + J2EE

CCMSSAP SolutionManager

ABAP

SAP NetWeaverBI (on SM box)

ABAP

SAP NetWeaverBI (on SM box)

NetWeaverAdministrator

. . . . . . . . . . . .

ApplicationSystems

MonitoringLayer

Analytics Layer

GRMG

Central Admin Services Architecture

Technical & KPI Monitorsand Notification Services

Performance & Service LevelReports & Trends

CentralAdministration

35

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

Decision Tree Source: SAP

Recommendation: Master/Slave configuration• System Landscape Directory design is covered by detailed design documents outside the scope of this strategy.

36

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

37

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

38

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

SAPWebAS(Solaris)

SAPWebAS(Solaris)

SAPGUI

SAPHelp

(Windows)

SAPHelp

(disaster)

TTC TTC-E

Diagram is conceptual

Disk mirror

39

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 3 rd 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)

ContentMgmt

(non-SAP)

SAPWebAS(Solaris)

ADK DART IRS archivesArchived Database Data

ArchiveLink Archived attachments& image files

O/S Scripts Archived log files

40

Contents

Introduction






41

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 system’s

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.

42

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 Production Solution Manager SCS instance– fsspsmers Production Solution Manager enqueue replication service– fsspsmdb00 Production Solution Manager database instance– fsspsmap00 Production Solution Manager CI– fsspsmap01 Production Solution Manager DI #1– fsspsmap02 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.

43

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 system’s 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 Production ERP system– XIN Sandbox PI integration server– CBA Pre-production BIA server– QPF Functional testing Enterprise Portal federation server– PSM Production Solution Manager– DI1 Additional development system for PI integration server to support a project– QE1 Additional test system for the core ERP system to support a project– PIW 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.

44

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 SAP’s reserved names. See any SAP installation guide for the list of reserved names.

45

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.

46

Standard: SAP Client Numbers

Clients in core ERP, BW, and PI Master data clients in ERP

100 = Production

100 = Client used by the most end users (unit test, enduring FIT, sandbox, …)

1xx = Other clients in ECC

200 = Production

200 = Primary end-user client (unit testing, enduring FIT, etc.)

2xx = Other clients in ECC

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 they’re 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 they’re in the correct client.

Systems will be configured to default to the most-frequently-used client (e.g. Client 100 in production).

Master data clients subject to finaldetermination of MDM approach

47

Documents

SAP Landscape Design - V24