CEIL - R3 Clients Details

7/30/2019 CEIL - R3 Clients Details

1/21

SAP R/3 SYSTEM LANDSCAPECairn Energy System and Client Deployment Strategy

Submitted to

Cairn Energy India Pty Ltd.

By

Wipro Ltd.August 2006

Version 1.0


2/21

CEIL System Landscape & Client Strategy

DOCUMENT INFORMATION

Project Name Document Name Document LocationCEIL SAP Implementation System and client

Deployment StrategyDocument Server

DOCUMENT HISTORY

Version

DocumentName

Date Author ReviewedBy

ChangeControl

1.0 System

and ClientDeployment Strategy

03/Aug/2006 Bharathan

Nair

Parthasarathy

Wipro Ltd. Page 2 of 21

Wipro Limited, 2006, All Rights Reserved.This document is proprietary to Wipro Infotech, a division of Wipro Limited.You may not modify, copy, reproduce, republish, upload, post, transmit or distribute any material from this document, inany form or by any means, nor may you modify or create derivative works based on the text of any file, or any partthereof for public, private or commercial use, without prior written permission from Wipro Limited.


3/21


DOCUMENT APPROVAL

Name Designation Signature DateParthasarathy K Wipro PM

Shaji Abraham CEIL PM




4/21


TABLE OF CONTENTS

1 SYSTEM DEFINITIONS.......................................................................5

1.1 Development (DEV)...........................................................................51.2 Quality Assurance System (QAS).........................................................5

1.3 Production (PRD)...............................................................................62 R/3 IN A THREE SYSTEM LANDSCAPE.................................................63 STANDARD CLIENTS..........................................................................8

3.1 Client 000: SAP Reference Client (SAPR).............................................83.2 Client 001: SAP Sample Client (SAPS)..................................................93.3 Client 066: SAP Early watch Service Client (SAPE).................................9

4 CUSTOMER DEFINED CLIENTS..........................................................105 CUSTOMER DEFINED CLIENT DESCRIPTION.......................................10

5.1 Client 200 Customizing Master Client................................................105.2 Client 210 Gold Client....................................................................115.3 Client 220 Unit Test......................................................................115.4 Client 230 Security........................................................................12

5.5 Client 240 Development.................................................................125.6 Client 250 Sandbox........................................................................13

5.7 Client 510 Gold Client....................................................................135.8 Client 520: Quality Assurance ...........................................................13

5.9 Client 521 Integration Test Client....................................................145.10 Client 570 Training Client............................................................145.11 Client 900 Production..................................................................145.12 Client 909 Pre Production............................................................15

6 LANDSCAPE DIAGRAM.....................................................................167 CLIENT ATTRIBUTES........................................................................178 ACCESS SEQUENCE FOR CUSTOMER DEFINED CLIENTS......................21




5/21


1 SYSTEM DEFINITIONS

1.1 Development (DEV)

All customizing and development work is performed in this system. After all

the changes have been unit tested, these changes can be transferred to the

quality assurance system (QAS) for further system testing. The customizingand development changes are transported using transport requests.

The development system contains a sandbox (SAND) client that allows new

users to become familiar with the R/3 System and lets experienced users

test customizing changes without affecting the main customizing client.

1.2 Quality Assurance System (QAS)

After unit testing the customizing and development changes in the

development system (DEV), the changes are transported to the quality

assurance system (QAS). Here, the configuration undergoes further testsand checks to ensure that it does not adversely affect other modules.

This is the Integration Test system. It is the closest version of the Production

System. After Go Live this system is usually refreshed from the Productionclient periodically. This gives the developers a static version of theproduction client in which to conduct tests. Before Go Live this system is

used for more extensive testing. Completed Unit Tests are strung together inlonger tests that constitute the entire business process. In addition multiple

business processes are run simultaneously to simulate the productionenvironment.

When the configuration has been thoroughly tested in this system andsigned off by the quality assurance team, it can be copied to other system

clients and to the production system (PRD).




6/21


1.3 Production (PRD)

A company uses the production system (PRD) for its production work. Thissystem contains company's live data and also the real business processes

are performed.

The other systems in the landscape must guarantee that defective programs

or incorrect customizing configurations do not adversely affect theproduction environment

2 R/3 IN A THREE SYSTEM LANDSCAPE

For implementing additional applications or additional components with

substantial proprietary developments or modifications, a configurationsystem consisting of the following three separate R/3 Systems has proven

most effective:

The first system for customizing, development and unit testing

The second system for system testing

The final system for production work

This configuration, recommended by SAP, conveniently supports:

Initial installation of SAP applications

Successive installation of additional SAP applications

Successive installation of SAP applications in different offices or plants

of a company

Implementation of substantial proprietary developments or

modifications

The relevant parameters stay in the development system (DEV) until thepreparation phase (test and release) is complete. Proprietary developments

and modifications are transported from the development system (DEV) tothe quality assurance system (QAS). Once tested and the appropriate sign-off procedures have been completed, the changes are then imported into the

production system (PRD) using the change management utilities.




7/21


A three-system landscape provides customers with an isolated development

environment, testing environment, and a production system. To establish

this landscape, the appropriate client tools must be used. Once established,all changes made in the DEV need to be recorded using change managementrequests and propagated to the entire landscape using the transport

methodology.

In the three-system landscape, a QAS exists between the DEV and the PRD.Each development and customizing phase is completed in the DEV and then

moved to the QAS for testing, training, and quality assurance. This allowsthe customers quality assurance group, also known as user acceptance, to

test new customizing configurations and program developments before

releasing them to the productive environment. It also allows thedevelopment and customizing teams to work on further development and

customizing tasks without impacting the acceptance tests.

A three-system landscape meets the needs of most customers. New

developments can be tested without affecting the production environmentand upgrades can be performed without concern over other projects.

Therefore, ASAP recommends the use of a three-system landscape.

The QAS system enables to integrate development efforts and to check the

validity and consistency of transported objects, before moving the objects

into production.

Once in production, the customers system landscape is in a state of

maintenance. All changes to either customizing or repository objects shouldbe distributed using the Change and Transport System (CTS). The client

transport tool can no longer be used. Once in maintenance, all development

should take place in the DEV, using the workbench organizer and thecustomizing organizer to record all changes. All objects are collected in

transportable change requests, to prepare for migration to the productionenvironment.




8/21


3 STANDARD CLIENTS

Every R/3 System is initially installed with three standard SAP clients. Therole of these clients is described below:

Client Name Description

000 SAPR SAP Reference

001 SAPS SAP Sample

066 SAPE SAP Early Watch Service

The contents of clients 000 and 001 are identical when a R/3 System is first

installed. Both clients contain organization-specific and non-organization-specific settings that can serve as a foundation for working in the R/3System.

3.1 Client 000: SAP Reference Client (SAPR)

This client is shipped as an industry-neutral model company.

To create a new client, as recommended in this documentation, the SAPreference client (SAPR) should be used as the source client in the client copy

procedure. The new client will then contain an executable system that canserve as the basis for further customizing, development, training, and

testing.

During an upgrade to the R/3 software, client-dependent changes will be

automatically updated in the SAPR. To reflect these changes in the otherclients, the settings will need to be copied from the SAPR to the other

clients.

The Implementation Guide (IMG) contains delta projects that highlight the

changes between different R/3 releases. These projects can be used for

distributing the new functionality to other clients and other systems in thelandscape.




9/21


3.2 Client 001: SAP Sample Client (SAPS)

As stated previously, when the R/3 system is installed, the SAP reference

client (SAPR) and the SAP sample client (SAPS) are identical. After thesystem has been upgraded, or additional languages have been imported, it

is likely that the SAPR will contain customizing table entries and language-dependent text entries relevant to the new release.

The SAPS, like all other clients in the R/3 System, will not contain the newentries after the update. If this information is required in the SAPS, it will

need to be transported with customizing transactions and the changemanagement system.

3.3 Client 066: SAP Early watch Service Client (SAPE)

SAP provides a proactive support service for checking the performance of a

customers system. This Early Watch Service (EWS) involves a survey of thecustomer system to check various performance criteria. A report is then

compiled and forwarded to the customer with recommendations. These

recommendations are aimed at improving system performance. The reportshould also alert the customer to potential problems, so that immediate,

corrective action can be taken.

The SAP Early Watch service client (SAPE) enables SAP to remotely accessthe customer system. The client contains a user record that the SAP EWSpersonnel use to log onto the customer system and gather the necessary

information. The user record only has the minimal R/3 authorizationsnecessary to allow the EWS to be performed. As the EWS personnel, survey

an isolated client, it also protects the companys confidential data in the

production (PRD) system.




10/21


4 CUSTOMER DEFINED CLIENTS

During SAP R/3 System implementation, few clients are required to fulfilldifferent roles in the implementation procedure. The table below lists the

clients in CEIL landscape

Instance Client Description

CED 200 Customizing Master Client

210 Golden

220 Unit Test

230 Security

240 Development Client

250 SandboxCEQ 510 Golden

520 Quality Assurance

521 Integration Testing

570 Training Client

CEP 900 Production

909 Pre-Production

5 CUSTOMER DEFINED CLIENT DESCRIPTION

5.1 Client 200 Customizing Master Client

This is an unique client. It is the origination client for all the functionaltransports across the landscape. It is the only client in the landscape that

cannot be recreated with a client copy. It cannot be refreshed, it can only be

restored.

This client is governed by the TMS Methodology. In practice this means thatall transports released in this client must be transported to Production.

Client Source: Configuration entered manually in this client can berefreshed on request via client copy from golden client [CED] 210]. In this

process the configuration will be lost, hence it is not at all advised.




11/21


Client Output: Configuration is moved via CTS to clients in [CED]210,220,240 [CEQ] 500,510,520,570 and [CEP] 900,909.

5.2 Client 210 Gold Client

The purpose of this client is to refresh all clients on DEV [CED] other thanthe Customization Client (200). It contains all transports received by the

Unit Test Client, however no transactions are performed here. It is a pristine

copy of the next latest version of Production. The TMS Methodology allowsfor refreshing the all clients in the landscape except for the Customization

Client (200). Only approved Configurations and Basis team are allowed inthis client.

Client Source: Approved configurations from CED client 200 are enteredvia CTS in this client. Manual config can be performed on a limited basis

where there is a need and with prior approval from the Project Manager.

Client Output: May refresh on request via client copy to clients 200, 250,and 120.

5.3 Client 220 Unit Test

This is the first client where official testing occurs. The Unit Test Client is fortesting individual transactions and configuration; i.e., the smallest unit of atransaction or business process. Everyone works in the Unit Test Client. All

transactions are executed in the Unit Test Client. ABAP code, Data uploads,Configuration, Master Data etc., are all tested in this client. This client is the

earliest version of what Production will look like with data in it.

This client can be refreshed with a client copy. This means that no transports

are created here. Nothing unique is created or generated in this client. Whenproblems are found, there are two options for resolution either testing in the

Sandbox client with the subsequent creation of the fix in the CustomizingClient or creation of the fix in the Customizing client without the need to testin Sandbox. In either case, the fix is created in the Customizing Client,ideally by the Customer project member, and transported to the Unit TestClient for further testing.




12/21


In limited and specific circumstances that are always documented by aSAPnet note, manual configuration must be performed in a client other than

the Customization client. When this is needed, the Unit Test client can be

opened for the purpose of performing such customization, then closed again.

Client Source: Approved configurations from CED client 200 entered via

CTS or Client Copy from Golden Client 210 in this client. Manual config may

happen on a very limited basis with prior approval.

Client Output: No Output

5.4 Client 230 Security

This client is used to generate the Roles, User IDs, Profiles, Authorizationsneeded in the Production clients. Transports from this client will go to the

Unit Test client (220), Integration Test client (520), Training client (570),Pre- Production (909) and finally the Production client (900).

Client Source: No Input.

Client Output: Client 230 is transported via CTS to clients 220, 520, 570,909 and 900

5.5 Client 240 Development

This client is used by the ABAP programmers to create new ABAP code. It

contains all the transports that the Unit Test client (220) receives. It shouldalso contain all the master data that an Unit Test client posses. It can be

refreshed from the Gold Client (210). Since ABAP programs are clientindependent, code created here can be tested in this client or in the Unit

Test client (220).

Client Source: Refresh is done based on request from [CED] Golden Client

210 or receives transports from [CED] client 200.

Client Output: Client 240 is transported via CTS to other instances needing

the latest ABAP objects.




13/21


5.6 Client 250 Sandbox

This is the Test Client for all customizing work. No transports come from thisclient. It is intended to be a client that is refreshed periodically from either

200 (Customizing) or 220 (Unit Test). Customer project members as well as

consultants test new configuration in this client before creating it in 200(Customizing).

Client Source: Refresh from [CED] Customizing Client 200 or Unit Test

Client 220.

Client Output: No Output

5.7 Client 510 Gold Client

This client receives all transports from the customization master (200). It isused to refresh the QAS [CEQ] clients. It contains all the transports andmaster data uploads. It contains no transactional data.

Client Source: Approved configurations from CED client 200 are entered

via CTS in this client or manual config may happen on a very limited basiswith prior approval.

Client Output: May refresh on request via client copy to clients 500, 510,520 and 570.

5.8 Client 520: Quality Assurance

Copies of customizing changes are moved here for system testing. This

client is used to test the customizing configuration changes made in thecustomizing / developmentclient (200). This second level of testing ensures

that everything has been successfully transported (in multi-system

landscapes). The quality assurance team checks customizing and

development.


via CTS in this client or manual config may happen on a very limited basis

with prior approval.




14/21


Client Output: No Output.

5.9 Client 521 Integration Test Client

This client is used for Integration Testing. Integration Testing consists of

Unit Tests strung together to comprise a complete business process.

Eventually all business processes are tested together to simulate theproduction environment.


via CTS in this client or manual config may happen on a very limited basis

with prior approval.


5.10 Client 570 Training Client

This client is where the actual training is done. It is refreshed from the

Integration test client .

Client Input: Refresh from [CEQ] (521).


5.11 Client 900 Production

This is an unique client in the landscape. It cannot be refreshed. It can only

be restored from a backup. Eventually it will receive all transports originallycreated in the Customization Master client (200) after testing in QAS

Client Input : Configurations, Developments and Security changes viaCorrections & Transports from [CED] Client 200, 230, 240. A few Production

specific data may require manual entry.

Client Output: Scheduled refresh from [CEP] client 900 to [CEQ] (570) and

[CED] 250.




15/21


5.12 Client 909 Pre Production

The pre-production client (PPRD) is used for the final testing of SAP R/3configuration in the productive environment. The PPRD is used by the

project team to perform final testing of the customizing changes before they

are transferred to the production client (PRD). This client can also be used totest data transfer programs with large amounts of data, in preparation for

the final import into the PROD.

The configuration allows entering of master data and transaction data into

the production system (PRD) to simulate the live environment. Thissimulation can be safely performed without affecting the real production

client (PRD) and can later be deleted.

If this client has been used to test data transfer programs with large

amounts of data, it may be necessary to delete this client before the finaldata transfer is performed into the PROD. If only small amounts of data have

been entered, this client can remain in the production system (PRD) afterthe system goes live. In this case, the client needs to be protected against

all user access and only opened up for individuals to check customizing

settings if problems arise.

Whether this client remains after the go-live date is a matter oforganizational choice. This decision depends upon the amount of disk space

available in the PRD and is influenced by the security concerns of CEIL.

Client Input: Configuration, Development and Security changes via

Corrections & Transports from [CED] Client 200,230,240. A few Productionspecific data may require manual entry.

Client Output: Scheduled refresh from [CEP] client 909 to [CED] 250

immediately after go live.




16/21


6 LANDSCAPE DIAGRAM




17/21


7 CLIENT ATTRIBUTES

R/3

System

Client

s

Options on SCC4 Option Entry

CED 200 Category Customizing

Changes and Transports for

Client specific objects

Automatic Recording of Changes

Cross-Client Object changes Changes to Repository and Client

Ind. Customizing allowed

Protection: Client copier and

comparison tool

Protection level 1: No

overwriting

R/3

System

Client

s


CED 210 Category Test

Changes and Transports forClient specific objects

No Changes Allowed

Cross-Client Object changes No Changes to Repository and

Client Ind. Customizing Obj.


comparison tool


overwriting

R/3

System

Client

s





No Changes Allowed


Client Ind. Customizing Obj.

Protection: Client copier andcomparison tool

Protection level 1: Nooverwriting




18/21


R/3

System

Client

s


CED 230 Category Test Changes and Transports for


Changes without automatic

recording

Cross-Client Object changes No Changes to Repository andClient Ind. Customizing Obj.

Protection : Client copier and

comparison tool


overwriting

R/3System

Clients




Automatic Recording of Changes

Cross-Client Object changes Changes to Repository and ClientInd. Customizing allowed



R/3System

Clients




Changes without automaticrecording

Cross-Client Object changes Changes to Repository and Client

Ind. Customizing allowed


comparison tool


overwriting




19/21


R/3System

Clients




No Changes Allowed

Cross-Client Object changes No Changes to Repository andClient Ind. Customizing Obj.



R/3System

Clients




No Changes Allowed

Cross-Client Object changes No Changes to Repository andClient Ind. Customizing Obj



R/3

System

Client

s





No Changes Allowed


Client Ind. Customizing Obj


comparison tool


overwriting




20/21


R/3System

Clients


CED 570 Category Training


No Changes Allowed




R/3

System

Client

s


CED 909 Category Production


No Changes Allowed




R/3System Clients Options on SCC4 Option Entry

CED 900 Category Production


No Changes Allowed







21/21


8 ACCESS SEQUENCE FOR CUSTOMER DEFINED

CLIENTS

Instance Client Description Access Sequence

CED 200 Customizing Master Client Consultants, Basis team

210 Golden Basis Team (Limited access)

220 Unit Test Consultants ,Core team

230 Security Basis Team

240 Development Client Developers, Basis team

250 Sandbox Every one

CEQ 510 Golden Basis Team (Limited access)

520 Quality Assurance Consultants521 Integration Testing Consultants ,Core team

570 Training Client Consultants ,Core team, end

users

CEP 900 Production End Users , Basis team,Limited access to consultants andcore team

909 Pre-Production Consultants, core team, Basis


Wipro Limited, 2006, All Rights Reserved.This document is proprietary to Wipro Infotech, a division of Wipro Limited.You may not modify, copy, reproduce, republish, upload, post, transmit or distribute any material from this document, inany form or by any means nor may you modify or create derivative works based on the text of any file or any part

Documents

CEIL - R3 Clients Details