DEV system Client system landscape

[Former Member]

Hello ,

I am planning to have 4 different clients on the DEV box. I want to know are the client settings proper as per my requirement.

Here is the requirement:

SANDBOX Client : Will be used for rough usage. ( no transport allowed )

CUST Client: Actual neat client which will be used for actual configuration , further more will be used to transport request to QAS server client. ( No access to ABAP'ers)

DEV Client: Exclusively to be used by ABAP'ers for development. ( No access to functional consultants, no transport allowed )

Unit Testing Client: Will be used for testing of configuration ( by local transport from CUST client) . ( no transport allowed)

Now , i have planned to made following client settings ...

SANDBOX Client :

1. changes w/o automatic recording , no transport allowed.

2. No changes to repository and cross client cust jobs allowed

3. Protection Level No restriction

CUST Client:

1. Automatic Recording of changes

2. Changes to repository and cross client cust jobs allowed

3.Protection Level 1: No overwriting

Dev Client:

1. changes w/o automatic recording , no transport allowed.

2. changes to repository and cross client cust jobs allowed

3. Protection Level : No restriction

Unit Testing Client

1. NO changes allowed

2. No changes to repository and cross client cust jobs allowed

3. Protection Level 1: No overwriting

Are my settings proper as per the requirement ....

Regards

[former_member126060]

Everything seems fine but i think your DEV client should also have " Automatic Recording of changes ".

- Niraj

[Former Member]

I am facing issues now , As i have all 4 clients in the same box and i want restriction to scc4 t-code at SANDBOX and DEV( abapers) , for now i have given them SAP_All - some of basis authorizations.

If i change the authorization object S_TABU_DIS access to

Activity: None

Authorization group: None

The consultants are not able to do anything at SPRO.

Please advice.

Regards

[Former Member]

Hi,

Since the DEV client is for developers only, why you are giving SAP_ALL access to them. There are some standard roles for ABAP developers like for example "SAP_BC_DWB_ABAPDEVELOPER", make a copy of these role to Z and assign the same to developers. Whereas for SANDBOX client, instead of assigning SAP_ALL, create a Z role as a copy of SAP_ALL template and disable all the BC (basis related objects) and also change the access to display only for other important objects, which should restrict the changes for SCC4 tcode also.

Other way is after creating the Z role has a copy of SAP_ALL, in object S_TCODE give the tcodes as /* to sb; sd to z* which should restrict access to SCC4. This is a suggestion, just give a try and check.

Also, in your below sandbox client setting, you have restricted the client against modification then how can your consultants and abapers use it as for rough purpose (for R&D)

SANDBOX Client :

1. changes w/o automatic recording , no transport allowed.

2. No changes to repository and cross client cust jobs allowed

3. Protection Level No restriction

And in your development client settings, it should be Automatic recording of changes. Otherwise how can you transport the ABAP changes to QAS......

Dev Client:

1. changes w/o automatic recording , no transport allowed.

2. changes to repository and cross client cust jobs allowed

3. Protection Level : No restriction

Regards,

Sharath.

[Nibu]

Hi

I would reccomend not to give SAP_ALL , but go for the SU53 authorization checks and provide the relavant authorizations only .

Regards,

Nibu Antony

[Former Member]

Hi Sharath ,

Here are few questions as per your solution....

Also, in your below sandbox client setting, you have restricted the client against modification then how can your consultants and abapers use it as for rough purpose (for R&D)

As per SAP documentation for SANDBOX its not recommended to allow cross client as this will affect the other client on the system , SANBOX they have use for just basic configuration and checks, moving further the CUST client will be copied for furthere R&D.

SANDBOX Client :
1. changes w/o automatic recording , no transport allowed.
2. No changes to repository and cross client cust jobs allowed
3. Protection Level :0 No restriction

And in your development client settings, it should be Automatic recording of changes. Otherwise how can you transport the ABAP changes to QAS......

The transport will only happen from CUST client of DEV to QAS box , ABAP development which are cross client will happen in DEV client only and in case they require the access to CUST client for some developments , that access will be provided with appropriate authorizations only , This Client will be used only for ABAP development only.

Dev Client:
1. changes w/o automatic recording , no transport allowed.
2. changes to repository and cross client cust jobs allowed
3. Protection Level : No restriction

Please let me know if i am moving in right direction.

Regards

[Former Member]

Hi,

Fine, I agree with your Sandbox settings, misunderstood sandbox client as a separate box (Normally which we follow). Since sandbox client is in same development system then your approach is fine as ABAP changes in DEV will automatically reflect in all clients.

But, as per my knowledge its better to have sandbox has a separate system rather than creating a client in development system. But anyhow, it again depends upon the available infrastructure. If separate server is not available then can do it as above.

And your DEV and CUST client settings are fine, please go ahead and gud luck!!!!

Regards,

Sharath

[Former Member]

Yes you are right its better to have SANBOX on another server , however they did not plan for that ....thats why we are having sandbox on same client.

One more quick question can we transport CUST transport request ( customization data) to SANBOX ...as the funtional consultants wants to do actual configuration at CUST client and transport that to SANBOX for R&D, is this a valid point ?

or they need to re-do the configuration at CUST client after the SANDBOX.

Regards

[Former Member]

Hi,

As per me, sandbox is for doing R&D with the configuration. Normally, they should first do R&D in sandbox and if it works fine then the same they can do in CUST client and transport across the landscape. Anyhow, in your case since sandbox is also in same development system in rare cases you can do that using SCC1 Tcode (Hope you are aware of this) which will copy the contents of transport request of CUST client in to SANDBOX client.

Also would like to mention that any point of time make sure that CUST and SANDBOX are having same level of configurations.

Gud Luck !!!!

Regards,

Sharath

Edited by: sharath Babu on Jul 15, 2010 11:49 AM