Ninja Guide SAP System Copy

Basis Technologies International

Ninja guide to

SAP system copies

killer tips for the Basis ninja


you need to test on

production-like data

To be confident in your testing

(so your next SAP project doesnt wreck your business)


Ninja guide to SAP system copies

Basis Technologies SAP User Survey, responses obtained from a survey of attendees during the conferences SAP Tech Ed Las Vegas (October 2013) and SAP TechEd EMEA (November 2012)

so providing testing teams with

regular full SAP system copies can put huge pressure

on the Basis team



Which is why weve created this Ninja guide to faster

homogenous, full SAP system copies



Start the clock - set yourself a task to record how long each step takes. This way, youll quickly be able to see where you might need to optimize

your performance next time - like BDLS, data scrambling.

Chances are there will be a couple of pain points to focus on.

Check youve got enough disk space in your test system before you start. If you think youre going to run into problems, think about

archiving some of your data - pick something easy like I-DOCs - there are some tools out there that make it quick, easy and less of a chore.

A FEW KILLER TIPS BEFORE YOU BEGIN

Make sure you know the passwords for your database users on your source system before getting started. Youll need these to reset the database to the new target name once its been restored onto the

target system.



Save yourself a bit of time and export the RFC destinations ahead of time and import them back in afterwards.

Take a backup of the source system

Use whichever database tools/backup software that youre currently using. If its a production system, chances are youre already performing regular database backups anyway. In which case, you just need to copy the latest backup files to your target system.

Export the data from the target system

Including RFC destinations, users, SAP system profiles, background jobs etc. Printers! Make sure you

identify which parts of your wider IT systems are shared

between Pre-Prod / Prod.

Its easy to forget, but the last thing you need is test invoices

coming out of your test system and being shipped to

your valued customers!!

Shutdown target system

STEP 1. DATA PREPARATION CLONE YOUR DATABASE


Restore the database of the target system from the source system

The way you do this will depend on your database platform or backup tools that you have available.

STEP 2. THE EXECUTION

Run Database Commands to rename the database from the source to the target

Again, use the tools you have available for your current platform.




Disable batch processing on the target system

To do this, you need to edit the instance profile. The easiest way to do this is to edit the instance profile and set the parameter rdisp/wp_no_btc to 0

STEP 2. SAFETY STEPS DONT LET YOUR GUARD DOWN

Isolate the target system from the network

You need to make sure that no ALE processing happens. There are different ways that this can be done. Ideally Production environments will have firewall rules set up so that ALE messages can only come from other Production systems

If this isnt the case, you can put in a temporary firewall to make sure nothing leaves the

target system.



Start up the target system and log on

STEP 3. ISOLATION AND TRANSFORMATION

Disable all Production batch jobs

The easiest way to do this is to edit the instance profile and set the parameter rdisp/wp_no_btc to 0 before starting up the target system. When youre sure that it is safe for backup jobs to start again, change the rdisp/wp_no_btc parameter back to its correct value and bounce the system.

Make sure youve refreshed your RFC destinations.

Clear out IDOC / BDOC queues

Recreate / import RFC destinations

Set up required background jobs



Set up operation modes and switch to a mode that has a background process

Perform post-installation actions from the transport organizer (SE06)

Set up users

Nice and easy use the export you did in Step 1



Our research shows that 58% of SAP System Copies

take over 24 hours to run.

There are now tools on the

market that make BDLS much, much faster like System CopyGT

Take a clean backup

Once BDLS is complete, its a good time to take a clean backup of your newly refreshed target system. Now if you need to go back to a fresh production like instance, you just have to restore from this backup and avoid having to do steps 2 and 3.

Run BDLS

BDLS goes on and onand on and on

90% of the time it take to perform a system copy is due to this one, unavoidable step.

BDLS is basically a massive, glorified find and replace - which chugs through your

database changing the logical system names.

STEP 4. PREPARE TO MEET YOUR NEMESIS BDLS


Notification checklist:

Date / time copy was taken What data / systems have

been copied What transports have been

applied When the next one is due

STEP 5. APPLY CODE AND SCRAMBLE


Reapply any in-flight transports

Perform any data scrambling

If youve got sensitive Production data in your testing system, like payroll details, dates of birth, addresses etc. you will want to scramble - or anonymize - these details before you open it up for your testing teams which can include supplier staff.

This can be quite a lengthy process, but there are some scrambling tools that speed up and automate this step.

Take a look at ScrambleGT for

instance

Notify your users that the system is available

The last thing you need to do is plain and simple communicate. It will be really helpful for your testing teams to have a bit more info. Consider sending them a mini release covering the checklist here -


www.basistechnologies.com

Youre all set!

All you need to do now is share these ninja tips with a fellow Basis geek

Documents

Ninja Guide SAP System Copy