Showing posts with label Client and Transports. Show all posts
Showing posts with label Client and Transports. Show all posts

Client Copy Data Types

The client copy can copy the following components of the source client into the target client:

· User master data: User master data is only deleted in the target system if a profile with user master data is copied. Authorization profiles and roles belong to customizing and are therefore always copied with it. Copying users without authorization profiles is problematic. The copy profile SAP_USER therefore contains additional authorization profiles and roles.

· Customizing: All profiles except SAP_USER contain customizing. Customizing data is generally in tables with delivery classes C, G, E and S.

· Cross-client customizing: Choose a profile with this data type for example when you want to create a test system which is analogous to the production system, and no system copy is to be made.


Inconsistencies can arise in the target system after transporting cross-client tables. Cross-client customizing can only be used to create a new system because existing clients can be corrupted by changes in their context.

Scenario 1: You have just installed the target system. The first step in setting up a client is to import a client from another system. Since there are no other clients in the system yet, you can also copy the cross-client customizing settings to ensure that they remain consistent, including those pointing to cross-client objects.

Scenario 2: You have setup clients in the target system whose data must be retained. Cross-client data must not be imported into the system. This data would overwrite the existing data, and the customizing of the other clients in the target system would no longer be consistent. Only the data in the new client would be consistent. This is why you should not transport cross-client data. The data in the other clients of the target system is then still usable, and only the new client needs some postprocessing to reconcile the client-specific Customizing data copied with the cross-client Customizing data of the target system.

· Master/transaction (application) data: select this option, for example, if you want to set up a test system from the production client.


Application data depends on customizing data, so it can only exist consistently together with it. Application data is therefore always deleted from the target client, exception for copies with SAP_USER. Application data is generally in tables with delivery class A.


The amount of data and thus the memory required and copy time for productive clients can be considerable. In this case you should not copy application data, you should create the required test data e.g. with CATTs (Computer Aided Test Tool).

Leaving content frame

Client Copy and Transport Authorizations

To copy or transport clients, you need the appropriate authorizations. There are two types of authorizations: general authorizations for client copy, and special authorizations that depend on what you want to copy.


The nitial user SAP* has all authorizations required, except authorization to create a transport request. It can be used for all client copy tools except the client export (SCC8).

General authorization objects for Client Copy

Authorization objects

Action

S_TABU_CLI

Maintain cross-client tables

S_TABU_DIS

Maintain system tables

S_CLNT_IMP

Import data in client copy

S_DATASET

Access the file system

Copy User Profiles and User Master Records

Authorization objects

Action

S_USER_AGR

Copy roles

S_USER_PRO

Copy authorization profiles

S_USER_GRP

Copy user master records

Transport Clients

You also need the following authorizations to transport clients:

Authorization object

Action

S_CTS_ADMI with

· TTYPE 'CLCP'

· ACTVT '01'

Create object lists for client transport and copy into another client

Remote Copy (authorization required for RFC user in source client)

Authorization

Action

S_TABU_RFC

Remote access to tables in target system

Leaving content frame

Transport Control Program tp

The transport control program tp is a utility for controlling transports between SAP Systems and for upgrading SAP Releases. As a control program, tp uses some special programs that are required to perform complete transports.


The transport control program tp is normally called by other programs:

    • Change and Transport System (CTS)
    • Transport Management System (TMS)
    • Upgrade control program
    • R3up

Therefore, you do not have to directly use tp .

Before you call tp directly, check whether the function you need is not offered by CTS or TMS.

Transport Material PDF Free download

Transportation

Transport Management System (BC-CTS-TMS)

Transport Organizer (BC-CTS-ORG)

Transport Tools (BC-CTS-TLS)

SAP 4.7 Enterprise Install Failure "FRF-00007

SAP 4.7 Enterprise Install Failure "FRF-00007 Unable to open RFC connection"

During the Install of SAP 4.7 Enterprise the installation fails with "FRF-00007 Unable to open RFC connection" when you are prompted to enter the DDIC password.

The solution I found was that you need to stop the install then log ito SAP with the User SAP* with password - "06071992" then change the DDIC password to whatever you want.

Once done restart the install and continue to the stage where you need to install the DDIC password, enter the changed password and the installation will continue without errors.

The only OSS notes related to this was "Press the continue button" and the installation may continue, or restart the installation.

What is a Logical system?

Hello !

Does anybody know what "logical system" is ??? I have read help in =
transaction SCC4 already, but I'm confused more than before ... :-))) =
What it is good for ? What is the reason for defining it ?

Give me an explanation, please ...
Thanks !

-----Reply Message-----
Subject: RE: Logical system

Hi,

'logical system' is used to identify an individual client in a system, for ALE
communication between SAP systems. That's why you see a field for 'logical
system' in the client master data in SCC4 (table T000). You use logical systems
in ALE config - this should be documented further in the IMG guide, or SALE and
BALE transactions.

cheers,

-----Reply Message-----
Subject: RE: Logical system

Just a note of warning regarding choosing the Logical System name.

I know of one site where it was chosen such that it depended on the actual
system name and, therefore, had to be changed after copying production back to
acceptance. The process ran for two to three days! I have not examined how the
logical system name is used but it would appear that selection should be made
carefully to avoid the need for this if the architecture can support it.

Perhaps someone with more experience of this object could comment on its usage
and name selection.

-----Reply Message-----
Subject: RE: Logical system

yes - you should use a naming convention for the logical system names which
includes distinct IDs depending on:
System ID (SID), and client number, and maybe also system number if you have
more than one instance per host machine. Hostname would be useful too, but I
think there's only 10 characters in v3.1x (maybe more with long name
functionality in 4.x ??).

eg., in DEV box , sys no 00, client 100, choose something like 'DEV00_100'.

cheers,

-----Reply Message-----
Subject: RE: Logical system

You state that a logical system appears to be nothing more than another label
for a client. I think (certainly cannot say I know!) that it is a little more
than that: I think it is an externally visible label for a client within a
system.

-----Reply Message-----
Subject: RE: Logical system

Thanks,

I had interpreted the term "logical" as meaning it had no relationship to a
specific instance. That's how I would use the term anyway. I take it from your
remarks and others on this thread that it is, in fact, a very instance and
client specific label - really very physical and not at all virtual/logical.

-----Reply Message-----
Subject: RE: Logical system

I know from experience that the logical system must be defined or you get
error messages all over the place during order processing stating the
logical system has not been defined.
The logical system is defined in the IMG. Don't know the transaction
identifier, but in 4.* it is found in the IMG > Cross Application Components
> Distribution ALE > Basic settings > Logical systems > Define logical
systems. Here the entry is just an identifier and a text entry.
As you stated, it is assigned to the Client in Tx SCC4. (The next step in
the IMG)
I went to the IMG for help. Here is the extract at "Logical systems" level:
"Logical Systems.
The distribution of systems ( ALE ) makes it necessary to be able to
identify every system individually within a network. The "logical system" is
used to do this.
A logical system is an application system within which the applications are
coordinated to work in one database. In the SAP sense of the word, a logical
system corresponds to a client.
In the following steps, you must define every client as a logical system by
first of all defining logical systems and then assigning the clients in
question to the corresponding logical systems.
Note:
Assignments must be unique (that is, a client may only be assigned to one
logical system.
Several clients must never be assigned to the same logical system."

Reading this it does seem that it is nothing more than another identifier
for a "Client".

Hope it helps,

-----End of Message-----

SAP Maintenance transport requests work flow

An example of a basic principle and flow is:-

1. A request for a change is submitted to support team

2. Change is done in DEV (if approved) and tested by support team (limited testing only due to lack of productive data)

3. Change is transported to TST

4. User testing takes place

5. User approves or rejects (giving reasons)

6. System manager approves the change to go into PRD

7. Change is transported to PRD

All transports are done by the support team.

If a change is urgent it is transported straight away, if not they are batched up and done once a week.

The Workflow can be controlled by a software like a Lotus Notes database so you can have a record of approval at every step.

Note :-

The system manager is the manager of the support team. The system "belongs" to him i.e. it is his responsibility and he has the final say on what goes into the PRD system. 99.999% of the time he will approves the change, this is mainly a way of keeping him informed of what changes are happening in the system.

Many companies uses the core modules MM, PP, FI, CO. The problem with transporting single transports is that if it is a program, the complete program buffer is reloaded therefore giving a performance hit. Therefore you tend to leave them and just have one performance hit per week (although most weeks there are no program changes). When you are in production the number of transports will settle down to a reasonable figure. Maybe about 10 transports a week, and most of those are material groups (which, although they are user data, they are classed as customising). This rises if you are doing any modifications or changing business processes etc, but 10 is about quite normal for most.

SAP Client lock

-----Original Message-----
Subject: Client lock

Hi all,

I have two questions :

1. How to lock the client from logon

2. How to see the all the users connected per day (with the activities they have done and resource utilization)

Thanks in advance

-----Reply Message-----
Subject: RE: Client lock

I cannot answer the first straight away, but the second questions, there are many available SAP transactions

use STAT very useful and many options available if you use them correctly.

-----Reply Message-----
Subject: RE: Client lock

1. I don't know how how to lock the client, but you can lock the system with
"tp locksys " and unlock it with "tp unlocksys ". You can
also stop the service, but then noone can login including yourself.
However, I had problems with tp locksys when applying some Hot Packages and
exporting client. It wouldn't work with system locked. I didn't try, but a
simple ABAP that locks and unlocks all the users in table usr02 (with exceptions
of yourself, SAP*, DDIC... - ofcourse) might be an interesting idea.

2. STAT transaction

-----Reply Message-----
Subject: RE: Client lock

hello,

U can lock the system thro "tp locksys" (Transport Utility).

Check the other options of "tp" command for locking the specific client under the system thro "tp help".

-----Reply Message-----
Subject: RE: Client lock

With this solution I can lock the whole system, but not specified by client.

Send me in more detail....

-----Reply Message-----
Subject: RE: Client lock

There's no way to lock a client.
You have to lock all users from loging in of this specified client.
The way you do is by user administration setting the lock.

-----Reply Message-----
Subject: RE: Client lock

Hi

We can lock a client using SCCR_LOCK_CLIENT and unlock SCCR_UNLOCK_CLIENT functions.

Once we run this functions with a client as input , that client will be locked/unlocked. Actually this function set flag '' Client is locked temporarly for client copy" in client maintanance menu. And the client will be available for users other than DDIC and SAP*. If you try to login in that client as any user , system gives message that ' Client locked temporarly'..

bye.

-----Reply Message-----
Subject: RE: Client lock

Thanks,

It is working fine.

Once again thank you very much

-----End of Message----

Copy users from DEV to PRD

1. Login to the client in your DEV system from where you want to copy.

2. Execute scc8. Select the profile sap_user.
Specify the target system.
Click on 'schedule as background job'.

3. Specify the background server name i.e. the server name where your DEV system is available.

4. Click on 'schedule job' button.
Verify the things and click on 'continue' button.

5. You will have options to specify the start time.
Specify to suit your convenience.
You can see the log in scc3.

6. Login to the destination client and execute scc6.
Specify the request number which was created during scc8.
You need to specify only one request number. Other(s) will be taken automatically.
Click on 'Prepare import'.

7. Specify the target client and click on 'Import'.
Log can be checked in scc3.

SAP Client Copy / System Refresh

Before doing a client copy, you need to prepare the following :-

1. Find the source client space with the client size custom program which can be implemented using the rel. note:
Find the space of the client - '0118823'. This will give you the size of the source client.

2. If your are on Unix OS, adjust all the file systems according to PRD file system to fit the PRD client in DEV
client based on space requirements also.

3. You can do the client copy by remote or export/import client.
Remote method is not preferred if you are doing a large client copy.
Do a client export/import.

4. To speed up the export/import, use R3trans export/import for the clustered tables.
Please find the rel. notes related to performance improvements for cluster tables in OSS.

5. Do import and post processing.
Note: Export may take 10 to 20 hr. for 50gb of data
import may take 4 days and post import will take 8 to 15 hr. for 50gb of data. And it all depends on
your system performance.

Please refer OSS rel. notes for the few RZ10 parameters which needs to be set for cluster tables to speed up the process.

Note :-

If it is a fresh installation, do this --

1. SCC4 --> Create client no. and fill other details.
2. Logon to the newly created client with SAP* and PASS as password.
3. SCCL --> choose any profile (preferably SAP_ALL), source client 000 and target client .
4. Preferably do a test run initially to check if it can go well.
5. As a care check space in databases.

What is system refresh when and why it is done?

The system refersh is nothing but the deletion of the client and replacing the data from other client. For example : you have clients 100, 200 and 300. Suppose when you want to refresh the client 100 you remove the client 100 and replace it with 200 0r 300 as per your reqiurement. Mostly the refresh of clients will be happen at the time of development stage.

System Refresh is a simplified term to Client Copy. Client Copy means copying the production client on to the quality to test the real data. As recommend by SAP this need to carried out every 3 months.

The process to carry out the same is as follows:
1. Create a client on quality system using txn scc4
2. Create a RFC between Production system and Quality System (need to create on quality system)
3. Login to the newly created client using sap* and pass as a password
4. Txn sccl to start the client copy. You can test the client copy by selecting the test run option. (test run will estimate the time taken for the activity).

Post Installation Task after successful R/3 46c

Generally you need to :-

1. import profiles (default, instance, start) into SAP R3
1.1 add/modify instance parameters such as
rdisp/max_wp_run, abap/timeout,
zcsa/system_languages, and so on...

2. update the R3trans and tp tools with the last ones available on sapnet

3. configure TMS (systems,layer and routes).
You can do it with virtual systems if you have only one SAP system

4. update SPAM/SAINT

5. check via Tcde db02 (with refresh option) the available space for TS other
than SYSTEM TS.( for the others %used must be less than 90)
5.1 check to see critical objects (table/index)
5.2 extend (via sapdba tools -> option TS administration) all TS which
shown critical objectsfor example:
PSAPPOOLD + 200M
PSAPPOOLI + 100M ...
You can get necessary via Note 195446 (for language import) and Note 118823 (for client copy)
5.3 refresh again in db02 and check the %used space

6. import language other than the default (DE & EN) if necessary

7. Client copy

8. configure printer (SPAD)

9. create user

10. change system user password such as SAP* , DDIC, and so on ...

Error you might encounter at the end of client copy :-

"there is a window "change and transport system not configured" Status is cancelled.

To rectify the errors :-

You need to configure CTS via tcde STMS for your SAP system.

If it's your only sap system, then:
- configure it as domain controller: run Tcde STMS and accept the default proposed domain
controller which is your system
- define one or two virtual system (Menu overview-->system then Menu
SAP system-->create-->virtual system)
- Menu Environment --> transport routes then press F5 and Menu Edit
Transport layer to create a "Z" layer for example "ZDEV"
Create a transport route between your real sap system and the virtual system
by using the two layers: "Z" layer and "SAP" standard layer
- save and distribute the TMS configuration

That is the main action you have to do to setup CTS.

Problems in Heterogeneous Setup

I am not in a hetro-geneous setup.

But a similar installation I have already visited, which one of the big installation in Bangalore, they used Sun solaris as dev and HP UX as PRD. But no problems. Logically SAP system just looks for where the data is stored and works on TCP/IP. It just does not matter where the database resides for development and production.

The transport mechanism just transports from the development client to productive client. So I assure you 100% you can plan this. This is supported by SAP.

You can even plan NT as development machine. It just works fine.

But some advantages are available if you have similar systems.

1. When updating patches for a particular os/db combination , you have a chance to see how it works, before trying
it on productive system.

2. You learn a lot on installation, sizing, many other related issues at the time of development, so that you can easily
sort it our at the time of installation of prd system.

The above cannot be told as advantageous, but take a note of these. After all it is a matter of cost + convenience!

I am on NT + SQL Server with SAP 4.7 Ent. and its works fantastic without any problems.

Problems with Multi-clients in one SAP Production instance

You are working on group of companies. They don't want to share any data between companies, simply no integration required, therefore mgt wants to have one client for one company that end up having multi-clients in prod instance. However, one of the SAP local guy told you not to continue with this lanscape.

Some of the potential problem of using multi-clients in one prod instance are:

1. problems affecting one client immediately affect all other clients.
an eg.: 1 client runs a job that fills up a tablespace or file-system.

2. a system problem (system crash) affects all clients immediately. e.g. an Oracle archive stuck will affect all clients.

3. programs/tables are client independant. Invidual customers cannot make changes to common programs/client without affecting the others.

4. Poorly written ABAP's will cause bad response throughout the SAP system, affecting all clients. I shudder to think of a situation where the programmer for 1 customer stuffs up and the other customers demand blood!

5. Taking all of this into account, your change management will turn into a NIGHTMARE! especially considering that each customer probably does no care about the other customers, so EVERY change of theirs is the most important one.

The above are some of the problems if you have multi-client in one SAP instance and there are many more arguments.

What is the best way to refresh QA from PRD?

How to make a system copy:

1. Take offline backup of both the server (source and target servers)

2. Verify the backup is successfully done.

3. Run the following command on source system.
a. Login as adm
b. svrmgrl
c. connect internal
d. alter database backup controlfile to trace;
e. exit;
f. Above command will generate a .trc file in /oracle/P01/saptrance/usertrace directory.
g. Copy the text from CREATE CONTROLFILE until the (;) and paste it in to any new .sql or controlfile.sql file.
h. Copy the controlfile.sql to target system.
i. Edit the file and replace the entire source SID to target SID.
j. Edit the reuse database command with the set database command

4. Copy the aft generated during the backup file from the source system to target system. (/oracle//sapbackup)
a. Change all the source to target .
b. Only don't change the backup volume name it must be target system .
c. Copy the above aft file name line from the source back.log to target.log file.

5. Shutdown the target server instance.

6. From this onwards all the command on the target system only.
a. Login as adm
b. run the SAPDBA
c. select J (Restore/Recovery)
d. select B (Full restore and recovery)
e. select A (Select backup of type)
f. Select the offline backup which you want to restore.
g. It will take some time to restore.
h. Once the database is restored login as adm and run the
i. svrmgrl
j. connect internal;
k. startup nomount (if the database is already mounted shutdown it using the shutdown command)
l. run the following command
m. @controlfile.sql (file name of the control file contains the CREATE CONTROLFILE statement)
n. After the run the above command it should give the "Statement Processed)
o. alter database open resetlogs p. shutdown
q. Start the database and SAP services using startup.

7. After this you have to reconfigure the STMS.

8. All the jobs also you have to reconfigure and reschedule.

9. Reconfigure all the printers.

10. If you want to change the Client number then use the local copy tool and remove the original client after successfully import to new client.

Proper way to delete a SAP client

Here goes:

1. log into the client to delete
2. go into SCC5 and delete client
3. log into another client and delete entry with SCC4
4. reorg database to recover database space.

Actually, if you check "on" the little "Delete Entry from T000" checkbox, you can skip step 3.

One other way of deleting a client which could give significant performance gain and save time is at OS level using - R3trans

To delete a client 200, you have to create a command file "del200" with following entries

Clientremove
Client = 200
Select *

Place the command file in /usr/sap/trans/bin

$ cd /usr/sap/trans/bin

$ R3trans –w -u 1

e.g $ R3trans -w del200.log -u 1 del200

To check the progress...

$ tail -f del200


Reorg the database post client delete