System Refresh Absoft08 Web Friendly

A Guide to SAP System Refreshes

ABSOFT WHITE PAPER

2 | A Guide to SAP System Refreshes

Contents

Executive Summary

Traditional Client Copy Refresh Method Better the devil you know? The Search for an Alternative Approach System Copy Method Archival of Production Data

SAP Infrastructure Investment

Specialist System Refresh Products Contact Us

4 5 7

8

9

10 11

A Guide to SAP System Refreshes | 3

Executive Summary

What is an SAP system refresh?

Meeting statutory audit requirements

Other benefits include:

The majority of SAP landscapes consist of three or more separate systems: Development, Quality Assurance (test system) and Production (live system). Each system contains one or more clients. A client is a self contained logical unit within a system. Each client contains its own separate data set.

With the increasing pressure on companies to deliver procedures that comply with Sarbanes-Oxley and other audit requirements, system refreshes are no longer a “nice to have” for many SAP customers. It is becoming mandatory for companies to maintain an up-to-date quality assurance environment in order to meet statutory audit needs.

• The ability to test new authorisations or security parameters using copies of live users without affecting the live user data.

In a typical SAP system the production data set is periodically copied onto the Development and Quality Assurance systems in order to allow full testing of customising and development changes that are made to the live SAP system. This is known as a system refresh. The frequency of these refreshes is determined by business and test team requirements but typically several refreshes are performed over the course of a year.

Using real, meaningful data for testing, development and training Aside from regulatory compliance, there are many additional benefits of carrying out regular SAP system refreshes. The main benefit of replicating live data into a quality assurance or development system is that it provides an isolated environment, away from the main business operations where developers and test teams can test any system enhancements or bug-fixes in conditions as close to those in Production as possible.

• Training for new employees and processes can be carried out away from the live system using real meaningful data. • SAP patch upgrades (Support Packages) can be tested in full using a copy of the live system to reduce or remove any errors that might not have been identified in the Development environment. Various options exist for performing a system refresh. The majority of companies will be aware of the traditional method of Client Copies from their initial implementation experience. Some will continue to use this method as their operational requirements allow it, while others quickly identify that there are more effective and appropriate methods of obtaining a copy of their Production environment. The purpose of this white paper is to outline the options available, to identify the advantages and disadvantages of each and to summarise which path may be most suitable for customers in the long term.

4 | A Guide to SAP System Refreshes

Traditional Client Copy Refresh Method Better the devil you know?

Traditionally many SAP customers have used the standard SAP client copy method of system refresh. As the name suggests, this involves the transfer of data from one system to another at a client level. Sufficient storage permitting, this method allows for many copies of the Production client (PRD) to be copied back to multiple clients within a single Quality Assurance system (QAS). This allows project and support teams to test with isolated sets of Production data within the same system. This is illustrated in Fig. 1 to the right.

QAS 100 – Config

321 – Project 1

The main problem with the traditional method of system refresh is that it requires downtime on the live system in order to be carried out successfully. This causes disruption to business operations, which gets worse as time progresses and the amount of data on the system grows.

321 – Project 2

Many of the 70,000 tables that are included in the copy job are related. For example, if a user were to create a new purchase order, many tables may be updated to record the information in the database. However, the client copy job makes no allowances for relationships between the various tables. So, to ensure consistency of the data, no updates should be made to the source client whilst the copy is running. In practical terms this means no users can be logged onto the Production client whilst a client copy is in progress. In order to minimise disruption to the business, client refreshes are always performed during weekend outages at pre-arranged outage windows.

450 - Production

250 – Integration

Can you afford to be locked out of your live system for a weekend?

SAP client copies work by copying all client specific data from source to target client. The client copy job itself is reasonably straightforward in its operation. In essence, there is a list of tables whose contents need to be copied, and a specified number of processes to work with. Each process copies data from source to target one table at a time. When the process finishes copying data for one table it moves on to the next in the list. In an SAP ERP 6.00 system there are approximately 70,000 tables.

PRD

Fig. 1

Client copy Tip I REDUCING SYSTEM DOWN TIME

It is possible to adjust a client copy strategy by performing a client delete in the target system prior to each copy. It can be seen from the graph where this strategy was changed as it reduces the overall downtime in the Production system. The overall result however is that this only delays the inevitable where it becomes impossible to carry out a refresh within the allocated Production downtime window.

Figure 2 on page 6 shows how the client copy times can increase in a typical system of 200 users.

A Guide to SAP System Refreshes | 5

Client Copy Times

20:00:00

Runtime (Hrs)

15:00:00

10:00:00

05:00:00

00:00:00

Jan 07

Feb 07 Mar 07

Apr 07

May 07 Jun 07

Jul 07

Aug 07 Sep 07

Oct 07

Nov 07 Dec 07

Jan 08

Feb 08

Mar 08

Fig. 2 Client copy Tip II REDUCING CLIENT COPY TIME

The number of processes you can define for the copy is limited by the hardware of both source and target host. Through experimentation and experience it is possible to optimise this, for example by applying the rule that two processes per CPU or core are possible.

Increasingly long runtimes present the following problems to all SAP customers: 1. Insufficient Time to Re-run a Failed Copy In the event of a client copy failure it may be necessary to reset and restart the copy procedure. This would entail deleting the data already copied and restarting the copy from the beginning. As refresh times increase, it becomes more difficult to reset and rerun a failed client copy over a single outage weekend. If the copy cannot be completed it leaves the target client in an inconsistent state rendering it useless until a further refresh is completed. A failed client refresh would have a detrimental effect on the users of that client. In the case of an integration testing client, support users would be unable to perform user acceptance testing. In the case of a project specific client, there may be no alternative clients available forcing the potentially costly suspension of project activities until a refresh could be completed. In order to perform a subsequent refresh to repair the client an additional outage of Production would be required. If the initial failure occurs on the weekend before monthend begins it may be two or three weeks until another outage can be scheduled.

6 | A Guide to SAP System Refreshes

2. Greater Likelihood of Communication Failure The client copy process is based on SAP’s remote function call technology. This essentially requires the target system to log onto the source system at an SAP level over a network connection. Although failures with this technology are rare they are not unknown. Network outages, SAP kernel bugs and general hardware failures can all cause these connections to fail. Unfortunately the longer the client copy runs, the greater the likelihood of a failure of this nature being encountered. 3. Availability of Production Outage Windows As the runtime increases the Production outage requirements are going to expand. It will be necessary to either start the copy sooner each weekend or allow it to run for longer impacting live users. Looking further ahead, perhaps 2 or 3 years from the present it is possible to predict future copy times which will clearly show that a single weekend outage window isn’t sufficient. Beyond this point, the business would need to agree on an extended outage of Production which would impact on the Monday to Friday working week. This is unlikely to be an acceptable solution.

The Search for an Alternative Approach System Copy Method

As discussed, the traditional method client copy will become impractical for most customers in the long term and for many SAP customers it is never a viable option because of the large amount of data held on their production system. So, what are the alternatives? System Copy Method An SAP system copy is a widely used solution for refreshing Quality Assurance systems with Production system data. In fact, it is the most commonly used refresh method for medium to large size SAP customers. The process involves taking the latest online Production system backup and restoring this onto the Quality Assurance system hardware. For most databases that SAP runs on a small amount of pre and post processing is required. As the refresh can be performed using a normal online backup no Production system outage is required. System refreshes of this type can normally be completed within less than a day including all pre and post-processing actions. The fundamental difference between a system copy and a client copy is that the whole source system database, client structure and all, is restored onto the target system. This difference is illustrated in Figure 3 on the right. As can be seen in Figure 3 a system copy overwrites the entire system. If the source system has one client and the existing target system has four clients then after a system copy is performed the target system will have a single client which is an exact copy of the source client. There are therefore advantages and disadvantages to this method:

Client Copy

QAS 100 – Config

PRD 450 - Production

250 – Integration 321 – Project 1 321 – Project 2 System Copy

QAS 100 – Config

PRD 450 - Production

Fig. 3 Advantages

Disadvantages

• Fast compared to the traditional client refresh method. Restore time is likely to be around half or less that of a client copy depending on backup hardware available.

• A system copy from Production back to Quality Assurance will provide support and project teams with only a single integration client. This may not be a suitable proposition for some customers. It has always been preferred to set up separate clients within the Quality Assurance system for project testing. A Quality Assurance system outage is required whilst the refresh is in progress.

• In terms of man effort this is comparable to the current client refresh method. • No Production system outages are required as the refresh can be performed using the existing Production system online full backups. • This is a well tested method with proven support from SAP’s own backup and restore tools.

• Refreshes are performed at a system level so this approach does not provide a solution for refreshing any unit test clients in the Development system.

A Guide to SAP System Refreshes | 7

Archival of Production Data

This isn’t a refresh method as such but a way to improve the traditional client copy approach. SAP Archiving is a method of removing old data from the database, storing it at an offline location and making it available for retrieval at a later date. SAP’s data archiving solution complies with statutory data retention rules and ensures that the data is both consistently removed from the database and available for access in the future. Archival of data is based on logical business data types called archiving objects; examples of archiving objects are Purchasing Documents and Credit Memo’s. These objects allow the archiving administrators to work easily with SAP’s complex data model since they are shielded from the underlying raw tables. Each object has a number of automated methods which, amongst other tasks, control whether certain data is written to archive, read from archive or deleted from the database.

8 | A Guide to SAP System Refreshes

Archiving is a three stage process:

1. The administrators determine which data is to be archived for the chosen archiving objects. The data is then copied from the database and written into external archive files. 2. The archiving programs test to see if they can read the data back out of the archive files. If this is successful the data is deleted from the database. 3. The archive files are saved on another server, separate from the SAP database. Depending on industry financial regulations, many SAP customers only consider data archiving for systems which contain more than six years worth of data. In the context of a system refresh, document data archiving could potentially be used to reduce the amount of data stored in a Production client. A reduced dataset would lead to reduced runtimes for any test client refreshes.

Advantages • A reduced production dataset allows Quality Assurance and Development client refreshes to be completed faster. Disadvantages • Complex to set up, requiring input from the business as well as support, functional and technical consultants. • As this is a complex solution it’s likely to be expensive in terms of man hours. • There may be legal requirements to retain data for six years. • Without detailed investigation it is difficult to estimate how much data could be archived. It is therefore difficult to estimate how much client refresh times may be reduced by. • Data archiving would need to be a periodic process as the volume of data in the Production system is always growing.

SAP Infrastructure Investment

Many SAP customers will choose to update their infrastructure and hardware over the lifetime of their SAP systems in order to benefit from the enhanced performance of modern servers and processors. This investment can make it possible to speed up existing client or system copy methods. Client copy and system copy times are physically limited by a number of factors such as: • Speed and number of processors on both source and target server. • Amount of installed memory on both source and target server. • Speed, number and configuration of hard disks on both source and target servers.

In order to fully determine where bottlenecks currently exist, the Production and Quality Assurance systems need to be closely monitored whilst a client refresh is in progress. Where bottlenecks are identified, targeted configuration or hardware upgrades can be investigated with a view to improving overall performance. Hardware vendors can also provide modern disk technologies to allow “snapshots” of live data to be taken and replicated which would combine part of the system copy method with a hardware investment.

Advantages • Has the potential to reduce current client copy times. Disadvantages • Any gains in terms of reduced client refresh times are likely to be short term as copy times are always increasing. It is impossible to estimate how much time can be gained using this option until the investment has been made and the benefits measured. • Depending on where bottlenecks currently exist this may be an expensive option. For maximum benefit bottlenecks should be addressed on the Development, Quality Assurance and Production.

• Speed of network interface between source and target servers.

A Guide to SAP System Refreshes | 9

Specialist System Refresh Products

There are a variety of products on the market now that are specifically designed to solve the problems that SAP customers face, which do not require the Quality Assurance or Development systems to be refreshed.

Gamma InfoShuttle

Advantages

InfoShuttle is a third-party SAP certified solution which offers a systematic method of building test or training scenarios with current data from a Production system. Transferring relational sets of data, InfoShuttle generates the building blocks for Production-like systems. As this can be performed on a selective basis, InfoShuttle dramatically reduces the time taken to build useful Production-like environments. It is this selective nature of InfoShuttle that offers benefits over the current whole client refresh strategy.

• Allows support and project teams to build their own reduced size test data sets. There is no requirement to involve technical support to perform refresh activities.

InfoShuttle requires no dedicated hardware as it essentially runs inside the SAP system. InfoShuttle uses built-in mechanisms to select, check, move and synchronise data between environments through a standard SAP interface via its own SAP transactions. InfoShuttle transfers are performed using selective hierarchical sets of master and transactional data, which automatically detect and include related objects. As a result, setting up the transfer can be done by the analyst who needs the data: i.e. the functional analyst, developer or user acceptance tester. InfoShuttle requires no Production downtime from a business user perspective. There is no requirement for the support and project users to be experienced with the technical aspects of SAP’s data transfer technologies. Data can be moved easily by knowing key elements, like Sales Order Number, Customer Number or Material Number. Since the amount of data defined within a data sub-set is smaller than the complete database, it requires less disk space in the target system, which reduces storage requirements in the nonProduction environments. For non-standard data objects or relationships, such as enhancements or Z-tables, InfoShuttle provides tools that facilitate the creation of custom transfer objects. The linking, done through drag and drop, generates ABAP code that retrieves the Z- table entries from the source and directly updates or creates the same Z- table entries in the target system.

10 | A Guide to SAP System Refreshes

• Offers a solution to copy data back to both Quality Assurance and Development system clients. • Allows specific Production data to be copied back to Quality Assurance or Development clients so it can be investigated by support staff. • Allows specific Production problems to be investigated in non-Productive environments without impacting on the testing activities of other support analysts. • Offers additional flexibility and features over the alternatives discussed here, such as the ability to perform data transfers to non-SAP R/3 systems via XML files. Disadvantages • As a software-based solution, Infoshuttle is a more expensive solution than hardware-based options. The benefits accrued, however, are likely to be proportionately greater due to the flexibility that the tool offers.

AP Test Data Migration Server (TDMS)

Advantages

SAP’s Test Data Migration Server (TDMS) product allows customers to extract transactional data from a Production system whilst retaining the master and customising data of the target test system. The transactional data can be configured to extract all data within a given date range.

• Enables reduced dataset transfers to refresh the target clients.

The TDMS requires its own separate SAP instance. It is based on a Web Application Server 6.40 platform and therefore requires its own hardware with a minimum 4 Central Processing Units, 4GB of Random Access Memory and 20GB hard disk storage for the database. The TDMS instance does not store the data in its own database, rather it uses its memory to filter and pre-process the data prior to copying it to the target client. In order to make use of TDMS you would need to order the basic TDMS service offering from SAP’s consulting services. This offering consists of an initial one day scoping workshop, a ten day project to set up the TDMS server and a final day’s workshop where the operation of the TDMS server is reviewed.

• Caters for individual client refresh giving a solution that supports multiple test clients in both the Quality Assurance and Development systems. Disadvantages • Requires its own dedicated hardware. • Transactional data can only be selected by date range. There is no option to select data by object type such as Purchase Order. • The product is geared towards system administrators with a technical background and would likely not be suitable for general use by support analysts. • Requires the use of SAP’s dedicated consulting group who will charge for the initial system setup. • This is likely to be an expensive offering once consulting, hardware and licensing costs are factored in.

FINDING A SOLUTION THAT FITS It is clear that there are several options available that will address the challenges posed by system refreshes. Some of these options are low cost alternatives that come with their own set of disadvantages, and some require additional investment but offer increased flexibility. In terms of the most complete solution, InfoShuttle offers the best features as a toolset. Of course, these advanced features do carry a cost, however they would allow support and project users to pull back the sub-sets of data they require to facilitate their testing. The current segregated client model would remain in place and no additional hardware would need to be procured or managed. As the support and project teams would be managing their own test data it would remove the need to involve technical support. This would lead to a faster turnaround of both support and project activities as analysts would have access to the data they needed whenever it was required. For SAP customers who do not want to invest in additional software, the system copy method may be the best solution as it is fully supported, reliable and faster than a client copy or the continual archiving of data. However, individual SAP customers must weigh up the costs and benefits of all the options outlined in this paper and choose the one they feel best fits their business requirements. Absoft has over twelve years experience of working with SAP customers to implement and optimise their SAP system landscapes. Since each SAP system is different and comes with its own unique set of challenges, Absoft works in partnership with its customers in order to fully understand their system landscape and plan maintenance and refresh strategies that will provide the best solutions for both the IT department and the business now and into the future. To find out more about how Absoft work’s with SAP customers visit http://www.absoft.co.uk/ workingwithabsoft A Guide to SAP System Refreshes | 11

50 087 696 (07/12) ©2008 SAP AG. All rights reserved. SAP R/3, mySAP, mySAP.com, SAP TDMS, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by Absoft for informational purposes only, without representation or warranty of any kind, and Absoft shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Unlocking Business Potential with SAP® Software Solutions Absoft Limited Davidson House, Campus 1 Aberdeen Science & Technology Park Bridge of Don, Aberdeen, AB22 8GT

Tel: +44 (0) 1224 707088 Fax: +44 (0) 1224 707099 E-Mail: [email protected] Web: www.absoft.co.uk