sap landscape design - v24
TRANSCRIPT
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
Environment Strategy
SAP System Instance Strategy
SAP Application Transport & Client Strategies
SAP NetWeaver Component Strategies
BASIS Naming Standards
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
Environment Strategy
SAP System Instance Strategy
SAP Application Transport & Client Strategies
SAP NetWeaver Component Strategies
BASIS Naming Standards
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.
= Will not be installed at the present time
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.
= Will not be installed at the present time
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
Environment Strategy
SAP System Instance Strategy
SAP Application Transport & Client Strategies
SAP NetWeaver Component Strategies
BASIS Naming Standards
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
DECDevelop / Unit Test
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
DECDevelop / Unit Test
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
DECDevelop / Unit Test
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
Environment Strategy
SAP System Instance Strategy
SAP Application Transport & Client Strategies
SAP NetWeaver Component Strategies
BASIS Naming Standards
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
Environment Strategy
SAP System Instance Strategy
SAP Application Transport & Client Strategies
SAP NetWeaver Component Strategies
BASIS Naming Standards
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