Spacely Sprockets Technical Infrastructure Document

Spacely Sprockets
Technical Infrastructure Document

1. GENERAL INFORMATION....................................................................................1
1.1 Company Data..........................................................................................................................................4
1.2 Locations...................................................................................................................................................4
1.3 Change History.........................................................................................................................................4
2. SAP SYSTEM & CLIENT LANDSCAPE............................................................5

2.1 SAP System Landscape Overview...........................................................................................................5
2.2 SAP Three System Landscape.................................................................................................................5
2.3 Two-Tier, Three-Tier and Three-Tier Distributed SAP Instance Setup..............................................5
2.4 SAP System & Client Landscape Diagram Redraw to show each landscape horizaontally (R/3, CRM, APO, BW) Transports Paths go from Dev to
QAS, QAS to Prod. Showing DEV path directly to PROD is misleading. The diagram of the SAP Landscape does not require every server at each layer to be
displayed...................................................................................................................................................................6
2.5 SAP Clients...............................................................................................................................................7

2.5.1 R3D Clients.........................................................................................................................................7
2.5.2 R3Q Clients.........................................................................................................................................8
2.5.3 R3P Clients..........................................................................................................................................8
2.5.13 Client Refresh Procedures...................................................................................................................9
3. NETWORK ENVIRONMENT...............................................................................10
3.1 Network Topology Diagram...................................................................................................................10
3.1.1 Wide Area Network..............................................................................................................................10
3.1.2 Local Area Network.............................................................................................................................10
3.1.3 SAP Network........................................................................................................................................10
3.2 Network Systems.....................................................................................................................................11
Copyright 2000 SAP AG. All rights reserved 1

Spacely Sprockets
4. SYSTEM ENVIRONMENT...................................................................................13
4.1 SAP Systems Overview...........................................................................................................................13
4.2 R/3 Enterprise Landscape....................................................................................................................13

4.2.1 R/3 Development Environment Overview..........................................................................................13
4.2.2 R/3 Quality Assurance Environment Overview..................................................................................14
4.2.3 R/3 Production Environment Overview..............................................................................................15
5. DESKTOP ENVIRONMENT.................................................................................18
5.1 Desktop Environment Overview...........................................................................................................18
5.2 Desktop Technical Requirements..........................................................................................................20
6. INPUT & OUTPUT DEVICES..............................................................................21

6.1 Device Overview......................................................................................................................................21
6.2 Output Devices........................................................................................................................................21

6.2.1 Printing................................................................................................................................................21
6.3 List of Input Devices..............................................................................................................................22

6.3.1 Input Devices.......................................................................................................................................22
6.4 Output Environment...............................................................................................................................24
6.5 Input Environment..................................................................................................................................24
7. SAP SOFTWARE INSTALLATION..................................................................25

7.1 SAP Software Installation Overview.....................................................................................................25
7.2 Installation of the SAP R/3 Instances....................................................................................................26
7.3 Installation of other SAP Software........................................................................................................26

Spacely Sprockets
7.3.1 Installation of SAP Portals...................................................................................................................26
7.3.2 Installation of SAProuter.....................................................................................................................26
7.3.3 Installation of SAP Connector.............................................................................................................26
7.3.4 Installation of Solution Manager.........................................................................................................26
8. CHANGE AND TRANSPORT SYSTEM (CTS)...................................................27

8.1 CTS Overview.........................................................................................................................................27
8.2 Transport Domains................................................................................................................................28

8.2.1 R/3 Change Transport Management System.......................................................................................28
8.3 Transporting Changes within a SAP Instance.....................................................................................28
8.4 Transporting Changes across SAP Instances.......................................................................................28

8.4.1 Ownership and Schedule for Transportation of Change Requests......................................................29
8.4.2 Releasing Change Requests for Population in the SAP Quality Assurance System...........................29
8.4.3 Moving Changes from the Quality Assurance System to the Production System..............................29
8.4.4 Post-Processing of Change Requests...................................................................................................30
8.4.5 Notification of Completed Transport Run to Core Team Members....................................................30
8.5 Change Request Standards...................................................................................................................30
9. SECURITY USERS AND ROLES................................................................32

9.1 Security Overview...................................................................................................................................32
9.2 Users.........................................................................................................................................................32
9.2.1 R/3 Users..............................................................................................................................................32
9.2 Central User Administration.................................................................................................................32
10. SYSTEM MAINTENANCE...............................................................................33

10.1 System Maintenance Overview.............................................................................................................33
10.2 Support Packages....................................................................................................................................33

Spacely Sprockets
10.3 Kernel Patches........................................................................................................................................33
10.4 Upgrades..................................................................................................................................................33
11. BACKUP AND RECOVERY.............................................................................34

11.1 Backup.....................................................................................................................................................34
11.1.1 Backup Overview............................................................................................................................36
11.2 Recovery...................................................................................................................................................37
11.2.1 Restore After Disk Failure.....................................................................................................................37
11.2.5 Restore after User Fault..........................................................................................................................38
11.2.6 Restore after Database Corruption.........................................................................................................38
11.2.7 Move to Different Hardware..................................................................................................................39

Spacely Sprockets
1. General Information
1.1 Company Data

Company name :
SAP customer number :
Responsible :
Document Version :
1.2 Locations
Data Center :
Users :
1.3 Change History
Date Name Description of Changes

Spacely Sprockets
2. SAP System & Client Landscape
2.1 SAP System Landscape Overview
The Spacely Sprockets project will implement one SAP components: R/3 Enterprise 4.7 Extension Set 2.00 (R/3).
Spacely Sprockets will purchase Dell Windows using servers for its Development and Quality Assurance instances and
IBM eServer xSeries servers for Production instances. IBM will be the vendor of choice for obtaining SAN storage arrays.
The OS of choice is Windows 2003 and the database will be MS SQL Server 2000.
Further implementation will create the need for servers to support Portals so ESS (Employee Self-Service) and MSS
(Manager Self-Service) subsystems can be used.
2.2 SAP Three System Landscape
Spacely Sprockets has elected to implement the SAP recommended Three System Landscape. This landscape provides
for a Development system, a Quality Assurance system, and a Production system in a separate, self-contained
environment.
A three system landscape provides the maximum protection for isolating destructive changes, allows developer
testing without impacting the performance of other systems, and provides more flexible user training.
The following is a diagram of the typical SAP three system landscape:
Quality
System
Develo
pment
Assurance Production
System System
2.3 Two-Tier, Three-Tier and Three-Tier Distributed SAP Instance Setup
Spacely Sprockets will be implementing a combination of two-tier, three-tier and three-tier distributed setups. Low use,
low priority systems such as the Development system will be installed with the Database Instance (DB), Central Instance
(CI), and Dialog Instance (DI) installed on one server while mission critical systems like the Production environment may
be spread across two or more servers. The last layer of the tier is always the presentation layer, which can either be
SAPGUI for Windows, SAPGUI for Java, or SAPGUI for HTML. This is the diagram of the SAP Tier System:

Spacely Sprockets
2.4 R/3 Enterprise Instances with Host Names
system # system description Hostname of CI SAP installation number

name
00 R3D R/3 Development System sttxsapd01 0020190495
00 R3Q R/3 Quality Assurance sttxsapq01 0020190495
System
00 R3P R/3 Production System sttxsapdb01 0020190495
2.5 SAP Clients

2.5.1 R3D Clients
Clien Purpose currenc categor client- client-

t# y y dependent independent
settings settings

Spacely Sprockets
100 Referred to as the Golden USD No Changes No Changes
Client. All other clients Allowed Allowed
were created from this one.
No configuration will be
entered in the Golden
Client. The Golden Client
will receive Transports from
the Configuration Client.
The only exception to this is
that client 100 will be the
parent client for CUA and
will contain all users, roles,
and profiles for R3D Client
200 and R3P Client 300.
Future client copies will

originate from this client.
110 Sandbox Client. The USD Changes No Changes
functional team will use this allowed No Allowed
client to test various Tracking
configuration options.
This client is created from a

client copy of 100 and will
be refreshed as needed.
120 Configuration Client. USD Changes Cross-Client
This will be the Allowed Configuration
Configuration Client. All Automatic Allowed
configurations will be Tracking
created in this client.

Spacely Sprockets
130 ABAP Client. This client USD No Changes Repository
is for the sole use of the Allowed Changes
ABAP development team. Allowed
They will do all of their
development and testing
from this client.
2.5.2 R3Q Clients
Client Purpose currency category client-dependent client-

# settings independent
settings
200 Golden QAS Client USD No Changes Allowed No Changes Allowed
210 GoldenConfigurationClient USD No Changes Allowed No Changes Allowed
This Client will be created from the Golden QAS

Client and contain the data required for executing
Integration Tests.
220 Training Refresh Client USD No Changes Allowed No Changes Allowed
Client containing Good Training Data.

221 Training Client USD No Changes Allowed No Changes Allowed
2.5.3 R3P Clients
Client Purpose currency category client-dependent client-

# settings independent
settings
300 Production Live Client. This is the production USD No Changes Allowed No Changes Allowed
client for R/3.
It will be created based on the Production Build

Specification yet to be written. This Specification
will outline the process to build Production based
on the Transports used to build the QAS Clients
during testing.

Spacely Sprockets
2.5.13 Client Refresh Procedures
Source target client copy justification frequency reference #

system/client system/client profile in diagram

Spacely Sprockets
3. Network Environment
3.1 Network Topology Diagram

3.1.1 Wide Area Network
Information not yet available.
3.1.2 Local Area Network
3.1.3 SAP Network
3.1.3.1 SAP Router Documentation
SAProuter is a software router provided by SAP to communicate between SAP systems and SAP Support (formerly
known OSS). In the past, SAProuter was only available to clients willing to invest in the hardware and
implementation costs of X.25, frame relay, etc. connections. In the past few years, however SAP has adopted
technology to allow VPN communication with its clients via the internet. However SAP still has very exactly
protocol requirements due to security, and must be FAXed information as the clients expected means of
communication. This information includes client server and VPN IP addresses, type of router, etc.
You must use SAProuter to control and log the connections between SAP and your R/3 System. SAProuter is used
at SAP Active Global Support.

Spacely Sprockets
3.1.3.2 SAProuter Hardware
SAProuter will be installed on a Dell Model 2650 2.4Ghz-Dual-512K 1GB-2D which it will share with a SAP Web AS
instance supporting Solution Manager. The SAProuter table will be resides on the same server.
The denied and permitted routes and IP addresses have yet to be determined.
3.2Network Systems
Purpose IP address hostname vendor model operating system

4. System Environment
4.1 SAP Systems Overview
4.2 R/3 Enterprise Landscape
4.2.1 R/3 Development Environment Overview
This is the Development environment for SAP R/3.
4.2.1.1 R3D Servers Hardware & Software Specifications

R3D - system configuration database instance and central instance.
Specifications Comments
Hardware Vendor Dell
Model PowerEdge 2650
CPU-Qty-Cache 4x 3184 Mhz
RAM 4GB
Raid Drives
Network IP address 10.2.5.10
Host name sttxsapd01
Domain Name
Static Routing
Network Services
OS Vendor Microsoft
Version Windows 2003
Patch Level
Code Page US_ENG
Software SAP SAP SID R3D
SAP System # 00
Component Release 4.70 SR 1
Basis Release 6.20
Kernel Patch Level Most current
Hot Pack / LCP # Most current
Code Page 1100
DBMS Vendor MS SQL Server
Version 2000
Patch Level 3a
Code Page 1100
4.2.1.2 OS-Users
Applicatio User Name Uid Group Name

n
All R3dadm R3dadm Local User
SAP_R3D_GlobalAdmin
All SAPServiceR3D SAPServiceR3D Local User
SAP_R3D_GlobalAdmin
4.2.1.3 File Directory Structure
Directory Purpose Size [GB]

Spacely Sprockets
C:\Program Files\Microsoft SQL Server MS SQL Server
Executables
F:\TEMPDB MS SQL Server TEMPDB
E:\usr\sap\R3D SAP R/3 Executables
\\sttxsapd01\sapmnt\trans R/3 Transport Directory
G:\R3DDATA1 SAP Database Data
F:\R3DLOG1 SAP Database Log Data
4.2.2 R/3 Quality Assurance Environment Overview
This is the Quality Assurance environment for SAP R/3.
4.2.2.1 R3Q Servers Hardware & Software Specifications
R3Q - system configuration database instance server

Hardware Vendor Dell
Model PowerEdge 2850
RAM 2GB
Raid Drives
Host name sttxsapq01
Domain Name
Static Routing
Network Services
OS Vendor Microsoft
Patch Level
Code Page US_ENG
Software SAP SAP SID R3Q
SAP System # 00
Basis Release 6.20
Code Page 1100
Version 2000
Patch Level 3a
Code Page 1100
4.2.2.2 OS-Users
Applicatio User Name uid Group Name

n
All R3qadm R3qadm Local User

Spacely Sprockets
SAP_R3Q_GlobalAdmin
All SAPServiceR3Q SAPServiceR3Q Local Users
SAP_R3Q_GlobalAdmin

Executables
F:\TEMPDB MS SQL Server TEMPDB
E:\usr\sap\R3Q SAP R/3 System Files
\\sttxsapd01\sapmnt\trans R/3 Domain Transport
F:\R3DDATA1 SAP Database Data
E:\R3DLOG1 SAP Database Log Data
4.2.3 R/3 Production Environment Overview
This is the Production environment for SAP R/3.

4.2.3.1 R3P Servers Hardware & Software
Specifications
PRD - system configuration database instance and central instance server
Hardware Vendor IBM
Model eServer xSeries
346
RAM 4GB
Raid Drives
Host name sttxsapdb01
Domain Name
Static Routing
Network Services
OS Vendor Microsoft
Patch Level
Code Page US_ENG
Software SAP SAP SID R3P
SAP System # 00
Basis Release 6.20
Code Page 1100

Spacely Sprockets
Version 2000
Patch Level 3a
Code Page 1100
PRD - system configuration application instance server
Hardware Vendor IBM
Model eServer xSeries
336
RAM 4GB
Raid Drives
Host name sttxsapp01
Domain Name
Static Routing
Network Services
OS Vendor Microsoft
Patch Level
Code Page US_ENG
Software SAP SAP SID R3P
SAP System # 00
Basis Release 6.20
Code Page 1100
Version 2000
Patch Level 3a
Code Page 1100
4.2.3.2 OS-Users
Applicatio User Name uid Group Name

n
All R3padm R3padm Local User
SAP_R3P_GlobalAdmin
All SAPServiceR3P SAPServiceR3P Local Users
SAP_R3P_GlobalAdmin

Executables
E:\TEMPDB MS SQL Server TEMPDB
D:\usr\sap\R3P SAP R/3 System Files

Spacely Sprockets
\\sttxsapd01\sapmnt\trans R/3 Domain Transport
G:\R3PDATA1 SAP Database Data
E:\R3PLOG1 SAP Database Log Data

Spacely Sprockets
5. Desktop Environment
5.1 Desktop Environment Overview
The SAP Presentation software comes in three version: SAPGui for

Windows, SAPGui for Java, and SAPGui for HTML. At this time, SAPGui 6.20
Compilation 3 is the most current version.
SAP does an excellent job of working with software partner Microsoft to

keep up with new Windows technology. A matrix of the supported SAPGui
Windows OS follows.

Spacely Sprockets

Spacely Sprockets
5.2 Desktop Technical Requirements
SAP has exacting technical specifications for workstations supporting SAPGui. These
specifications vary depending on the operating system, patch level of the operating
system, and SAP components to be accessed via the SAPGui instance.
In order to use the most current version of SAPGui which is SAPGui 6.40 Patch Level 4, the
following criteria must be met.
OS OS Service IE IE Service Memo Monitor/Resolu Proces

Pack Pack ry tion sor
Win ME 5.5 64 MB 17 - 1024 x 768 P233+

Win 5.5 64 MB 17 - 1024 x 768 P233+
2000
Win XP 5.5 64 MB 17 - 1024 x 768 P233+
NT 4.0 Service Pack 5.5 64 MB 17 - 1024 x 768 P233+
4

Spacely Sprockets
6. Input & Output Devices
6.1 Device Overview
6.2 Output Devices

6.2.1 Printing
SAP breaks down printer into three categories: local printing, front-end printing,
and remote printing. Local printing is the fastest print method.
Spacely Sprockets will provide a list of all local and remote printers at all supported
locations with IP address, printer model, etc. to be added to SAP. These printer will
be added in the SAP Development systems and ported into the Quality Assurance
and Production environments.
6.2.1.1 Local Printing
When you print locally, the SAP spool process sends the data to a printer that is set
up on the operating system of the application server. The print request is then
forwarded from the spool system of the operating system to the relevant printer.
You can connect the printer locally to the computer or you can access it over the
network.
6.2.1.2 Remote Printing
The SAP spool process can access any printing system in the network that can
handle the lpr/lpd protocol. This protocol originates from BSD UNIX and is an
industry standard for controlling printing. It is supported by many modern
operating systems and by network-enabled printers.
The line printer requester is a client and sends the print data to the server (lpd
side). Using this protocol, various data formats, for example, PostScript or PCL can
be transmitted.
Window PCs do not usually have a line printer daemon (lpd). To be able to print
using lpr/lpd, SAP developed its own lpd program for PCs called SAPlpd, which is
installed with the SAP frontend. SAPlpd contains some extensions of the lpd

Spacely Sprockets
protocol, for example, data compression, encryption using the SAP standard SNC,
and data transmission using the SAProuter.
Remote printing is the slowest way to print from SAP. Unfortunately, most of the
hand-held output devices will need to be used via remote printing.
6.2.1.3 Front-End Printing
Another option when printing from the SAP System is front-end printing, which lets
you access printers that are not defined in the SAP spool system.
The output data is transmitted directly over the SAPGui to the front-end PC. To do
this, the existing connection between the SAPGui and the application server is used,
so that an additional network connection is not required. The SAPGui starts SAPlpd
on the front-end PC and transmits the print data to it. SAPlpd then sends the data to
the Windows standard printer or to another printer installed on the operating
system.

Spacely Sprockets
6.3 List of Input Devices
6.3.1 Input Devices
Input # Vendor Model

Device

Spacely Sprockets
6.4 Output Environment
Output SAP SAP Spool OS Queue Device AccessM Usag Loca

Type Device Server or Print Type ethod e
Name name
Print
Fax
Email
Page
Barcode
6.5 Input Environment
Input Device Location Usage Server

Type Name
Barcode
Handheld
PDA

Spacely Sprockets
7. SAP Software Installation
7.1 SAP Software Installation Overview
SAP components must be installed as detailed in the SAP Technical Installation guide for
that component.
All installations will include the following steps:
Download of latest installation manual

Setup of Windows environment variables
Setup of Windows administration users
Setup of Windows server environment
Installation of J2EE Java SDK
Installation of Oracle 9.2 Database
Patching of the Oracle 9.2 Database
Installation of SAP Central Instance
Installation of SAP Database Instance
Installation of SAP Application Instance (only for systems with additional dialog
instances)
Validation of SAP Installation
Request and Installation of SAP License
Creation of Basis Support Team users
Configuration of Change and Transport System
Application of outstanding Support Packages
Import of Add-on components for OLTP and other plug-in support
Replacement of SAP Kernel
Mass regeneration of ABAP programs
Installation of SAP Online Documentation
Installation of additional languages
Client copy of client 000 to client 100
Loading the PCC
Refresh of database statistics
Creation of SAP_ALL limited role for Core Team Members
Creation of Core Team Member users
Creation of System users

Spacely Sprockets
Creation of RFC links between new instance and existing SAP instances
Creation of output devices
This document will not get into the specifics of these or any other installation steps as the
SAP installation procedures are a constantly changing and evolving technology. The latest
version of the installation manuals can be downloaded from
http://service.sap.com/instguides.
7.2 Installation of the SAP R/3 Instances
Spacely Sprockets will be installing SAP R/3 Enterprise 4.70 SR 1 on Windows 2000 using
Oracle 9.2.
The installation will consist of a database instance and a central instance, plus an
additional dialog instance for R3P. For the R3D environment, all three instances will be
installed on one server. For the R3Q environment, the database will be installed on one
server with the central instance on another server. For the PRD environment, the database
instance, central instance, and application instance will be installed on separate servers.
Spacely Sprockets has elected to implement the following R/3 Enterprise Core products:
<I dont know this information>
7.3 Installation of other SAP Software
Spacely Sprockets has elected to install a number of additional components and

component extensions.
7.3.1 Installation of SAP Portals
This information is not yet available.

7.3.2 Installation of SAProuter

7.3.3 Installation of SAP Connector

7.3.4 Installation of Solution Manager

Spacely Sprockets
8. Change and Transport System (CTS)
8.1 CTS Overview
The SAP system includes a collection of tools closely linked to the ABAP workbench and the
customizing functions, which are very important for managing and coordinating development and
customizing work within a group of SAP systems. These tools form the overall Change and
Transport System (CTS).
The CTS components are in charge of performing essential functions in the overall development
and customization environment, and thus in the implementation process as well as in the
operation and support after productive start.
Among the functions of the different CTS tools are:
Administration and control of new development requests

Modification and correction of repository objects
Recording and auditing of all configuration settings and changes
Configuration of development classes
Locking of objects to avoid parallel work
Version management
Documentation of changes
Assurance of teamwork development
Transporting of objects and settings changes among systems
Logging of transport results
Setting the system change options
Recording of where and by whom changes are made
Configuration of the systems landscape
Integration of the CTS into the SAP landscape is dependent on the correct configuration of the
whole transport chain. The following summary guideline provides the necessary steps for
configuring the transport system, although these steps only have to be performed once.
Configuration steps are made up of three basic tasks:
Configure the transport directory and TPPARAM. The transport directory \usr\sap\trans is
created by the installation program, and is unique within SAP system type. In other words,
a \usr\sap\trans directory is created for all R/3 instances but only one directory is the
controlling transport directory for all the R/3 instances. You have to make sure that this
directory can be accessed correctly among systems within a transport group. As of R/3
release 4.6, no manual configuration of TPPARAM is necessary.
Initialize the change and transport organizer (CTO). This is accomplished by transaction
SE06 and is one of the first tasks to perform after installation of the R/3 system.
Create a default development class. To be able to transport development objects, you
must define a class which is not local (such as $TMP) or for test purposes (all starting with
T). You should define the development class in the range allowed for customers, starting
with Y or Z.
Configure transport systems and routes. This configuration step is performed using
transaction STMS. Configuration using transaction STMS should be performed in client 000
of the transport domain, that is the SAP instance controlling the flow of transports.
Spacely Sprockets will use the standard three systems in a group recommended by SAP, following
the design below. Please note that the Delivery route is determined by the functional team once
standards for Change Release and Approval have been designed.

Spacely Sprockets
Transport
Developme
ZXXX
Quality Assurance Production
System
System System
nt
SAP Delivery
8.2 Transport Domains

8.2.1 R/3 Change Transport Management System
R3D will be the CTS domain controller for the SAP R/3 landscape. All R/3 transport cofiles,
data files, logs, etc. will be stored in the \usr\sap\trans directory created during the
installation of the R/3 R3D system. It is mandatory that the R3D \usr\sap\trans directory be
accessible by the other R/3 instances, R3Q and R3P, as well as any application servers
dedicated to R/3 added later.
Change request creation will be limited to the R3D 100 and 130 clients.
The ZR3D transport layer will be used to facilitate transport flow from R3D to R3Q and R3P.
Transport
ZR3D
R3Q R3P
R3D
SAP Delivery
8.3 Transporting Changes within a SAP Instance
Change requests may be migrated by users between certain clients in the SAP Development
system R3D using transaction SCC1. The transports do not need to be released before this
migration can be done.
8.4 Transporting Changes across SAP Instances
Change requests are moved from the Development instance R3D to the Quality Assurance
instance R3Q automatically. Once transports are released from in instance R3D, they are
automatically added to the R3Q import queue. A job is scheduled to import these changes into
the R3Q instance every 15 minutes. The transports in the R3Q import queue go to clients 200 and
210.
Before a change can be imported into the Production R3P instance, it must be approved using the
STMS_QA transaction by:
The system administration

The request owner
The department head

Spacely Sprockets
Once all three of these roles have approved the transport, a job running daily at 7pm will move
the change requests into client 300 of R3P.
8.4.1 Ownership and Schedule for Transportation of Change Requests
The Basis Support team will perform all manual transports across SAP instances.
Transports will occur between the SAP Development R3D instance and the R3Q instance
every 15 minutes. This schedule is subject to change.
Special requests for transports outside of the normally scheduled times will be performed
due to emergency situations only (ie a Production system is crashing, etc.) Poor planning is
not an emergency.
Change requests will be transported across instances at these times:
R3D R3D Client 100 6am and 6pm daily

R3D R3Q Client 200 Every 15 minutes
R3Q Client 210
R3Q R3P Client 300 7pm daily
8.4.2 Releasing Change Requests for Population in the SAP Quality Assurance System
The owner of the change request, or a member of the Core Team designated to this task by
one of the project managers, will release the change request when it is ready to go into the
R3Q Quality Assurance system. Releasing change requests are not the responsibility of the
Basis Support Team. Once the Change Request is released in the R3D Development
system, it will automatically be sent to the transport queue of the R3Q Quality Assurance
system. Any change request appearing in the queue of the SAP Quality Assurance system
will automatically be transported during the next scheduled transport run. More than one
entry per change request will appear in the import queue due to movement to multiple
clients in R3Q.
Developers need to be cognitive of the fact that transports are moved into R3Q Quality
Assurance and R3P Production systems in the order that they appear in the transport
queue (ie in the order in which they were released). If any change requests must be run in
a specific order, the Basis Support Team must be notified BEFORE the change requests
have been released in order to prevent improper transport.
8.4.3 Moving Changes from the Quality Assurance System to the Production System
All Change Requests must be approved by both the functional group team leader and a
project manager before being moved into the R3P Production environment. The approval
process is in the hands of the Core Team and can be inserted here at a later date. In order
to insure that the Production environment correctly matches the environment where
changes were tested, an approval for production Change Request may be delayed pending
approval of prior Change Requests.
Approval for moves into Production can be either a transactional or written process. SAP
supplies the STMS_QA transaction to facilitate the approval process. This transaction can
be configured to meet Spacely Sprockets needs. If a written approval form is to be used,
the form will need to take into account the 4 component nature of the Spacely Sprockets
landscape.
The following page contains an example of a Change and Transport Request Form.

Spacely Sprockets
Here is a sample Change Request Approval form:
Change and Transport Request Form
Before Production Exists
Requestor Date
Source Client Target Client(s)
Source R/3 System R3D Target R/3 R3P

System
Change Request # Type of Change
Customizing Client-dependent
Workbench Client-independent
Description of
contents
Tasks/Request Change request released All tasks released To be
released
Special
Requirements
Approved by
(please sign)
IT Team USE ONLY
Imported by Date
Transport Log 0 Transport (export and import test) was successful.
Return Codes 4 Warning messages were generated.
8 Error messages were generated.
12 Fatal error has occurred.
Comments
Exception handling Date

- Corrected change Reason
request #
Project Date
Management
Approval
8.4.4 Post-Processing of Change Requests
Change requests can require post-processing after successfully being moved to a target
SAP system. While the Basis Support Team will make every effort to intercept non-zero
return codes generated from a transport run, it must be remembered that a return code of
4 often happens and is commonly ignored. It is ultimately the responsibility of the Core
Team member owning the change request to verify the proper transportation of the change
and to notify the Basis Support Team if assistance is needed with any post-processing
instructions.
8.4.5 Notification of Completed Transport Run to Core Team Members
At the end of each business day, the Basis Support Team will distribute a list of Change
Requests transported that day. This list will be distributed via e-mail using a Spacely
Sprockets distribution list.
8.5 Change Request Standards

Spacely Sprockets
Change Requests generated by Core Team Members must be attached to a development class
supported by the ZXXX transport layer. These transport layers are:
ZR3D R/3 Development System

SAP SAPs Standard Transport Layer
The description entered at the time of the Change Request creation must follow the following
standard:
WWW: XX: YYY: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Where:
WWW is the initials of the owner of the change request
XX is the 2 letter abbreviation of the component
YYY is the client where the change request was generated
ZZZ... is a short description of the change made
Example:
JCS: BC: 000: Application of OSS Note 752052 FI Fix for GL

Spacely Sprockets
9. Security Users and Roles
9.1 Security Overview
All SAP users will be assigned roles matching their respective job assignments. These roles
will be initially created by copying a standard SAP supplied role and modifying the copy to
match Spacely Sprockets needs. The authorization objects and authorizations contained in
each role will be designated by the Functional Team and implemented by the Basis Support
Team. All role and user configuration will take place in R3D Development instance client
100.
Once the roles have been created, users will be attached. Users and roles for R/3 will be
moved to the R3Q Quality Assurance system and imported into the Training Golden Client.
All users trained in SAP functionality will be required to use their real user IDs given to
them on the final day of user training. The users supervisor will be required to verify that
the user has shaken out their assigned role and can successfully perform all tasks for
which they have received training.
9.2 Users
9.2.1 R/3 Users
9.2.1.1 Core Team Users
R3D: Core Team Members will be assigned a security role designed to allow
them as much access as possible while still securing the R3D instance. At
this time 3 roles have been identified: core team leaders, core team
members, and ABAP programmers. These roles will to designed to facilitate
speedy configuration, customization, and development.
R3Q: Core Team Members will have the same authorizations as in the R3D
system.
R3P: Core Team Leads will have the same authorizations as in the R3D
system until post GoLive when they will be assigned to roles fitting their
regular SAP duties. Core Team Members, including Experio consultants, will
be assigned to a display only version of the SAP_ALL role.
9.2.1.2 Communication Users
Special communications users will be created in all three R/3 instances to

facilitate remote function calls between the SAP systems and to other
external non-SAP programs. These users are password protected but do not
require a SAP log on screen. These users will have all authorizations needed
to perform the specific tasks to which they are designed. Users ALEREMOTE,
WF_BATCH, RFC_USER, TMSADM and ITSUSER are included in this group.
Other communications users for SAP Portals, TREX, etc. will be added as
needed.
9.2.1.3 Basis Users
The Basis Support Team will be directly connected to the SAP_ALL and
SAP_NEW profiles. The SAP supplied users SAP* and DDIC will have their
passwords changed as soon as post-installation work as been completed.
9.2.1.4 Non-Core Team Users
All users outside of the Core Team must be assigned to a limited security role
in all R/3 systems.

Spacely Sprockets
9.2 Central User Administration
Spacely Sprockets will implement Central User Administration (CUA). R3D Client 100 will
be the parent client with R3Q Client 200 and R3P Client as children in the CUA model. The
Basis team will create and maintain this model using CUA specific transactions SCUA,
SCUM, and SCUL as well inbound and outbound RFC/ALE queue functions such as SMQS.
10. System Maintenance
10.1 System Maintenance Overview
SAP maintenance comes in the form of support packages and kernel replacements.
Support packages are changes and fixes to SAP ABAP code, and thus must be applied from
within the SAP instance using transaction SPAM in client 000 by a non-DDIC user.
Kernel patches are changes and fixes to SAP executable files stored on the operating
system of the SAP server. Kernel patches may require that the SAP instance be taken down
in order to replace programs in use when an instance is up. They are applied by a simple
file overwrite by the <sid>adm of the SAP instance.
It is important to note that it is in Spacely Sprockets best interest to install and maintain
one Basis version 6.20 and avoid having different Basis version combinations like 4.6D and
6.20. This will provide uniformity for moving changes between systems as well as making
the system maintenance process easier to perform.
10.2 Support Packages
All released support packages will be applied immediately after SAP system installation.
After initial installation, support packages will be installed every two months, and in an
emergency on demand. Application of support packages will be stopped six weeks before
GoLive and only SAP Notes application to correction known problems.
The support packages will be applied in the Development instance of the SAP landscape.
After one week, the support package will be applied to the Quality Assurance instance
following by installation in the Production instance a week after that.
Mass generation of all ABAP programs will be performed after every support package
application.
10.3 Kernel Patches
The newest kernel for the R/3 software will be downloaded and applied at installation time.
On other kernel patches will be done unless it is a SAP recommendation to resolve an issue.
A kernel patch will first be applied to the R3D Development instance of the SAP landscape.
As soon as the patch can be successfully tested, it will be moved into R3Q Quality
Assurance and R3P Production.
10.4 Upgrades
Upgrades to new versions of SAP software is not covered in the scope of this project.

Spacely Sprockets
11. Backup and Recovery
11.1 Backup
The database of a SAP system contains critical company data, which is protected by a
backup strategy. A backup strategy must be planned carefully to meet a company's
individual requirements and tested to see if it works.
An intact and current database backup is crucial for database recovery. Recovery time is a
critical factor as R/3 is primarily an online transaction processing application. The backup
strategy should clearly define procedures for fast restore and recovery.
The correct backup strategy is determined by the:
Data volume requiring backup
Tools available for backup
Time available for complete database recovery
There are two basic types of failure which require database recovery:
Media failure affecting particular data files, or the entire disk.
Logical failure, for example, inadvertently modifying or dropping a table.
For a MS SQL Server database, you need to back up the:
Data Files
Log Files
Hitachi Consulting has provided Spacely Sprockets with a DOS Batch file that will backup
the database and log files on each R/3 server. It consists of the following code:
@echo off
rem For R3D---Create a directory on <backup_server> called R3DBackup
if exist e:\usr\sap\R3D\SYS\exe\run\saposcol.exe (
net stop MSSQLSERVER
xcopy \\10.2.5.10\R3DDATA1\R3DDATA1.mdf \\<backup_server>\R3DBackup
/Q /H /S /Y
xcopy \\10.2.5.10\R3DDATA2\R3DDATA2.ndf \\<backup_server>\R3DBackup /Q /H
/S /Y
xcopy \\10.2.5.10\R3DDATA3\R3DDATA3.ndf \\<backup_server>\R3DBackup /Q /H
/S /Y
xcopy \\10.2.5.10\R3DLOG1\R3DLOG1.ldf \\<backup_server>\R3DBackup /Q /H
/S /Y
net start MSSQLSERVER
goto :AllDone
)
rem For R3Q---Create a directory on <backup_server> called R3QBackup
if exist e:\usr\sap\R3Q\SYS\exe\run\saposcol.exe (
xcopy \\10.2.5.11\R3QDATA1\R3QDATA1.mdf \\<backup_server>\R3QBackup
/Q /H /S /Y
xcopy \\10.2.5.11\R3QDATA2\R3QDATA2.ndf \\<backup_server>\R3QBackup /Q /H
/S /Y
xcopy \\10.2.5.11\R3QDATA3\R3QDATA3.ndf \\<backup_server>\R3QBackup /Q /H
/S /Y

Spacely Sprockets
xcopy \\10.2.5.11\R3QLOG1\R3QLOG1.ldf \\<backup_server>\R3QBackup /Q /H /S
/Y
)
rem For R3P---Create a directory on <backup_server> called R3PBackup
if exist e:\usr\sap\R3P\SYS\exe\run\saposcol.exe (
xcopy \\10.2.5.15\R3PDATA1\R3PDATA1.mdf \\<backup_server>\R3PBackup /Q
/H /S /Y
xcopy \\10.2.5.15\R3PDATA2\R3PDATA2.ndf \\<backup_server>\R3PBackup /Q
/H /S /Y
xcopy \\10.2.5.15\R3PDATA3\R3PDATA3.ndf \\<backup_server>\R3PBackup /Q
/H /S /Y
xcopy \\10.2.5.15\R3PLOG1\R3PLOG1.ldf \\<backup_server>\R3PBackup /Q /H
/S /Y
)
@echo "Don't know this server"
:AllDone
To increase fault tolerance, SAP and Microsoft recommend mirroring the control files and
online redo log files. The mirrored copy of a file should be on a different physical disk than
its corresponding original copy. To increase fault tolerance even further, connect the disks
to different disk controllers.

Spacely Sprockets
11.1.1Backup Overview
SAP recommends a backup cycle of at least four weeks. This means that you cannot
overwrite a tape used for database or offline redo log backup for at least four weeks. The
larger the backup cycle, the more backups are available for recovery. Large backup cycles
help protect against errors which are not immediately apparent.
Backups can be done with the database either online (hot) or offline (cold). Performing
online backups instead of offline backups:
enables 7x24 hours operation of the R/3 system
avoids the performance loss caused by database buffers needing to be reloaded

after an offline backup
Since online backups put an extra load on the hardware resources of the database server,
online backups should be performed when system activity is low and no time critical jobs
are running, (for example, at night).
If system availability requirements permit, a full offline backup should be performed at

least once during the backup cycle. The consistency of offline backups does not depend on
the intactness of offline redo logs, as is the case with online backups. For recovery you
need the complete sequence of offline redo log files since the last backup - for online
backups or offline backups.
In addition to the database backup, you need to backup the offline redo log files. If any one
of the offline redo log files is unusable, for example, due to a physical tape error, complete
recovery is not possible. Therefore, you should save each offline redo log file twice on
different tapes.
All redo log files in the archive directory which have been archived once are
written to tape.
All redo log files which have been archived twice are deleted from the archive
directory.
All offline redo log files which have not yet been archived are written to tape SAP
recommends repeating this procedure daily, to:
ensure data security
reduce the amount of redo log data in the archive directory

Spacely Sprockets
One of the most critical errors is the "archiver stuck situation, which causes a complete
standstill of the database and hence of the R/3 System. This error occurs when no more
free space is available in the archive directory. To prevent "archiver stuck situations , the
size of the archive directory should be at least four times the average volume of redo
information generated per day.
11.2 Recovery
There are different reasons why errors may occur that make it necessary to restore the
database:
Disk failure
A disk may crash resulting in the loss of the transaction log or database files.
User fault
A user may, for example, unintentionally delete a file or import a wrong transport.
Database corruption
In rare cases, a logical error may be discovered in the database.
Move to different hardware
A disaster might have destroyed existing hardware or a move to faster hardware
might be necessary.
After a power failure the database does not have to be restored. When the power is cut off,
the system shuts down abruptly and the execution of transactions is interrupted. The SQL
Server has an automatic recovery mechanism to deal with this situation. When the
database is restarted, an automatic recovery mechanism starts working. This means open
transactions are rolled back and completed transactions that were not written to the data
files at the time of shutdown are re-executed.
The most effective method to restore a database depends on the type of error that has
occurred. Finding out exactly what happened is therefore the first step in any restore
process. The following describes different error situations and gives an overview of the
steps required to restore the database in these situations.
11.2.1 Restore After Disk Failure
The procedure to follow in order to repair a damaged database after disk failure differs,
depending on how files have been allocated to disks and which of these disks have been
damaged. This documentation assumes that you have distributed your system to 3
different disk systems. This complies with SAPs recommendations that at least the
following components of your system should be located on different disks:
Log files of the SAP database

Data files of the SAP database
SAP, SQL Server and Windows executables, and other databases, for example,
msdb, master and tempdb

Spacely Sprockets
11.2.2 SAP Data Disk Crash
The SAP database normally resides on a RAID5 storage system for increased protection
against data loss. If a single disk fails it simply needs to be replaced and will not disrupt
database operation. However, if the whole RAID system crashes, the consequences are
serious. The SAP database will be damaged, work in the system will come to a standstill
and a database restore will have to be performed before resuming normal work.
To restore the database after this type of failure, you first have to immediately backup the
most recent transaction logs. Once this has been done, you can restore the database by
loading the latest database backup and applying the succeeding transaction log backups.
11.2.3 SAP Log Disk Crash
The SAP log records all the changes that are made to the database. They enable
transactions to be redone when a database is restored and therefore play a central role in
any restore operation. For this reason, SAP recommends that they be written to a RAID1
storage system that ensures data is protected against loss by a mirroring strategy. The
transaction log will only be lost, if the original and mirrored log disk fail.
If the entire log disk system crashes, you need to proceed in the same way as for a failure
of the SAP data disk. The only difference is that you will not, in a first step, be able to
backup the transaction logs that were in use at the time of the failure. You have to begin by
restoring the most recent database backup and then continue with the application of the
available transaction log backups.
You can only restore your database to the state it had at the time of the last log backup. All
the following changes are lost because the current transaction log is damaged and it is
therefore impossible to re-execute the changes it contains.
11.2.4 Executables Disk Crash
If your disk system with all other files except the transaction log and SAP data files fails,
this has far reaching consequences for the system. The Windows operating system, SAP
executables, SQL server executables, msdb and master databases will be gone.
The best way to rectify the situation is to restore the crashed disk on the basis of the last
available full Windows backup.
11.2.5 Restore after User Fault

Spacely Sprockets
A user might erroneously delete a table or import a wrong transport. Depending on what
has happened, there are different ways in which you can proceed. One of the options that
may be useful is a point in time recovery. It can restore the database to the state it had on
a specific day at a specific time. Before you implement this procedure, SAP recommends
that you first perform a full Windows backup. This safeguards you from losing your data, if
the tape for restoring the database is unreadable.
For more information see the SQL Server Books Online.
11.2.6 Restore after Database Corruption
When you recognize that the data in your database is corrupted you need to diagnose the
problem more precisely. The optimal method of restoring the integrity of the database
depends on the extent and cause of the damage. You probably need assistance from your
SAP Basis consultant, in order to analyze the error and find the most effective solution. It
may be possible to repair the corrupted database. Other options are:
Database and transaction log restore
Point in Time Recovery
11.2.7 Move to Different Hardware
There are two reasons why you may need to restore the entire system on different
hardware:
Total loss of hardware.

Database copy, for example from a test system to a productive system.

Spacely Sprockets Technical Infrastructure Document

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Spacely Sprockets Technical Infrastructure Document

Uploaded by

Copyright:

Available Formats

Spacely Sprockets

Technical Infrastructure Document

1.3 Change History.........................................................................................................................................4

2. SAP SYSTEM & CLIENT LANDSCAPE............................................................5

2.2 SAP Three System Landscape.................................................................................................................5

2.3 Two-Tier, Three-Tier and Three-Tier Distributed SAP Instance Setup..............................................5

2.5 SAP Clients...............................................................................................................................................7

2.5.13 Client Refresh Procedures...................................................................................................................9

3.2 Network Systems.....................................................................................................................................11

Copyright 2000 SAP AG. All rights reserved 1

4.2 R/3 Enterprise Landscape....................................................................................................................13

5.2 Desktop Technical Requirements..........................................................................................................20

6. INPUT & OUTPUT DEVICES..............................................................................21

6.2 Output Devices........................................................................................................................................21

6.3 List of Input Devices..............................................................................................................................22

6.4 Output Environment...............................................................................................................................24

6.5 Input Environment..................................................................................................................................24

7. SAP SOFTWARE INSTALLATION..................................................................25

7.2 Installation of the SAP R/3 Instances....................................................................................................26

7.3 Installation of other SAP Software........................................................................................................26

Copyright 2000 SAP AG. All rights reserved 2

8. CHANGE AND TRANSPORT SYSTEM (CTS)...................................................27

8.2 Transport Domains................................................................................................................................28

8.3 Transporting Changes within a SAP Instance.....................................................................................28

8.4 Transporting Changes across SAP Instances.......................................................................................28

8.5 Change Request Standards...................................................................................................................30

9. SECURITY USERS AND ROLES................................................................32

9.2 Central User Administration.................................................................................................................32

10. SYSTEM MAINTENANCE...............................................................................33

10.2 Support Packages....................................................................................................................................33

Copyright 2000 SAP AG. All rights reserved 3

11. BACKUP AND RECOVERY.............................................................................34

Copyright 2000 SAP AG. All rights reserved 4

1.1 Company Data

1.3 Change History

Date Name Description of Changes

Copyright 2000 SAP AG. All rights reserved 5

2.1 SAP System Landscape Overview

2.2 SAP Three System Landscape

The following is a diagram of the typical SAP three system landscape:

2.3 Two-Tier, Three-Tier and Three-Tier Distributed SAP Instance Setup

Copyright 2000 SAP AG. All rights reserved 6

2.4 R/3 Enterprise Instances with Host Names

system # system description Hostname of CI SAP installation number

2.5 SAP Clients

Clien Purpose currenc categor client- client-

Copyright 2000 SAP AG. All rights reserved 7

Future client copies will

This client is created from a

Copyright 2000 SAP AG. All rights reserved 8

2.5.2 R3Q Clients

Client Purpose currency category client-dependent client-

This Client will be created from the Golden QAS

Client containing Good Training Data.

2.5.3 R3P Clients

Client Purpose currency category client-dependent client-

It will be created based on the Production Build

Copyright 2000 SAP AG. All rights reserved 9

Source target client copy justification frequency reference #

Copyright 2000 SAP AG. All rights reserved 10

3.1 Network Topology Diagram

Information not yet available.

3.1.2 Local Area Network

Information not yet available.