Basis books

SAP AG 1999

TABC10/11 Technical Consultant Training (Week 2)

Technical Consultant TrainingR/3 AdministrationTechnical Consultant TrainingR/3 Administration

TABC10/11 R/3 Release 4.6B 50039590

TABC10/11 R/3 Release 4.6B 50039590

Week 2Week 2

Oct-9-2000

SAP AG 1999

Copyright 2000 SAP AG. All rights reserved.

Neither this training manual nor any part thereof maybe copied or reproduced in any form or by any means,or translated into another language, without the priorconsent of SAP AG. The information contained in thisdocument is subject to change and supplement without priornotice.

All rights reserved.

Copyright

n Trademarks:

n Microsoft ®, Windows ®, NT ®, PowerPoint ®, WinWord ®, Excel ®, Project ®, SQL-Server ®, Multimedia Viewer ®, Video for Windows ®, Internet Explorer ®, NetShow ®, and HTML Help ® are registered trademarks of Microsoft Corporation.

n Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation. n Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc.

n ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken

n Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc. n TouchSend Index ® is a registered trademark of TouchSend Corporation.

n Visio ® is a registered trademark of Visio Corporation.

n IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation. n Indeo ® is a registered trademark of Intel Corporation.

n Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape Communications, Inc.

n OSF/Motif ® is a registered trademark of Open Software Foundation. n ORACLE ® is a registered trademark of ORACLE Corporation, California, USA.

n INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated.

n UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation. n ADABAS ® is a registered trademark of Software AG

n The following are trademarks or registered trademarks of SAP AG; ABAP/4, InterSAP, RIVA, R/2, R/3, R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript, SAPtime, SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and ALE/WEB. The SAP logo and all other SAP products, services, logos, or brand names included herein are also trademarks or registered trademarks of SAP AG.

n Other products, services, logos, or brand names included herein are trademarks or registered trademarks of their respective owners.

Contents

Section: Software Logistics................................................................................................................................................... 1 Introduction..........................................................................................................................................................................2

Introduction to Software Logistics...............................................................................................................................3 R/3 System, Servers, and Instances..............................................................................................................................4 R/3 Data ............................................................................................................................................................................5 R/3 Clients........................................................................................................................................................................6 Standard Client Roles .....................................................................................................................................................7 Additional Client Roles..................................................................................................................................................8 Aims of the R/3 System Landscape.............................................................................................................................9 The SAP-Recommended System Landscape...........................................................................................................10 Transporting Changes...................................................................................................................................................11 Tools for Managing Changes and Transports ..........................................................................................................12 Change and Transport System (CTS)........................................................................................................................13 Summary of this Unit ...................................................................................................................................................14

Change and Transport System Prerequisites.................................................................................................................15 Change and Transport System Prerequisites ............................................................................................................16 Setting Up the System Landscape: Overview..........................................................................................................17 System Landscape Physical Transport Route ..........................................................................................................18 Creating a Transport Directory ...................................................................................................................................19 The Transport Management System (TMS) .............................................................................................................20 What is a System Landscape?.....................................................................................................................................21 Structure of the Transport Management System .....................................................................................................22 Centralized Configuration Data..................................................................................................................................23 Setting Up the Transport Management System .......................................................................................................24 Establishing a Transport Domain ...............................................................................................................................25 Initializing the Transport Domain Controller...........................................................................................................26 Adding Additional R/3 Systems to a Domain ..........................................................................................................27 Transport Domain Management.................................................................................................................................28 Configuring the Transport Control Program tp........................................................................................................29 Configuring Transport Routes ....................................................................................................................................30 Transport Routes ...........................................................................................................................................................31 Graphical Editor ............................................................................................................................................................32 Distribution and Activation of Transport Routes ....................................................................................................33 TMS Authorization Concept.......................................................................................................................................34 Hierarchical List Editor................................................................................................................................................35 Alternative Configuration / Extended Transport Control.......................................................................................36 System Change Options...............................................................................................................................................37 TMS Quality Assurance...............................................................................................................................................38 Configuring the QA Approval Procedure .................................................................................................................39 Verifying TMS Setup ...................................................................................................................................................40 Summary of this Unit ...................................................................................................................................................41 Unit Actions...................................................................................................................................................................42 Change and Transport System Prerequisites: Exercises.........................................................................................43 Change and Transport System Prerequisites: Solutions.........................................................................................45

Change Management for Customizing ..........................................................................................................................48 Change Management for Customizing......................................................................................................................49 What is Customizing? ..................................................................................................................................................50 Customizing from a Technical Perspective..............................................................................................................51 Implementation Guide (IMG) .....................................................................................................................................52 Projects in Customizing ...............................................................................................................................................53 Managing Transports in Projects................................................................................................................................54 Planning Customizing Change Management ...........................................................................................................55 Using the IMG for Customizing.................................................................................................................................56 Customizing Tools ........................................................................................................................................................57 Customizing Organizer................................................................................................................................................58 Change Requests and Tasks ........................................................................................................................................59 Client Change Options.................................................................................................................................................60 Recording of Customizing Changes ..........................................................................................................................61 Transporting Customizing Changes...........................................................................................................................62 Customizing Procedure ................................................................................................................................................63 Testing Customizing Change Requests (1)...............................................................................................................64

Testing Customizing Change Requests (2)...............................................................................................................65 Releasing Customizing Change Requests.................................................................................................................66 Cross-client Customizing.............................................................................................................................................67 Summary of this Unit ...................................................................................................................................................68 Appendix: Customizing Using Current Settings......................................................................................................69 Further Documentation ................................................................................................................................................70 Unit Actions...................................................................................................................................................................71 Change Management for Customizing: Exercises...................................................................................................72 Change Management for Customizing: Solutions...................................................................................................75

Change Management for Developing ............................................................................................................................83 Change Management for Development.....................................................................................................................84 Planning Change Management for Development....................................................................................................85 Customizing Tools vs. Development Tools ..............................................................................................................86 Customizing Organizer vs. Workbench Organizer.................................................................................................87 Workbench Organizer (WBO) ....................................................................................................................................88 Concepts of SSCR Registration..................................................................................................................................89 Correctly Naming Repository Objects ......................................................................................................................90 R/3 Repository Object Attributes...............................................................................................................................91 Development Class.......................................................................................................................................................92 Transport Layers and Development Classes ............................................................................................................93 Classifying Tasks and Change Requests ...................................................................................................................94 R/3 Repository Object Locking ..................................................................................................................................95 Repository Objects: Originals and Copies ................................................................................................................96 Modification Assistant .................................................................................................................................................97 Modification Adjustments after Upgrade..................................................................................................................98 Modification versus Development .............................................................................................................................99 Releasing Change Requests...................................................................................................................................... 100 Version Management................................................................................................................................................. 101 Monitor Transports .................................................................................................................................................... 102 Organizer Tools .......................................................................................................................................................... 103 Workbench Organizer Settings................................................................................................................................ 104 Summary of this Unit ................................................................................................................................................ 105 Appendix: Include objects in request...................................................................................................................... 106 Appendix: Authorizations for Change Management ........................................................................................... 107 Unit Actions................................................................................................................................................................ 108 Change Management for Development: Exercises .............................................................................................. 109 Change Management for Development: Solutions............................................................................................... 113

Transport Management.................................................................................................................................................. 123 Transport Management ............................................................................................................................................. 124 Overview: TMS Transport Strategy....................................................................................................................... 125 Transport Process: Release and Export .................................................................................................................. 126 Transport Process: Import into Quality Assurance.............................................................................................. 127 Transport Process: Quality Assurance.................................................................................................................... 128 Transport Process: Import into Production............................................................................................................ 129 Import Queue Status.................................................................................................................................................. 130 Import Queues and Import Buffers ......................................................................................................................... 131 Import Queue .............................................................................................................................................................. 132 Start Import ................................................................................................................................................................. 133 Start Imports of Complete Projects ......................................................................................................................... 134 Preliminary Import ..................................................................................................................................................... 135 Time and Date of Import........................................................................................................................................... 136 QA Approval............................................................................................................................................................... 137 QA History .................................................................................................................................................................. 138 Special Transport Workflow.................................................................................................................................... 139 Configuring the Special Transport Workflow....................................................................................................... 140 Creating Transport Proposals ................................................................................................................................... 141 Transport Proposal Worklist .................................................................................................................................... 142 Transports Between Transport Groups................................................................................................................... 143 Checking for Critical Objects................................................................................................................................... 144 Monitoring Tools........................................................................................................................................................ 145 Code Freeze and Testing........................................................................................................................................... 146 Timing Transports...................................................................................................................................................... 147 Defining Change and Transport Management...................................................................................................... 148

Summary of this Unit ................................................................................................................................................ 149 Unit Actions................................................................................................................................................................ 150 Transport Management: Exercises.......................................................................................................................... 151 Transport Management: Solutions.......................................................................................................................... 153

Advanced Transport Management............................................................................................................................... 158 Advanced Transport Management.......................................................................................................................... 159 Transport Directory File Name Conventions ........................................................................................................ 160 Introducing tp.............................................................................................................................................................. 161 tp Import Commands................................................................................................................................................. 162 tp Unconditional Import Modes............................................................................................................................... 163 tp Commands for Accessing Buffe rs ...................................................................................................................... 164 ABAP Programs Used in Performing Transports................................................................................................. 165 tp Processing Sequence............................................................................................................................................. 166 Steps during Import (1) ............................................................................................................................................. 167 Steps during Import (2) ............................................................................................................................................. 168 Monitoring and Analysis: tp Log Files................................................................................................................... 169 Monitoring and Analysis: Transport Tool Log Files ........................................................................................... 170 tp Return Codes .......................................................................................................................................................... 171 Troubleshooting (1) ................................................................................................................................................... 172 Troubleshooting (2) ................................................................................................................................................... 173 Cleaning-Up the Transport Directory ..................................................................................................................... 174 Transport Organizer (1)............................................................................................................................................. 175 Transport Organizer (2)............................................................................................................................................. 176 Summary of this Unit ................................................................................................................................................ 177 Appendix: Introducing R3trans ............................................................................................................................... 178 Appendix: Import Process: tp and the Import Buffer........................................................................................... 179 Appendix: Import Process: R3trans........................................................................................................................ 180 Appendix: Import Process: tp / ABAP Communication (1)............................................................................... 181 Appendix: Import Process: tp / ABAP Communication (2)............................................................................... 182 Appendix: Import Process: tp / ABAP Communication (3)............................................................................... 183 Appendix: Additional Transport Profile Parameters............................................................................................ 184 Appendix: Predefined Transport Profile Variables .............................................................................................. 185 Appendix: tp Commands.......................................................................................................................................... 186 Appendix: tp Steps..................................................................................................................................................... 187 Appendix: Complete List of tp Action Types ....................................................................................................... 188 Appendix: TRBAT Function Codes ....................................................................................................................... 189 Appendix: Log Files for Importing DEVK900021 .............................................................................................. 190 Unit Actions................................................................................................................................................................ 191 Advanced Transport Management: Exercises....................................................................................................... 192 Advanced Transport Management: Solutions....................................................................................................... 194

Client Tools ..................................................................................................................................................................... 200 Client Tools ................................................................................................................................................................. 201 Client Tools: Overview............................................................................................................................................ 202 Client Copy and Transport Tools ............................................................................................................................ 203 Local Client Copy...................................................................................................................................................... 204 Remote Client Copy .................................................................................................................................................. 205 Client Transport: Export Process............................................................................................................................. 206 Client Transport: Import Process............................................................................................................................. 207 Profile Selection ......................................................................................................................................................... 208 System Requirements ................................................................................................................................................ 209 Client Copy Using Parallel Processing................................................................................................................... 210 Copy Logs and Control Information....................................................................................................................... 211 Client Copy: Monitoring and Troubleshooting..................................................................................................... 212 Client Delete ............................................................................................................................................................... 213 Client Compare ........................................................................................................................................................... 214 Client Compare: Selection Options......................................................................................................................... 215 Client Compare: Difference List ............................................................................................................................. 216 Adjusting Customizing Objects ............................................................................................................................... 217 Client Maintenance Settings..................................................................................................................................... 218 Authorization Objects for Client Tools .................................................................................................................. 219 Summary of this Unit ................................................................................................................................................ 220 Appendix: SAP Standard Client Copy Profiles .................................................................................................... 221 Appendix: Table Delivery Classes .......................................................................................................................... 222

Further Documentation ............................................................................................................................................. 223 Unit Actions................................................................................................................................................................ 224 Client Tools: Exercises.............................................................................................................................................. 225 Client Tools: Solutions.............................................................................................................................................. 227

OCS Patches and R/3 Upgrades................................................................................................................................... 230 OCS Patches and R/3 Upgrades .............................................................................................................................. 231 Evolution of an R/3 Production System................................................................................................................. 232 R/3 Release Strategy.................................................................................................................................................. 233 OCS: Hierarchy of SAP Software Components ................................................................................................... 234 Online Correction Support (OCS) ........................................................................................................................... 235 SAP Patch Manager (Transaction SPAM)............................................................................................................. 236 Applying Support Packages ..................................................................................................................................... 237 Applying Patches in a Three-System Landscape.................................................................................................. 238 Manual Corrections Based on SAP Notes ............................................................................................................. 239 Upgrade Project Overview....................................................................................................................................... 240 System Upgrade Process........................................................................................................................................... 241 Preserving Customer Objects and Modifications................................................................................................. 242 Preparing the Repository Switch ............................................................................................................................. 243 Performing the Repository Switch .......................................................................................................................... 244 Modification Adjustment Transactions.................................................................................................................. 245 Modification Adjustment Process (1) ..................................................................................................................... 246 Upgrade: OCS and Modification Adjustment....................................................................................................... 247 Upgrading a Three-System Landscape................................................................................................................... 248 Avoiding Modifications in Future Upgrades......................................................................................................... 249 Summary of this Unit ................................................................................................................................................ 250 Appendix: Upgrade Planning Strategies ................................................................................................................ 251 Appendix: Planning with the Upgrade Assistant.................................................................................................. 252 Appendix: Upgrade Preparation with PREPARE (1) .......................................................................................... 253 Appendix: Upgrade Preparation with PREPARE (2) .......................................................................................... 254 Unit Actions................................................................................................................................................................ 255 OCS Patches and R/3 Upgrades: Exerc ises........................................................................................................... 256 OCS Patches and R/3 Upgrades: Solutions........................................................................................................... 257

System Landscape Strategies ....................................................................................................................................... 259 System Landscape Strategies................................................................................................................................... 260 R/3 in a Single-System Landscape.......................................................................................................................... 261 R/3 in a Two-System Landscape............................................................................................................................. 262 R/3 in a Three-System Landscape........................................................................................................................... 263 System Landscape Requirements (1)...................................................................................................................... 264 System Landscape Requirements (2)...................................................................................................................... 265 ASAP System Landscape Setup (1)........................................................................................................................ 266 ASAP System Landscape Setup (2)........................................................................................................................ 267 ASAP System Landscape Setup (3)........................................................................................................................ 268 ASAP System Landscape: Summary (1) ............................................................................................................... 269 ASAP System Landscape: Summary (2) ............................................................................................................... 270 Alternative System Landscape Setup (1) ............................................................................................................... 271 Alternative System Landscape Setup (2) ............................................................................................................... 272 Alternative System Landscape Setup (3) ............................................................................................................... 273 Alternative System Landscape Setup (4) ............................................................................................................... 274 Alternative System Landscape Setup (5) ............................................................................................................... 275 Alternative System Landscape: Summary (1)....................................................................................................... 276 Alternative System Landscape: Summary (2)....................................................................................................... 277 System Landscape Maintenance.............................................................................................................................. 278 Database Copy for System Landscape Setup (1).................................................................................................. 279 Database Copy for System Landscape Setup (2).................................................................................................. 280 Complex System Landscapes................................................................................................................................... 281 Phased System Landscape........................................................................................................................................ 282 Global System Landscape......................................................................................................................................... 283 Summary of this Unit ................................................................................................................................................ 284 Further Documentation ............................................................................................................................................. 285 Unit Actions................................................................................................................................................................ 286 System Landscape Strategies: Exercises................................................................................................................ 287 System Landscape Strategies: Solutions................................................................................................................ 288

Upgrade Guide ................................................................................................................................................................ 289

Upgrade Guide............................................................................................................................................................ 290

Section: R/3 Technical Implementation and Operation Management.......................................................................291 Implementation with ASAP.......................................................................................................................................... 292

Implementation with ASAP ..................................................................................................................................... 293 Choosing a Suitable Implementation Strategy (1)................................................................................................ 294 Choosing a Suitable Implementation Strategy (2)................................................................................................ 295 Choosing a Suitable Implementation Strategy (3)................................................................................................ 296 TeamSAP Components............................................................................................................................................. 297 AcceleratedSAP - SAP´s Full Life-Cycle Solution.............................................................................................. 298 What Does ASAP Offer You? ................................................................................................................................. 299 ASAP Implementation Assistant Hierarchyand Scheduling............................................................................... 300 The ASAP Implementation Assistant..................................................................................................................... 301 Phase 1: Project Preparation..................................................................................................................................... 302 Phase 2: Business Blueprint ..................................................................................................................................... 303 Phase 3: Realization................................................................................................................................................... 304 Phase 4: Final Preparation ........................................................................................................................................ 305 Phase 5: Go Live and Support.................................................................................................................................. 306 ASAP Supports Continuous Improvement............................................................................................................ 307 ASAP Roles (1) .......................................................................................................................................................... 308 ASAP Roles (2) .......................................................................................................................................................... 309 Project Duration: Example ....................................................................................................................................... 310 Implementation with ASAP: Unit Summary ......................................................................................................... 311 Further Documentation ............................................................................................................................................. 312 Appendix: ASAP and SAP Consulting Services .................................................................................................. 313 Appendix: ASAP and SAP Education Services.................................................................................................... 314 Exercises...................................................................................................................................................................... 315 Solutions...................................................................................................................................................................... 316

Overall Design ................................................................................................................................................................ 318 Overall Design............................................................................................................................................................ 319 System Sizing: Key Questions................................................................................................................................. 320 The Sizing Process..................................................................................................................................................... 321 Factors Affecting Sizing ........................................................................................................................................... 322 Quick Sizer on SAPNet............................................................................................................................................. 323 ASAP Phases: System Sizing .................................................................................................................................. 324 Network Design: Key Questions............................................................................................................................. 325 Network Load Caused by User Interaction............................................................................................................ 326 Calculating Line Capacity ........................................................................................................................................ 327 Router and SAProuter ............................................................................................................................................... 328 Network Structure: An Example ............................................................................................................................. 329 ASAP Phases: Network Design............................................................................................................................... 330 Security: Key Questions............................................................................................................................................ 331 Security Aspects ......................................................................................................................................................... 332 Security: Presentation and Application Layers ..................................................................................................... 333 Security: Database and Operating System Layers................................................................................................ 334 Security: Communication Layer.............................................................................................................................. 335 ASAP Phases: Security ............................................................................................................................................. 336 Interfaces: Key Questions......................................................................................................................................... 337 Determine Required Interfaces ................................................................................................................................ 338 Restart and Recovery................................................................................................................................................. 339 R/3 Interfacing Techniques ...................................................................................................................................... 340 Interface Integration: Two Examples ..................................................................................................................... 341 Scalability for Internet Transactions....................................................................................................................... 342 Internet Application Components (IACs).............................................................................................................. 343 ASAP Phases: Interfaces........................................................................................................................................... 344 High Availability: Key Questions........................................................................................................................... 345 What is High Availability?....................................................................................................................................... 346 Considerations for High Availability...................................................................................................................... 347 Crash Kit ...................................................................................................................................................................... 348 Notification, Escalation, and Recovery .................................................................................................................. 349 ASAP Phases: High Availability............................................................................................................................. 350 Overall Design: Unit Summary ............................................................................................................................... 351 Further Documentation (1)....................................................................................................................................... 352 Further Documentation (2)....................................................................................................................................... 353

Exercises...................................................................................................................................................................... 354 Solutions...................................................................................................................................................................... 355

Going Live....................................................................................................................................................................... 356 Going Live................................................................................................................................................................... 357 ASAP Phases for Going Live................................................................................................................................... 358 A Model Going Live Project.................................................................................................................................... 359 Verifying Change and Transport Management..................................................................................................... 360 System Tests: Core R/3 Transactions..................................................................................................................... 361 System Tests: Stress Test.......................................................................................................................................... 362 System Tests: Stress Test Methodologies.............................................................................................................. 363 Cutover: Testing and Data Conversion .................................................................................................................. 364 Cutover: Preproduction Data Load ......................................................................................................................... 365 Verification and Fine Tuning................................................................................................................................... 366 GoingLive Check Sessions....................................................................................................................................... 367 Going Live: Typical Problems ................................................................................................................................. 368 Going Live: Unit Summary ...................................................................................................................................... 369 Further Documentation ............................................................................................................................................. 370 Exercises...................................................................................................................................................................... 371 Solutions...................................................................................................................................................................... 372

Technical Operation....................................................................................................................................................... 373 Technical Operation................................................................................................................................................... 374 Your R/3 Technical Operations Manual................................................................................................................ 375 Service Level Agreements........................................................................................................................................ 376 SAP Support................................................................................................................................................................ 377 Assistance Throughout the Entire Life Cycle ....................................................................................................... 378 Support and Escalation.............................................................................................................................................. 379 SAP Services............................................................................................................................................................... 380 ASAP Phases: Technical Operation Tasks ............................................................................................................ 381 Technical Operation: Unit Summary ...................................................................................................................... 382 Further Documentation ............................................................................................................................................. 383

SAP AG 1999

Section: Software Logistics

Introduction Advanced TransportManagement

Change and TransportSystem Prerequisites Client Tools

Change Managementfor Customizing

OCS Patches and R/3Upgrades

Change Managementfor Developing

System LandscapeStrategies

Transport Management Upgrade Guide

SAP AG 1999








Introduction

SAP AG 1999

Introduction to Software Logistics

Contentsl Parts of an R/3 System landscape

l The SAP-recommended system landscapel Making and transporting changes in the system landscape

ObjectivesAt the end of this unit, you will be able to:

l Define the types of R/3 Systems, servers, instances, R/3 data,and clients

l Outline the aims of different client roles and of the systemlandscape as a whole

l Explain the systems and clients in a recommended R/3 Systemlandscape

l Outline management tools for changes and transportsl Outline the components of the Change and

Transport System (CTS)

SAP AG 1999

Databasefor C11

Database Server "dbserver"

Application Server A3



R/3 Central instance "DVEBMGS00"

R/3 instances "D00" + "D01"R/3 instance "D00" R/3instances"D00" +"D01"

Presentation Servers

R/3 SystemC11

R/3 System, Servers, and Instances

n An R/3 instance is a group of R/3 services that are started and stopped as a unit (by an R/3 dispatcher) and have a common instance profile. The name of an R/3 instance is composed of letters standing for the relevant services, and an instance number which is unique for each computer. The services may be D, V, E, B, M, G, or S, which respectively stand for dialogue, update, enqueue, background, message, gateway, and spool services.

n The diagram shows an example of an R/3 System, C11, comprising:

� A database server containing the central R/3 instance and a relational database. The database server is the computer (dbserver) on which the Relational Database Management System (RDBMS) is installed. Note: In general, there may or may not be an R/3 instance installed on the database server.

� Three application servers (A1, A2, and A3), on which five additional R/3 instances (D00, D00, D01, D00, and D01) are installed. An application server is a computer on which one or more R/3 instances are installed.

� Several presentation servers (frontends) on which the user interface SAPGUI is installed.

n A central instance is an R/3 instance which contains the message service, and typically contains all R/3 Services (and is named, for example, DVEBMGS00). A central system is an R/3 System consisting of an RDBMS service and the central instance. A dialogue instance is an R/3 instance consisting of dialogue work processes.

SAP AG 1999

Customizing data

Usermaster data

Client 033

Applicationdata

Customizing data

Usermaster data

Client 044

Applicationdata

ABAP DDIC

Repository Tools:• Object browser• ABAP editor• Function builder• Screen painter• Menu painter

Runtime environmentof the application:• ABAP interpreter• Screen interpreter• Call interfaces• Dialog controlData

model

Cross-client Customizing

R/3 Repository objects

Cross-client

Client-

specific

R/3 Data

n R/3 data can be divided into two categories:

� Client-specific data is data affecting only one client, such as user master and application data.

� Cross-client data is data affecting the whole system environment, such as cross-client Customizing data and all Repository objects.

n The ABAP Dictionary is a data dictionary that is part of the ABAP Repository:

� Each piece of ABAP Dictionary information is entered only once and is then available anywhere in the system at any time. The ABAP Dictionary automatically supplies all new or changed information, thus providing current runtime objects and ensuring data consistency and security.

� The R/3 runtime environment consists of all ABAP programs required during R/3 execution. The ABAP interpreters in the runtime environment do not use the original of an ABAP program. Rather, they use a copy generated once only during runtime (early binding). Runtime objects, such as programs and screens, are automatically regenerated (late binding) when a time stamp comparison between the object and the ABAP Dictionary detects a difference.

� This combination of early binding and late binding ensures that the active integration of ABAP Dictionary information does not affect system-wide performance. All performance-critical information is stored in the runtime objects and is always kept up-to-date.

SAP AG 1999

Customizing data

Usermaster data

Client

Applicationdata

R/3 Clients

l A client:

n Is a unit of the R/3 System that is technically, organizationally,and commercially self-contained

n Has its own set of user master data, applicationdata, and Customizing based on table keyranges

l Technical implementationof clients:

n All users must log into a specificclient within an R/3 System

n Application data (master andtransaction data) belongs only toone specific client

n A client is a self-contained unit in commercial, organizational, and technical terms, with its own user master data and set of table key ranges.

n Data from different clients is kept separate at the R/3 kernel level. SQL statements executed by an application use the client number in the where-clause. Although a table may contain data from several different clients, the where-clause limits access to particular clients.

n Examples of client-specific data include:

� User master data – such as parameters, authorization, user groups

� Customizing data – such as organizational units, assignments, and document types

� Application data – such as business transaction data, and material master data

n The SAP client concept can integrate several companies or subsidiaries in a single R/3 client – by using company codes and the SAP authorization concept.

� Company codes define the smallest corporate organizational units for which a complete self-contained set of accounts can be drawn up for external reporting.

� The SAP authorization concept enables the parent company to access all subsidiaries for report purposes, while subsidiary-specific data is protected against access from other subsidiaries through company code definition.

SAP AG 1999

CUST

QTST

PROD

Development andDevelopment andCustomizingCustomizing

Quality assuranceQuality assurance

ProductionProduction

For configuring client settings andcreating new functionality

For testing functionality andverifying configuration

For productive activities andbusiness data

Standard Client Roles

n The standard client roles fulfill the optimal minimum requirements of your R/3 System:

� Client CUST is the central Customizing client where complete adaptation of R/3 to customer-specific needs takes place. All changes performed in this client are recorded so they can be supplied to the other clients using the Transport Management System.

� Client QTST is used to test and verify the new Customizing settings in the application.

� Client PROD is the client for production activities, that is, where your company's business is carried out. Customizing changes imported into this client have to be first tested carefully in the QTST client in order to ensure that production operation is free of disruption.

n To realize the full benefit of a three system landscape, every critical client should have a separate R/3 System.

SAP AG 1999

SAND SandboxSandbox

TestTest

TrainingTraining

For experimenting withCustomizing transactions andsettings

For testing configuration settingsusing data

TRNG For end-user training

TEST

Additional Client Roles

n Additional clients within a system landscape may include:

� A sandbox client for experimenting with transactions and settings

� A test client so that Customizing changes can be verified against sample data

� A end-user training environment

n Additional client roles can be implemented according to customer-specific needs.

SAP AG 1999

Aims of the R/3 System Landscape

l The system landscape should enable you to:

n Protect application data using:

w Client roles

w Authorization concepts

n Perform development, quality assurance, and productionactivities in separate environmentsto ensure:

w Consistency of Repository objects

w A secure and stable production environment

n To maintain data security, protect application data by using the client concept, which separates data according to clients, and the authorization concept, which separates data within one client according to user.

n In addition, you should strictly separate the environments for development, quality assurance, and production, because:

� If data is lost, a client can only be rebuilt consistently if test master data and Customizing data are held in separate data environments.

� The performance of the production client should not be affected by development and test activities in the other clients.

� Changes to Repository objects are client-independent, and immediately affect the runtime environment. Therefore, changes have to be tested before being transported to the production system.

� If you had only one system, no further development would be possible after production had started. Changes to Repository objects could be made only when production operations were stopped for development and testing.

n A two-system landscape is not optimal because development and quality assurance testing both occur in the development system. Since no separate quality assurance system is available, all objects transported to the consolidation system immediately become part of the production system.

SAP AG 1999

ProductionDevelopment QualityAssurance

SAND

TEST CUST QTST TRNG PROD

The SAP-Recommended System Landscape

n To ensure smooth production operation, an R/3 System landscape should contain the three R/3 Systems, the standard clients, and any required additional clients.

n A three-system landscape is the recommended R/3 System landscape and meets the needs of most customers:

� Development takes place in the development system. Changed objects are then released to the quality assurance system.

� In the quality assurance system, new developments can be tested without affecting the production environment. A quality assurance system enables you to integrate development efforts and to check the validity and consistency of transported objects before moving the objects into production.

� All objects imported into the quality assurance system can also be delivered to one or more production systems.

n The three system landscape is also a basis for performing an R/3 Release upgrade.

n R/3 Systems in the same system landscape require unique system names.

SAP AG 1999

Customers must customize R/3to meet the needs of their

business flow AND may requireadditional functionality created

with the ABAP Workbench

CUST

QTST

Transports arerequired to movechanges through

the systemlandscape.

TEST

Transporting Changes

n More than 800 business process chains with their associated functions are represent in the R/3 System. During implementation of these process chains, the different characteristics of the standard solutions needed for different branches of industry and company types, including multiple languages and national particularities, are realized through Customizing. Customizing changes are required for all implementations of R/3. New functionality beyond that provided by SAP may be realized using the development tools of the ABAP Workbench.

n Though Customizing and development, the R/3 System can be adapted to changed business processes even after installation, and in productive operation. To ensure consistency, Customizing and development are distributed to other clients within the same R/3 System and to other R/3 Systems.

n Transporting is the process by which changes are distributed within a system landscape.

SAP AG 1999

Who?Who?

When?When?

How?How?

What?What?

“Do not let the“Do not let theprocess manageprocess manage

you!”you!”

Tools for Managing Changes and Transports

R/3 provides tools for:

l Auditing changes made in all R/3 Systems:

n Recording changes to change requests

n Documenting changes

l Controlling by whom and where changes are made:

n Client change options

n System change options

n User authorizations

l Establishing where and when changes are distributed:

n Setting up the Transport Management System (TMS)

n Setting up a client using client tools

n Managing the import process

l Supporting R/3 Release changes and upgrades

n R/3 provides the tools required for the creation, documentation, and distribution of changes within a system landscape. To set up the system landscape so that it supports the management, verification, and testing of all changes:

� A single client is recommended for all Customizing work. Set client change options appropriately before using your clients.

� A single R/3 system (the development system) is recommended for all development work. Set the system change options appropriately.

� To create and assign appropriate user authorizations to developers and customizers, use the sample profiles included in R/3. These authorizations control whether a user can create, modify, or release change tasks and requests.

� Record and document all changes to a client or system.

n The way in which R/3 enables service and support is one of the decisive factors for a stable production environment. SAP provides a comprehensive concept for service and support, including advance corrections, and the Online Correction Support (OCS), which provides Support Packages and other patches.

SAP AG 1999

CTS

Change and Transport Organizers(CTO)

WorkbenchOrganizer

SE09

CustomizingOrganizer

SE10

TransportOrganizer

SE01

TransportManagement

System (TMS)

STMS

Transport Tools

tp and R3trans

Change and Transport System (CTS)

n In R/3 Release 4.0, SAP has introduced the Change and Transport System (CTS), comprising the following tools:

� The Change and Transport Organizer (CTO) provides functions for organizing software development projects. It is designed to support projects of all sizes, whether they are carried out centrally or in a distributed environment.

� The Transport Management System (TMS) organizes, monitors, and performs transports for all R/3 Systems within a system landscape. In addition, TMS is used to configure and manage the setting up of R/3 Systems and transport routes within a system landscape.

� Operating system transport tools are executables that communicate with the R/3 System, the database, and files generated during the export process.

SAP AG 1999

Summary of this Unit

Now you are able to:

l Define the types of R/3 Systems, servers,instances, R/3 data, and clients

l Outline the aims of different client roles and ofthe system landscape as a whole

l Explain the systems and clients in arecommended R/3 System landscape

l Outline management tools for changes andtransports

l Outline the components of the Change andTransport System (CTS)

n Software logistics provides procedures for development and Customizing which enable you to maintain order among all the R/3 Systems and clients in your system landscape.

n Development and Customizing, quality assurance testing, and production work are performed in different clients in one or more R/3 Systems. Three R/3 Systems are recommended, to allow you to:

� Test the transport of changes from one system to another before transporting these changes to the production system.

� Create cross-client changes so as not to affect the production environment without previous testing. Note that, while most Customizing work is client-specific, all Repository objects and global settings are cross-client.

� Avoid development occurring in the production system – for reasons of security, system load, and the need to test any change without endangering the production environment.

SAP AG 1999








Change and Transport System Prerequisites

SAP AG 1999

Change and Transport System Prerequisites

Contentsl Setting up a system landscape

l Change and Transport Organizer (CTO)l Transport Management System (TMS)

ObjectivesAt the end of this unit, you will be able to:l Set up the common transport directory

l Initialize the Change and Transport Organizer (CTO)l Explain TMS functions

l Monitor TMS setup in all R/3 Systems in the system landscape

SAP AG 1999

install

install

Setting Up the System Landscape: Overview

l Before R/3 and database installation:

n Define the network structure for thesystem landscape

n Install the hardware and the operating system

l During R/3 and database installation:

n Create a common transport directory

l After R/3 and database installation:

n For database copy, initialize the Change and TransportOrganizer (CTO)

n Set up the Transport Management System (TMS)

n To set up your system landscape:

� Install an R/3 System as a development system; the quality assurance and production R/3 Systems are not required at this stage.

� Create a transport directory at operating system level. This directory is required for the Transport Management System.

� If you have performed a database copy, initialize the Change and Transport Organizer (CTO) using Transaction SE06.

� Configure the system landscape using the Transport Management System (TMS) using Transaction STMS.

n To enable transports in a heterogeneous operating system environment, you must set up different transport directories. However, to enable transports in a heterogeneous operating system environment using a single transport directory, refer to SAP Note 83327 in SAP's Internet site, SAPNet, under the alias “notes”.

SAP AG 1999

Export Import Import

...

System Landscape Physical Transport Route

ProductionDevelopment Quality Assurance

SAND

TEST CUST QTST TRNG PROD

Transport Directory

n Transporting enables you to synchronize Customizing and development in multiple R/3 Systems through the transfer of changes from the development system to downstream systems. Transports along the transport route must occur in only one direction.

n Transporting requires a transport directory to enable R/3 Systems in the system landscape to store and access various data files, command files, and log files.

n Physically, changed objects in a three-system landscape are transported in three steps:

n All objects in a change request that is to be released are exported – by being "copied" – from the database of the source system to the transport directory.

n The objects are imported into the database of the quality assurance system.

n After testing and verification, the objects can be imported to the defined delivery systems.

SAP AG 1999

Transport Directory

.

..

sapnamescofiles

bufferlog

actlog

olddataEPSdata

bin tmp

trans

Creating a Transport Directory

Development

QualityAssurance

n The global transport directory and all the necessary subdirectories are created during the installation of an R/3 System. Mount this directory using the operating system tools (nfs for UNIX; share for NT) for all systems within a system landscape or a transport group. The amount of disk space required depends on the amount of development work: estimate 10 MB for each customizer and developer. You will need additional space for client exports. The R/3 Parameter DIR_TRANS has to point to the path of the transport directory. For Unix, the default path is /usr/sap/trans. For Windows NT, the default path is \\$(SAPTRANSHOST)\sapmnt\trans and you must define the transport host with the alias SAPTRANSHOST on the domain name server.

n The subdirectories required in the common transport directory include:

� bin: Configuration files for tp (TP_<DOMAINNAME>.PFL) and TMS (DOMAIN.CFG)

� data: Exported data

� olddata: Old exported data (to be archived or deleted)

� log: Transport logs, trace files, and statistics

� actlog: Action logs for all tasks and requests

� buffer: Transport buffer for the each system, indicating which transports are to be imported

� cofiles: Command or change request infrmation files that include information on the transport type, object classes, required import steps, and post-processing exit codes

� sapnames: Information pertaining to transport requests for each SAP user

� EPS: Download directory for advanced corrections and Support Packages

� tmp: Temporary data and log files

SAP AG 1999

Concepts behind the TMS:

l Centralized configuration of Change and Transport

System (CTS) for all R/3 Systems

l Centralized management of change requests and the

import process

l Transport strategy based on predefined transport routes

The Transport Management System (TMS)

n The Transport Management System (Transaction STMS) enables you to:

� Define an R/3 System's role within a system landscape or transport domain

� Configure the transport routes using either a graphical editor or hierarchical editor

� Configure the transport tool transport control program tp.

� Display the import queues of all R/3 Systems in the transport domain

� Decide whether the quality assurance testing was successful in the QA System

� Start the import of change requests in an import queue

� Perform transports between R/3 Systems without a common transport directory

� Handle transport proposals of developers

SAP AG 1999

DV1

QA1

PR1

DV2 PR2

Systemlandscape forthe Europeanimplementation

Systemlandscape forthe Asianimplementation

TransportTransport DomainDomain

What is a System Landscape?

QA2

n With R/3 Release 4.0, SAP introduced the TMS and the concept of a transport domain (all R/3 Systems to be managed centrally using the TMS) and a transport group (all R/3 Systems that share the same transport directory and belong to the same transport domain).

n The term system landscape refers to the group of R/3 Systems normally comprising the development system, the quality assurance system, and the production system. A system landscape consists of all the R/3 Systems that share change requests for the purpose of maintaining consistent Customizing and development environments.

n A system landscape is usually synonymous with a transport domain. Having all R/3 Systems of the same system landscape in the same transport domain ensures consistent configuration and easy delivery of all change requests.

n A transport domain may, however, contain more than one system landscape. For example, a company may have different system landscapes for each subsidiary. These R/3 implementations are very different and do not share change requests. To benefit from centralized configuration with the TMS, you can include both system landscapes in the same transport domain.

SAP AG 1999

Transportgroup 1

Transportgroup 2

Transport domain 2

Transport group

Transport domain 1

= Transport domaincontroller

Structure of the Transport Management System

Transport Directory

Transport Directory

Transport Directory

n The TMS supports several transport directories within a transport domain. The R/3 Systems with a common transport directory each form a transport group.

n Transports between different transport groups are supported by the TMS; transports between different transport domains are only supported by external systems.

n In most implementations of R/3, a customer only needs one transport domain and one transport group. If more than one transport directory is needed, additional transport groups are required.

n All R/3 Systems to be administered using the TMS belong to a transport domain. Within this transport domain, certain system settings such as the transport route settings are identical for all R/3 Systems. In order to have consistent settings, in the transport domain, one R/3 System (the domain controller) has the reference configuration, and all the other R/3 Systems in the transport domain receive copies of this reference configuration.

SAP AG 1999

Transport Domain

Domain Controller

RFC

RFC

RFC

l A transport domaincomprises all R/3 Systemsjointly administrated throughthe TMS

l Transport paths are centrallyconfigured from each R/3System to all other R/3Systems

l The domain controllerdefines the referenceconfiguration

l All other R/3 Systemsautomatically receive copiesof the referenceconfiguration

Centralized Configuration Data

n When setting up an R/3 System with the TMS, you include the R/3 System in an existing or new transport domain.

n All R/3 Systems in a transport domain must have unique system IDs, and may or may not share the same transport directory.

n Within a transport domain, the TMS enables RFC communication between all R/3 Systems, for example, to distribute configuration changes or perform imports.

n Changes to the transport domain configuration are made in the domain controller, and then distributed to all R/3 Systems in the transport domain. Each time you make a change to the domain controller, a dialog box is displayed asking whether to distribute the change. You can distribute several changes at one time.

SAP AG 1999

Create a Transport Domain andTransport Domain Controller

ConfigureTransport Routes

QAProcedure

Configuration

Setting Up the Transport Management System

n Before you can work with the TMS, you must configure the TMS on all R/3 Systems in your system landscape.

n To configure the TMS:

� Configure the transport domain Assign R/3 Systems to the transport domain, and specify one R/3 System as the transport domain controller.

� Configure transport routes The transport routes are used to define both the target system in which you want to consolidate change requests, and the R/3 Systems to which change requests are delivered after verification and testing.

� Configure Quality Assurance (QA) Procedure Define a QA system, where the decision is made whether objects may be further transported to the production system.

n After setting up the TMS, use the TMS tools to check and monitor TMS configuration.

n The transport domain and transport groups define which R/3 Systems are managed by the TMS and which systems share the same transport directory. Transport routes define how change requests are transported and thus strictly reflect the system landscape implementation process.

SAP AG 1999

Transport domain

QAS

Transport group

Domain Controller

Establishing a Transport Domain

Transport Directory

n The transport domain contains all R/3 Systems whose transports are to be administrated jointly. One of these R/3 Systems is chosen as the transport domain controller.

n Since all activities relevant to the entire transport domain, such as configuring transport routes or RFC connections, can only be carried out on the domain controller, the R/3 System selected to be the domain controller should have:

� High availability

� A high level of security

� A high level of maintenance

n The domain controller is normally configured on a production system or a quality assurance system.

n The system load on the R/3 System that is chosen as the domain controller is low, and only increases for a short period when the TMS configuration is changed.

SAP AG 1999

Transaction STMS in client 000 will:

l Assign the R/3 System as the transport domain controllerl Create transport domain name DOMAIN_<SID>l Create transport group GROUP_<SID>l Create CPIC user TMSADM in client 000l Create RFC destinationsl Set up file DOMAIN.CFG in directory bin of the transport directory

Initializing the Transport Domain Controller

n To activate the TMS on an R/3 System, run Transaction STMS in client 000 with user authorization S_CTS_ADMIN.

� If the R/3 System is already assigned to a transport domain, the TMS initial screen shows the system's status, either as a domain controller, or as an R/3 System within a domain.

� If the R/3 System is not yet assigned to a transport domain, R/3 tries to locate an existing transport domain within the current transport group by reading the file DOMAIN.CFG in the directory bin of the common transport directory. If no transport domain exists, a new transport domain is created, and the current R/3 System is assigned as the transport domain controller.

n When a transport domain controller is first created, the TMS generates:

� A transport domain and a transport group

� User TMSADM

� The RFC destinations required for the TMS

� File DOMAIN.CFG in directory bin of the common transport directory, for storing the TMS configuration

n The name of the transport domain may not contain blanks and may not be changed afterwards without reconfiguring the domain controller. By default, a transport domain will have the name DOMAIN_<SID>, where <SID> is the system ID of the domain controller.

SAP AG 1999

Transaction STMS in client 000 will:l Obtain the transport domain controller address from

DOMAIN.CFG (or you can explicitly define the address)l Create CPIC user TMSADM in client 000l Generate RFC destinations automaticallyl Send the R/3 System’s request for participation in the

transport domain to the transport domain controller

From the transport domain controller, you can:l Accept participation of additional R/3 Systemsl Test and verify TMS configuration and

communication between R/3 Systems

Adding Additional R/3 Systems to a Domain

APPROVEDELETE

n After configuring an R/3 System as the transport domain controller, each additional R/3 System must apply for inclusion to the transport domain controller. The transport domain controller then must confirm inclusion for each R/3 System. The initial screen of Transaction STMS indicates if an R/3 System is waiting for inclusion in the transport domain.

n After you have included an R/3 System from one of the transport groups in the transport domain, the description of the transport domain is stored in the file DOMAIN.CFG in the common transport directory. All other R/3 Systems connected to this transport directory read the file DOMAIN.CFG during STMS initialization to identify the domain controller and transport group address. If your R/3 Systems do not have a common transport directory, you can manually configure TMS with the address of the domain controller.

n When an R/3 System has been configured for the TMS and accepted in the domain, you will find a newly created user TMSADM and generated RFC destinations required for the TMS

n When configuring the TMS on an R/3 System, you can specify the application server to be used for all TMS functions. Choose the application server with the highest availability. This is generally the server that provides the enqueue service.

SAP AG 1999

Transport Domain Management

Transport Domain

Transport Group

Domain Controller

Transport Directory

Backup Controller

Configure a backup

controller that is able to take over controller

activities .

n To check the current status of the transport domain configuration for each R/3 System in the transport domain, access the TMS overview. From the TMS initial screen, choose Overview → Systems. In this overview, you can also see whether the configuration is up-to-date, and whether any errors occurred when distributing the configuration.

n If the R/3 System acting as the domain controller fails, no changes can be made to the TMS configuration. SAP therefore recommends that you configure a backup domain controller that can assume the function of the domain controller when required.

n It may also be necessary to move the domain controller to another R/3 System. In such a case, you must activate the backup controller. Now, the backup controller becomes the domain controller and vice versa.

n All planned R/3 Systems are not normally set up at the same time. Instead, the system infrastructure is set up in stages. After setting up the development system and initializing the TMS, you can use the TMS to model the proposed transport routes for the anticipated system infrastructure. The TMS allows you to configure these planned R/3 Systems as virtual systems of the transport domain.

SAP AG 1999

Configuring the Transport Control Program tp

Transport Directory

tp

RFC

System

Description

DEV

Development System

ALLLOG

SYSLOG

TESTIMPORT

TRANSDIR

CTC

DBHOST

DBNAME

DBTYPE

IMPDP_BY_E...

NBUFFORM

NO_IMPORT_A

R3TRANSPATH

SAPEVTPATH

STARTDB

STARTSAP

STOPDB

Management Communcations Data Transport tool

ALOG$(syear)$(yweek)

ALOG$(syear)$(yweek).$(system)

false

\\$(SAPTRANSHOST)\sapmnt\saptrns\

0

twdfmx03

DEV

ora

yes

1

1

\\tzwdfmx03\sapmnt\DEV\SYS\exe\run\R3trans. exe

\\tzwdfmx03\sapmnt\DEV\SYS\exe\run\sapevt.exe

PROMPT

PROMPT

PROMPT

n The transport control program tp requires a transport profile that contains information about establishing the database connection for all R/3 Systems in the transport domain. TMS generates and manages this transport profile as a part of the transport domain configuration. You do not have to adjust the transport profile using a text editor on operating system level.

n To display the tp parameters of an R/3 System, call Transaction STMS. Choose Overview → Systems. Mark one system and choose SAP System → Display. Choose the tab Transport tool. From the menu, choose Goto → tp parameters. This displays the parameters in TP_<DOMAINNAME>.PFL and the default value of all parameters used by the programs tp and R3trans. If a parameter is not specified, a default value will be used. Global parameters override defaults. Local parameters override global parameters. For example, you can specify a global parameter value for all but one system if a local parameter applies to that system.

SAP AG 1999

After establishing a transport domain:� Model transport routes from the domain controller,using:l Default standard configurations

n One-system landscapen Two-system landscapen Three-system landscape

l Hierarchical list editorl Graphical editor

� Distribute and activate the new configuration datafor all R/3 Systems within the transport domain

Use SAP standardtransport routes to create

default transport routes and save time!

Configuring Transport Routes

n To save you the effort of specifying individual transport routes, you can configure standard system groups. Transport routes for the standard system groups are generated automatically.

n You can choose from the following standard system groups:

� Single system

� Development system and production system

� Development system, quality assurance system, and production system

n If you use the standard configuration function, the current configurations for all R/3 Systems are replaced by the standard settings. Existing development classes, transport layers, or objects created in the R/3 System are not deleted.

n For complex system groups, define additional consolidation and delivery routes after setting up the standard transport route configuration on the basis of one of the standard system groups.

n If you modify and save an active configuration, the version counter increases. To activate a stored version, from the R/3 initial screen choose STMS → Overview → Transport Routes → Configuration → Get other version.

SAP AG 1999

Eachdevelopment /integrationsystem has aconsolidationroute assigned asthe standardtransport layer.

Transport Routes

Consolidation

Delivery

Integration system

Transport Layer

Consolidation system

Consolidation

Delivery

Source system

Recipient system

DEV

ZDEV

QAS

DEV

QAS

n A transport routes can be either a consolidation route or a delivery route. For a standard three-system landscape, the transport routes are as follows:

� A consolidation route connects the development system and the quality assurance system. This transport layer is named Z<SID>, where <SID> is the system ID of the development system.

� A delivery route is created between the quality assurance system and the production system.

� In the development system, if changes are made to objects whose development class refers to the (standard) transport layer corresponding to a consolidation route, these changes are recorded in requests and transported to the quality assurance system and then to the production system. If you change SAP objects, these changes are recorded in repairs, which can be transported in the same way but using the consolidation route "SAP".

n To create a consolidation route, enter a transport layer name in the field Transport layer. A transport layer name must be within the customer's name range.

n You can only create delivery routes for consolidation routes that already exist.

SAP AG 1999

Graphical Editor

Standardtransport

layer

Consolidationroutes

Deliveryroutes

• To insert new systems into theconfiguration, use drag and drop• To define transport routes, insertarrows and choose type of transportroute• Distribute and activate the newconfiguration

n SAP provides two editors for configuring additional transport routes for more complex system landscapes:

� Hierarchical list editor The R/3 Systems in the transport domain and their transport routes are displayed in a tree structure.

� Graphical editor The R/3 Systems and their transport routes are displayed graphically. The R/3 Systems can be positioned and linked using the mouse. To call the graphical list editor, use Transaction code STMS. Then, choose Overview → Transport routes.

n To create transport routes, use the mouse to drag the appropriate R/3 Systems from the node area, and drop them in the display area. To create a transport route between these R/3 Systems, from the screen Display Transport Routes, choose Configuration → Transport Route → Create Transport Route . The mouse pointer becomes a stylus. Using the stylus, draw a line connecting the two R/3 Systems between which a transport route is desired. In the dialog box Create Transport Route , enter the required information for either the consolidation or delivery route. Save.

SAP AG 1999

Transport Domain

Domain Controller

RFC

RFC

Distribution and Activation of Transport Routes

l Distribution of transportroutes is recommendedfrom the transport domaincontroller

l Distribution and remoteactivation use a temporaryTMSSUP connection(requiring a user ID andpassword)

l Activation triggers checksto verify that newtransport routes do notaffect existing requests

n The TMS checks the following configuration issues:

� Whether the settings of the transport control program tp are consistent with the transport route configuration.

� Whether the deliveries go out from at least one consolidation system

� Whether the transport profile parameter multileveldelivery is switched on when using multilevel deliveries for the R/3 Systems involved (< Release 4.0A).

� Whether the R/3 Systems involved are at least R/3 Release 4.5A when using enhanced transport control and whether the accompanying transport profile parameter “CTC = 1”. The systems also checks if enhanced transport control is mixed with simple transport control.

� Which effects the configuration has on open tasks and requests. If the configuration of the transport routes is consistent, it is compared with open requests. You cannot release inconsistent requests.

SAP AG 1999

Domain controller

TMS Authorization Concept

Transport domain

Domain Controller

[email protected][email protected]_QAS

Read access

RFC Connectioncalculated at runtime

Write access

n Perform the initial configuration of the TMS on each R/3 System using client 000 and user authorization S_CTS_ADMIN.

n To prevent unauthorized access to an R/3 System through the TMS:

� The TMS authorization check is always performed in the target system.

� RFC destinations are generated during setup and cannot be modified.

� An R/3 System outside the transport domain may not access R/3 Systems in the transport domain.

n For TMS communication, RFC destinations are generated per target system:

� TMSADM@<SID>.<DOMAIN NAME> For this link, the system creates in each R/3 System the user TMSADM, who receives very limited authorizations. This link is used for all read access and for distribution of R/3 System information.

� The destination for critical access is calculated at runtime based on the address information stored within the TMS configuration when an R/3 system is accepted in the domain. accesses. If the authorizations of TMSADM is not sufficient, the internal connection automatically triggers a logon screen in the target system on which a user with greater authorizations has to identify through logon. If this procedure is too time-consuming, e.g. in case of a large number of R/3 Systems, you may provide user TMSADM with the required authorizations, that is profile S_A.TMSCFG. If an R/3 System is accessed, in which user TMSADM has greater authorizations, the logon procedure is suppressed.

SAP AG 1999

l Transport routes areedited from the domaincontroller

l Standardconfigurations exist for2-system and3-system landscapes

l Transport layers,consolidation routes,and delivery routes canbe defined

l Configuration can bedistributed andactivated

Hierarchical List Editor

n Since the Graphical editor is generally set as the default editor, you have to change the settings to use the Hierarchical list editor. To use the Hierarchical list editor, call Transaction code STMS. From the initial STMS screen choose Overview → Transport routes → Extras → Settings. In the dialog box, choose Hierarchical list editor and Enter. To activate the new settings for the transport route editor, choose the Back arrow. From the initial STMS screen, choose Overview → Transport routes.

SAP AG 1999

TransportTarget Group

Clients tobe delivered

Deliveryroutes

Alternative Configuration / Extended TransportControl

n The Extended Transport Control enables you to set up a client-specific transport route configuration:

� Client-specific transport targets: The transport targets of consolidation and delivery routes do not just specify a system, they also specify a client. Client-specific transport targets are entered in the form: <SID> <client> (for example, QAS.013 ).Target groups combine several client-specific transport targets under a symbolic name. You can specify target groups when you define consolidation and delivery routes. To differentiate them from traditional transport targets you must start and end the names with "/" (for example, /EUROPE01/ ).

� Client-specific consolidation routes: For each transport layer, the consolidation routes determine where changes made in the system are transported to after the request has been released. If you have activated extended transport control, then the transport target can be a specific client in a target system or target group. If you do not activate extended transport control, you can specify systems only as consolidation targets. This means that the transport administrator has to specify the correct target client at the time of import.

� Client-specific delivery routes: Delivery routes determine whether change requests are to be flagged for import into subsequent systems/clients, after they have been imported into a system. If you have activated extended transport control, then you can set the delivery routes as client-specific. This makes it possible to supply several clients in one system in sequence. You can also specify a target group as the target of a delivery route.

NOTE: You cannot use client-specific and cross-client transport routes together.

SAP AG 1999

System Change Options

n The system change option defines whether Repository objects and client-independent Customizing objects are globally modifiable. If they are globally modifiable, you can specify for each software component or namespace whether it can be modified.

n To reach the system change option from the Transport Management System, use Transaction STMS and choose Overview → Transport Routes → Environment → System change option.

n A software component is set of dedicated development classes. They can be set to restricted modifiable, meaning that new objects can only be created as non-original objects.

n Namespaces can be reserved for software developed by SAP customers and partners. These namespaces are designed for large-scale customer enhancements as well as add-ons developed by partners.

n The syntax for objects from reserved namespaces is: /<namespace>/<object name>, for example /abcdefgh/customer. The namespace prefix can have up to 10 characters.

n For each R/3 System, the customer can define whether the objects contained in the namespaces and name ranges may be changed.

n To enable objects to be changed, the R/3 System must not be globally locked to changes.

SAP AG 1999

TMS Quality Assurance


o.k.

TMS QA Approval Procedure

n The TMS Quality Assurance (QA) approval procedure increases the quality and the availability of the production systems by letting you check requests in the quality assurance system before they are delivered to subsequent systems.

n The system for which the QA approval procedure is activated is called the QA system. When the QA approval procedure is activated, change requests are only forwarded to the delivery systems if all the QA approval steps are processed for each request in the QA system, and each request has been approved. (When you configure the QA system, you determine how many QA approval steps have to be processed for each request.) If one check for an approval step is not successful, the entire request cannot be approved. You can only import completely approved requests into the delivery systems.

n Rejected requests are not imported into the delivery systems of the QA system.

SAP AG 1999

Configuring the QA Approval Procedure

1. Define the QA System

2. Define the Approval Procedure

n Before you can process change requests in the TMS QA system you must configure the QA approval procedure. Ensure that the system landscape and/or transport domain is set up so that there is at least one development, one quality assurance, and one production system. The system to be configured as the QA system must have the following attributes:

� It must be the target of at least one consolidation system.

� It must deliver to at least one additional system.

n In the system attributes for the chosen system, the option delivery after confirmation must be set. In the approval procedure, you can define which users must provide approval so that the transport can be imported into the delivery system.

n After configuration, the QA worklist is automatically set up. All the requests that are then imported into the QA system are included in the QA worklist.

SAP AG 1999

l RFC connection test

l Transport directory check

l Transport control program (tp) check

Verifying TMS Setup

n All R/3 Systems in a transport domain communicate with each other using RFC connections.

n To check these RFC connections in the TMS overview, from the TMS initial screen (Transaction STMS) choose Overview → Systems → R/3 System → Check → Connection test. The connection test is performed in both directions. If you find that there are connection problems with R/3 Systems having several application servers, you can change the server configured for the TMS.

n To verify the availability of the transport directories of all systems within the domain, from the TMS initial screen (Transaction STMS) choose Overview → Systems → R/3 System → Check → Transport directory.

n To test the transport control program tp, from the TMS initial screen (Transaction STMS) choose Overview → Systems → R/3 System → Check → Transport tool.

SAP AG 1999


l Set up the common transport directory

l Initialize the Change and Transport Organizer (CTO)

l Initialize the TMS and explain TMS functions

l Monitor TMS setup in all R/3 Systems in the system landscape


SAP AG 1999

l Do the Exercises?

l Solutions for the Exercises

Unit Actions

Change and Transport System P rerequisites: Exercises

No. Exercise

1 Logging on to the Customizing client on the development system as a project team leader

1.1 Throughout this course, you will have user ID LEAD-##, where ## is the number assigned to you by the instructor. This user has project team leader authorizations as well as most CTS administration authorizations. Log on to the Customizing client in the development system using the user ID LEAD-##.

1.2 Change the password for LEAD-## in the Customizing client.

2 Reviewing TMS setup

2.1 What is the name of the transport domain that includes the development system?

2.2 Which R/3 System is the domain controller for this domain? Is a backup domain controller defined?

2.3 How many transport groups are defined for this transport domain? What are the names of the transport groups?

3 Verifying the setup of the transport directory and the transport control program

3.1 In order to transport change requests from one system to another, R/3 uses a transport directory. Using TMS, check any one of the R/3 Systems in the transport domain and verify that proper access to the transport directory is possible.

3.2 Although changing or adding transport profile parameters is normally not necessary, you can check the parameters that where defined by the TMS. Display the transport profile parameters defined for the development system. Also view all transport profile parameter values - even those that are SAP default values.

3.3 Verify that the development system is able to communicate with the transport control program tp.

4 Reviewing the transport routes for the entire transport domain

4.1 View the current transport domain and its transport routes using the graphical editor.

4.2 What transport routes have been defined for this system landscape? Are the transport routes consolidation routes or delivery routes?

4.3 What is a standard transport layer for the development system? Do all R/3 Systems in the system landscape require a standard transport layer?

4.4 Why is the transport layer SAP needed?

5 Reviewing the QA approval procedure

5.1 Verify the QA approval procedure for the transport domain. Which R/3 System is defined as the QA system?

5.2 Which approval steps are necessary for a change request ?

6 Optional exercise: Creating a virtual R/3 System and adding it to the current transport domain

6.1 You foresee a need for a dedicated training system in your system landscape. Although the additional R/3 System does not yet physically exist, a virtual R/3 System can be created to act as its placeholder. Using TMS, create a virtual system called T##, where ## is the number assigned to you by the instructor.

6.2 Creating a virtual R/3 System requires information distribution. How was the information regarding the virtual system distributed?

6.3 The quality assurance system needs to deliver change requests to the training system T##. Create the required transport route to ensure that T## will receive all released change requests after they are verified and tested in the quality assurance system.

6.4 Save your transport route and return to the initial TMS screen.

6.5 What is the status of the current transport route configuration?

6.6 What steps are required to activate this new transport route configuration within the entire domain? Do not try to distribute and activate the new configuration. Have the instructor activate and distribute the new transport routes.

6.7 To perform distribution, you need the authorization S_CTS_ADMIN in all target systems. Why does SAP require authorization for the distribution of a new configuration?

7 Optional exercise: Reviewing the RFC connections required for TMS communications.

7.1 TMS uses various RFC connections to communicate with all R/3 Systems in the transport domain. Review all RFC connections generated during TMS setup.

7.2 TMS provides tools for verifying RFC connections in R/3. Check to see whether all RFC connections required for TMS are correct.

Change and Transport System Prerequisites: Solutions

No. Solution

1

1.1 Ask your instructor the host name and system number for DEV. Log on as user LEAD-## to system DEV, client 300. The initial password for this user is INIT.

1.2 During first logon, change the password.

2

2.1 To access the TMS initial screen, from the R/3 initial screen choose Tools → Administration → Transports → Transport Management System. Alternatively, use Transaction STMS. The transport domain for the system in which you are currently logged into is displayed. Note that DEV is part of the transport domain DOMAIN_DEV.

2.2 From the TMS initial screen, use Overview → Systems. Note the icons associated with each of the R/3 Systems in the transport domain. To display the key for these icons, choose Legend (or choose Extras → Legend). An icon indicates the transport domain controller and another icon indicates a backup domain controller.

2.3 To find out the transport groups in the transport domain, from the TMS initial screen choose Overview → Systems. To see a summary of the transport groups for the domain, choose Goto → Transport groups. There is one transport group – GROUP_DEV – for the domain DOMAIN_DEV.

3

3.1 To display the transport settings for an R/3 System, from the TMS initial screen choose Systems (or choose Overview → Systems). Position the cursor on an R/3 System and choose SAP System → Check → Transport directory. To see all required subdirectories and whether R/3 was able to read and write to these directories, expand the list.

3.2 From the TMS initial screen, choose Overview → Systems. Double-click on system DEV and choose the tab Transport tool. To see all possible transport profile parameters and their default values, choose Goto → tp parameters.

3.3 From the TMS initial screen, choose Overview → Systems. Position the cursor on the R/3 System DEV and choose SAP System → Check → Transport tool. To see whether DEV can communicate with tp and the database, expand the list.

4

4.1 From the TMS initial screen, choose Transport routes (or choose Overview → Transport routes).

4.2 For this transport domain, the transport layer ZDEV exists as a consolidation route from DEV to QAS. In addition, the transport layer SAP exists as a consolidation route from DEV to QAS to allow for the transport of SAP-delivered objects. There is a delivery route from QAS to PRD.

4.3 Using the graphical editor, you will see that the standard transport layer indicated in the system DEV is ZDEV. The standard transport layer is the default transport route for change requests that are released and exported from the development/integration system. Only R/3 Systems in which changes originate require a standard transport layer.

4.4 The transport layer SAP is the transport route for all SAP-delivered Repository objects that are modified in the development/integration system. Without this transport route, changes to SAP standard objects can not be transported using the Workbench Organizer.

5

5.1 To display the QA approval procedures, from the TMS initial screen choose Systems (or choose Overview → Systems). Choose Goto → Transport domain and select the tab QA Approval Procedure. QAS is set to be a QA System.

5.2 On the same screen you see that the steps that are necessary for approval are flagged.

6

6.1 To add a virtual R/3 System to the transport domain, from the initial TMS screen choose Systems (or choose Overview → Systems). Then choose SAP System → Create → Virtual system. Use T## as the virtual system name and provide a description. The default value for the communication system is DEV. To save the virtual system T##, choose Save. Because TMS provides centralized configuration, the dialog box Distribute TMS configuration is displayed. To distribute your change to all other systems within the transport domain, choose Yes.

6.2 When an R/3 System has been configured for TMS, user TMSADM is created in client 000. RFC connections for user TMSADM are generated, which enable: (1) All TMS read access, for example, access to configuration status and import queue data (2) The distribution of R/3 System information configured with TMS.

6.3 To create a new transport route, from the initial TMS screen, choose Transport routes (or choose Overview → Transport routes). Activate the change mode by choosing Configuration → Display <-> Change. In the Node area, click on your virtual system T##. Move your cursor to the Display area and click once again. The virtual system T## appears in the Display area. To turn the cursor into a stylus (pen), choose Edit → Transport route → Add transport route . Draw a line from the quality assurance system QAS to your virtual system T##. The dialog box Create Transport Route is displayed. Select Delivery and choose Transfer. Creating this transport route as a delivery route means that after the changes are imported into the quality assurance system, they are delivered to the virtual system as well as the production system.

6.4 From the graphical editor, choose Save (or choose Configuration → Save). Enter a short text for the new configuration and Enter.

6.5 The initial TMS screen indicates that “The transport route configuration is

inconsistent.” If you choose Transport routes (or Overview → Transport routes), the icon visible in the box of System DEV indicates that the actual configuration is modified but is not yet active. As well, the title bar of the transport route configuration screen indicates that the configuration has been Saved but note that it does not indicate that it is Active.

6.6 The configuration needs to be distributed and activated in all R/3 Systems within the transport domain. To distribute the current configuration to all or selected R/3 Systems within the transport domain, have the instructor choose Configuration → Distribute and activate from the transport route configuration screen.

6.7 Transport routes define the path used for transporting change requests within your system landscape. Changing the current transport routes can result in inconsistent Customizing and development in the system landscape. Thus, SAP requires authorization for the distribution of a new transport route configuration

Note: After creating or changing transport routes, you need to distribute and activate the new transport routes using an RFC connection. Because the user TMSADM used by the RFC does not have enough authorization to perform distribution and activation, you must log into each target system to which you wish to distribute the latest TMS configuration for the transport domain. You will need to log into the target systems with a user having S_CTS_ADMIN authorization.

7

7.1 To display information on RFC communication, from the R/3 initial screen choose Tools → Administration → Administration → Network → RFC Destinations (or use Transaction SM59). Expand R/3 connections and there you will see generated connections specific to TMS. To see detailed information on an RFC connection, double-click on the connection name.

7.2 From the TMS initial screen, choose Systems (or choose Overview → Systems). To verify the RFC connections to all R/3 Systems, choose SAP System → Check → Connection test.

SAP AG 1999








Change Management for Customizing

SAP AG 1999

Change Management for Customizing

Contentsl Tools and procedures for managing Customizing

change requests

ObjectivesAt the end of this unit, you will be able to:l Explain the general concepts of projects in

Customizing

l Explain the relation between the ImplementationGuide (IMG) and the Customizing Organizer

l Use the Customizing Organizer to create, manage,and release Customizing change requests

SAP AG 1999

What is Customizing?

Adoption of R/3 to meetAdoption of R/3 to meetthe the businessbusinessrequirementsrequirements of a of acustomercustomer

Sales andDistribution

MaterialsManagement

ProductionPlanning

SalesSalesOrganizationOrganization401 - Printers401 - Printers

DistributionDistributionChannelChannel

100 - Wholesale100 - Wholesale

DistributionDistributionChannelChannel

200 - Consumer200 - Consumer

CompanyCompanyCodeCode00010001

n Customizing adapts the R/3 software to meet a company's individual business requirements by setting up the business transactions the company requires in R/3.

n To illustrate the the kinds of business transactions an enterprise may need to customize in R/3, consider the example of an international company which sells printers wholesale. To enable customers at a particular outlet to place a wholesale order for printers, the company must customize R/3 to recognize the company's structure This could encompass:

� Defining a sales organization

� Defining distribution channels

� Assigning distribution channels to the sales organization

� Defining pricing conditions and tax determination rules

� Assigning general ledger accounts

n Most Customizing is client-specific and affects only a particular client. However, some changes such as pricing conditions are cross-client and affect all clients in an R/3 System.

n The process of Customizing the system can be controlled and accelerated using the AcceleratedSAP method.

SAP AG 1999

Customizing from a Technical Perspective

Client Sales Currency Company ... Org. CodeClient Sales Currency Company ... Org. Code 001 0001 USD 0001 325 0001 USD 0001

Table TVK0Table TVK0

Client Sales Lang. Description Org. Client Sales Lang. Description Org. 001 0001 E Sales Org 1 325 0001 E Sales Org 2

Table TVK0TTable TVK0T

View V_TVK0View V_TVK0

Sales DescriptionOrg. Sales DescriptionOrg. 0001 Sales Org 1

Physical storage ofCustomizing data

Logical representationof Customizing data

n Customizing activities typically create or change entries in multiple tables through table views and are client-specific (only affect the current client).

n A table view is a virtual table which presents data that is physically stored in multiple tables.

n The table entries created with the help of table views are identified by the key fields of the respective table.

SAP AG 1999

Implementation Guide (IMG)

SAP Reference IMG

FI

PP

........PS

HR

CO MM

SDProject IMGs

Project 001Project 002

FI

CO

PS

MM

FI

CO

Project 002 View(required activities)

Project View

n An R/3 System is delivered with a complete IMG for all R/3 System modules, called the SAP Reference Implementation Guide (IMG).

n When defining a Customizing project customers select the functions they require in the different R/3 modules and components these functions are used to generate the project IMG. All relevant Customizing transactions, project-specific or cross-project documentation, and project-management information is located in the subsets of the SAP Reference IMG, known as Project IMGs. All Customizing activities should be done directly from within a Project IMG.

n Within a project IMG it is possible to generate project views that restrict the extend of Customizing, for example, for different levels of necessary activities.

n The Project IMGs can be changed at any time through regeneration. The respective previous IMG is then overwritten. However, status information and project documentation is not lost.

n The Project IMGs are cross-client.

n To access the Customizing menu, use Transaction code SPRO or, from the R/3 initial screen choose select Tools → AcceleratedSAP → Customizing → Edit Project.

SAP AG 1999

Projects in Customizing

Project Management:•Create Customizing projects and project views•Define project scope and duration•Assign team members to the project•Define project language and type of documentation•Define and maintain options

Project 001

Project work:•Perform Customizing activities•Document system settings

n Customizing is based on two clearly-defined user roles: project leader and project team member. Each role has specific areas of responsibility. This structures and organizes implementation activities.

n The project leader is responsible for defining and managing the project.

n Customizing project team members make Customizing project system settings and document project progress by maintaining project status and project notes. Any number of project team members can be assigned to each project. The project leader makes this assignment.

n To display team member assignments in the Project IMG, choose Additional information → Status information → Select team members.

SAP AG 1999

Managing Transports in Projects

. .

defines

ResponsibilityImplementation Project

Project attributesActivation of CTS

Customizing activities

Change request Atask1task2

Development activities

Change request Btask1task2

. .. .

n As of Release 4.6A project IMGs may be linked to the Change and Transport System (CTS). Change requests can be assigned specifically for Customizing.

n The CTS reflects a project-concept based on user roles. The change requests created and assigned by the project leader contain smaller units called tasks that have been allocated to the project team members. In these tasks, the changes made by the team members are recorded. A team member can also own several tasks belonging to a change request.

n Projects can be transported separately as a unit containing several change requests. In general Customizing projects should not overlap. However, during the release of change requests, dependencies of requests belonging to different projects should be recorded, and projects checked for overlapping.

SAP AG 1999

Use a singleclient for all Customizing

Project

Change Request

task task

l Define Customizing policies:

n Define policies for creating the Project IMGsand Views within a project, and the use of project status and documentation.

n Establish a single source client for all Customizing.

l Restrict access tochange request management tasks:

n Determine change management roles

n Assign appropriate user authorizations

l Establish project teams:

n Establish project team leaders to defineprojects, and to assign change requests to team members.

n Provide training on the use of change requestmanagement tools to all project teams.

Planning Customizing Change Management

n Customizing is the standard way of adapting the functionality of the delivered SAP components to the requirements of a company. Project control tools allow easy documentation and monitoring of each phase of the R/3 implementation and Customizing.

n Customizing is required for all R/3 implementations. Because Customizing is a highly integrated process, both between functional modules and within the modules themselves, all Customizing activities must be performed in a single client, usually known as the development client. Development tasks should also be restricted to this client, thus ensuring that there is a single environment for all implementation efforts.

n The project leader is responsible for creating change requests for all project team members at the start of a development or Customizing project.

n The Project Management functionality enables you to assign tasks in the Customizing Organizer and Workbench Organizer.

n After project team members complete their work, they save their changes in the tasks that comprise the change request, and document the changes in the task. When all project team members have released their tasks, the project leader releases the change request for transport to other R/3 Systems within the system landscape.

SAP AG 1999

Using the IMG for Customizing

Activities IMG Description

* Status * Scheduling* Resources* MS Project for enhanced planning functionality

* Access Customizing transactions

* Structured by note types* MS Word as a text editor* SAP Office folders

Project Management Project Documentation

* Concepts* Recommendations* Requirements* Activities

Global Settings

CountriesCurrenciesCalendars

Implementation

Guide (IMG)

n The IMG:

� Provides all Customizing transactions

� Is where all Customizing activities must be performed

� Is integrated with the AcceleratedSAP method

� Gives you online access to all the information required to customize an R/3 System

� Offers project management tools

n To view client dependencies for items within the IMG: From the R/3 initial screen, choose Tools → AcceleratedSAP → Customizing → Edit project → Goto → SAP Reference IMG → Additional information → Technical data → Client specific.

n To view transport dependencies for items in the IMG: From the R/3 initial screen, choose Tools → AcceleratedSAP → Customizing → Edit project → Goto → SAP Reference IMG → Additional information → Technical data → Transport type.

SAP AG 1999

Customizing Tools


Customizing Organizer

CustomizingDEVK900124 Change Request

DEVK900125 TaskDEVK900126 Task

View Maintenance: DataV_TVAKV_TSPA

Transport Management System

Global SettingsCountriesCurrenciesCalendars

n SAP provides the following implementation tools for Customizing:

� The Implementation Guide (IMG) is the main Customizing tool. Once you decide which R/3 modules you require, the project IMG automatically generates a hierarchical list of tasks (or Customizing transactions) for you to customize.

� The Customizing Organizer (CO; Transaction SE10) records Customizing changes in change requests (of type CUST) which can be released to the transport system for export to other systems in the R/3 System landscape.

n The CO is completely integrated with the Transport Management System (TMS).

SAP AG 1999


lChange requestsfor Customizing

l If selected,change requestsfor Workbench

lGlobal transportinformation

The CustomizingOrganizer providesinformation about:

n Customizing changes consists mainly of table entries and are saved to Customizing requests.

n The Customizing Organizer (Transaction SE10) is used to create, manage, release, and analyze change requests that record Customizing changes.

n All Customizing requests that belong to a specific user are displayed according to a set of standard selection criteria. Selection options include user (owner), request type, request status, and date.

n As cross-client Customizing is recorded in workbench change requests you have also the option to display these type of requests.

n In Transaction SE10, the screen area Global Information gives you a graphical, cross-system overview of the status of transported change requests.

n To access the Customizing Organizer, use Transaction code SE10, or from the R/3 initial screen choose Tools → Customizing → AcceleratedSAP → Customizing Organizer.

SAP AG 1999

Change Requests and Tasks

Task A ( team leader)

Task B (member 1)

Task C (member 2)

Object 1Object 3

Object 2Object 1

Object 4

. ..

. .

. .

Task D (member 2)Object 5. .

records in

Responsibility

records in

records in

records in

Change request (team leader)

n The WBO and the CO allow you to work with a team on a development or Customizing project, and allow the changes made to the R/3 System to be recorded.

n These changes are recorded using change requests which can be assigned to an entire project.

n These requests contain smaller units consisting of the tasks that have been allocated to a project team member. In these tasks, the changes made by this team member are recorded; that is, a list of changed objects is maintained.

n In general, an object can be listed in several tasks belonging to the same change request (with the exception of repairs). Likewise, a team member can own several tasks belonging to a change request.

n The recorded objects are only transported in the context of the entire change request. Thus, the project representing this change request can only be imported in its entirety into another R/3 System.

SAP AG 1999

Client Change Options

Changes and transports for client-specific objects

Changes w/o automatic recording

Automatic recording of changes

No changes allowed

No transports allowed

Cross-client object changes

Changes to Repository and cross-client Customizing allowed

No changes to cross-client Customizing objects

No changes to Repository objects

No changes to Repository and cross-client custom. obj.

Affects all clients in a system

Can be set for each client in a system

n To set the client change options, use Transaction code SCC4, or from the main R/3 menu choose: Tools → Administration → Administration → Client Admin. → Client Maintenance. Double-click the relevant client.

n The client change options for client-specific attributes include:

� Changes without automatic recording: Allows changes to table entries but does not automatically include the changes in change requests. The changes can be manually included in change requests for transport.

� Automatic recording of changes: Allows changes to table entries and automatically includes the changes in a change request.

� No changes allowed: Prevents all users from making changes to table entries.

� No transports allowed: Allows changes to table entries but does not allow the changes to be transported either manually or automatically. This option can be used to isolate a training or sandbox client.

n The client change options for cross-client attributes protect cross-client Customizing objects and R/3 Repository objects during Customizing.

n The client change options are maintained in the client maintenance table T000.

SAP AG 1999

Recording of Customizing Changes

CustomizingtransactionsCustomizingCustomizingtransactionstransactions

Customizingsettings in

tables

CustomizingCustomizingsettings in settings in

tables tables

Project IMG


tables


tables tables


tables


tables tables

‘Automatic recording of changes’

Customizing.-OrgCustomizingRequest

Customizing.-OrgCustomizingRequest

‘Changes w/orecording’

Clientchange option

n A Customizing transaction is a transaction for setting Customizing table entries. To use a Customizing transaction, you do not have to know about the technical aspects of where and how a business object is maintained, or which transactions are used to access and change which fields in which tables.

n After Customizing settings are changed using a Customizing transaction, the settings should be saved as follows:

� When a client is configured to automatically record changes, the settings are automatically saved to a change request managed by the Customizing Organizer.

� If the client is not configured for automatic recording of changes, the settings are saved but not recorded in a change request. However, they can be included in a change request manually. To do this from within the Customizing transaction: choose Table/View → Transport, provide a change request, select the Customizing entries to be included in the change request, click Include in Transport, choose Save, then exit.

n All Customizing transactions in the IMG also allow entries to be saved to a change request manually.

n Note that some transactions are classified as manual transports. These transactions must be manually added to a change request for transport to their target system. In addition, some Customizing transactions have transport steps which differ from those indicated in the above diagram.

n To view transport dependencies for items within the IMG: From the R/3 initial screen, choose: Tools → AcceleratedSAP → Customizing → Edit project → Goto → SAP Reference IMG → Additional Information → Technical data → Transport type.

SAP AG 1999

Transporting Customizing Changes

DEVK900126 SCHMIDT

View Maintenance: DataV_TVKOV_T001

Object list

Task DEVK900126

Key field list

Client

Sales Organization SO02300

Table TVKO

Field Value

Key list

Object VDAT V_TVKO

Table Key

R3TR VDAT V_TVKO K

R3TR VDAT V_T001 K

TVKO 300SO02

TVKOT 300DSO02TVKOT 300ESO02

n Customizing change requests usually contain changes or additions to tables or views. The change request also contains the keys identifying the table entry. When exported, this change request will extract the relevant table entries from the source database.

n Because of the dynamic accessing of table entries during Customizing, both client-specific and cross-client Customizing are not protected from being overwritten. Table entries are locked while the Customizing transaction is being used, but they are unlocked as soon as the changes are completed and saved to a change request. For additional information see R/3 Note 1916 in SAPNet.

n To activate the logging of changes to Customizing tables, use IMG logging through Transaction code SCU3 (or, from the main R/3 menu, choose Tools → AcceleratedSAP → Customizing → IMG Logging). Prerequisite for IMG Logging is:

� In Technical settings in ABAP Dictionary Maintenance (Transaction SE11), the Log data changes has been selected for the respective Customizing tables or views.

� The profile parameter rec/client is set to the appropriate clients.

n Generally, all objects are transported to the target system in the state in which they exist in the source system. Objects transported from the source system overwrite objects in the target system that have the same names. Objects are deleted in the target system if they do not exist in the source system.

n If not otherwise specified, the Customizing changes are transported using the standard transport layer.

SAP AG 1999

Customizing Procedure

Customizer Administrator

Transportdirectory

Assign Customizing settings to change

requests

Importchange requests

into the targetsystem

Release/exportchange requests

Document and releasethe task containing

Customizing changes

Create change requests and assign users

Perform Customizing transactions from

within the IMG

Project leader

Authorizationsexist to definea user’s role

Completechange

documentation

Unit-test the contentsof the task

n The Customizing Organizer and the Transport Management System are designed to work together. During normal Customizing work:

� The project leader first assigns a change request to a project, and assigns the subsidiary tasks to the users involved

� These users perform Customizing changes that are recorded in the change request

� After Customizing is completed, users must release their tasks

� The change request can then be released from the source system for export to the operating system

� The transport to the target system takes place on operating system level.

SAP AG 1999

Testing Customizing Change Requests (1)

l Before releasing a Customizing change request,perform a unit test to:

n Test the functionality of the change request

n Verify that the content of the change request is complete

l Maintaining a separate client for testing allows:

n True unit testing

n Maintenance of test data without the risk of creatingCustomizing-dependent data

l Transaction SCC1 copies changes from one client toanother based on:

n A task

n A change request

n A change request and its tasks

n All Customizing must be tested prior to production in two ways. First perform unit testing, then system testing.

n Unit testing is the testing of individual Customizing changes. System testing is the testing of all Customizing changes together. Unit testing should be performed by the customizer and completed before the release of the change requests.

n Unit testing typically requires application data. Because many customers find it advantageous to keep their Customizing client free of application data, another client is created with the necessary application data for unit testing.

n Thus, prior to releasing a change request, copy the recorded changes to a separate client for unit testing. To copy the contents of a change request or one of the constituent tasks to another client within the same R/3 System, use Transaction SCC1.

n After unit testing the tasks, a change request can be released. Unit testing alone, however, is not sufficient for transporting Customizing changes to production. After unit testing, the change needs to be tested with all other Customizing settings in system testing to ensure that all system settings function properly together.

SAP AG 1999

Testing Customizing Change Requests (2)

ChangerequestClient

Client

Only for client-specificCustomizing

Transaction SCC1:Copy based on a transport request

Transaction SCC1:Copy based on a transport request

Task

n To copy the contents of a change request from one client to another client, use Transaction SCC1 or, from the main R/3 menu, choose Tools → Administration → Administration → Client admin. → Special functions → Copy transport request. Enter the source client and the change request to be copied.

n Only one change request may be copied at a time. As copying each change request individually may be time consuming, use the Include Objects option in Transaction SE10 to bundle several change requests into one change request. This larger change request can then be copied to the target client, saving time.

n Note: If the change request contains cross-client objects, these objects are not copied.

SAP AG 1999

Customizing Organizer: Requests

Release and export

Release to new change request

Release to change request

Releasing Customizing Change Requests

Release to (new) change request:

lReleases and copies a Customizing change requestto a transportable change request

lCustomizing change request no longer modifiable

lCustomizing change request not yet exported to theoperating system level

Release and export:

lCopies table entriesfrom the database to afile at the operatingsystem level

lKey values stored inthe change requestspecify data to becopied

n An export of a change requests copies table entries from the database to a file at the operating system level. The key values stored in the change request determine which data is copied.

n A Customizing change request can be released and copied to a transportable change request. It can no longer be modified, but is not exported to the operating system level until it is released.

n After releasing Customizing change requests, remember to verify the success of the export using transport logs and action logs, which are accessed from the Customizing Organizer (Transaction SE10).

SAP AG 1999

Cross-clientCustomizing

Customizingchangerequests

Workbenchchangerequests

Customizing data

Usermaster data

Client CUST

Applicationdata

Global Customizing settings

Cross-client Customizingobjects

R/3 Repository objects


n The most difficult task in the distribution of Customizing changes is distinguishing between cross-client and client-specific Customizing and knowing which client-specific Customizing activities affect master data.

n To determine the client dependency of IMG transactions in a Project IMG, from the IMG menu, choose View → Additional information → Technical data → Client-dependence.

n Cross-client Customizing affects either:

� Cross-client Customizing objects, which are Repository objects generated by Customizing demands. To ensure proper transport, assign these Repository objects to a customer development class. Examples of these objects are matchcodes, condition tables, and hierarchies.

� Global Customizing settings, which are the standard system settings and configurations in various tables whose key value does not contain a client number. Examples of these settings are calendars, printer settings, communication settings, and schedules.

n While client-specific Customizing changes are recorded to Customizing change requests, cross-client changes must be saved to Workbench change requests. Thus, changes to cross-client Customizing objects, global settings and Repository objects require a Workbench change request.

SAP AG 1999



l Define the general concept of projects in Customizing

l Explain the relation between the Implementation Guide (IMG) and the Customizing Organizer

l Use the Customizing Organizer to create, manage, and releaseCustomizing change requests

SAP AG 1999

Appendix: Customizing Using Current Settings

Table T000• Changes and transports for client-

specific objects: No changes allowed• Cross-client object changes:

No changes to Repository and cross-client Customizing objects

• Client role: Production

Production Client

•

• Exchange rates TRX1• Insur. Premiums TRX2• Pension schemes TRX3• Interest rates TRX4

Viewcluster SOBJ

•Exchange rates• Insurance premium• Pension schemes• Interest rates

n Certain kinds of Customizing changes, known as data-only Customizing changes, need to be carried out in a production client without being saved as change requests. Examples of such data include interest rates, health insurance premiums, pension schemes, tax schemes, and currency exchange rates, which may require frequent adjustment in R/3.

n Since these types of changes have no effect on business processes, they are not subject to extensive testing like other Customizing changes. To avoid having to use change requests for these changes, SAP has introduced the Current Settings function.

n Current Settings may be used within a production client without impacting business flow related Customizing objects.

n SAP-approved Current Settings for Customizing objects are kept in the field CURSETTING in the table OBJH, that can be viewed by viewcluster SOBJ. SAP recommends that no customer changes be made to the table.

n When using Current Settings in a production environment:

� Client role is set to Production

� Cross-client object changes are set to: No changes to Repository and cross-client Customizing objects

� Changes and transports for client-specific objects are set to: No changes allowed.

SAP AG 1999

Further Documentation

In SAPNet, see also:

l SAP Note 1916

l Information about AcceleratedSAP(use alias "ASAP")

SAP AG 1999

l Do the exercises?

l Solutions for the exercises

Unit Actions

Change Management for Customizing: Exercises

No. Exercise

1 Your are the project leader for a team of customizers preparing to implement the R/3 Sales and Distribution module at company TRANS Inc. Keep in mind during the exercises that your role as a project team leader requires managing many team members who typically have more limited authorization and access to R/3 functionality.

1.1 What are the roles and responsibilities of a project team leader in regard to change and transport management? What authorizations are required to realize this role within R/3?

1.2 Your Customizing team has a project leader with the account LEAD-##, where ## is your group number. Log on to the Customizing client as the project leader.

1.3 Authorizations are used to restrict the activities of a team member. What change management tasks should a team member NOT be allowed to perform? Why? What authorization does SAP provide to enable a team member to perform change management tasks?

2 Ideally, Customizing activities are organized in projects and Project IMGs are created. As a project leader, you are responsible for a project named CUST_##. It has already been defined and the scope of the project determined. However, you need to link the project to the Change and Transport System (CTS).

2.1 Review Project CUST_## that was created in the development system. Check the scope of your project and the Project IMG views created for mandatory (critical and non-critical) activities.

2.2 Activate the CTS functionality for Project CUST_##. Assign a change request of type Customizing to the project – this will require creating a change request.

2.3 Verify that the project status for your project is maintained so that change requests can be created and transported to the QAS system?

2.4 Save and exit your project.

3 Customizing is required to enable someone at TRANS Inc. to create and process a sales order within the R/3 System. In particular, you must define a distribution channel and a sales group.

3.1 To perform the Customizing for Sales and Distribution, you need to use the Project IMG that was generated for Project CUST_##. View the Project IMG assigned to the Project CUST_##.

3.2 As a Customizer for Project CUST_##, expand the Project IMG hierarchy to use the Customizing activity Enterprise Structure → Definition → Sales and Distribution → Define, copy, delete, check distribution channel. This enables you to define the distribution channel ##, where ## is your group number. Choose continue to acknowledge the information that the same Customizing objects are also maintained in other projets.

Note: To simplify defining a new distribution channel, copy an existing one

(use the function Copy as) and provide a new key and description.

3.3 Save the distribution channel and record the change to the Customizing change request assigned to Project CUST_##.

3.4 From within your Project IMG for CUST_##, is it possible to record changes to a Customizing change request that is not assigned to Project CUST_##?

3.5 Using the Customizing Organizer, view the contents of the Customizing change request and its task. What table entries are recorded in the task?

3.6 To create a new sales group, from the Project IMG hierarchy for Project CUST_##, choose Enterprise Structure → Definition → Sales and Distribution → Maintain sales group. Create the sales group S##, where ## is your group number. Save the sales group and record the change to the Customizing change request assigned to your project.

Note: Define a new sales group by copying an existing entry (use the function Copy as). The minimum data you need to provide is a description for the S##.

3.7 Using the Customizing Organizer, view the contents of the Customizing change request and task. What new table entries were recorded in the task?

4 The Customizing changes made to TRANS Inc. are ready for unit testing. All unit testing is performed in the unit test client.

4.1 Why does SAP recommend using a separate client for unit testing?

4.2 Log on to the unit test client on the development system as the user LEAD-##. The default password is INIT.

4.3 Copy your newly created distribution channel and sales group from the Customizing client to the unit test client in the development system using the functionality Copy Transport Request.

4.4 Review the log files associated with the Copy Transport Request you just performed.

4.5 Although the log files indicate that the client copy of the change request was successful, verify that your distribution channel and sales group were copied to the unit test client. Use the SAP Reference IMG to see if the Customizing entries exist in the unit test client for the two Customizing activities you performed in client 300.

5 After the Customizing has been completed and unit tested, the change requests will need to be released. (Do not release the project!)

5.1 Is it possible to release the tasks and change request of another project leader?

5.2 Is it possible to release a change request if some tasks are not yet released?

5.3 Changes have been made and recorded in the Customizing client and then unit tested in another client. From which client must the tasks and change requests be released?

5.4 Release the Customizing task or tasks to which you recorded changes.

5.5 Release and export the Customizing change request for Project CUST_##. For each change request released, verify that the export process completed without error.

5.6 How can you verify that the release of each change request was successful?

5.7 When Customizing change requests are released, they automatically added to the import queue for the quality assurance system. How do the change requests know that the next system in the system landscape is the quality assurance system?

6 Optional exercise: Perform a Customizing activity that generates a client-independent Customizing object.

6.1 Some Customizing activities actually create new Repository objects, more commonly known as generated Customizing objects. For example, a pricing condition table is a generated cross-client Customizing object Thus, a Workbench change request of type transportable is required. As the project leader, use the Customizing Organizer to create a transportable change request.

Be sure to assign the new change request to your Project DEV_P#####.

6.2 In the Project IMG for Project CUST_##, choose the IMG activity for Sales and Distribution → Basic Functions → Pricing → Pricing Control → Define condition tables → Create condition tables. Create the condition table 5## where ## is the number assigned to you. Save the condition table to development class ZDEVBC325. Record the change to a change request belonging to your project

Note: Ignore the activation warning that may appear.

6.3 Return to the Customizing Organizer. Review the contents of the transportable change request. Which objects were recorded by creating a pricing condition table?

6.4 Display the Object Directory for all objects that you are responsible. Note the differences between each object and compare the objects in the R/3 System with those actually recorded in the change request.

6.5 Release and export the change request containing the condition table.

7 Optional exercise: Perform a Customizing activity that changes cross-client settings.

7.1 Expand the General Settings tree structure from within your Project IMG for CUST_## and view the client dependency for all Customizing activities.

7.2 To demonstrate making a client-independent Customizing setting, create a public holiday in the calendar. The holiday is your birthday. To create the holiday, use the IMG activity for General Settings → Maintain Calendar.

7.3 The calendar and public holidays are transported manually. Transport the calendar using the manual transport functionality provided in the IMG activity General Settings → Maintain Calendar. This will require create a new change request to which the calendar is recorded.

7.4 What type of change request is required to transport the calendar?

7.5 Release and export the change request containing the calendar and your public holiday.

Change Management for Customizing: Solutions

No. Solution

1

1.1 The project team leader is responsible for the creation of projects and the relevant Project IMGs in which Customizers work. The project leader is then responsible to create change requests, assign team members to the change requests, associate change requests to the project, and eventually for the release of change requests. This requires the R/3 authorization S_CTS_PROJEC. You can use the authorization profile S_A.CUSTOMIZ to provide a user with basic project leader authorizations including S_CTS_PROJEC.

1.2 Log on to DEV as project leader LEAD-## in client 300.

1.3 A team member is responsible for performing project activities such as development and Customizing. They are responsible for working from within their Project IMG to perform required Customizing activities and development efforts. After unit testing their changes, a team member is responsible for releasing their tasks. However, they should not release change requests. Releasing of a change request is a significant step, indicating the changes it contains are ready to be transported downstream and ultimately into the production system. For each request released, log files are generated and need to be reviewed. All released change requests require quality assurance testing and verification.

SAP protects against the release of change requests by providing the authorization S_CTS_DEVELOP. S_CTS_DEVELOP is for all task level responsibilities, but not for the creation or release of a change request. The authorization profile S_A.DEVELOP exists for team member Customizing and development work and includes the authorization S_CTS_DEVELOP.

2

2.1 To review the definition of Project CUST_##, choose Tools → AcceleratedSAP → Customizing → Project Management. Mark the Project CUST_## and choose Display project. The scope of the project is defined within the Scope tab. Note that the Project IMG was generated by manually selecting components from the SAP Reference IMG (rather than choosing specific application components). By choosing the Project views tab, you can see the related Project IMG views that are defined.

2.2 To change Project CUST_##, choose Tools → AcceleratedSAP →Customizing → Project Management. Mark the project CUST_## and choose Change project. (Or, if you are currently displaying the project, choose Customizing project → Display / Change.) To activate CTS functionality for the project, select the tab Transport request and choose “Activate CTS functionality”. Confirm the information dialog box concerning the “activation of CTS project functions”.

To assign change requests of type Customizing, choose ‘Assigned CTS requests’. In the next screen, choose Create request. In the selection dialog box, choose Customizing request and choose copy. To create the Customizing request, enter a short description and provide the names of any

other users that you may wish to add to the change request besides your user. Note that the proposed project ID for this project is DEV_P<#####> where ##### is a system assigned sequential value. Choose Save to have the change request created and assigned to Project CUST_##.

2.3 From the Transport request tab in the Display project screen, choose CTS project status switch to see configured transport targets. For your project, it should be set so that “All configured transport targets.” This will ensure that all change requests assigned to the project can be created and released on system DEV in the source client 300, and can also be imported into QAS . The change requests for this project are to follow the transport routes defined by TMS. For this class as in most implementation, you will not want to change this default setting. However, if you wish to prevent the creation, release or import of change requests for a particular project, you would do it by changing the project status switch.

2.4 To save changes to your project, from the Change: Project CUST_## screen choose Save.

3

3.1 From the R/3 initial screen, choose Tools → AcceleratedSAP → Customizing → Edit project (Transaction SPRO). To see the Customizing required for Project CUST_##, mark this project on the worklist and choose Display project. The Project IMG tree structure for Project CUST_## is displayed. Expand any one of the functional branches to view Customizing activities for this project.

3.2 To access the IMG Customizing activity, click on the clock-and-check icon next to Define, copy, delete, check distribution channel. A warning message indicates that this activity is also a Customizing activity maintained in other projects. Choose Enter to continue. To create the new distribution channel, choose Define distribution channel. A list of distribution channels is displayed. Select an existing distribution channel and choose Copy As. Give the distribution channel the key ## and a short description.

3.3 To save the new distribution channel, choose Save. The dialog box Prompt for Customizing request is displayed. View possible change request for the current Customizing project by choosing F4. Because CTS functionality is activated, only change requests for your project – technically referred to as DEV_P##### – are displayed. To select a change request, double click either a change request number or a task number. The change request number is supplied to the Prompt for Customizing request dialog box. To save your change, choose Continue. To exit from the distribution channel listing, choose Back. There is no need to perform any additional activities. To return to Project IMG choose Cancel.

3.4 The answer is ideally NO, but if you have the authorization to create change requests, the answer is YES.

Typically, if you are using the Project IMG of a specific project, you can only save your changes to a change request assigned to that project.

However, because of the authorizations assigned to you as a project leader, when saving a change, you can create a new change request. By default, the new Customizing change request is assigned to the current project. You can eliminate the proposed project or change the project assignment for the new

change request. This then allows you to record the change to a change request that is not assigned to the current project.

Note that the owner of the change request can change the assignment of the change request to a project at anytime using the Customizing Organizer or Workbench Organizer.

3.5 To go to the initial screen of the Customizing Organizer, choose Tools → AcceleratedSAP → Customizing → Customizing Organizer (or use Transaction SE10). To display change requests for the current user (LEAD-##), choose Display. The view the change recorded as a result of creating a new distribution channel, expand the change request and task to which the change was recorded. Note that changes were recorded to the view V_TVTW. You can also see that the view V_TVTW consists of the tables TVTW and TVTWT. The key value recorded to tables include both the client number (for example, 300) and the number you assigned to the distribution channel.

3.6 To access the Project IMG for your project, from the initial R/3 menu choose Tools → AcceleratedSAP → Customizing → Edit project (or use Transaction SPRO). Select Project CUST_## from the worklist and choose Display project. The Project IMG tree structure for Project CUST_## is displayed. Expand the IMG hierarchy to get to the particular IMG activity.

To access the IMG Customizing activity, click on the clock-and-check icon next to Maintain sales group. A warning message indicates that this activity is also a Customizing activity maintained in other projects. Choose Enter to continue. A list of available sales groups is displayed. Select an existing sales group and choose Copy As. Give the sales group the key S## and a short description. Choose Transfer.

To save the new sales group, choose Save. The dialog box Prompt for Customizing request is displayed. View possible change request for the current Customizing project by choosing F4. Because CTS functionality is activated, only change requests for your p roject – technically referred to as DEV_P##### – are displayed. To select a change request, double click either a change request number or a task number. The change request number is supplied to the Prompt for Customizing request dialog box. To continue to save your change, choose Continue. To exit from the distribution channel listing, choose Back. There is no need to perform additional activities. To return to Project IMG choose Cancel.

3.7 To go to the initial screen of the Customizing Organizer, choose Tools → AcceleratedSAP → Customizing → Customizing Organizer (or use Transaction SE10). To display change requests for the current user (LEAD-##), choose Display. To view the change recorded as a result of creating a sales group, expand the change request and task to which the change was recorded. Note that changes were recorded to the view V_TVKGR. You can also see that the view V_TVKGR consists of the tables TVKGR and TVGRT. The key value recorded to tables include both the client number (for example, 300) and the number you assigned to the sales group.

4

4.1 A unit test client provides an environment where customizers can test the contents of their tasks and change requests. It also provides a client for

maintaining application data that is separate from the Customizing environment.

4.2 Log on to client 400 on system DEV as user LEAD-## with the default password INIT. Because you have not yet logged on to this client, you are required to provide a new password.

4.3 To perform a Copy Transport Request, from the R/3 initial screen choose Tools → Administration → Administration → Client Administration → Special functions → Copy Transport Request (or use Transaction SCC1). Specify the source client to be client 300. Provide the change request ID for the change request to which your new distribution channel and sales group are saved. (The change requests for your user can be displayed using F4.) Select the option Incl. tasks for request and choose Start immediately. Once the copy has completed, a log file is displayed. To return to Transaction SCC1, choose Back.

4.4 All client copy logs files can be viewed from within R/3. From the R/3 initial screen, choose Tools → Administration → Administration → Client Administration → Copy logs. To view log files specific to change requests, first choose All clients and then All transport requests. To view the copy log for a specific change request for client 400, double-click the target client 400. To view the log file associated with your change request, double-click your request number.

4.5 From the R/3 initial screen, choose Tools → AcceleratedSAP → Customizing → Edit project → SAP Reference IMG. The tree structure for the SAP Reference IMG is displayed. Choose Enterprise Structure → Definition → Sales and Distribution. Choose the IMG activity icon next to Define, copy, delete, check distribution channel and see if your distribution channel is available. Return to SAP Reference IMG and choose Maintain sales group and see if your sales group is available.

5

5.1 It is not possible to release a task for which you are not the owner. However, a user with appropriate authorization can change the owner of a task. For example, the project team leader can change ownership of a task owned by a team member and then release the task. Changing ownership of a task (or a change request) is recorded in the action log of the task (or change request).

5.2 It is not possible to release a change request if some tasks are not yet released. SAP prevents the transport of objects that may still be under construction.

5.3 Change requests and tasks can only be released in the client from which they originated. In other words, all releasing must take place from the Customizing client 300 in the development system DEV.

5.4 As LEAD-## in client 300, from the Customizing Organizer: Requests overview screen, expand the tree structure of the Customizing change requests.

To release a task, select the task and choose Release directly. If documentation for the task has not yet been provided, the documentation screen appears. Provide documentation for the task and choose Save. To

exit from the documentation screen, choose Back.

Review the message bar at the bottom of the SAPGUI screen. The message bar will indicate if the task was released or if an error occurred during the release process. As another indicator, the color of the change request in the Customizing Organizer: Requests overview screen will change if the task has been successfully released.

5.5 Expand the tree structure of Customizing change requests in the screen Customizing Organizer: Requests.

To release a change request, select the change request and choose Release directly. The dialog box Release Customizing Request is displayed. To release the change request so that it can be imported into the quality assurance system, choose Release and export, then choose Continue. This exports also the change request to the file system after being successfully released.

During the release and export process, the export log for the change request is displayed. Initially, the export log file reports that the export is currently in process. Choose Refresh until the log file reports that the export has completed. Expand the log file to verify that the export from DEV is successful. To return to the Customizing Organizer hierarchy, choose Back.

5.6 Log files for each release and export can be displayed immediately following the release of a change request.

However, to review export log files at a later time (or for another user) return to the initial screen of the Customizing Organizer using Transaction SE10. Enter the user whose transport information you wish to see, for example LEAD-##. On the right side of the screen, the Global Information is displayed showing generic data on the number of transports and the success of those transports. To display log files associate with these requests, choose Transports. A tree structure containing R/3 Systems and transport logs are displayed. To see either the export logs (or eventually the import logs), drill down to each system and change request.

5.7 Customizing change requests all follow the standard transport layer defined by the Transport Management System. The development system DEV has a standard transport layer of ZDEV. The transport layer ZDEV consolidates to the quality assurance system QAS. Therefore, all Customizing change requests released and export from DEV consolidate to QAS.

6

6.1 Log on to DEV as LEAD-## in client 300.

Access the Customizing Organizer using Transaction SE10. Because you need to create a Workbench change request of type transportable, select the category Workbench and choose Display. To create a change request, choose Request/task → Create…. The dialog box Create Request is displayed. Select Transportable change request and choose Copy. Provide a Short description for the request. Assign the change request to your project DEV_P#####. Save the new request.

6.2 In the Project IMG CUST_## tree structure, choose the IMG activity for Sales and Distribution → Basic Functions → Pricing → Pricing Control → Define condition tables → Create condition tables. Continue past the warning and

choose Create condition tables. Provide a number for the condition table to be created – the number should be 5## where ## is the number assigned to you. To proceed, choose Enter. (There is no need to provide a Reference Condition table.)

Select one or two fields for Selected fields by double clicking on field entries under the column FieldCatlg. After selecting the fields, choose Generate. (If you get the error message ‘Table is already defined with the same fields’ choose another field. All condition tables must have unique Selected fields.) The dialog box Generate Conditions is displayed. To continue with the generation, choose Yes.

All Repository objects require a development class. Enter the development class ZDEVBC325 for the new object. Save the change to the transportable change request for your project DEV_P#####.

Ignore the activation warning that may appear. To return to the IMG, choose Back.

6.3 Access the Customizing Organizer using Transaction SE10. Because you need to create a Workbench change request of type transportable, select the category Workbench and choose Display. Expand the tree for the transportable change request containing the pricing condition table. Two condition table objects were recorded to the task – a condition table info structure and a condition table, both of which are named A5##.

To see the actual program IDs and object names recorded to the task, select the task and choose Request/task → Object list → Display object list. The following entries should appear: R3TR VKOS A5## R3TR VKOI A5##

The condition table is assigned the letter “A” followed by the number you gave your table. Although you created a table, note that there is not an entry for the object R3TR TABL A5##.

6.4 To search for objects in the object directory, view the table contents of table TADIR. To access table/view maintenance, choose Transaction SM31. Supply the table name TADIR and choose Display. To search for objects in find all objects for which you have created, enter yourself as Person responsible. Choose Execute.

Three objects with the name A5## are listed. First, review the objects that are contained in your task – the object entries for R3TR VKOI and R3TR VKOS. These two objects are in the development class ZDEVBC325 and are originals in the system DEV. These are the objects you created during your Customizing. The data required to generate a condition table is contained in the Repository objects R3TR VKOI A5## and R3TR VKOS A5##. Using these objects, R/3 generates the condition table R3TR TABL A5##. Therefore, this table is owned by SAP and belongs to an SAP development class.

The condition structures are what SAP transports, not the table itself. The table is generated during the import of the change request and therefore does not need to be recorded in the change request.

6.5 From the Customizing Organizer: Requests screen, select the task to which the condition table has been recorded and choose Release directly. If

documentation for the task has not yet been provided, the documentation screen is displayed. Provide documentation for the task and choose Save. To exit from the documentation screen, choose Back.

To release the change request, select the change request and choose Release directly.


7

7.1 To access the Project IMG for your project, from the initial R/3 menu choose Tools → AcceleratedSAP → Customizing → Edit project (or use Transaction SPRO). Select Project CUST_## from the worklist and choose Display project. The Project IMG tree structure for Project CUST_## is displayed. Expand the IMG hierarchy for General Settings.

To display the client dependency for all Customizing under General Settings, choose View → Additional information → Technical data → Client-dependence. Note that the IMG activity Maintain calendar is cross-client and thus client-independent. However, the IMG activity Check units of measurement is client-specific and thus client-dependent.

7.2 In the Project IMG tree structure for CUST_##, choose the IMG activity for General Settings → Maintain calendar. Continue past the warning.

To change the current calendar, select Public holidays and choose Change. The Public Holidays screen is displayed, listing all defined public holidays. To create a new public holiday, select Create . The dialog box Change Public Holiday is displayed. Because the holiday is to be based on your birthday, select with fixed date and choose Create . Provide the day and month of your birthday. At the bottom of the screen, provide a short and long text description for the public holiday. To create the holiday, choose Create .

Note that SAP provides a warning that the change is not automatically transported and requires manual transport. Choose Continue. The Public Holidays screen appears listing your birthday as a public holiday. Choose Back to return to the initial menu for maintenance of the calendar.

7.3 To transport the current calendar, from the initial maintenance screen for the calendar, choose Calendar → Transport. The dialog box Transport Calendar is displayed, informing you of that all changes to the calendar are not recorded to change requests but that the entire calendar must be manually transport. To proceed, choose Continue.

When prompted for a change request, choose Create Request. Note that the change request is automatically assigned to your project. Provide a short description for the change request and record the calendar to the newly created change request by choosing Continue. To return to the Project IMG, choose Back.

7.4 Because the calendar is client-independent, transporting the calendar requires a Workbench change request of type transportable.

7.5 From the Customizing Organizer: Requests screen, select the task to which

the calendar change has been recorded and choose Release directly. If documentation for the task has not yet been provided, the documentation screen is displayed. Provide documentation for the task and choose Save. To exit from the documentation screen, choose Back.

To release the change request, select the change request and choose Release directly.


SAP AG 1999








Change Management for Developing

SAP AG 1999

Change Management for Development

Contentsl Adapting R/3 to meet customer business requirements through

developmentl Using the Workbench Organizer

l Modifying SAP Repository Objects

ObjectivesAt the end of this unit, you will be able to:l Define the functions of change requests and the Object Directory

l Use the Workbench Organizer to create and manage change requestsl Analyze change requests using Workbench Organizer tools

l Modify SAP Repository objects

SAP AG 1999

Perform all development

in a single R/3 System

DevelopmentProject

Change requestTask Task

Planning Change Management for Development

Restrict Repository object changes:l Create a single R/3 System for all

developmentl Ensure proper system and client change

optionsl Assign appropriate user authorizations

Define development standardsl Use development classes to group parts of

the development projectl Establish standards for development and

documentationl Maintain versions

Establish project teams:l Provide all project teams with training on

change request management tools.l Assign team leaders to projects and assign

change requests to team members.

n The R/3 change management solution is based on creating, documenting, and distributing change requests. The customer must set up the infrastructure for the management, verification, and testing of changes.

n Recommendations for development change management include the following:

� Perform development efforts in a single environment only: the development system. Set the system change option accordingly.

� Use development classes to group functionally related Repository objects. The transport layer assigned when creating a development class enables the same pre-defined transport route to be used for all objects in the development class.

� When releasing a change request, document the purpose and the status of the changes.

� To maintain security, use authorizations to control which users can create, modify, or release change requests. SAP delivers sample authorization profiles that provide the system access required for various levels of responsibility in change management.

SAP AG 1999

Cost center Edit G oto D etails Environment System He l p

?? éé

é é3333

Global SettingsCountriesCurrenciesCalendars



CustomizingDEVK900124 Change Request


View Maintenance: DataV_TVAKV_TSPA

Transport Management System

Workbench Organizer

TransportableDEVK900131 Change Request


ABAP Program SourceZCDEMOZCACTION

ABAP Development Workbench

ObjectBrowser

ABAPDictionary

ABAPEditor

FunctionLibrary

ScreenPainter

MenuPainter

ABAP Development Workbench

Customizing Tools vs. Development Tools

n SAP provides different implementation tools for Customizing and development.

n For Customizing:

� The Implementation Guide (IMG) is the main Customizing tool. Once you decide which R/3 modules you require, the IMG automatically generates a hierarchical list of steps (or Customizing transactions) for Customizing.

� The Customizing Organizer (CO) (Transaction code SE10) records Customizing changes in change requests (of type CUST) which can be released to the transport system for export to other systems in the R/3 System landscape.

n For development:

� The ABAP Development Workbench provides access to development tools, which cover the entire software development cycle. These tools may be used both for customer-specific development and SAP enhancements of R/3 applications.

� The Workbench Organizer (WBO) (Transaction code SE09) records ABAP Development Workbench changes in change requests (of type SYST), which can then be released to the transport system for export to other systems in the R/3 System landscape.

n The CO and the WBO are completely integrated with the Transport Management System (TMS).

SAP AG 1999

WorkbenchOrganizer - SE09

l Customizing

n Change documentation

n Teamwork

n Table change history(logging)

l Connected to ClientAdministration and TransportManagement System

l Development

n Change documentation

n Teamwork

n SSCR

n Development Classes

n Object locking

n Version management

l Connected to TransportManagement System

CustomizingOrganizer - SE10

Customizing Organizer vs. Workbench Organizer

n Customizing changes are saved to a Customizing change request. Development changes are saved to Workbench change requests.

n Customizing changes consist of table entries.

n Workbench change requests concern changes to R/3 Repository objects, such as ABAP programs, screens, data dictionary objects and global documentation.

n Compared to Customizing, change management for development is more complex, requiring:

� Registration of developers within SAP Software Change Registration (SSCR)

� Development classes for R/3 Repository objects

� Locking of R/3 Repository objects during development

� Versioning of R/3 Repository objects

SAP AG 1999

l Displayschangerequests

l Displays globaltransportinformation

l Providesaccess toWBO tools

Workbench Organizer (WBO)

Workbench Organizer: Initial Screen

n The Workbench Organizer is used to create, manage, release, and analyze change requests for development.

n To access the Workbench Organizer, use Transaction SE09 or, from the R/3 initial screen, choose either:

� Tools → ABAP Workbench → Overview → Workbench Organizer

� Tools → Administration → Transports → Transport Organizer → Workbench

n All Workbench change requests that belong to a specific user are displayed according to a set of standard selection criteria. Selection options include user (owner), request type, request status, and date.

n The screen area Global Information gives you a quick graphical overview of the status of transported change requests and repairs.

SAP AG 1999

SAP Software Change Registration(SSCR)

SAP Software Change Registration(SSCR)

• Developers must register withSSCR

• Each developer is assigned anaccess key

• Access key for each developeris only entered once

• Developers must register withSSCR

• Each developer is assigned anaccess key

• Access key for each developeris only entered once

Concepts of SSCR Registration

• Modified SAP objects must beregistered with SSCR

• Each object is assigned anaccess key

• Access key for each object isonly entered once per R/3release level

• Modified SAP objects must beregistered with SSCR

• Each object is assigned anaccess key

• Access key for each object isonly entered once per R/3release level

Register Developers to use ABAP workbenchRegister Developers to use ABAP workbench Register SAP objects to be modifiedRegister SAP objects to be modified

n Any R/3 user who wishes to use the ABAP Workbench to create, modify, or delete Repository objects (including customer objects) in your R/3 System must be registered using the SAP Software Change Registration (SSCR) process. Such users are often referred to as a development users or developers.

n As a result of the registration process, each developer is assigned an access key. The access key is entered and saved on the developer's system in the table DEVACCESS.

n The access key is associated with the developer's logon ID and the R/3 System's license number. The developer is prompted for the access key on the initial attempt to create or change a Repository object.

n Developers only need to enter each access key once in the R/3 System. The system will not request the access key during subsequent attempts to create or modify Repository objects. The key will remain valid through R/3 updates.

n You must register not only developers, but all Repository objects that are to be modified. When registering an object you must supply the object program ID, object type, object name, the R/3 System’s license number, and R/3 Release. After registering a SAP object in an R/3 System and applying the access key, the key is stored in the database table ADIRACCESS so that further changes to the object do not require SAP Software Change Registration. Registered objects keys become invalid after a release upgrade.

n Software Change Registration (SSCR) provides development reliability, rapid error correction, and high system availability.

SAP AG 1999

ComplementaryComplementarysoftwaresoftware

SAP Partners

DevelopmentDevelopment

SAP standardSAP standardsoftwaresoftware

SAP

Namespace prefixes uniquely identify objects created

by SAP partners

CentralCentral

Customers can reserve aname range for

a development class

DecentralizedDecentralized

Customer name ranges separate customer objects from SAP objects

Y...Z...

V_TRESN

/xxxx/Object name

Correctly Naming Repository Objects

n To prevent conflicts with object names when creating Repository objects, developers must follow naming conventions. Extended name lengths allow you to use descriptive names. Object names should clearly describe the function of the Repository object.

n Name ranges differentiate between SAP Repository objects and customer Repository objects. Customer Repository object names usually begin with a Y or Z. For an overview of all of the current naming conventions for Repository objects, see SAP Note 16466 in SAPNet.

n Using customer name ranges correctly prevents object name conflicts between customer objects and SAP objects. However, in an R/3 System with more than one development system, additional naming conventions are required to prevent object name conflicts.

n Customer name ranges can be reserved using the view V_TRESN, which enables developers to assign a specific name range to a development class.

n Reserving namespaces is the only way to prevent naming conflicts that occur with objects created in Complementary Software from SAP partners. SAP partner companies can apply to SAP for a namespace prefix through SAPNet.

SAP AG 1999

l All R/3 StandardRepository objects

l All customer developedRepository objects

l Development class

l Person responsible

l Original system

l Original language

l Repair flag

l Generation flag

The Object Directory lists:

The attributes for Repositoryobjects include:

R/3 Repository Object Attributes

Object attributesObject attributes

n The Object Directory is a catalog of all Repository objects in the R/3 System, including all R/3 standard Repository objects that are delivered with R/3 Systems, and all Repository objects created by the customer using the ABAP Workbench. Attributes for each Repository object are assigned by the system.

n With the appropriate authorization, you can modify the development class and person responsible for the object. To protect Object Directory entries, only user DDIC can modify all attributes except original language. To modify Object Directory entries from the Workbench Organizer choose Tools → ABAP Workbench → Overview → Workbench Organizer → Goto → Organizer Tools → Object Directory. Alternatively, use Transaction SE03.

n Some Repository objects may be generated automatically by the system as a result of Customizing activities. In the Object Directory, these system-created objects are flagged as "generated".

n Modifications to SAP objects or to objects that are not in their original system (such as objects being modified in the quality assurance system after having been created in the development system), are termed "repairs". In the Object Directory, these objects are flagged as "repaired".

n For each entry in the Object Directory, the primary key is comprised of the following fields: program identification (PGMID), object type, and object name. The PGMID is usually R3TR. Other PGMIDs are R3OB and LIMU.

n Examples of object types are PROG (ABAP programs), DEVC (development class), VIEW ( table view), FORM ( ABAP form), COMM (command file), and CHD0 (change document).

SAP AG 1999

l Provides a logical grouping of objects forcoordination of development efforts

l Defines a Repository object’s transport layer

l Can be used to control naming of objects

V_TDEVC

DevelopmentClass

TransportLayer

Description

AA

AA2

ZFINANCE

SAP Assets: master data 2.0

SAP Assets: master data

ZDEV Finance reports

: : :

ZINTERFACE ZDEV Interface programs

PROGRAMZZXXXXXX

ZFINANCE

Table

ZZXXX

Development class

Development Class

n All Repository objects are assigned a development class.

n Development classes are objects of the ABAP Workbench and can be created by the Repository Browser or by maintaining the view V_TDEVC. When creating a development class, the standard transport layer is assigned by default to the development class. Users may also choose an alternative transport layer.

n Customer development classes may begin with the following letters:

n Y or Z indicates that the development class is for objects that are to be transported.

n $ indicates a development class for temporary objects that are not to be transported and therefore do not require a transport layer.

n T indicates a development class for local objects which are linked to the Workbench Organizer, which provides version management and object locking.

n The development class $TMP is used when a Repository object is saved as a local object and is not recorded to a change request.

n You can use view V_TRESN to specify which development class can be assigned for a name range. For example, program names starting with the string ZTE are prevented from being assigned to a development class other than the one defined for this name range in V_TRESN.

n The view V_TDEVC holds all development classes in the R/3 System, including all SAP development classes.

SAP AG 1999

ConsolidationConsolidation

QAS

SAP

ZDEV

ZTRN

•• Consolidation routes Consolidation routes


TRN

IntegrationIntegration

DEVZDEV

Transport Layers and Development Classes

l A development class isassigned to a transportlayer

l If the transport layer is avalid consolidation route,the objects of thatdevelopment class aretransported to theconsolidation system

l SAP objects modified in thecustomer integrationsystem follow the SAPconsolidation route

n When a transport layer is assigned to a development class, all objects belonging to that development class have the same predefined consolidation route. This also means that it is not possible to transport Repository objects into two consolidation systems in one step. SAP does not recommend using parallel consolidation systems.

n In the diagram, both the SAP transport layer and the the standard transport layer ZDEV follow the same consolidation route from DEV to QAS, that is, from the development system to the quality assurance system. All Repository objects assigned to a development class whose transport layer is ZDEV are transportable.

n In this example, the transport layer ZTRN follows a consolidation route from DEV to TRN (from the development system to the training system). All Repository objects assigned to a development class whose transport layer is ZTRN are transportable.

n SAP objects belong to the pre-installed SAP transport layer. These objects cannot be reassigned to customer transport layers. In the diagram, SAP objects that are modified in DEV will follow the standard transport layer and be transported to QAS. There is only one SAP transport layer in a system landscape.

n In this example, only Repository objects whose development class has the transport layer SAP, ZDEV, or ZTRN can be transported using the Workbench Organizer. In other words, if an object is assigned to a transport layer that is either blank or for which there is no transport route, the object cannot be transported using the Workbench Organizer.

SAP AG 1999

l Change requests or tasks of typeunclassified have empty object lists.

l Changes to original objects are savedto tasks of type Dev. / Correction.

l Changes to copies are saved to tasks oftype Repair.

l The development class of a Repositoryobject determines if a change request oftype Transportable or Local is required.

Unclassified

Unclassified

Repair

Dev./correction

Transportable

Repair

Dev./correction

Local

Classifying Tasks and Change Requests

n A distinction is made between two types of development tasks: development/correction (changes in the original system) and repair (changes in a system other than the original system).

n When changing an object that is not an original, the system prompts the user to specify Object for repair. For the object specified, a repair flag is set to prevent the object from being overwritten by imports into the system. Thus, the object is locked exclusively for the task of type repair.

n Unlike changes to original objects, repairs do not allow access to other developers listed in the same change request. To enable another developer to edit the object, make that person the owner of the repair using the Change owner function in the Workbench Organizer.

n When a task of type repair is released, the repair flag is deleted automatically.

n The development class of the Repository object determines whether the change request type is transportable or local. If the assigned development class has a valid transport layer, a request of type transportable is used. Otherwise, a local change request is used.

SAP AG 1999

Only developers assigned to theWorkbench change request maymodify Repository objects lockedby that request.

WBO Change Request - DEVK900096

Original objectsmay be modifiedby all developersassigned to theWorkbenchchange request.

Task DEVK900098

Task DEVK900097

ZABAP01

ZABAP02

ZABAP04

ZABAP03

----------

----------

----------

R/3 Repository Object Locking

n There are two locking mechanisms when Repository objects are being modified:

� The editor program which works with the enqueue work process to ensure that only one user at a time can modify an object in the system, and

� The Workbench change request which ensures that the developer modifying the object is assigned to a valid task within the Workbench change request.

n When a Repository object is assigned to a task within a Workbench change request, that object can only be modified by the developers associated with that change request. This prevents users outside the development team from making changes to any of the objects in the change request.

n An object list is associated with each task. Each user working on an object has a corresponding entry in the object list of their task. The object list records which users have actually edited the object.

n Objects may be manually entered in the object list of a task or request. These objects are not automatically locked if they are entered manually. To manually lock the object, in the Workbench Organizer Initial Screen, choose Display → Request/task → Object list → Lock objects.

SAP AG 1999

Quality Assurance

CopyCopy

CopyCopy

CopyCopy

Original objectOriginal object

Development


Repair


Development

Repair

CopyCopyModification

Development

DevelopmentLocal objects

Repository Objects: Originals and Copies

n R/3 Repository objects should only be changed in the R/3 System where the system identifies them as original objects. An object is the original in only one system, the system where it was created. All other systems may only contain copies of the object. This ensures that changes are only made to Repository objects in the development system.

n When a Repository object is transported to a downstream system, it exists there as a copy. When changes are necessary, to prevent inconsistencies between versions, you should change the original in the development system and transport it to the other systems. Changes to copies are only made in exceptional cases and are termed repairs. In all customer systems, including the customer's development system, SAP-delivered Repository objects are copies. Repairs to SAP objects are termed modifications.

n The system change options selected when setting up the Workbench Organizer (Transaction SE06) control which Repository objects can be modified in the R/3 System. Only in the development system should be set to permit changes to customer-developed objects and, if necessary, SAP objects.

n Objects saved as local objects are not transported.

SAP AG 1999

DATA: BEGIN OF OUTLINE, TRSTATUS LIKE E070-TRSTATUS, BLANK3, USER LIKE E070-AS4USER, BLANK4, AS4DATE LIKE E070-AS4DATE, END OF OUTLINE. DATA: OLDKORR LIKE E070-TRKORR.

CLEAR OUTLINE. OUTLINE-STRKORR = TEXT-001. OUTLINE-TRKORR = TEXT-002. OUTLINE-USER = TEXT-003. OUTLINE-DATE = TEXT-004.

DATA: BEGIN OF OUTLINE, TRSTATUS LIKE E070-TRSTATUS, BLANK3,*{ REPLACE &$&$&$&$ 1*\ USER LIKE E070-AS4USER, as4USER LIKE E070-AS4USER,**} REPLACE BLANK4, AS4DATE LIKE E070-AS4DATE, END OF OUTLINE. DATA: OLDKORR LIKE E070-TRKORR.

CLEAR OUTLINE. OUTLINE-STRKORR = TEXT-001. OUTLINE-TRKORR = TEXT-002.*{ REPLACE &$&$&$&$ 2*\ OUTLINE-USER = TEXT-003. OUTLINE-as4USER = TEXT-003.**} REPLACE OUTLINE-AS4DATE = TEXT-004.

An object before modificationAn object before modification

DeleteDeleteReplaceReplaceInsertInsert

An object after modificationAn object after modification

Modification Assistant

n To support the different levels of modification, SAP provides tools such as: the IMG, Business Add Ons, Transaction CMOD, and the ABAP development environment.

n The Modification Assistant helps you modify SAP standard delivered objects and simplify the upgrade process. When you change SAP objects in an ABAP Workbench editor, you branch into a special modification mode. Originals are initially protected in this mode and are only changed when you press the corresponding buttons.

n The Modification Assistant logs all modifications that are made in the system. The log is easy to read and dramatically reduces the amount of effort needed to upgrade your system.

n In addition, the Modification Assistant works with the most commonly used ABAP development tools such as ABAP Editor, Screen Painter, Menu Painter and Text element maintenance.

n The Modification Assistant is not used for changes made to objects such as global interfaces and classes and their components. These objects are adjusted in the system during upgrade in the conventional manner.

SAP AG 1999

New SAP standardNew SAP standard

Customer modificationCustomer modification

Merging necessaryMerging necessary

Development Quality assurance

CopyCopy CopyCopy

RepairModificationAdjustment

Upgrade

Modification Adjustments after Upgrade

n If a new version of an SAP object is imported into the customer system, as part of an upgrade, adjustments must be made to the repaired SAP object. (Modifications are also considered repairs.) This may involve making the same customer changes to the new SAP object.

n Before the upgrade, all open repairs must be confirmed and released. This check is performed by the upgrade check routines of the tool PREPARE.

n To adjust the ABAP Dictionary during an upgrade, use Transaction SPDD. To merge all other Repository objects, use Transaction SPAU.

n Modification upgrades are not automatic. Customers must decide which development efforts and modifications they wish to retain, bearing in mind that the new SAP functionality may quite possibly make retaining the modification unnecessary.

n Adjusting modified objects is simplified by the Modification Assistant.

SAP AG 1999

Developer

Administrator

Import changerequests to

target systemusing TMS

Project leader

Release and exportchange request

Document and releasetask (confirm repair )

Create/change object using

Workbench tools

Assign object tochange request

Enter SAP Software Change Registration access

key for the SAP object

Versionmanagement

SAPModification?

Assign object to a development class

Change the object

Access controland teamwork

New object?

YES

YES

NO

NO

Change the SAP object Create the object

Modification versus Development

Importqueue

n Before changing SAP-delivered Repository objects (performing a modification), you must not only be registered as a developer in SAP Software Change Registration (SSCR), you must also register each SAP object you intend to change. Registering the object gives you an access key which you apply only once to the object.

n When performing a modification, the Workbench Organizer prompts you for a change request in the same way that it does when you make changes to customer-owned objects. Since the object is owned by SAP and not the system itself, the change will be saved to a task of type repair.

n All SAP objects have SAP-defined development classes. All new customer Repository objects must be assigned to a customer-created development class. Development classes are used to group objects in the project and transport them along the same transport route.

n After the repair task or transportable task is complete, the developer releases the task, and the lock on the object is transferred to the change request.

n At the end of the project, the change request is released. This releases all locks and records a version of the changed objects (both SAP and customer objects) in the version database.

SAP AG 1999

Releasing a task requires:

l User owns the task

l Content in the task

l Documentation

DEVK900097

DEVK900098

DEVK900099TaskTask

DEVK900096WorkbenchWorkbench

changechangerequestrequest

Release ReleaseReleasing thechange request:

• Writes a version tothe version database

• Unlocks the object

• Exports data if thechange request istransportable

Documentation

Releasing a change request requires:

l User owns the change request

l Documentation and release of alltasks in the change request

l All objects are or can be locked

Releasing Change Requests

n After the development tasks are completed, a change request is released so that the changes can be transported to another R/3 System.

n Releasing a task or change request requires:

� The person releasing the task or change request must be its owner and have the correct authorization

� Objects in the task or change request are (or can be) locked

n Releasing a change request requires that all tasks were documented and released.

n A released task can no longer be modified, but additional tasks can be created to modify the objects in the released task. A released task cannot be deleted. However, if the task is empty, it is deleted when the change request is released.

n Releasing a transportable change request records a version of all the objects included the change request, and then exports the objects (copies the objects from the database to an operating system file).

n Releasing a local change request records a version of the objects in the change request, but does not export them to a file at the operating system level.

SAP AG 1999

Report Source Versions: ZZABAP

Development DB

Active and temporary versions

Versions of R/3 Repository objects can be:

l Compared

l Restored

Version REL Request Date Time Author

Versions in the development database

Versions in the version database

act. 4.0A DEVK900110 10.05.1998 10:10:00 Developer

00002 4.0A DEVK900105 08.05.1998 18:10:00 Developer

00001 4.0A DEVK900096 07.05.1998 08:04:00 Developer

Version Overview

Version DB

All versions savedthrough releasingchange requests

Version Management

n When a change request is released, a new version of each Repository object in the change request is written to the version database, which thus contains a complete change history of all Repository objects. In addition to the versions created automatically by the release of change requests, users can also create temporary versions at any time. To do this, in the maintenance transaction for the Repository object, choose Create version.

n You can access version management from:

� Repository Browser (Transaction SE80)

� Workbench Organizer (Transaction SE09)

� Display and maintenance transactions for all Repository objects.

n In the Version Overview, the active and temporary versions are displayed in the development database, and versions saved as a result of released change requests are displayed in the version database.

n The version database resides in the development system. Versions cannot be transported between R/3 Systems. If the development system is removed from the system landscape, all versions in the version database are lost.

SAP AG 1999

Monitor Transports

n After releasing a transportable change request, review the transport logs to ensure that the export was successful.

n To access the transport logs, from the initial screen of the Workbench Organizer (Transaction code SE09), choose Display→ Goto → Transport log.

n In the transport logs, the return codes indicating the success or failure of the export are:

� 0: The export was successful

� 4: A warning is issued but all objects were transported successfully

� 8: A warning is issued and at least one object could not be transported successfully

� 12 or higher: A critical error has occurred (generally not caused by the objects in the request)

SAP AG 1999

Organizer Tools

Organizer Tools SE03Organizer Tools SE03Organizer Tools SE03

Components that can be analyzed are:

• Objects

• Objects in Requests

• Object Directory

• Request / Tasks

• Administration

Components that can be analyzed are:

• Objects

• Objects in Requests

• Object Directory

• Request / Tasks

• Administration

SAP AG 1999

l Object errors can bedetected before the changerequest is exported.

l Transport errors can bedisplayed at logon.

Global Customizing Workbench Organizer

Display transport errors at logon

Globally activated

Globally deactivated

Can be set for specific user

Check objects on request release

Globally activated

Globally deactivated

Can be set for specific user

Organizer Settings

Individual settings

Display short texts of tasksDisplay change date of requestsSort by request owner

Display transport errors at logonCheck objects on request release

Workbench Organizer Settings

n Workbench Organizer settings provide customers with several options that can be used (1) for displaying transport errors at logon and (2) for applying objects checks to objects contained in change requests before the change request is exported to a file at the operating system level.

n To cause transport errors to be displayed to transport request owners when they log on, select display transport errors at logon.

n Object Checks identify and display errors found in Workbench change requests. Errors, such as program syntax errors, are identified and displayed when a change request is released, but not yet exported. More detailed information about the error can be found by simply double -clicking the error on the displayed report.

n To activate or deactivate the display of transport errors at logon and object checks:

� Globally, choose Tools → ABAP Workbench → Overview → Workbench Organizer → Goto → Organizer Tools → Administration → Global Customizing Workbench Organizer. Select Globally activated

� For a specific user, choose Tools → ABAP Workbench → Overview → Workbench Organizer → Goto → Tools → Administration → Global Customizing Workbench Organizer. Select the option Can be set for a specific user.

� For each logged on user, choose Tools → ABAP Workbench → Overview → Workbench Organizer → Display → Utilities → Settings. The options Display transport errors at logon and Check objects on request release must be set by the user that is logged on.

SAP AG 1999



l Describe several ways of adapting R/3 to meet customerbusiness requirements

l Define the functions of change requests and the ObjectDirectory

l Use the Workbench Organizer to create and manage changerequests

l Analyze change requests using Workbench Organizer tools

l Modify SAP Repository objects

SAP AG 1999

l Extension of the former Include template functionl Available in all Change and Transport Organizer transactionsl Allows you to merge the object lists of selected requests into

the current request

Include Objects in Request

Object list from request

Object list from multiple requests

Freely selected objects

Appendix: Include objects in request

n You can fill a change request with object entries by one of the following methods:

� Including the object list of one or more existing change requests You can copy the entire object list of any existing change request or change requests. This is helpful when wanting to bundle a collection of change requests to be transported using Transaction SCC1.

� Freely selected objects By entering the relevant selection criteria (for example, the object type, development class, or the responsible person), the objects found are displayed in a hierarchical overview. You can select the objects you want to include in the request.

� Manually making entries using the object list editor You can access the object list editor from the request overview by double -clicking a request or task node. The object list editor requires basic knowledge about the syntax of the entries

n Whichever method you use, the objects are initially entered in the object list without locks. When the request is released, the R/3 System tries to lock the objects. If conflicts occur with other change requests that are locking some of the objects because they are still being edited, these other change requests need to be released. Locking ensures that each object is only included in one change request.

SAP AG 1999

Super user:S_CTS_ALL

TasksChange requests

Tools View

Project team leader:S_CTS_PROJEC

Developer:S_CTS_DEVELO

End user:S_CTS_SHOW

Appendix: Authorizations for Change Management

n User authorizations control the access to R/3 transactions and data, and determine which administration functions the user is permitted to perform and what parts of a change request the user may edit.

n For both the Workbench Organizer and the Customizing Organizer, the basic authorization object is S_TRANSPRT, which includes the user authorizations shown in the diagram. These authorizations enable the respective user to perform the following activities:

� Superuser – has all authorizations related to requests and tasks

� Project leader – can create and manage requests and tasks

� Developer – can only use existing requests

� End user – only has display authorization.

n The most commonly used composite profiles delivered by SAP for change management are as follows:

� S_A.SYSTEM: for the system administrator with all CTS authorizations.

� S_A.CUSTOMIZ: for Customizing project team leaders (for all system setting activities).

� S_A.DEVELOP: for developers and Customizing team members who only work at the task level.

� S_A.SHOW: for R/3 Basis administration, includes display authorizations only, for example, for change request information and corresponding logs.

n You can include additional authorizations in authorization profiles.

SAP AG 1999

l Do the exercises?


Unit Actions

Change Management for Development: Exercises

No. Exercise

1 Creating a Workbench Organizer change request for development efforts within the project.

1.1 Prior to the start of any development efforts, the project team leader must create a change request for the development efforts of the project team. Team members are assigned tasks in the change request where their efforts are then recorded.

Logon to the development client as the project leader.

1.2 Create a Workbench change request of type Transportable and assign it to Project CUST_##.

1.3 How many tasks are associated with your Workbench change request?

1.4 What type of change request was created?

What is the difference between a local change request and a transportable change request?

2 Creating a development class.

2.1 To group your development efforts, create a development class. The development class should be named Z_DEVCLASS_##, where ## is the number assigned to you.

2.2 What is the standard transport layer for the development system? In addition to the standard transport layer, what other valid transport layers exist in your system?

2.3 Save the development class and record the change to the previously created Workbench change request for your project.

2.4 Use the Workbench Organizer to verify that the development class was saved to a task in your change request.

3 Creating a new ABAP program.

3.1 Begin creating the ABAP program Z_ABAP_##, where ## is your assigned number.

3.2 Register yourself as a developer for the R/3 System DEV. (The instructor will provide the needed access keys.)

3.3 Assign the following required attributes to the ABAP program Z_ABAP_## you are creating: Title = LEAD-## ABAP Type = Executable program Status = Test program Application = Basis.

3.4 Assign your new ABAP program to the development class that was created for your project – the development class Z_DEVCLASS_##.

What would happen if you assigned a development class with an invalid transport layer to your program?

3.5 Save the new ABAP program to a change request for Project CUST_##.

3.6 Using the ABAP editor, add a new line of code to your newly created program. Add the following command: Write: 'example'.

Verify that there are no syntax errors in your program. Save and activate the program. As a test, execute the program.

3.7 Review the Workbench change request created in this exercise. How many objects are assigned to the task within the change request? Which objects are assigned to the task?

4 Releasing a Workbench task and change request.

4.1 Release the task containing the new development class and ABAP program. How can you tell if the task has been released?

4.2 As project leader, release and export the change request.

4.3 How do you know that the change request was exported successfully?

5 Optional exercise: Demonstrating enqueue locks and Repository object locks

5.1 Create a new Workbench change request of type Transportable.

5.2 Modify the ABAP program you created – the program Z_ABAP_##. Change the program by entering on a new line the following command: ULINE.

Activate your report. Before saving your work, have another user try to edit your program. What happens? Why?

5.3 Save your change to the Workbench change request created.

5.4 Ask a user from another group sitting next to you to edit your ABAP program Z_ABAP_## by adding the command: WRITE: 'The end'.

Can this user edit your ABAP program? Why?

5.5 Release all tasks containing the program Z_ABAP_##.

5.6 As the project leader, release and export your change request created for this exercise. To verify that the export was successful, check the return code from the export process in the transport logs.

6 Using Organizer Tools to locate recorded changes and analyze attributes of Repository objects.

6.1 Search for change requests and tasks using the relevant activity from within the Organizer Tools (Transaction SE03). Locate all change requests and tasks containing your ABAP program Z_ABAP_##.

6.2 Using the relevant activity from within the Organizer Tools (Transaction SE03), display the attributes associated with the objects recorded in a change request for which you are the owner.

7 Modifying an SAP Repository Object.

7.1 You will be modifying the ABAP program BC325X##, where ## is the number assigned to you. Which development class does this object belong to? Which

R/3 System is the original system for this object?

Note: Create a new change request of type transportable. This change request is used for this and the next exercise (exercises 7 and 8) and will not be assigned to your project. Make a note of the change request number.

7.2 Modify the source code of BC325X##. Because this object is owned by SAP, you require a SSCR key for the object. Use the registration key provided by the instructor.

7.3 You want the program BC325X## to display the user’s name. To achieve this, in line 21 and line 30 of the source code for BC325X##, replace the field name USER with AS4USER.

The program BC325X## currently sorts change requests by the change request number. You would like to see the change requests sorted by author. Modify line 38 of the original source code, which reads:

ORDER BY STRKORR TRKORR

Modify it so that it now reads: ORDER BY STRKORR AS4USER TRKORR

For all modifications use the Replace function of the Modification Assistant.

Save your work to the new change request. What type of change request was created?

7.4 Save your changes to a new change request. What type of change request was created?

7.5 View the repair flag for program BC325X##.

7.6 Release the task containing the change ABAP program. Do not release the change request – it will be used to record changes as a result of the next exercise.

8 Modifying an ABAP Dictionary object.

8.1 As you will be adding an additional field to the pool table BC325X## (where ## is the number assigned to you by the instructor), review the structure of this table using the ABAP Dictionary.

8.2 Change the table BC325X##. This will require that you provide an SSCR key for the object.

8.3 Add the field TELNO to table BC325X##. Assign data element CHAR 20 to the field.

8.4 Save the changes to pool table BC325X## to a new task in the change request used in the previous exercise in this chapter. After recording and saving the change, activate the new table structure.

8.5 So that you can verify the correct adjustment of the pool table after the upgrade, add some data to table BC325X##.

8.6 Which TMS configuration setting ensures that modifications to SAP objects are transportable?

8.7 Release your task created during this exercise and the change request containing the changes to the BC325X## SAP-delivered objects.

9 Optional exercise: Demonstrating the benefits of Object Checks.

9.1 As a project leader, you may wish to activate the object checks. What are object checks and how are they activated?

9.2 Activate object checks for your user using the individual settings from within the Workbench Organizer.

9.3 Create a new program named Z_ABAP_CK_##. Assign this program to the development class that you created earlier - Z_DEVCLASS_##. Save this object to a new change request.

9.4 You want to include a syntax error in program Z_ABAP_CK_##. Using the ABAP Editor, enter the following bad line of code:

Write: 'example'

To create a syntax error, do not enter a period at the end of the statement. Save the program.

9.5 Release the task and change request containing the program Z_ABAP_CK_##. What happens?

10 Optional exercise: Creating a local object and later reassigning it to a development class for transport.

10.1 Create a local ABAP program called Z_LOCAL_ABAP_##, where ## is the number assigned to you. This requires that you do not assign the program to a development class but choose the button Local object.

10.2 On a new line of the ABAP Editor, enter the command: Write: 'example'.

Save your change. Check this program for syntax errors and then activate this program.

10.3 Is there a change request number associated with this program? Why or why not?

10.4 Is there a development class associated with this local object? Where can you find this information?

10.5 Is this object transportable? Why? What change is necessary to make this local object a transportable object? Make the necessary changes so that you can transport the program Z_LOCAL_ABAP_##.

10.6 Record the change of the object’s development class to a new change request. What type of change request is required for this program Z_LOCAL_ABAP_##?

11 Optional exercise: Restoring a Repository object from a previous version.

11.1 How many versions of your ABAP program Z_ABAP_## exist? Compare the first version with the last version of your program. What does the comparison indicate?

11.2 Retrieve the first saved version, restoring your program back to its former status. Why does the R/3 System ask you for a change request?

Change Management for Development: Solutions

No. Solution

1

1.1 Log on to DEV as LEAD-## in client 300. The project team leader (LEAD-##) has the authority to create change requests.

1.2 To create a change request within the project, from the R/3 initial screen choose Tools → ABAP Workbench → Overview → Workbench Organizer (or use Transaction SE09). To display the change request for your user, choose Display.

From the screen Workbench Organizer: Requests, choose Request/task → Create. The system asks you to select the type of change request to be created. Select Transportable change request and choose Copy.

Provide the new change request with a short text describing the development assignment. To assign the change request to the group’s project CUST_##, provide the technical representation of your project – DEV_P##### – in the field Project. Since LEAD-## is added to the list by default there is no need to add further actions. Choose Save.

1.3 You should have only one task assigned to the change request, the task to be used by the project member LEAD-## for development work.

Note: If you saved the change request and you want to add further users, you can do this by selecting the change request and choosing Request/task → Create. The dialog box Add user is displayed. Enter further team members and Save.

1.4 The newly created change request is of type Transportable.

Transportable change request can be distributed/transported to downstream systems. Local change requests are local the R/3 System and can not be distributed/transported to downstream systems.

2

2.1 From the R/3 initial screen, choose Tools → ABAP Workbench → Overview → Object Navigator (Transaction SE80). To create a new object, choose Workbench → Other object. Enter the name of the development class you wish to create – for this example, enter Z_DEVCLASS_##. Choose Create. The Create Development Class screen appears. Enter a short description for your development class. Select as a software component HOME and as an application component BC for “Basis”. Choose Save.

2.2 The standard transport layer is the transport layer that defines the consolidation route from the development system (DEV) to the quality assurance system (QAS). For this system the standard transport layer is ZDEV.

By default, the standard transport layer is automatically displayed on the screen that is used to create development classes. To display other valid transport layers in your system, use the possible entries arrow beside the transport layer on the same screen.

2.3 From the Create Development Class screen, choose Save. The Create

Object Directory Entry window appears. Choose Save.

The Prompt for transportable change request dialog box appears asking for a change request to which the new Repository object can be recorded. Use either F4 or Own requests to find a change request to which you can record the change. After providing a change request ID, choose Continue.

2.4 To verify that the development class was saved to a task in your change request go to the Workbench Organizer from the Object Navigator by choosing Environment → Workbench Organizer (or use Transaction SE09).

From the initial screen of the Workbench Organizer, choose Display. From the list of change requests displayed where your user is involved, click the plus sign in the folder icon on the left side of your change request number and drill down to your task number. Verify that the development class you created is listed in a task.

3

3.1 From the R/3 initial screen, choose Tools → ABAP Workbench → Development → ABAP Editor. Enter the name of the program that you wish to create – for this exercise, Z_ABAP_## -- and choose Create.

3.2 When the access key dialog box is displayed, enter the 20-digit developer’s access key that is provided by the instructor. Choose Continue.

3.3 Provide the attributes for the new program - the title, type, status and application area. Choose Save.

3.4 When the development class dialog box is displayed, enter the development class you created for your project – development class Z_DEVCLASS_##. Choose Save.

If a development class with an invalid transport layer is assigned to a Repository object, the object cannot be transported to downstream systems.

3.5 The Prompt for transportable change request dialog box appears asking for a change request to which the new Repository object can be recorded. Use either F4 or Own requests to find a change request to which you can record the change. After providing a change request ID, choose Continue.

3.6 If the ABAP Editor is not displaying your program, you can access it using Tools → ABAP Workbench → Development → ABAP Editor, providing the name of the program, and selecting Change.

Using the ABAP Editor in change mode, add the required command. When entering the command, make sure that you end it with a period to ensure that a syntax error will not result. To save the addition of the command line, choose Save. To verify that there are no syntax errors, choose Program → Check → Syntax. Activate your program by choosing Program → Activate (Ctrl F3). To execute your program, choose Program → Test.

3.7 To display the contents of this change request in the Workbench Organizer, from the R/3 initial screen choose Tools → ABAP Workbench → Overview → Workbench Organizer (or use Transaction SE09) and then choose Display. Expand your change request.

There should be two objects assigned to the task. The objects assigned to the task are the development class Z_DEVCLASS_## and the ABAP

program Z_ABAP_##.

4

4.1 To release a task, select the task and choose Release directly. If documentation for the task has not yet been provided, the documentation screen appears. Provide documentation for the task and choose Save. To exit from the documentation screen, choose Back.

Review the message bar at the bottom of the SAPGUI screen. The message bar will indicate if the task was released or if an error occurred during the release process. As another indicator, the color of the change request in the Workbench Organizer: Requests overview screen will change if the task has been successfully released.

4.2 To release a Workbench change request, from the Workbench Organizer: Requests overview screen, select the change request to be released and choose Release directly or choose from the menu Request/task → Release → Direct processing.

If there are tasks in that change request that have not been released, you cannot release the change request unless the tasks are empty. The system deletes empty tasks when a change request is released.

4.3 During the release and export process, the export log for the change request is displayed. Initially, the export log file reports that the export is currently in process. Choose Refresh until the log file reports that the export has completed. Expand the log file to verify that the export from DEV is successful. To return to the Workbench Organizer hierarchy, choose Back.

Export logs can be displayed using the Workbench Organizer at a later time. To view logs on transportable change requests that have been released, from the initial screen of the Workbench Organizer (Transaction SE09), select the options Transportable and Released and choose Display. To see the transport logs for a change request from the Workbench Organizer: Requests overview screen, select the change request ID and choose Goto → Transport logs.

5

5.1 To create a new change request using the Workbench Organizer, choose Tools → ABAP Workbench → Overview → Workbench Organizer (or use Transaction SE09) and then choose Display. Choose Request/tasks → Create. Select type Transportable change request and choose Continue. Provide a description for the change request and then choose Save.

5.2 To edit a program, from the initial R/3 menu choose Tools → ABAP Workbench → Development → ABAP Editor (or use Transaction SE38). Enter the name of the program to be changed - Z_ABAP_## - and choose Change.

The ABAP editor for the program Z_ABAP_## appears. Add the following line of code to the program: ULINE.

If a USER-B tries to change a Repository object while the Repository object is being changed by USER-A, the message “User USER-B is currently editing <object name>” will appear. USER-B is only able to display the

Repository object until USER-B completes his changes to the object. Enqueue processes that only allow a single user to edit objects and keyed data at any one time cause this locking.

Another kind of locking method with R/3, is the locking of Repository objects to a change request. When a Repository object has been changed and recorded to a change request, the object is locked by the change request until the change request has been released. Therefore, only users who have tasks in the change request are able to change the object. This locking of Repository objects is the responsibility of the Workbench Organizer.

5.3 After completing the edits on the program, choose Save. The Prompt for transportable change request dialog box appears asking for a change request to which the changed Repository object can be recorded. Use either F4 or Own requests to find a change request to which you can record the change. After providing a change request ID, choose Continue.

5.4 To edit a program, from the initial R/3 menu choose Tools → ABAP Workbench → Development → ABAP Editor (or use Transaction SE38). Enter the name of the program to be changed - Z_ABAP_## - and choose Change.

In order to be able to edit an object that is locked by a Workbench change request, the user must be assigned to a task in that change request. Because all users in this class have project leader authorization, all other users in the class have the authorization to create a task in your change request for their user ID. When another project leader tries to edit your program, the dialog box Create task appears and indicates that in order to change Z_ABAP_##, a new task has been created in your change request.

Therefore, a user from another project team is able to edit objects locked by your change request only if that user owns a task belonging to the change request in which the object is currently locked.

5.5 To release a task, from the Workbench Organizer: Requests overview screen, select the task and choose Release directly. If documentation for the task has not yet been provided, the documentation screen appears. Provide documentation for the task and choose Save. To exit from the documentation screen, choose Back.

Note that you can only release a task for which you own. One task may be own by another user and you are not able to release it. Either have the other user release his or her task. Or, change ownership of the task and then release the task. To change ownership of a task, select the task and choose Request/task → Change owner.

5.6 To release a Workbench change request, from the Workbench Organizer: Requests overview screen, select the change request to be released and choose Release directly. Review log files to verify the success of the release and export.

6

6.1 To access the Organizer Tools, from the initial R/3 menu choose Tools → ABAP Workbench → Overview → Workbench Organizer and then choose Goto → Organizer tools (or simply use Transaction SE03). A list of Organizer Tools are displayed.

To locate objects in change requests, select the activity Search for Objects in Requests/Tasks and choose Execute. The Search for Objects in Requests/Tasks screen is displayed. On the left side of the screen, mark the checkbox beside R3TR PROG and enter the name of your program to the right. To display all change requests containing this ABAP program, select the options Modifiable and Released at the bottom of the screen. To locate your object in change requests, choose Execute.

6.2 To review the objects of a particular change request, from the Organizer Tools menu (Transaction SE03), select the activity Analyze Objects in Requests/Tasks and choose Execute. Enter a change request ID and choose Enter. A list of all objects contained in the change request is displayed. To display the attributes associated with an object, double-click one of the objects.

Note that the attributes are stored in the Object Directory (table TADIR) for these objects. There are other activities from within the Organizer Tools that allow you to change the Object Directory entry for an object or a collection of objects.

7

7.1 To see the attributes associated with the program BC325X##, go to the ABAP Editor. From the R/3 initial screen choose Tools → ABAP Workbench → Development → ABAP Editor (or use Transaction SE38). Enter the name of the SAP-delivered program – BC325X##. Select Attributes and choose Display.

The development class for this object is STRS. Choose Continue to return to the ABAP Editor: Initial Screen.

To find out in which R/3 System this object originated (or is “owned”), from the ABAP Editor: Initial Screen, choose Goto → Object Directory Entry. The original system for this object is SAP.

7.2 To change the SAP-delivered object, from the ABAP Editor: Initial Screen enter the name of the program to be changed - BC325X## - and choose Change. Because you are changing an SAP-owned object, you are asked to enter the access key for this object. Enter the access key provided by the instructor and choose Continue.

Confirm the information that only urgent repairs should be done in foreign namespaces. Read the information in the next window about the usage of the Modification Assistant.

7.3 From the ABAP Editor: Modify Report BC325X## screen, you can use the Modification Assistant functionality to change the SAP-delivered program.

To change line 21, select line 21 and choose Replace. The Modification Assistant will comment the existing code for line 21 and will allow changing a copy of the original. Change the word USER to AS4USER. Because of this change, line 30 is no longer line 30 but rather line 34. Select line 34 and choose Replace. The Modification Assistant will comment the existing code for line 34 and will allow changing a copy of the original. Change the word USER to AS4USER.

Line 38, the line of code that indicates the sort order variables, is now line 46. Select line 46 and choose Replace. The Modification Assistant will comment

the existing code for line 46 and will allow changing a copy of the original. Add the word AS4USER to the order clause.

Since the original system for this program is SAP, this type of change is termed a repair so that the Modification Assistant can control the changes performed to the object.

7.4 To save the changes made to the SAP-delivered program using the Modification Assistant, choose Save. The Prompt for transportable change request dialog window appears. Select the option Create request and provide a description for the new change request to which the repair will be saved. Choose Save and then Continue. The changes to the program BC325X## have been recorded and saved to a change request of type transportable. Choose Back to return to the ABAP Editor: Initial Screen.

7.5 To view the repair flag, from the ABAP Editor: Initial Screen (Transaction SE38) enter the program name and choose Goto → Object directory entry. The most important Object directory entries are displayed. To view all attributes inclusive of the repair flag, choose Object attributes (the button most right). Note that the Repair flag for program BC325X## has been set.

7.6 To release your task, from the R/3 initial screen choose Tools → ABAP Workbench → Overview → Workbench Organizer (or use Transaction SE09) and then choose Display. The change requests and tasks assigned to your user are displayed. Select the task to which the program BC325X## has been recorded and choose Release directly. If documentation for the task has not yet been provided, the documentation screen appears. Provide documentation for the task and choose Save. To exit from the documentation screen, choose Back.

8

8.1 To display the pool table BC325X##, use the menu path Tools → ABAP Workbench → Development → ABAP Dictionary (or use Transaction SE11). Provide the name of the database table – BC325X## – and choose Display. Select the Attributes tab and you will see the development class for the Repository object. Choose Goto → Object directory entry to see that the table’s original system is SAP.

8.2 To change an ABAP Dictionary object, use the menu path Tools → ABAP Workbench → Development → ABAP Dictionary (or use Transaction SE11). Provide the name of the object to be changed, in this case the database table BC325X##, and choose Change.

Because you are changing an SAP-delivered object, you will be required to provide an SSCR key. Supply the requested object key given to you by the instructor and choose Continue. Confirm the information that only urgent repairs should be done in foreign namespaces. The Customer Modif.: Different Original and Logon Languages dialog window appears. Choose Maint. in logon lang. to continue.

8.3 From the Dictionary: Maintain Table screen, you can add a new field by choosing the tab Fields and then the button New rows . Add the TELNO with the field type as CHAR20.

8.4 To save the new field, choose Save. You are prompted for a transportable change request. Choose Own Requests and double-click on the change

request you used in the previous exercise to record the change to the SAP-delivered program. Choose Continue to save and record the new table structure to a change request. Because you have already released the task for this change request, a prompt will indicate that another task is being created for you. Choose Continue.

To activate the new table structure, from the Dictionary: Maintain Table screen, choose Activate (or choose Table → Activate). Once activated, the status Active is displayed for the pool table.

8.5 To add data to an ABAP Dictionary table, from the Dictionary: Maintain Table screen, choose Utilities → Table contents → Create entries (or use Transaction SE16 → Create Entries). Create a few entries in the table. When you are done adding entries, choose Back.

To view the contents of the table, from the Dictionary: Maintain Table screen, choose Utilities → Table contents → Display (or use Transaction SE16 → Display).

8.6 All SAP objects are assigned a development class with the transport layer SAP. In our system landscape, a valid consolidation route is assigned to the transport layer SAP. The consolidation route is from the development system, DEV, to the quality assurance system, QAS. Therefore, repairs to SAP-delivered objects are able to transported.

8.7 To release your task, from the R/3 initial screen choose Tools → ABAP Workbench → Overview → Workbench Organizer (or use Transaction SE09) and then choose Display. The change requests and tasks assigned to your user are displayed. Select the task to which the table BC325X## has been recorded and choose Release directly. If documentation for the task has not yet been provided, the documentation screen appears. Provide documentation for the task and choose Save. To exit from the documentation screen, choose Back.

To release the change request, from the Workbench Organizer: Requests screen, select the change request to be released and choose Release directly.

9

9.1 Object checks look for syntax errors in change requests when you try to release the change request. If there are syntax errors, the change request is not released. A report is displayed that lists the errors. After the errors are corrected, the user can attempt to release the change request again.

Object checks can be activated with settings set to global or individual. Global settings apply to all users and a ll of their development work, while individual settings apply to the work of specific developers.

To activate object checks globally, from the R/3 initial screen choose Tools → ABAP Workbench → Overview → Workbench Organizer and then Goto → Organizer tools (or use Transaction SE03). Select the Organizer Tool activity Global Customizing Workbench Organizer. Choose Execute.

For the settings Display transport errors at logon and Check objects on request release, select the option Can be set for specific user, then Save the configuration. This enables every user to maintain global settings individually when, from the Workbench Organizer (Transaction SE09), the menu option

Settings → Organizer is chosen.

9.2 To set individual settings, from the R/3 initial screen choose Tools → ABAP Workbench → Overview → Workbench Organizer → Settings → Change & Transport Organizer. Select the tab Change & Transport Organizer’. Select the option Check objects when request is released.

9.3 To call the ABAP Editor, from the R/3 initial screen choose Tools → ABAP Workbench → Development → ABAP/4 Editor (or use Transaction SE38). Enter the name of the program that you wish to create - Z_ABAP_CK_## - and choose Create .

Enter a Title, Type, Status and application for the new program. Choose Save. Enter the development class Z_DEVCLASS_## and choose Save.

The Prompt for transport change request dialog window appears. Select the option Create request and provide a description for the new change request to which the new program will be saved. Choose Save and then Continue.

9.4 From the ABAP Editor: Change screen, add the line of code as follows:

Write: 'example'

Choose Save to save the new line of code. To activate the object, choose Activate. Choose Activate anyway when the system states that there are syntax errors in the object.

9.5 To release your task, from the R/3 initial screen choose Tools → ABAP Workbench → Overview → Workbench Organizer (or use Transaction SE09) and then choose Display. The change requests and tasks assigned to your user are displayed. Select the task to which the table BC325X## has been recorded and choose Release directly. If documentation for the task has not yet been provided, the documentation screen appears. Provide documentation for the task and choose Save. To exit from the documentation screen, choose Back.

To release the change request, from the Workbench Organizer: Requests screen, select the change request to be released and choose Release directly. Because the object checks for this change request are not up-to-date, you are prompted run the object check. Choose Check.

The results of the object check report a syntax error in your program. The change request is not released because an error was found. You can now either:

Continue with the Release although there are syntax errors by choosing Continue

Display the errors in the error report by double clicking on Extended program check. Choose Display all changes and correct the error by marking the ABAP program and choosing Change.

After correcting the reported error, release and export the change request.

10

10.1 From the R/3 initial screen, choose Tools → ABAP Workbench → Development → ABAP Editor. Enter the name of the program that you wish to create – for this exercise, Z_LOCAL_ABAP_## – and choose Create.

Provide required information for this program – a Title and the attributes Type, Status and Application. Choose Save.

Rather than recording the object to a development class, when the Create Object Directory Entry screen appears, choose Local object.

10.2 From the ABAP Editor: Change screen, add the line of code as follows:

Write: 'example'.

Be sure to end the line of code with a period to ensure that a syntax error does not result. Choose Save to save the new line of code. To verify that there are no syntax errors, check your program by choosing Program → Check → Syntax. To activate the object, choose Activate.

10.3 There is no change request associated with this program. Local objects are not linked to the Workbench Organizer.

10.4 Yes. All Repository objects have an assigned development class. The development class for Z_ABAP_LOCAL_## is $TMP. All local objects are assigned to the development class $TMP.

To display the attributes of program Z_ABAP_LOCAL_##, use the menu path Tools → ABAP Workbench → Development → ABAP Editor (or use Transaction SE38). Provide the name of the program, select Attributes and choose Display. The development class for the Repository object is $TMP.

10.5 No, the object is not transportable. The development class is $TMP does not have a valid transport layer and is also not linked to the Workbench Organizer for transport.

In order to transport the object, it must be reassigned to a development class that contains a valid transport layer.

To change the development class of an ABAP program, from the ABAP Editor: Initial Screen (Transaction SE38), enter the name of the program to be changed – in this case, Z_ABAP_LOCAL_## – and choose Goto → Object directory entry. From the dialog box Display Object Directory Entry, choose Display/change. Change the development class for this object from $TMP to Z_DEVCLASS_##. Choose Save.

10.6 After saving the change to the object’s development class, the Prompt for transportable change request dialog window appears. Select the option Create request and provide a description for the new change request to which the new program will be saved. Choose Save and then Continue. The change requires a transport change request because the new development class for the object has a valid transport layer that is assigned to a consolidation route for this R/3 System.

11

11.1 To view the different versions associated with an object, you must go to the maintenance tool for that object. Therefore, to see the versions associated to a particular ABAP program, go to the ABAP Editor using Tools → ABAP Workbench → Development → ABAP Editor. Enter your program name. To view all saved versions of the program, choose Utilities → Versions → Version management. To compare two versions, select the two versions that you wish to compare, then choose Compare.

There should be two versions of your program. One was created when your first change request was released, and the second one was created when a second change request was released.

Comparing these two versions shows that the two command lines ULINE. and Write: ‘The end’. were added to the program.

Choose Back to return to the initial Version Management screen.

11.2 From the Version Management initial screen, you can retrieve a saved version by mark the version in the list and choosing Retrieve. A dialog box warns you that you are about to overwrite the current version of the object with an older version. Choose Continue. This will require that you record your change to a change request of type transportable

The active version of the program is still the last version of the ABAP program. The retrieved version is not yet active. Using the ABAP Editor, activate the restored version of the program..

SAP AG 1999








Transport Management

SAP AG 1999

Transport Management

Contentsl Transport management strategy

l Transport processl Transporting with TMS

ObjectivesAt the end of this unit, you will be able to:l Describe the transport process

l Perform imports using TMSl Define transport management strategies

SAP AG 1999

Overview: TMS Transport Strategy

Transport domain

Transport group

1. Release and export

2. Import

3. Import

Consolidation

route

Delivery

route

Transport Directory

n Before R/3 Release 3.1H, transports were performed at the operating system level. With the introduction of the Transport Management System (TMS), transports are performed from within the R/3 System.

n In the TMS:

� Change requests are transported along predefined transport routes. You can define multiple consolidation and delivery routes. (See also the unit Prerequisites of the Change and Transport System.)

� Most imports are performed with Transaction STMS. The previously technical import procedure on operating system level can now be performed by any authorized users from within R/3.

� Change requests to be imported are displayed in the import queue of the target system in R/3.

� Using TMS you can import a complete import queue, that is, all change requests that were exported from the development system. This ensures that no import errors occur due to missing objects and that newer versions of an object do not get overwritten by older versions.

SAP AG 1999

Transport Process: Release and Export


Transport directory

DEV

QAS

PRD

Buffers:

CR1

Data-/CofileCR1CR1

Export transport files

Fill QAS buffer

Releasechangerequest

n The first step in the transport process is to release a change request and thereby export all the associated objects from the database of the development system (DEV) to files in the common transport directory at the operating system level. For each request released, the data is exported to a data file in the subdirectory data , and a control file is written to the subdirectory cofiles.

n During export, the entries required for the subsequent import are created in the import buffer and the import queue of the target system, and a test import is performed (by default).

n In the directory buffer at the operating system level, there is an import buffer file for each R/3 System in the transport group. The file is named after the corresponding system ID and contains control information regarding which transport requests are to be imported and the order of import.

n Several transport control commands can be used to manage import buffer files at the operating system level. In releases with TMS functionality, the control information in the import buffer files is read and represented in import queues accessed from R/3. An import queue shows all change requests that are listed in the the corresponding buffer.

SAP AG 1999

Transport Process: Import into Quality Assurance


DEV

QAS

PRD

Buffers:

CR1

Data FileCR1CR1

Import change request

CR1

(CR1)

Fill PRDbuffer

(inactive)

Data-/CofileCR1

n Using TMS from within R/3, the second step in the transport process is: importing all requests listed in the import queue of the quality assurance system (QAS). TMS performs the import by starting the transport control program tp at the operating system level.

n After the successful import into the quality assurance system, the requests are placed inactively in the import buffer and import queue of the production system (PRD) and any other delivery system.

SAP AG 1999

Transport Process: Quality Assurance


DEV

QAS

PRD

Buffers:

CR1

CR2

Import correction

CR1

(CR1), (CR2)

CR2 CR2

Create andrelease

correction(if needed)

Data/CofileCR1

Data-/CofileCR2

n After import to QAS, the objects need to be tested for possible errors. Errors should be corrected in DEV, and the changes again imported into QAS. During import into QAS, additional transport requests are added to the buffer of PRD.

SAP AG 1999

Transport Process: Import into Production


DEV

QAS

PRD

Buffers:

CR1 CR1

CR1, CR2

Activate entries Import both requests

CR1CR2 CR2

O.K.

CR2

Data/CofileCR1

Data-/CofileCR2

n After all the change requests that were imported into QAS have been thoroughly tested and verified, the change requests must be approved. The status of the entries then changes from inactive to active and the change requests are ready for import into the production system (PRD).

n Using TMS, you can import all change requests (or simply a first set of verified change requests) listed in the production system import queue in the given (not manipulated) sequence.

n To ensure that there is no negative effect on production activities in PRD, ensure that errors and their corrections are imported in the correct order.

SAP AG 1999

Import Queue Status

Transport domain

Transport group

DEV: 0

QAS: 7

PRD: 3

View queue

Start imports

n The most important tools for performing imports using TMS are the import queues that reflect the system-specific import buffers at the operating system level. The import queues display the requests that are to be imported, in the order of their release. The import queues of all systems are displayed in each system in the transport domain. You can perform imports to all systems from any R/3 System in the domain.

n To access the TMS import overview, use Transaction STMS and choose Overview → Imports. The import overview shows the current status of the import queue of each R/3 System in the transport domain.

n To improve performance, data is only read from the transport directory the first time you call TMS. After that, the information shown is buffered in the database. The time stamp in the import overview indicates how recent the data is. The internal buffers of TMS become invalid each day at midnight. However, to refresh the data, choose Edit → Refresh. It may be more convenient to have the refresh performed periodically in the background. To do this, choose Extras → Update all Import Queues. SAP recommends running this refresh hourly using RSTMSCOL.

SAP AG 1999

Import Queues and Import Buffers

DEVK900016DEVK900018DEVK900020DEVK900023StopmarkDEVK900002DEVK900033DEVK900035

Import buffer

Operating System

R/3 System

1 DEVK9000162 DEVK9000183 DEVK9000204 DEVK900023End of import queue5 DEVK9000026 DEVK9000337 DEVK900035

Import queue

End mark

Stopmark

Transport Directory

n The terms import buffer and import queues are related. The import queue is the representation in R/3 of the import buffer located on operating system level. The import queue highlights the requests that will be imported during the next start import (import all). Because of end marks, there may be more requests in the import buffer than are highlighted in the import queue.

n The end mark and stopmark are the corresponding markers in the import queues and buffers respectively, which indicate that only the requests before the mark will be imported. Regardless of how the end mark/stopmark is created, the mark is set in both the import buffer and the import queue. An end mark is indicated in an import queue through the statement "End of import queue". In an import buffer, the term "stopmark" is visible. There can only be one end mark or stopmark in each import queue or import buffer.

n To set an end mark/stopmark by closing an import queue, in the Import Queue screen choose Queue → Close. This is analogous to the operating system command "tp setstopmark <SID>". The status bar shows the action performed.

n To remove an end mark/stopmark by opening an import queue manually (normally not needed), in the Import Queue screen choose Queue → Open. Opening an import queue is analogous to the operating system command "tp delstopmark <SID>".

n From operating system level, a stopmark can only be placed at the end of the buffer. Using TMS, however, you can move end marks to any position in the import queue.

SAP AG 1999

Import Queue

Use the import queue to:l View the status of requests and access:

n Object listsn Documentationn Transport logs

l Close and open the queue, move the end mark.l Import:

n All requestsn Complete Projectsn Preliminary requestsn Requests according to filter settings

l Add, delete and forward requests.

DEV: 0

QAS: 7

PRD: 3

n To display the import queue of an R/3 System, select the queue in the Import Overview screen and choose Import Queue → Display. The import queue is displayed, showing the order in which the requests were exported, and the name, owner, and short text of the change request. The change request status is are shown by color. You can navigate to a request's object list, documentation, or log.

n To keep target R/3 Systems consistent, deadlines are required to coordinate the release of change requests by developers. To prevent change requests released after the deadline from being imported, the import queue can be closed. These change requests are positioned after an end mark in the queue for the next import. Only the requests before the end mark are imported in the next import.

n In exceptional cases, a change request may need to be forwarded to another R/3 System before being imported into the defined target system. For example, before being imported into the quality assurance system, a request may need to be rushed to a training system. To import to a target system outside the predefined transport routes, in the Import Queue screen choose Request → Forward → System.

n Change requests can also be deleted from or added to an import queue. Note, however, that object dependencies may cause inconsistencies in the target system after the next import. For example, if you delete a request containing a new da ta element, all other requests containing tables that depend on that data element will fail. To avoid these inconsistencies, you are strongly advised not to delete individual change requests. Make your corrections in the development system and release a new change request.

SAP AG 1999

Start Import

Request Project1 DEVK900016 DEV_P000012 DEVK9000183 DEVK9000204 DEVK9000235 DEVK9000026 DEVK900033 DEV_P000017 DEVK900035

Import allrequests

Date/deadline Execution Options

n To import all requests in the queue (thereby performing what is known as an import all), choose Queue → Start import. The dialog box Start Import appears. Enter the target client and choose Continue. If you start the import from another R/3 System in the transport domain, a logon window from the target system is displayed. After you have logged on, TMS starts the transport control program tp in the target system.

n In the dialog box Start Import, in the tab Execution you can select whether TMS starts tp synchronously or asynchronously. Selecting asynchronously means tp works in the background so that your user session is not blocked for the duration of the import. The Import Overview screen indicates whether the import is running. After the import, the end mark is removed and the queue is opened again automatically. After change requests have been imported successfully, they are automatically added to the import queue of further target systems. When using the QA Approval Procedure functionality, all requests in the import queue are set to inactive. The configured transport route specifies which change requests are automatically forwarded to which target systems. If an import containing one or more inactive requests is started, the TMS will not perform the import.

n If you perform an import through an import all, objects are imported in the correct sequence. This means that if change requests near the start of the list and those near the end of the list affect the same objects, the final versions of the objects after import will represent the latest changes. Thus, the incorrect objects do not affect your productive environment.

n The ability to perform a complete import (import all)can be deactivated for each System with the TMS parameter NO_IMPORT_ALL.

SAP AG 1999

Start Imports of Complete Projects


Import allrequests Request Project

1 DEVK900016 DEV_P000016 DEVK900033 DEV_P00001

n Before performing the import, SAP recommends setting the end mark to close the import queue. This avoids unintentionally importing other change requests that may appear in the import queue.

n You can set a filter on the import queue to limit the displayed change requests to change requests with specific properties, for example, so that you can see only those change requests that belong to a specific project. To set a filter, place the cursor in a row of the import queue and choose Edit → Filters.

n To prevent change requests being imported from unapproved projects, use the filter to import only the change requests belonging to approved projects.

n You can only import if you filter according to projects or clients. Filtering with other criteria will not allow you to perform an import.

SAP AG 1999

Preliminary Import


Importrequest

MarkRequests

Request Project1 DEVK900016 DEV_P000012 DEVK900018 3 DEVK9000204 DEVK9000235 DEVK900002 6 DEVK900033 DEV_P000017 DEVK900035

5 DEVK900002

2 DEVK900018

n In contrast to standard imports preliminary imports are imports of single requests. SAP strongly recommends only using standard imports because of object dependencies and the risk of inconsistencies when importing individual requests. For example, an ABAP report in one request may be able to be imported successfully, but the table that it refers to may be in another request that has not yet been imported. Until the table is imported, execution of the report will generate short dumps. Use preliminary imports only in exceptional cases.

n To minimize the risks associated with preliminary imports, the request remains in the import queue after the import and is re-imported the next time the entire import queue is imported. This guarantees that export and import sequences are always the same. This is defined by the Option Leave Transport request in queue for later import, which is initially marked.

n By default, the TMS checks if requests in the import queue are dependent on change requests in other projects. The import only occurs if the predecessor's relationships will not be damaged. To change this default setting, from the import queue choose, for example, Request → Import and select Continue import. In particular circumstances, it may be necessary to specify additional options when performing a preliminary import:

� Ignore that the transport request has already been imported

� Overwrite originals

� Overwrite objects in unconfirmed repairs

� Ignore invalid transport type

SAP AG 1999

Time and Date of Import

Import

Immediate At start time(periodically)

After event(periodically)

n Depending on whether you have chosen to import by project, individual import, import all, or special transport workflow, the available options vary. When starting an import, you can select the following options in tab Date:

� Immediate: Selecting this option starts the import immediately in a dialog work process.

� At start time: Selecting this option starts the import at a time you enter. The import is scheduled as a background job in the target system. If you also enter a date and time in the field No start after, the import is started in the time frame between the times entered in Planned start and No start after. If there is no background process available during this time, an import will not occur. If you want the import to be performed regularly, you must enter a time in the field Period (use the F4 help for the field). Note that the field Period does not appear on the import screen for individual transports and the special transport workflow.

� After event: Selecting this option starts the import only after a specified event is triggered. If you select Execute import periodically, the import is started each time the specified event is triggered. Otherwise, the import is started only the first time the event occurs. Note that the option Execute import periodically does not exist for individual transports and the special transport workflow.

n From the Import Queue of each SAP System all planned imports can be monitored and maintained by choosing Goto → Job Monitor.

SAP AG 1999

QA Approval

Request Project1 DEVK900016 DEV_P000012 DEVK900033 DEV_P00001

QA Worklist

..16 ..33

Production

Quality Assurance

..16

Import no longerpossible

(usage notrecommended)

Import possible

QAS

n To display the QA worklist, use Transaction STMS and choose Overview → Imports → Goto → QA worklist. The date/time at the top right-hand side of the screen indicates when the QA worklist was last updated; the top left-hand side indicates how many requests still need to be processed. The list displays the change requests corresponding to the selected approval steps. By default, the change requests corresponding to all approval steps are shown. To select the approval step whose corresponding change requests you wish to see, choose Worklist → Select approval step. By double-clicking various items in the table listing the change requests, you obtain further information on those items.

n The requests in a QA worklist have to be tested before they are imported into the delivery systems. The QA status Rejected means that one or more approval steps of a request were rejected by the person responsible. A request is only approved if all the approval steps have the status Approved.

n Requests can only be imported into the delivery systems if all the requests ready for import have received approval according to the various approval steps. If all the requests for one project have been approved, they can be imported into the delivery system even if other projects still have unprocessed or rejected requests in the worklist. Requests with the QA status Rejected as well as unprocessed requests in the worklist are not imported into the delivery systems.

n SAP recommends not rejecting requests containing errors, but instead correcting the error using subsequent transports and approving the affected requests as an entire package.

SAP AG 1999

QA History

Date Time Request Project Status18.08 12:05 DEVK900016 DEV_P0000118.08 12:08 DEVK90001818.08 13:05 DEVK90002019.08 10:23 DEVK90002319.08 10:44 DEVK90000220.08 23:59 DEVK900033 DEV_P0000120.08 23:59 DEVK900035

QA History List

Who approvedquality assurance

testing for thischange request?

Approval stepmade by user ...........

n From the QA worklist screen, you can access the QA history by choosing Goto → QA history.

n The QA history shows all the requests for a specific period that are no longer displayed in the QA worklist. Requests are no longer displayed in the QA worklist when they have been approved or deleted. The default period for the QA history is the past 30 days. However, this time period can be changed.

n To find out who was responsible for approving a change request, choose Request → Display → QA status.

SAP AG 1999

Special Transport Workflow


Transport Directory

DEV

QAS

PRD

Buffers:

CR1

Data-/CofileCR1CR1

Important!O.K.

n Use the special transport workflow if transport corrections are needed urgently, or if transports are required that do not follow the defined transport routes.

n A prerequisite for using the special transport workflow is configuring an SAP System as the Workflow Engine. This system must have the following criteria, which are listed in order of importance:


� Low to medium system load

n These prerequisites are usually met by the quality assurance system. All the tasks performed in the special transport workflow are processed centrally on the Workflow Engine and the results communicated to the affected SAP Systems.

SAP AG 1999

Configuring the Special Transport Workflow

RFC

WorkflowEngine

Management Workflow Engine QA Approval Procedure

RFC Address

System QAS

Client 300 Quality Assurance

Target host twdfmx04

System no. 00

User TMSADM_WF

n To configure the special transport workflow:

� Log on to the SAP System functioning as the transport domain controller.

� Call Transaction STMS and then choose Overview → Systems → Goto → Transport domain .

� Choose the tab Workflow Engine.

� Switch to change mode by choosing Configuration → Display<->Change.

� Enter the SAP System, the client, and the target host for your Workflow Engine. Choose Save. Respond affirmatively to the dialog box to distribute the configuration change. In the next screen, log on to the system that is to be configured as the Workflow Engine. The system automatically:

Creates the user TMSADM_WF.

Generates the RFC destinations required for the Workflow Engine.

Sends the address data of the Workflow Engine to all systems in the transport domain.

Performs the Workflow-related Customizing on the Workflow Engine.

SAP AG 1999

Creating Transport Proposals

Change request (team leader)

Task A (team leader)

Task B (team member 1)

Object 1Object 3

Object 2Object 1

. ..

Create transportproposal

Workbench/CustomizingOrganizer

Information ontransport proposals

Transport Propo...

Inbox

Outbox

n To use the special transport workflow you must create a transport proposal. To do this, go to the Change and Transport Organizer (Transaction SE09 or SE10) and select released requests. Choose Display. Position the cursor on a request that you want to transport and choose Utilities → Create transport proposal. The dialog box Create transport proposal appears. Enter a short text, the target system, and possibly other change requests. The target systems apply to all requests that you enter.

n Note that any requests that you place in the transport proposal must have been previously released.

n If a transport proposal is created, the SAP System gives this transport proposal a proposal number, and then places it in the specific TMS worklist for the transport administrator (see below).

n If the transport administrator rejects your transport proposal, it reappears in your transport proposal inbox. You can cancel the transport proposal, or revise it and send it back to the transport administrator.

n After the transport administrator has approved your transport proposal, the import is started and the transport proposal reappears in your transport proposal inbox. Check that the transport requests are being imported correctly into the target systems, and confirm the transport proposal.

SAP AG 1999

Transport Proposal Worklist

TMS worklistTitle Status AgentVery important transport!!!!!! BONDJ

Import into target system

n To approve or reject a transport proposal, call Transaction STMS. To display the TMS worklist, choose Overview → Worklist. Double-click the transport proposal you want to process. Check if the requests, the list of target systems, and the import times and import options for the transport proposal are correct. You can display the requests by choosing Display and the icon for the transport logs. Switch to change mode if you want to make changes to the requests, transport targets, import times, or import options.

n You can create a message for a developer by choosing the icon Manage Attachments.

n To process the transport proposal, choose the respective icon to approve or reject the transport proposal.

n If you approved the transport proposal, the import into the specified systems is automatically started. The transport proposal is placed in the developer's transport proposal inbox and the developer confirms it.

n If the transport proposal was rejected, it is placed in the developer's transport proposal inbox for modification.

SAP AG 1999

Transports Between Transport Groups

Transport domain

Transport group B

Transport Directory

Transport group A

Transport

Route

Transport Directory

Data FileCofile


n Usually all the R/3 Systems in a transport domain share the same common transport directory. There are situations, however, in which separate "common transport directories" are set up for different parts of the same domain. Multiple common transport directories are used, for example, when:

� An R/3 System is connected to the domain through a slow or expensive network connection

� Strict security measures prevent allowing direct file system access from other systems

� Dissimilar hardware platforms prevent the use of a common transport directory

n Within a transport domain, R/3 Systems that share a common transport directory form a transport group. The Transport Management System supports transports between transport groups. After a change request has been released, in the common transport directory the request is marked for import into the target system. If the source and target systems are in different transport groups, however, the import queue of the target system must be adjusted from the Import Queue screen in the target system group choosing Extras → Other requests → In other groups. TMS searches for requests for the selected R/3 System in the import buffers (on operating system level) of all transport groups in the transport domain, and transfers the data files and cofiles belonging to the requests. Before the transfer of the data file, the change request is marked in the import queue with a "lightning" icon that disappears after adjusting the import queue of the target system.

n Note the following limitations in regard to transporting between different transport groups:

� The transport logs displayed are specific to the transport group of the R/3 System you are using.

� Transports displayed in the Change and Transport Organizers are also specific to the transport group of the R/3 System you are using.

SAP AG 1999

Checking for Critical Objects

Object listR3TR PROG ZABAPR3TR TABU ZTABLE...............






Object listR3TR PROG ZABAPR3TR TABU ZTABLE...............DEV: 0

QAS: 7

PRD: 3

Request1 DEVK9000162 DEVK9000183 DEVK9000204 DEVK9000235 DEVK9000026 DEVK9000337 DEVK900035


Table of critical objects

Compare for critical objects

R3TR TABU ZTABLE

n To check if the change requests in an import queue contain critical objects that should not be imported into the target system, go to the Import Overview and choose Queue → Check → Critical objects. The object lists of the requests are checked to see if they contain critical transport objects. The results are displayed in a hierarchical list. Requests containing critical objects are marked with the appropriate icon. The critical objects are highlighted in color.

n Before performing this check, you must have maintained the critical transport objects in the SAP System whose import queue you want to check for critical objects.

n To display or maintain the critical transport objects defined for the relevant SAP System, call transaction STMS in the SAP System for which you want to display/maintain the critical objects. Choose Overview → Imports → Extras → Critical transport objects.

n Since the table of critical objects is a Customizing table, it should be maintained in the development system, and then transported to other SAP Systems from there.

SAP AG 1999

Monitoring Tools

l Import monitor

l tp system log

l Import queue consistency check

l Transport control program check

l Transport directory check

l RFC connection test

n TMS provides various tools with which you can monitor transport activity in your transport domain:

n From the Import Overview screen, (Transaction STMS, Overview → Imports):

� To display tp status information from table TPSTAT, choose Goto → Import Monitor

� To display the file ALOG containing the return codes of all individual transport steps for the current transport group, choose Goto → Import History

� To display all tp calls and errors for the current R/3 System in the file SLOG, choose Goto → TP system log

� To check if the data files and cofiles of change requests in an import queue exist in buffers of the transport directory and can be read, choose Import queue → Check → Consistency.

n Perform the following tasks from the Systems Overview screen (Transaction STMS, Overview → Systems):

� To check the transport control program tp for all or just one specific system within the domain, choose R/3 System → Check → Transport tool

� To verify the availability of the transport directories of all systems within the domain, choose R/3 System → Check → Transport directory

� To check RFC connections in both directions, choose R/3 System → Check → Connection test

n See also the unit Prerequisites of the Change and Transport System.

SAP AG 1999

Code Freeze and Testing

Moredevelopmentfor project A

Moredevelopmentfor project A

Transport log check

Transport log check

Testing and

verification

Testing and

verificationSign-offSign-off

Developmentfor project A

Developmentfor project A

STOPError fixing

Developmentsystem

Qualityassurancesystem

DEVK900465

DEVK900478

DEVK900450DEVK900454DEVK900467

DEVK900486DEVK900434DEVK900446DEVK900433DEVK900420DEVK900487DEVK900451

DEVK900447

Import all requests into production using TMS

PRD import queue

Production system

n To ensure a stable test and development environment, use a developer deadline to "freeze" work on objects in the development system until the completion of quality assurance verification.

n Thus, the procedure to be followed during object development and testing is:

1. Release the change request containing the developed objects

2. Freeze development of the objects in the development system

3. Import the objects and verify the changes in the quality assurance environment

4. Sign-off the changes

5. If necessary, allow further development on the objects in the development system

n When errors are discovered during quality assurance testing, the objects concerned are sent back to the development system for correction. However, if additional development has been performed on this or related objects, the problem is more difficult to correct.

n If an object has gone through the error fixing cycle, it is included in at least two different requests within the import queue of the production system. If you import the complete import queue (import all) into the production system after sign-off, the pre-corrected object has no effect in your production environment.

SAP AG 1999

Timing Transports

Quality assurancesystem

Production systemDevelopment system

CUST

TEST

QTST

TRNG

PROD

The timing of transports is determined by:l Role of clientl Synchronization needsl Testing and verificationl Code freezing requirements

Transport points Transport points

n After export, a request is not automatically imported, but must be manually imported. When planning importing, include enough time to accommodate post-import tasks such as the quality assurance testing. SAP recommends planning imports in regular intervals (monthly, weekly, or daily) using import all into the target system. More frequent importing is not recommended.

n Transports include:

� Releases of change requests

� Imports into a client in the same system using Transaction SCC1

� Imports into clients in downstream systems

n The timing of transports is based on

� The clients and the roles they play in your system landscape

� Synchronization requirements (when changes are required in different systems, prior backups)

� When and how verification and testing of transports will take place

� Code freezing requirements

SAP AG 1999

Defining Change and Transport Management

Tip: transport

testable units!

l Define steps for distributing changes to all clientsand systems within the system landscape

l Identify all transport points

l Establish code freeze techniques

l Define verification procedures for allimports

l Establish a transport schedule

n Change management includes creating, releasing, distributing, and verifying change requests for all R/3 Systems in the system landscape. Ensure that your distribution procedures are supported by the TMS setup. Determine release, import, and verification requirements for all transport points in your system landscape. For each transport point, define:

� When will transports take place?

� Who is responsible for a change request during its various transport phases?

� How will transports be verified before being distributed or redistributed?

� What if a transport is successful, but testing proves that the contents are incorrect?

� Are sign-offs required for transporting?

n Assign persons to be responsible for all transport steps. Use authorizations to restrict access to change request management tasks and to the operating system level.

n SAP provides techniques for the distribution and the management of changes using import buffers. These buffers indicate the changes to be transported to the target system and the transport order. You must establish and control the buffers, and the distribution or redistribution process. To verify all imports: review transport logs, establish testing standards and quality assurance procedures, and define sign-off procedures.

n SAP recommends transporting a whole change project when all objects are in an acceptable state, rather than each single object as soon it is ready.

SAP AG 1999


l Describe the import process

l Perform imports using TMS

l Monitor the import process using TMS

l Define transport managementstrategies


SAP AG 1999

Unit Actions

l Do the Exercises?


Transport Management: Exercises

No. Exercise

1 To perform transport functionality from within R/3, you will be required to have TMS administration rights.

1.1 What authorizations are required to realize the role of a TMS administrator within R/3?

1.2 Your project leader account has TMS administrative rights. To perform TMS tasks, log on to the development system as the project leader.

1.3 In addition to performing TMS tasks on the development system, importing change requests requires TMS administration rights on any R/3 System into which you will be importing. Log on to the quality assurance test client in the quality assurance system as project leader with the default password. Provide a new password and log off.

2 Review the import buffers for all R/3 Systems within the system landscape.

2.1 Are there any requests waiting to be imported?

2.2 Are there any requests waiting to be imported into the production system?

2.3 Review the current status of the import queues of all R/3 System. Is the import queue of QAS open or closed?

3 Reviewing the import queue of the quality assurance system.

3.1 Display the requests that are to be imported into the quality assurance system. Which R/3 users released the requests?

3.2 Display the objects to be imported with a change request that was released with your project leader account.

4 Importing all change requests belonging to your project into the quality assurance system.

4.1 Set a filter so that the import queue displays only the change requests belonging to your project. Import all change requests into the quality assurance system by performing a project import. Import the request into the quality assurance test client. NOTE: DO NOT PERFORM AN IMPORT FOR YOUR CHANGE REQUESTS THAT CONTAIN REPAIRS TO SAP-DELIVERED OBJECTS!

4.2 Display more information about the change requests still waiting in the import queue for QAS.

5 Monitoring the success of imports.

5.1 Use the Customizing Organizer to monitor all transported requests for your project leader.

5.2 Using the import monitor, monitor the success of all the most recent imports into the quality assurance system.

5.3 To get further details about all transport steps for imports into QAS, view the system log file SLOG. To get details pertaining to system log file activities and return codes, view the more detailed import steps found in the file ALOG.

6 Performing quality assurance testing, even when imports into the quality assurance system are successful.

6.1 TRANS Inc. has learned through experience that after the successful import of change requests, the functionality of the system must be extensively tested. How is this performed?

6.2 Verify that the Customizing entries you transported as project leader exist in the quality assurance test client.

6.3 Verify that the development objects you transported as project leader exist in the quality assurance system.

7 Performing the QA procedure that permits the import of your change requests into the production system.

7.1 After changes are imported into the quality assurance system, the requests are placed into the import queue of the production system. Display the status of your change requests in the import queue of the production system. Is it OK to import these change requests into the production system?

7.2 After all objects belonging to the transports of your project are tested, perform QA approval from within the QA Worklist of the quality assurance system. Approve all change requests of your project.

7.3 Display the import queue of the production system. What is the status of the change requests for your project?

8 Releasing the project containing the Customizing and development efforts.

8.1 After all change requests for your project efforts have been released, release the complete Project CUST_## from within the project management.

8.2 Does the CTS functionality apply only to Project CUST_## in the current client?

8.3 When is it possible to complete a CTS project? What would be the best time to complete a project in a three-system landscape?

8.4 Optional step: How can you transport only a project’s definition and documentation?

9 Optional exercise: Creating and working with transport proposals for an important change request. Prerequisites: Special Transport Workflow has been configured by your instructor.

9.1 Use the Workbench Organizer to create a transport proposal for the change request that you created for the repair of the SAP-delivered objects. The target system for the transport proposal should be the production system PRD (you have decided not to perform quality assurance in the QAS System).

9.2 Check your transport proposal in your inbox.

9.3 To check all transport proposals, call the worklist from the initial TMS screen. Assuming now that you are the administrator checking your own work, mark your transport proposal and reject it.

9.4 Monitor the status of your transport proposal from the transport proposal inbox of the Workbench Organizer. Find the rejected transport proposal, and, now acting as the original developer, accept the rejection of the transport proposal.

Transport Management: Solutions

No. Solution

1

1.1 TMS requires the R/3 authorization S_CTS_ADMIN. The profile S_A.SYSTEM can be used to provide a user with required transport administration tasks including S_CTS_ADMIN.

1.2 Log on to DEV in client 300 as LEAD-##.

1.3 Log on to QAS in client 300 as LEAD-##. The default password is INIT. Provide a new password and log off.

2

2.1 To access the initial TMS screen, from the initial R/3 menu choose Tools → Administration → Transport → Transport Management System (or use Transaction STMS). To see the import overview of all R/3 System in the transport domain, from the TMS menu, choose Overview → Imports (or choose Import Overview). From the Import Overview screen, the Requests column displays how many requests are ready to be imported into a specific R/3 System. At this point in time, there are requests ready to be imported into the quality assurance system QAS.

Note: The number of requests ready to be imported for a particular R/3 System may differ from the actual number of requests in the import queue. This number can be different for example, if there are non-standard change requests in the queue or if there are additional requests after an end mark.

2.2 The only requests waiting to be imported into the production system PRD are those requests that have successfully been imported into the quality assurance system QAS.

2.3 From the Import Overview screen, the Status column displays the current state of each system’s import queue. To see the meaning of the icons associated with the R/3 Systems, display the legend/key using Extras → Legend.

3

3.1 Use Transaction STMS to access the initial TMS menu. From the TMS menu, choose Overview → Imports to see the Import Overview of all R/3 System in the transport domain. Double-click the quality assurance system QAS and the Import Queue: System QAS screen appears. All requests that are waiting to be imported into QAS are listed. The Owner column gives information on which user released the specific request.

3.2 To display the object list for a request owned by LEAD-##, from the screen Import Queue: System QAS, either double-click on the request number or position the cursor on the request and choose Request → Display → Object list. The object list can be expanded to see all objects transported in the change request. To return to the screen Import Queues: System QAS, choose Back.

4

4.1 Use Transaction STMS to access the initial TMS menu. From the TMS menu, choose Overview → Imports to see the Import Overview of all R/3 System in the transport domain. Double-click on the R/3 System QAS. All requests that are waiting to be imported into QAS are listed.

Mark the Project column and choose Edit → Filters. Using F4, find your project and choose Copy. Only the change requests belonging to your project are displayed in the import queue. To perform an import for all the change requests associated with your project, choose now Queue → Start Import. In the dialog box Start Import enter client 300 as target client and choose Continue. Verify the start of the import by choosing Yes.

Because you are importing into another R/3 System, you are required to provide authorization for the target system. Log on to the quality assurance client 300 on QAS as LEAD-## as required to enable the import to take place.

4.2 To see more technical information for the requests in the queue of QAS, first delete the filters, then from the screen Import Queues: System QAS, choose Edit → Display more. This displays more columns, including T and UMO. The column T displays the type of change request - either ”W” for Customizing or ”K” for a transportable request. The column UMO indicates what unconditional modes are associated with the requests. Any change request that was a preliminary import will have the unconditional mode ”I”. This indicates the request can be reimported into the target system without producing an error.

5

5.1 Log files for a particular change request can be viewed from within the Import Queues: System QAS screen by double-clicking a change request and choosing Goto → Transport logs.

To review export and import log files for all change request for which you are owner, go to either the Customizing Organizer (Transaction SE10) or the Workbench Organizer (Transaction SE09). On the right hand side of the screen is the Global Information displaying generic data on the number of transports and the success of those transports. To review log files associate with these requests, choose Transports. A hierarchical list of R/3 Systems appears. Locate the import log files for QAS. Drill down on each R/3 System and change request to see the detailed import logs and returns codes.

5.2 To monitor the most recent import activity for an R/3 System, access the Import Monitor. From the TMS menu (Transaction STMS), choose Overview → Imports to see the Import Overview of all R/3 System in the transport domain. To view the Import Monitor for QAS, mark the queue for QAS and choose Goto → Import monitor. The return code of the last import activity (or current import activity if an import is running) for QAS is displayed.

5.3 From the Import Overview screen, select the import queue for QAS and choose Goto → tp system log. Scroll to the bottom of the log file and view which steps have been performed. Note that this log file (SLOG) is sys tem-specific for QAS.

To view more details on the import steps, from the tp System Log screen, choose Goto → Transport steps. The ALOG file contains the return codes of all individual transport steps for the entire transport group. You can use the

ALOG log file to see the return codes of all single steps that have been performed during the import.

6

6.1 Quality assurance testing requires that the desired functionality of R/3 result from testing of sample business data. Quality assurance testing also needs to ensure that completed functionality is maintained even after the import of new changes and additional functionality.

To perform quality assurance testing, there should be a dedicated quality assurance team with a well-defined set of test data. Using test scripts that may or not be automated with a tool such as CATT, business functionality must be tested. The results must be compared with desired results. All inconsistencies must be noted and forwarded back to the Customizers and developers to correct on the development system.

6.2 Log on to QAS in the quality assurance client 300 as LEAD-##.

To verify Customizing, use the SAP Reference IMG to see that some of your Customizing objects such as the Distribution Channel and Sales Organization exist in the quality assurance test client 300 on QAS. To access the SAP Reference IMG, from the initial R/3 menu choose Tools → AcceleratedSAP → Customizing → Edit project → SAP Reference IMG.

NOTE: Looking for the existence of changes is not true quality assurance testing!

6.3 The most recently imported development changes can be test by verifying that the objects such as the ABAP program Z_ABAP_## and development class Z_DEVCLASS_## exist in QAS and can be executed.

NOTE: Just looking for the existence of objects is not true quality assurance testing. The object’s functionality needs to be tested.

7

7.1 Use Transaction STMS to access the initial TMS menu. From the TMS menu, choose Overview → Imports to see the Import Overview of all R/3 System in the transport domain. Double-click the production system PRD. The Import Queue: System PRD screen appears. From the column St (Status), you can see that the change requests imported into the QAS System have the status Request must still be approved. These requests cannot be imported into the production system until they are confirmed using the QA approval procedures.

If a QA approval procedure is not defined, change requests that are imported into the quality assurance system may technically be imported into any delivery system of this quality assurance system with out a formal approval process.

7.2 Use Transaction STMS to access the initial TMS menu. From the TMS menu, choose Overview → Imports to see the Import Overview of all R/3 System in the transport domain. Select the quality assurance system QAS and choose Goto → QA worklist. The screen QA Worklist: System QAS appears.

Select the Project column with the mouse and choose Edit → Filters. Enter your project name and choose Continue.

To approve a change request, select the change request that has been

tested and choose Request → Approve. The Approve Transport Request screen appears. Provide a reason for the approval of the change request and choose Continue.

7.3 From the Import Overview of all R/3 Systems in the TMS, double -click the production system PRD. The screen Import Queues: System PRD appears. From column Status you can see that the change requests that have been approved in the QAS System have the status Request waiting to be imported. These requests can now be into the production system using any one of the import methods.

8

8.1 To close a CTS project, from client 300 in DEV, choose Tools → AcceleratedSAP → Customizing → Project Management. Mark Project CUST_## and choose Project → Change. From the tab Transport request, choose Complete CTS project. An informational screen appears indicating the impact of closing a CTS project. Choose Continue.

The screen Complete CTS project for CUST_## appears; it shows the status of the Project CUST_## change requests and the import queue of the target system. If some change requests for the project have not yet been released, you can release them now directly by choosing Modifiable requests and then releasing the respective change requests. If some change requests have been released but have not been imported, you can import the change requests by choosing Import.

After all change requests for the project have been released and import, you can successfully close and complete the CTS project.

8.2 Projects apply to all clients within an R/3 System. This means that for one project, corresponding change requests can exist in multiple clients. You can complete a project only if the corresponding change requests have been completed in all clients.

8.3 From the technical perspective it is possible to complete the project as soon as all assigned change requests have been successfully imported into the QA system.

However, SAP recommends completing the project only after the changes have been applied to all systems in the system landscape, that is, after the changes are also applied to the production system and verified in the productive operation. In addition, as long as a project has not yet been closed, the system checks if overlaps occur with concurrent projects.

If you reactivate a project, only overlaps with new objects are recognized.

8.4 The project definition itself can be transported within Project Management using Tools → AcceleratedSAP → Customizing → Project Management. Mark Project CUST_## and choose Project → Transport. In the Transport documents window, select all documents for the project that you wish to transport. If there are no documents listed, choose Continue. The Enter Transport Request dialog box appears. Use Create, select Transport change request, and choose Continue. A new change request will be created that contains the definition and documentation for Project CUST_##. This change request can be used to transport the project to another R/3 System.

9

9.1 To create a Transport Proposal, first display all released change requests using either the Customizing Organizer (Transaction SE10) or the Workbench Organizer (Transaction SE09), selecting Released and choosing Display.

Select a released change request that you would like to add to a Transport Proposal and choose Utilities → Create transport proposal. Provide a description for the transport proposal. Add additional change requests to the proposal if desired. Finally, provide the target R/3 System and client to which this proposal should be delivered and ultimately imported. In this example, the transport proposal should go to PRD . In the field Time, you may specify a given date and time for the import to be performed – otherwise it will be done as soon as your transport proposal is accepted. In the field Import options, you may add required unconditional modes if necessary.

Choose Create and send proposal.

9.2 To see what transport proposal for which you are responsible, from the initial screen of Customizing Organizer select the tab Transport proposal on the right hand side of the screen. Choose the icon for Inbox to display information on your transport proposals.

9.3 Use Transaction STMS to access the initial TMS screen. Choose Overview → Worklist to display the TMS worklist. A logon is performed on the workflow server and the current list of transport proposal are displayed. Double click on your transport proposal and choose Reject proposal.

9.4 To see what transport proposal for which you are responsible, from the initial screen of Customizing Organizer select the tab Transport proposal on the right hand side of the screen. Choose the icon for Inbox to display information on your transport proposals.

You will see that your transport proposal is rejected. Mark your transport proposal and choose the icon to take back your request. From this screen you can specify some more explanation for this transport and send it back again.

SAP AG 1999








Advanced Transport Management

SAP AG 1999

Contentsl Transport directory naming conventions

l Transport tools and communication mechanismsl Managing nonstandard transports using the Transport Organizer

l Import process and troubleshooting

ObjectivesAt the end of this unit, you will be able to:l Outline the files in the transport directory

l Explain transport tools and their intercommunicationl Perform imports and troubleshooting with tp

l Clean-up the transport directory

Advanced Transport Management

SAP AG 1999

DevelopmentSystem (DEV)

Transport Directory

actlogDEVZ900073DEVZ900074

sapnamesSMITH

dataR900073.DEV

cofilesK900073.DEV

bufferQAS

logULOG 98_1SLOG9803.DEVALOG9803DEVE900073.DEVDEVP900073.QAS DEVI900073.QAS N980215.QAS …..

User SMITHcreates change request

DEVK900073

DEVK900073 is releasedand exported to QAS

Quality AssuranceSystem (QAS)

Transport Directory File Name Conventions

n As the transport control program tp runs on many different operating systems, restrictive naming conventions are required. Change requests are named <source SID>K9<5 digits>, where K9 indicates a customer request. The six digits (including the 9) are a serial number.

n The transport directory contains, for example, the following subdirectories:

� actlog with files named <source SID>Z<6 digits> recording each action on a request or task (for example, creation, release, or change of ownership).

� sapnames with files named after the user's logon name. A file is created for each R/3 user who performs transport actions, and updated when the user releases a request.

� buffer with an import buffer for each R/3 System named after the SID. When a change request is released, the import buffer of target systems is updated.

� data with files named R9<5 digits >.<source SID> containing the exported objects, and files beginning with D9 if application defined objects (ADOs) are transported.

� cofiles with command files named K9<5 digits>.<source SID> (containing, for example, import steps to be performed)

� log with all log files, such as ULOGs, ALOGs, SLOGs, log files named <source SID><action>9<5 digits>. <action SID> for each executed step, and log files named <action><date>. <action SID> for steps that are collectively executed, for example, step N (structure conversion) and step P (move nametabs). For a list of possible actions and related letters, see the Appendix.

SAP AG 1999

R/3

Operating system

TransportDirectory

Export Import

Development

Buffer, logs, cofile,TP_<DOMAINNAME>.PFL

QualityAssurance

Insert table entries into control tables

Buffer, logs, cofile,TP_<DOMAINNAME>.PFLCalls

Release and export calls tp

tp ABAP communication

tptp tptp

R3transR3trans

Calls

Insert table entries into control tables database

QAS

database

DEV

Introducing tp

n The transport control program tp is a tool for controlling transports between R/3 Systems and for performing R/3 Release upgrades. tp tracks transports by controlling exports and imports of objects between R/3 Systems, ensures that the steps in exporting and importing objects are performed in the correct order, and ensures that imports into a target system are done in the same order as the exports from the source systems.

n tp is an operating system level tool using special programs (such as C programs), operating system commands, and ABAP programs in R/3.

n tp performs exports and imports separately. In the export phase, the objects to be transported are extracted from the database of the source system and stored in files in the transport directory. In the import phase, the objects are added to the database of the target system. An export should always take place immediately after the change request has been released, so that the objects can be freed for further modification.

n There is no automatic mechanism that imports a request into a target system immediately after export. In R/3 Releases before 3.1H (without TMS functionality), imports are performed using tp commands at the operating system level. After 3.1H, using the TMS, imports are instead performed from within R/3.

n Although most transport activities can be performed using TMS, you may find the need to use tp commands for exceptional cases. Because import buffers and import queues are identical, using tp and using TMS produces consistent results.

SAP AG 1999

Transport Directorytp import all QASclient=200DEVK900004

DEVK900008DEVK900016DEVK900013 tp import DEVK900016 QAS client=200 u0

Import

QAS

Release and Export

DEV

databasedatabase

tp Import Commands

n Imports performed using tp at the operating system level should be restricted to exceptional cases, such as imports to multiple clients.

n There are two commands for importing to a target system using tp at the operating system level:

n tp import all <target SID> client=<client_number>. Analogous to the default import of TMS, this command imports all waiting change requests in the correct sequence (their export sequence).

n tp import <change request> <target SID> client=<client_number> u0. Analogous to the TMS preliminary import, this command enables you to give individual change requests priority.

n Importing individual requests is not recommended as the correct order of requests is not necessarily maintained, and thus newer versions of objects may be overwritten by older versions through the regular import of all waiting requests. To ensure that the objects imported through an individual transport are not overwritten by an older version, only use unconditional mode 0 (option u0) when starting individual imports. Using this mode is analogous to the TMS preliminary import and causes the change request to remain in the list of requests to be imported. When the regular transport takes place, the request will automatically be imported again in the export sequence. Individual imports only should be performed in exceptional cases.

n Processing imports out of order can result in severe inconsistencies in the target system. These are hard to diagnose. If you wanted to import single requests not as preliminary import (NOT recommended), you would use tp import <change request> <target SID> client=<client_number> (without the option u0).

SAP AG 1999

0 Import from the buffer without deleting and set unconditional Mode 1 in the buffer to allow another import at the correct location (Overtaker).

1 Ignore that the change request has already been imported.

2 Overwrite the originals.

3 Overwrite system-specific objects.

6 Overwrite objects in unconfirmed repairs.

8 Ignore restrictions based on table classification.

9 Ignore that the system is locked for this type of transport.

tp Unconditional Import Modes

n Unconditional modes are among the options that can be assigned to tp commands. They are used to cause specific rules of the Change and Transport System (CTS) to be ignored.

n Each unconditional mode is represented by a digit. To use an unconditional mode, add a ‘u' to the tp command line and add the required digit or digits. For example, if you want to import request DEVK900132 into the quality assurance system and overwrite originals, enter the following command:

tp import DEVK900132 QAS u2

n Use unconditional modes carefully. It is preferable to transport according to the rules of the Change and Transport System (CTS).

n Some unconditional modes can be used directly in TMS.

SAP AG 1999

tp helptp showbuffer <SID>tp addtobuffer <request> <SID> [u<digit(s)>]tp delfrombuffer <request> <SID>tp cleanbuffer <SID>tp setstopmark <SID>tp delstopmark <SID>

Buffer for QAS

tp Commands for Accessing Buffers

TASK UMODE ----------------------------------------------------------------------------------------------DEVK900048 8DEVK900057DEVK900053STOPMARK Is a special entry (not a change request) DEVK900069 2

TASK UMODE ----------------------------------------------------------------------------------------------DEVK900048 8DEVK900057DEVK900053STOPMARK Is a special entry (not a change request) DEVK900069 2

n The contents of import buffer files in the transport subdirectory BUFFER are organized as a table. Each line contains information on a specific transport request that is specified in column TASK. One column includes the unconditional mode that is linked to the transport request. Other columns specify import actions.

n tp offers several commands for accessing buffers:

� tp showbuffer <SID> displays buffer entries.

� tp addtobuffer <change request> <target SID> registers the request as the last request to be imported. If the request has already been added for import, it is placed at the end of the queue.

� tp delfrombuffer <change request> <target SID> deletes a single request from the buffer.

� tp cleanbuffer <SID> removes successfully imported change requests from the buffer. This functionality is included in the command tp import all <target SID>.

� tp setstopmark <SID> places a stopmark at the end of a buffer so that subsequent tp import commands only process the requests that are located before the stopmark.

� tp delstopmark <SID> deletes the stopmark from a buffer.

SAP AG 1999

R/3

Operating system

Export ImportRDDMASGL

RDDGENBB

...RDDVERSL

RDD*-RDD*-JobsJobs RDDIMPDPRDDIMPDP

database

QAS

Development

QualityAssurance

TRBAT TRJOB

write logs

tp

starts

triggers

schedules

RDDNEWPP

TransportDirectory

ABAP Programs Used in Performing Transports

n Transport steps implemented using ABAP programs include activating the ABAP Dictionary, converting structures, and generating reports and screens. To execute these steps, tp use the tables TRBAT and TRJOB to communicate with the various ABAP programs. As these ABAP programs are run as background processes, there must be at least two background work processes running in R/3.

n When imports are performed, tp triggers the import dispatcher RDDIMPDP by sending the event SAP_TRIGGER_RDDIMPDP with the help of the tool sapevt. In client 000 and each client that is to receive imports, user DDIC must schedule the job RDDIMDP with event-based scheduling. RDDIMPDP can be scheduled by running the ABAP program RDDNEWPP.

n Normally, RDDIMPDP is automatically scheduled after a client copy. To verify if the required import dispatchers are scheduled, check the job overview using Transaction SM37. The correct name of the import dispatcher for each client is RDDIMPDP_CLIENT_<nnn> where nnn represents the client's name. The corresponding event is SAP_TRIGGER_RDDIMPDP_CLIENT.

n tp and the background jobs needed for transports communicate using table TRBAT, which contains temporary data. tp inserts information into TRBAT specifying the steps to be performed for a specific request. tp then triggers RDDIMPDP to read TRBAT and execute the required programs as background jobs whose names start with RDD. For example, RDDMASGL is for mass activation, RDDGENDB for conversion, and RDDVERSL for versioning. Each RDD* job receives a job number that is recorded in table TRJOB. The jobs report their current status back to TRJOB.

SAP AG 1999

1st 2nd 3rd 4th 5th 6th 7th 8th 9th

TASK DDIC | ACTIV | MAIN I | MC ACT | ADO I | LOG I | VERS F | XPRA | GENERA | UMODE------------------------------------------------------------------------------------------------------------------------------------------------------------DEVK900048 | | 1 | | | | 1793 | | | DEVK900057 | | 1 | | | | 25 | | 23 |DEVK900053 | | 1 | | | | 5 | | | DEVK900069 1 | 1 | 1 | | | | 1 | | 1 | DEVK900078 | | 1 | | | | 197 | | |DEVK900083 | | 1 | | | | 25 | | 23 | DEVK900087 | | 1 | | | | 5 | | | DEVK900092 1 | 1 | 1 | | | | 1 | | 1 |

tp Processing Sequence

l tp collectively processes each import step for all requestsbefore proceeding with the next import step

l tp does NOT process all import steps for only a singlerequest before proceeding to the the next request

n tp processes each import step collectively for all requests in the import queue.

n The required steps for each request are listed in the import buffer file. The contents of the buffer file is organized as a table. Each column represents an import step. The numbers in the columns indicate either if the import step is necessary, or the number of objects in the request that require the step.

n In the example above, first the import step DDIC is processed for requests where it is required (DEVK900069 and DEVK900092); then the ACTIV step (for DEVK900069 and DEVK900092); then the MAIN I step (for all requests); and so on.

n The 'tp import all' command does NOT process all steps for one request before moving on to the steps for the next request. For example, if you detect an error in an object that has already been released, you correct the object and release it again. 'Import all' then imports the whole buffer in the correct sequence and the faulty object is overwritten. Because the generation step is the last step and is performed only once for all objects in the requests, the faulty object does not affect your production system. Only the correct version of the report is activated and generated.

SAP AG 1999

• ABAP Dictionary import• ABAP Dictionary activation• Distribution • Structure conversion(*)• Move nametabs(*)• Main import• Activation of the enqueue definitions• Enqueue conversion (*)

• ABAP Dictionary import• ABAP Dictionary activation• Distribution • Structure conversion(*)• Move nametabs(*)• Main import• Activation of the enqueue definitions• Enqueue conversion (*)

DDIC I

ACTIV

MAIN I Imp

ort

pro

cess

MC ACT

MC CONV

(*) = generic steps not dependent on requests

Steps during Import (1)

n ABAP Dictionary import with R3trans: All ABAP dictionary structural data is imported inactively, thus enabling you to import into an active R/3 System.

n Activation of ABAP dictionary and distribution: Runtime descriptions (nametabs) are written inactively. After activation and running logical checks for the new dictionary structures, the distribution program decides what actions are required to bring the new objects into the running system.

n Structure conversion: If necessary, changes are made to table structures.

n Move nametabs: After the new ABAP runtime objects are put into the active runtime environment, database structures are adjusted if necessary. From the beginning of this step until the end of the main import, inconsistencies may occur in the R/3 System that are removed at the end of the main import.

n Main import with R3trans: All data is imported and the R/3 System returns to a consistent state.

n Activation and conversion of enqueue objects: Objects that were not previously activated are activated in this separate step after the main import. They are used immediately in the running system.

SAP AG 1999

• Import of application defined objects (ADOs)• Logical import• Versioning• Execution of user defined activities (XPRAs)• Generation of ABAP programs and screens

• Import of application defined objects (ADOs)• Logical import• Versioning• Execution of user defined activities (XPRAs)• Generation of ABAP programs and screens

ADO I

VERS FXPRA Im

po

rt p

roce

ss

GENERA

LOG I

Steps during Import (2)

n Import of application defined objects (ADOs): These objects include forms, styles, and printer definitions.

n Logical imports: This phase is currently not active and is ignored during the import process. The intentions of this phase will be to import data to a shadow client prior to performing required Customizing transactions in the target client.

n Versioning: Versions of Repository objects are only created on the R/3 System from which the objects was exported. However, the import process does modify the object's Version counter which is incremented for all Repository objects during import.

n Execution of user-defined activities (XPRAs): XPRAs are objects that can be used to start reports in the target system. The XPRA object has the same name as the report.

n Generation of ABAP programs and screens: During this step, you can resume normal business activities in the system.

SAP AG 1999

ALOG

SLOGULOG

tp

Transport subdirectorylog

Monitoring and Analysis: tp Log Files

n For long-running imports, it may be helpful to monitor the log files written at the operating system level. All logs in the transport environment are stored in the transport subdirectory log. These logs include logs created by tp (ULOG, SLOG and ALOG), and logs created by the various transport tools.

n The current ULOG file records all tp commands that are free of syntax errors, and is named using the name convention ULOG<YY>_<one digit>. Each line in the ULOG file represents a tp command.

n The SLOG file is used to monitor the transport activities of a specific R/3 System. It contains a general overview of performed imports indicating the return code and thus the success of each import. The name of the SLOG file can be set in the parameter file TPPARAM using the global parameter syslog. The default setting is SLOG<YY><WW>.<SID>.

n The ALOG file records the return code for all transport steps handled in the common transport directory. The name of the ALOG file can be set in the parameter file TPPARAM using the global parameter alllog. The default value is ALOG<YY><WW>.

SAP AG 1999

R3trans

RDD*

Directory log

Directorytmp

DEVI900073.QAS

DEVV900073.QAS

...

DEVI900073.QAS

DEVI900073.QAS

...

tp

Import process

Monitoring and Analysis: Transport Tool Log Files

n The various transport tools write a log for each transport action to the transport subdirectory tmp. After completion of the step, tp moves these logs from tmp to log. The log files are named <source SID><action><6 digits>.<target SID>, where the 6 digits are taken from the corresponding change request, and the performed action is represented by a single character (see also Appendix).

n Each log file contains a table with seven columns showing:

n The level for the transport protocol display in R/3. The possible levels are:

� Performed actions and return code

� Additional error messages

� End-user logs

� Details for developers and hotline

n Whether the text is information, a warning, an error, or a program abort.

n The language ID of the following text.

n The message type, that is, the work area relating to the information.

n The message ID in the related work area.

n The message text. Up to 1000 message texts for each work area are defined in the R/3 repository.

SAP AG 1999

0 Successful transport4 Warning8 Error12 Fatal error

0 ≤ rc ≤ 16 rc = max (tool-rc)

16 < rc < 100 Combination of tool-rc and tp warning

100 ≤ rc < 200 tp warning

200 ≤ rc tp error

Transport toolreturn codes

tp return codes (rc)

File system Database

tp Return Codes

n tp receives return codes from all the transport tools involved in an import process. tp's own return code following exit is interpreted as follows:

� 0 to 16 indicates the maximum values of all return codes from transport tools.

� 17 to 99 is a value that has been calculated from the return codes of the transport tools and a tp warning, for example, that the buffer of the target system has no write permission.

� 100 to 199 indicates warnings. Warnings mean that something went wrong and tp could not perform all tasks. 100 to 149 are "normal" tp warnings, for example, that RDDIMPDP cannot be triggered by sapevt. Return codes of 150 to 199 are rare and indicate incorrect operation by a user. For example, a return code of 152 is received if tp tries to import a request that is not included in the buffer.

� 200 or more indicates tp errors. For example, if a file could not be accessed as required by the import process, the return code is 212.

n More significant than the value of a return code is the accompanying text. To display the text of a specific tp return code, use the tp command tp explainrc <value of return code>.

SAP AG 1999

Alert Monitor

• View tpconnection errors

• Locatepermissionproblems

• See RFC failures

• Reviewindividual logfiles at theoperatingsystem level.

System Log (SLOG) Action Log (ALOG)

• View all tp returncodes

• Locate whatchange request orgeneric phaseproduced awarning or error

Troubleshooting (1)

n The first step in troubleshooting transport errors is to eliminate the obvious setup issues using the alert monitor, which records all TMS transport actions. To use the alert monitor, use Transaction STMS and choose Monitor >> Alert viewer. The following information is displayed for each TMS function: the date and time, the user name, the TMS status message, and the target R/3 System. To display the full text of an error message, double -click on the error message.

n R/3 logs are shown in a tree structure with three-levels:

n The top level shows the SLOG file, used to monitor the transport activities of an R/3 System and determine the success of import requests.

n If import failures are recorded in the SLOG file, drill down to the ALOG file and locate what particular import step produced the return code listed in SLOG.

n From ALOG, to locate the log file for the specific request that produced the error and evaluate the cause of the problem, use either the import monitor or the relevant Change Organizer (the Workbench, Transport, or Customizing Organizer).

n All log files that are not dependent on specific requests (such as the log files for structure conversion and nametab moving) cannot be displayed in R/3. An import may abort and yet the log files displayed in TMS reveal no errors. This means the error was produced by one of the request-independent steps. To locate the step that recorded a failure, check the transport directory on the operating system level.

SAP AG 1999

V 000047V 000048

TRJOB

Transport Directory

C11K900003 N 0000 ...C11K900008 N 8888 ...

TRBAT

Job overview01.01.98 12:06 516 Job started01.01.98 12:07 560 Step 001 started01.01.98 12:07 007 Fatal Error01.01.98 12:08 518 Job aborted

R/3

SM31 - check tables SM37 check protocolsof RDD* jobs

log

sapnames

actlog

buffer

tp

File system

sapevt

R3trans

Operating System

Troubleshooting (2)

n In R/3, check if the transport daemon RDDIMPDP is scheduled correctly and event-triggered. To check on the success of all related background processes (RDD*-jobs), go to the job overview (Transaction SM37). Enter RDD* in the Job name field and a ‘*’ in the ‘or after event’ field.

n The import buffer in subdirectory buffer provides information about the progress and success of imports.

n Problems may result from wrong versions of tp or R3trans; tp not running (UNIX: ‘ps -ef | grep tp'); permission or share problems with the common transport directory; or not enough free disk space.

n When analyzing a problem, compare the logs and buffer entries with the entries in tables TRBAT and TRJOB (Transaction SM31). If required, insert the transport request or header in TRBAT (use the codes in the Appendix) and restart RDDIMPDP.

n If a communication problem between tp and R/3 is indicated, try calling sapevt on operation system level and see if it triggers RDDIMPDP.

SAP AG 1999

Administrator

tp check all

tp clearold all

BufferRead

Search

LogCofiles

Data Find

ALL_old.lis

Names of files that areunused (not marked for import)

Read

Write

and TP_<DOMAINNAME>.PFL

Delete

Data files older than datalifetimeMove

OLDDATA

Cofiles older than cofilelifetime

Old data files older than olddatalifetime

Log files older than Loglifetime

1.

2.

Find

Cleaning-Up the Transport Directory

n To clean up the transport directory, use the commands tp check all and tp clearold all. In the course of time, many large files may accumulate in the transport directories. These contain important information, but they also require disk space and become obsolete over time.

n tp check all searches in these directories for files that are no longer needed, that is files whose corresponding request is not marked for import into any R/3 System, as revealed by the buffer entries. The names of all files are listed in ALL_OLD.LIS in transport subdirectory tmp.

n The command tp clearold all uses the result list of tp check all (ALL_OLD.LIS) to find files that have exceeded a maximum age. To specify the maximum age, use the transport profile parameters datalifetime, olddatalifetime, filelifetime, and loglifetime. Data files in the transport subdirectory DATA that are older than the parameter datalifetime are moved to the transport subdirectory OLDATA. Files in the subdirectories LOG and COFILES are immediately deleted if they exceeded the age specified by loglifetime or cofilelifetime. Files in OLDDATA are deleted if they are older than olddatalifetime.

n Before cleaning-up the transport directory, SAP recommends making a copy of the transport directory and saving it for audit purposes.

n See SAP Note 41732 in SAPNet.

SAP AG 1999

Transport Organizer (1)

l The Transport Organizer provides functions for:

n Display

n Transport of copies and relocations

n Object lists

n Client transports

n Delivery transports/preliminary transports

l Provides tools for complex system landscapes

l Enables navigation to different transport types, and theworkbench and Customizing organizers

n Since some request types have their own naming conventions and a single owner is not always a suitable selection criterion, the Transport Organizer was designed with five different initial screens that allows access to the Transport Organizer, or to branch to the Workbench or Customizing Organizer.

n Depending on your area of work, when using the Transport Organizer you may prefer to use a particular selection screen. To access this selection screen directly when calling the Transport Organizer, define this selection screen as your default initial screen by choosing Settings → Define as initial screen. This setting applies until you overwrite it by defining another selection screen or the overview screen as the initial screen.

SAP AG 1999

Transports of copies and relocations

Transport of copies

Relocations without development class change

Relocations with development class change

Relocations of complete development classes

Transport Organizer (2)

n Use Transport of copies to transport objects to another R/3 System. The objects are transported with the version they have in the current R/3 System; the original location of the objects is not changed. This function replaces T-type transports as of Release 3.x.

n Use Relocations of objects without a development class change if development work on objects is to take place in another R/3 System temporarily. Special developments may be carried out in a separate R/3 System, for example, so as not to interfere with the development process. This request type allows you to move the original location of objects to the target system. This function replaces "Transport of Originals" or C-type transports as of Release 3.x.

n Use Relocations of objects with development class change when the development system of individual objects is to be changed on a permanent basis. This request type allows you to change the original location of objects to the target system and change the development class of the objects at the same time. Due to the development class being changed automatically, the objects have the desired transport attributes immediately after being imported into the target system of the request.

n Use Relocations of a complete development class when the development system of a complete development class is to be changed on a permanent basis.

n On transporting original objects, see also SAP Note 67074 in SAPNet.

SAP AG 1999


l Describe common transport directory

l Explain transport tools and their inter-communication

l Perform imports, troubleshooting (including TMS)

l Describe and define transport managementUse the Transport Organizer for nonstandard transports


SAP AG 1999

R/3

Operating system

Export Import

Development QualityAssurance

database

QAS

exit code

database

DEV

R3transR3trans R3transR3transconnect, read

connect, update,delete and insert

exit code

tptp

write data files,logs

read data files,write logs

TransportDirectory

Appendix: Introducing R3trans

n R3trans is a transport tool at the operating system level used to transport data between R/3 Systems. R3trans is also used when installing new R/3 Systems, performing R/3 Release updates, and for logical backups. R3trans is usually called by other programs such as tp and the upgrade control program R3up.

n For transports between R/3 Systems, to access the database, tp indirectly calls R3trans – by causing Unix to issue a fork(), Windows NT to issue a CreateProcess(), and AS/400 to issue a spawn(). During export, R3trans stores the object data extracted from the database in data files in the transport subdirectory data. The format of these data files, R3trans format, is independent of the platform. During import, R3trans reuses these data files.

n Direct use of R3trans is not supported but may be required in exceptional cases. In case of transports, R3trans should always be used through tp. Import steps differ for the different object types. Further activities may be required in addition to R3trans activities. tp ensures that all export and import steps, including R3trans activities, are completed successfully.

n Upward compatibility: R3trans writes data using a standard R/3 transport format. Thus you can export data with an old R3trans version and import data with a new version of R3trans. You can also transport between different databases or operating systems.

n Note that although exports and imports are independent of the R3trans version, the database platform, or the operating system, SAP does not support using tp or R3rans for transports between different R/3 Releases.

SAP AG 1999

tp

AB

AP

AB

AP

AB

AP

OS

Lev

elO

S L

evel

OS

Lev

el

TRBAT TRJOB

database

Buffer

RDDIMPDP

Importdispatcher

DDICactivation Conversion Generation ...

../tmp - Log file(s)

../log - Log file(s)R3trans

Dat

abas

eD

atab

ase

Dat

abas

e

Appendix: Import Process: tp and the Import Buffer

n The first step of an import process is the tp call, triggered by starting an import through TMS or by a ‘tp import' command at operating system level.

n To ensure that all transport requests stored in the buffer begin the import process automatically, each time a ‘tp import' call is made, a ‘tp setstopmark' is executed.

n After the steps of the import process are completed, the command ‘tp delstopmark' is performed automatically, and a ‘tp cleanbuffer' deletes the transport requests from the import buffer.

n After all involved tools have finished their work, tp exits to the operating system level and writes a return code to the appropriate log file for the activity. For example, ‘tp import' and ‘tp setstopmark' commands are recorded in the ULOG file.

n Note: The command 'tp import' is reentrant. If an error occurs during import, after you eliminate the error condit ion and restart tp, tp finds the correct point to restart.

n By default, tp aborts if one import phase receives a return code larger than 8. The transport profile parameter stoponerror defines what return code value should cause tp to abort.

SAP AG 1999

TRBAT

TRJOB

D

atab

ase

Dat

abas

eD

atab

ase

AB

AP

AB

AP

AB

AP

OS

Lev

elO

S L

evel

OS

Lev

el

DD import Main import


../log - Log file(s)Buffer

tpR3trans

RDDIMPDP

Importdispatcher

DDICactivation Conversion Generation ...

database

Appendix: Import Process: R3trans

n During the import process, tp reads the command file that includes all the necessary steps for the specific request and calls R3trans at the operating system level through a forc() for Unix systems, a CreateProcess() for Windows NT, or a spawn() for AS/400 environments.

n For each import step, tp passes a control file to the transport subdirectory tmp for use by R3trans. R3trans reads the corresponding data files in the transport subdirectory data and connects directly to the database to perform inserts or updates to the included objects. After R3trans finishes performing inserts or updates, it passes an exit code to tp.

n For each transport action, R3trans writes a log file in transport subdirectory tmp. After R3trans completes its work, tp moves this log file to the transport subdirectory log.

n During the import process, R3trans is called by the import steps ABAP dictionary import (for the import of ABAP dictionary definitions), and main import (for the import of table contents).

SAP AG 1999

Dat

abas

eD

atab

ase

Dat

abas

eA

BA

PA

BA

PA

BA

PO

S L

evel

OS

Lev

elO

S L

evel

Triggers

TRBAT TRJOB

RDDIMPDP

Importdispatcher

Inserts entries

Reads

DDICactivation Conversion Generation


../log - Log file(s)Buffer

...

tpR3trans

database

Appendix: Import Process: tp / ABAPCommunication (1)

n For every transport request, tp writes an entry in table TRBAT. The import function currently being performed for the request is represented by a character. For a list of TRBAT function codes, see the Appendix.

n In the example below, there are 3 change requests waiting for DDIC activation in the table TRBAT. tp inserts a header entry to tell RDDIMPDP to start processing. Some activities that are independent of transport requests, such as distribution and structure conversion, only have a header entry in TRBAT. Return code 9999 indicates that the step is waiting to be performed. For the header entry, tp inserts a B (for "begin") as return code.

Request Function Return Code Timestamp DEVK904711 J 9999 00000001 DEVK904712 J 9999 00000002 DEVK904713 J 9999 00000003 HEADER J B 19983103143701

n To trigger the transport daemon RDDIMPDP in R/3, tp uses the operating system level tool sapevt.

SAP AG 1999

Dat

abas

eD

atab

ase

Dat

abas

eA

BA

PA

BA

PA

BA

PO

S L

evel

OS

Lev

elO

S L

evel

TRBAT TRJOB

RDDIMPDP

Importdispatcher starts RDD*-jobs

Inserts job number


Writes status


../log - Log file(s)

Checks and writes table

Buffer

...

tpR3trans

database


n When RDDIMPDP is started, it checks the table TRBAT to find out if there is an action to be performed such as mass activation, distribution, or table conversion. It sets the header entry to R (for "run"), and starts the appropriate RDD* program as a background task, reschedules itself, and exits. The activated program (in this example, the mass activator) sets the status of the first entry in TRBAT to active (return code 8888):

Request Function Return Code Timestamp DEVK904711 J 8888 00000001 DEVK904712 J 9999 00000002 DEVK904713 J 9999 00000003 HEADER J R 19983103143903

n Each of the required background tasks receives a job number generated by R/3 background processing. This job number and the step ID are inserted into table TRJOB by the RDD* jobs.

SAP AG 1999

Dat

abas

eD

atab

ase

Dat

abas

eA

BA

PA

BA

PA

BA

PO

S L

evel

OS

Lev

elO

S L

evel

Restarts

TRBAT TRJOB

RDDIMPDP

Importdispatcher restarts RDD*-jobs

Monitorstables

Deletesentries


Writes status


../log - Log file(s)

Checks tables

Writes logs

Buffer

Moves logs

...

Deletesentries

tpR3trans

database


n The background tasks write their return codes in TRBAT and delete the corresponding entry in TRJOB. Return codes of 12 or less indicate that the step is finished. In TRBAT, the column TIMESTMP contains the finishing time. When all the necessary actions are performed for all transport requests, the header entry is set to F (for "finished") by the RDD* jobs.

Request Function Return Code Timestamp DEVK904711 J 4 19983103144202 DEVK904712 J 0 19983103144357 DEVK904713 J 0 19983103144512 HEADER J F 19983103144512

n All the background jobs log the steps they perform either in the database or in transport subdirectory TMP.

n tp monitors the entries in TRBAT and TRJOB. When the header entry in TRBAT is set to F and TRJOB is empty, tp copies the logs of the completed steps from directory tmp to log and deletes the corresponding TRBAT entries.

n If problems are detected by tp when monitoring TRBAT and TRJOB, tp re-triggers RDDIMPDP through sapevt. RDDIMPDP automatically recognizes if a previous step is still active or was aborted by checking TRJOB and TRBAT. If a step was aborted, RDDIMPDP restarts this step. Two background work processes must be available.

SAP AG 1999

Global settings:

Distribution of transports:

R3trans:

Transport daemon:

Global settings:Global settings:

Distribution of transports:Distribution of transports:

R3trans:R3trans:

Transport daemon: Transport daemon:

TRANSDIR path of the default transport directorySTOPONERROR return code value that will abort tp

TESTIMPORT flag to activate/deactivate test import intoconsolidation system

R3TRANSPATH path to locate the program R3transRECCLIENT turn on table logging for the specified clients

during transports

SAPEVTPATH path to locate the sapevt executable

Appendix: Additional Transport Profile Parameters

n During an import, tp checks the maximal return code after completing a transport step. For example, this check is done after doing the DDIC import of all transports in the current import queue. If a return code appeared that was equal or higher than the value of stoponerror, tp will abort.

n The automatic execution of a testimport is part of complete export of a transport request. From time to time the testimport into the target system is not possible. For example, when the target system is a non existing system but only a buffer being filled for later use. In this case, the automatic testimport may be switched off. Examples of the parameter include:

� DEV/testimport = no will switch off the automatic test import for every export from DEV

� wnt|testimport = no will switch off the automatic test import for every export executed on a Windows-NT box

� DEV/wnt|testimport = no will switch off the automatic test import for every export from SRC executed on a Windows-NT box.

n See also SAP Online Documentation for additional transport profileparameters.

SAP AG 1999

$(cpu) The CPU name (alphaosf, hp, rm600, rs6000, sun, wnt, as4).This can be important for operating systems in heterogeneousnetworks.

$(cpu2) This variable contains an acronym for the name of the operatingsystem. The same acronyms as those used for specifyingoperating system-specific parameters are used, i.e.: aix, hp-ux,osf1, sinix, sunos and wnt.

$(dname) Abbreviation for the day of the week (SUN,MON,....).$(mday) Day of the current month (01-31).$(mname) Abbreviation for the name of the month (JAN,FEB,...).$(mon) Month (01-12).$(system) Name of the R/3 System.$(wday) Day of the week (00-06, Sunday=00).$(yday) Day of the current year (001-366).$(year) Year (four positions).$(syear) Short form of the year (two positions).$(yweek) Calendar week (00-53).

Appendix: Predefined Transport Profile Variables

n The global parameter file provides predefined variables that you can use when specifying parameters. Enter one of these variables in the following format: $(xyz).

n These variables are used in transport profile for example to set the parameters ALLLOG and SYSLOG.

SAP AG 1999

Usage: tp <command> [argument(s)] [option(s)], where <command> may be one of:

Exporting

EXPORT EXPWBOR3E VERSESDETST

ADDTOBUFFERSETSYNCMARKSETSTOPMARKMARKCLEANBUFFERDELFROMBUFFER

Importing

PUT IMPSYNCIMPORT R3ICMD MEALIM MVREPOSR3H MVKERNELACT SDITACOB GENT1GENTB GENGENT2 XPADIST VERSIMVNTABS

Special Functions

LOCKSYS UNLOCKSYSLOCK_EU UNLOCK_EUWRITELOG GETPROTSSAPSTART SAPSTOPGETTBATGENT GETTRBATENTGETDDXTTENT GETDDXTFENTGETOPENCORR CREATECOFILEPREPAREBUFFER CREATEINFO

Information

SHOWBUFFERCOUNTSHOWPARAMSGOCONNECTSTATUSCHECKIMPDPSHOWINFOGETOBJLISTEXTRDOCUGETCONVENTEXPLAINRC

DELSYNCMARKDELSTOPMARKUNMARK

CLEAROLDCHECK

Buffer Actions Disk Space

For more details, call tp with the desired command (and no other parameters)

Appendix: tp Commands

n tp commands are executed in the transport subdirectory bin by user <SID>adm, and are written tp <command> [argument(s)] [option(s)]

n To display general information on the syntax of all tp calls, use tp help. To display a description of the syntax and function of a specific command, use tp <command> without any options.

n To display a count of all requests registered for import into a specific system, use tp count <SID>.

n To display the environmental variables required for logging on to the correct database of a specific system with the help of the values in the global parameter file, use tp go <SID>. Note that this command does not perform a connect; tp executes this command before a connect.

n To test whether a connection to an R/3 System's database was successful, use tp connect <SID>.

n To display how the import dispatcher RDDIMPDP is scheduled for a specific R/3 system, use tp checkimpdp <SID>.

n To display all current settings of the parameter file, use tp showparams <SID>.

n To display status information on the serialization of a specific system, use tp status <SID>.

SAP AG 1999

Mnemonic Step Program Environment

E main export R3trans OS

P test import R3trans OS

H DD objects: import R3trans OS

A DD objects: activation RDDMASGL R/3

S DD objects: distribution RDDGENBB R/3

N DD objects: conversion RDDGENBB R/3

6 DD objects: move nametabs pgmvntabs OS

I main import R3trans OS

T import of table entries R3trans OS

M enqueue activation RDDGENBB R/3

G repository objects: generation RDDIC03L R/3

V version update RDDIC R/3

Appendix: tp Steps

SAP AG 1999

A ddic activation T R3trans import of table entriesB TACOB activation of DD objects V version updateb backup W forwarding and linking K transportsC corr.release of C-sources X export of self defined objectsc kernel copy < enqueue type (SE07)D import of selfdefined objects (SDO) > dequeue type (SE07)d remove stopmark 1 start databaseE main export 2 stop database F export of C sources 3 start SAP systemG generation of repository objects 4 stop SAP systemH DD import 5 move reports I main import 6 move nametabsJ new activator symbol 7 touch all reports L R3trans import commandfile 8 reset SAP buffers M enqueue activation ( lock DE (development environment) N TACOB conversion of DD objects ) unlock DEn TACOB conversion of MC objects { locksysXP test import | locksysQ execution of reports before put } unlocksysR execution of reports after put (XPRA) ? unknown actionS distribution of DD objects

Appendix: Complete List of tp Action Types

SAP AG 1999

Header JOBNAME Report Explanation

=====================================================================

X RDDDIC0L RDDDIC0L ADO export

J RDDMASGL RDDMASGL Mass activator (new)

B RDDTACOL RDDTACOL TACOB activator

S RDDDIS0L RDDGENBB Distributor

N RDDGEN0L RDDGENBB Import converter

M RDDMASGL RDDMASGL Mass activator (Enqueue)

Y(n) RDDGEN0L RDDGENBB Matchcode converter

O RDDGEN0L RDDGENBB Batch converter (not in Upgrade)

D RDDDIC1L RDDDIC1L ADO import

V RDDVERSL RDDVERSL Create version

R RDDEXECL RDDEXECL XPRA execution

G RDDDIC3L RDDDIC3L Generation

Functioncodes

Appendix: TRBAT Function Codes

n The function codes in TRBAT describe the actions being performed on a change request during import:

B: Activating all dictionary objects in table TACOB with mass activation; D: Importing application defined objects (ADO); G: Generating reports and screens.

J: Activating all dictionary objects – other than enqueue objects – with mass activation.

M: Activating enqueue objects in the change request with mass activation.

N: Converting all structure changes generated by the import and recorded in table TBATG, other than the structure changes to matchcode objects.

O: Converting all structure changes recorded in the table TBATG and generated by actions in the online system and not by the import.

R: Executing reports after put (XPRA); S: Distributing actions – required to transfer the new dictionary structures into the runtime environment – to different steps.

X: Exporting application-defined objects; Y: Converting structure changes to matchcode objects which were generated by the import and are recorded in table TBATG.

n Note that actions B (TACOB activation), N, O, Y (structure conversion), and S (distribution program) only have header entries and no entries in field FUNCTION as they are change-request independent.

SAP AG 1999

• Dictionary import• Dictionary activation• Distribution(*) • Structure conversion(*)• Move nametabs(*)

• Main import• Activation of the enqueue

definitions• Enqueue conversion(*)• Import of application

defined objects (ADOs)• Logical import• Versioning• Execution of user defined

activities (Xpra)• Generation of ABAP

programs and screens

• Dictionary import• Dictionary activation• Distribution(*) • Structure conversion(*)• Move nametabs(*)• Main import• Activation of the enqueue

definitions• Enqueue conversion(*)• Import of application

defined objects (ADOs)• Logical import• Versioning• Execution of user defined

activities (Xpra)• Generation of ABAP

programs and screens

DDIC I

ACTIV

MAIN I

ADO I

VERS F

XPRA

Imp

ort

Pro

cess

DEVH900021

DEVA900021DS980605.QAS

P980625.QAS

DEVI900021

DEVV900021DEVR900021

DEVG900021 GENERA

LOG I

MC ACT

N980625.QAS

N980605.QAS

DEVMS900021

DEVD900021

DEVU900021

MC CONV

Appendix: Log Files for Importing DEVK900021

SAP AG 1999

l Do the exercises?


Unit Actions

Advanced Transport Management: Exercises

No. Exercise

1 Reviewing export and import files in the transport directory

1.1 You want to view all files generated by a change request that has been export from the development system and imported into the quality assurance system. In order to view the files generated by the export and import process, which R/3 System should you log on to? Log on to the correct R/3 System.

1.2 View all files in the transport directory related to one of your change requests that has already been released and exported from the production system.

1.3 View all files in the transport directory related to a change request of yours that has already been imported into the quality assurance system.

2 Monitoring the import dispatcher RDDIMPDP

2.1 Verify the scheduling of the import dispatcher RDDIMPDP in the quality assurance system.

3 Closing an import queue and importing change requests into the quality assurance system. Because imports can only be started once, this exercise must be performed with the instructor’s assistance.

3.1 Have the instructor close the import queue for the quality assurance system.

3.2 To import just the first 10 change requests in the queue for the quality assurance system, the end mark of the queue must be moved to just after the 10th request. Have the instructor move the end mark.

3.3 How many change requests are waiting to be imported into the quality assurance system?

3.4 Have the instructor import requests waiting to be imported into the quality assurance system. The requests should be imported into the quality assurance client.

3.5 Monitor the progress of the import.

3.6 After the import of the first group of requests has completed, what happened to the end mark?

3.7 Have the instructor import all requests still waiting to be imported into the quality assurance system. The requests should be imported into the quality assurance client.

3.8 Monitor the progress of the import.

4 Troubleshooting import problem #1

Prerequisites (to be performed by the instructor): Rename buffer QAS in subdirectory buffer of the transport directory to QAS.sav. Copy file EXERCISE_4 to QAS in subdirectory buffer of the transport directory

4.1 While the instructor imports the change requests into the quality assurance system, monitor the import process.

4.2 The import monitor reports a return code of 8. What import phase and/or change request produced the import error?

4.3 How can you locate the log files for the change request that produced the import error? What is the error that is reported?

4.4 How would you correct this error?

5 Troubleshooting import problem #2

Prerequisites (to be performed by the instructor): Copy file EXERCISE_5 to QAS in the subdirectory buffer of the transport directory

5.1 While the instructor imports the change requests into the quality assurance system, monitor the import process.

5.2 The import monitor reports a return code of 8. What import phase and/or change request produced the import error?

5.3 How can you locate the log files for the change requests that produced import errors? What are the errors that are reported?

5.4 What caused this error? How could it have been prevented?

5.5 How would you correct this error?

6 Optional exercise: Troubleshooting import problem #3.

6.1 To demonstrate a problem with authorizations, proceed as follows. Have the instructor log on to the development system. Using TMS, close the queue for QAS. When prompted for log on authorization to QAS, use the user account LOSER (password: PLOSER). Was the queue closed for QAS?

6.2 On DEV, review the log files to find out why the user LOSER was not able to close the buffer properly. What error message do you see?

7 Optional exercise: Moving Repository objects from one R/3 System to another.

7.1 How can an entire development class be transported from one R/3 System to another?

7.2 R/3 Repository objects are "owned by" specific systems. In other words, a Repository object knows which system it originated in. Where can you find out which system a Repository object originated in?

7.3 If a Repository object (or an entire development class) is transported from the development system to the quality assurance system, which system will own the object?

7.4 You have a dedicated R/3 System for importing legacy data. This is a temporary system called TMP. At some point in time, the developers working in this system and their programs must be moved to DEV, the R/3 System for all Customizing. How would you recommend moving these programs?

7.5 How can you relocate your Repository objects from the development sys tem to another system within the system landscape?

Advanced Transport Management: Solutions

No. Solution

1

1.1 DEV and QAS share the same transport directory and thus are in the same transport group GROUP_DEV. Therefore, it does not matter from which R/3 System you view the transport directory.

Log on to either DEV or QAS in client 300 as LEAD-##.

1.2 Use Transaction AL11 to view files at the operating system level. Double-click on the directory parameter DIR_TRANS. Then gradually double-click the individual directories and the individual files to display.

The following files created or modified in the transport directory during the export process for change request, for example, DEVK900132, would include:

Subdirectory cofiles contains important control information on how to import and process change requests. You can find the command file K900132.DEV.

Subdirectory data contains data file R900132.DEV. This file stores all the data that was extracted from the development system based on the objects recorded in the change request.

Subdirectory buffer contains control information on which transports are to be imported into which systems and the order in which imports should take place. Each buffer file is named with the <SID> of the corresponding R/3 system. You can see request DEVK900132 listed twice in the buffer file of QAS. The first entry is the actual import queue entry and the second entry is a comment line. If the change request has been imported, the first line (like the comment line) will be commented with a ”#”.

Subdirectory log contains transport logs, trace files, and statistics. The fourth letter specifies the step that has been performed. The SID at the end of each filename specifies the R/3 System on which the action had been performed. The following log files had been written during the export process of request QASK900132: DEVEK900132.QAS – export log file DEVPK900132.QAS – test import log file

Subdirectory sapnames contains information for SAP users (e.g. the status of each change request). For each user who released a request there is a file written. Double-click on the file for your user LEAD-##.

Subdirectory actlog contains action logs for all tasks and requests. These files are only changed by the R/3 System. In this example the following files can be found: DEVEK900132 – action log for the request DEVEK900133 – action log for the related task

1.3 Use Transaction AL11 to view files at the operating system level. Double -click on the directory parameter DIR_TRANS. Then gradually double-click the individual directories and the individual files to display.

The following files created or modified in the transport directory during the import process for change request, for example DEVK900132, would include:

Subdirectory buffer contains each buffer file named with the corresponding SID. You can see request DEVK900132 listed twice in the buffer file of QAS. The first entry is the actual import queue entry and the second entry is a comment line. Because the request has been imported, the first line (like the description line) will be commented with a ”#”. After import into QAS, the request appears in the buffer of TC3 twice. The first entry is not commented but the second reference to the request is.

Subdirectory log contains log files written during both the export and import process. Examples of log files that may be written during the import process of request QASK900132 include: DEVH900132.QAS – import log file DEVA900132.QAS – dictionary activation log file DEVI900132.QAS – main import log file DEVMS900132.QAS – enqueue log file DEVD900132.QAS – ADO log file DEVV900132.QAS – versioning log file DEVR900132.QAS – user defined activities DEVG900132.QAS – generation log file

Note that each change request requires different import phases and log files are only written for the phases required by that request. In addition, some import phases are generic and log files are written during the import process that are not specific to the change request but to the overall import process. These log files for week 33 of 1998 include: DS980802.QAS – Distribution phase log file N980802.QAS – Structure conversion log file P980802.QAS – Move nametabs log file N980802.QAS – Enqueue conversion log file

2

2.1 Log onto QAS in client 300 as user LEAD-##.

To view the scheduling of RDDIMPDP, use Transaction SM37. Choose RDD* as Job name and * as User name. Deselect Active and Finished in box Job Status. Enter * for or after event. Choose Execute.

The screen Job Overview is displayed. A list of all scheduled RDD*-jobs is displayed: RDDIMPDP, RDDIMPDP_CLIENT_001, RDDIMPDP_CLIENT_100, and RDDIMPDP_CLIENT_300. They all have status released.

To view how the jobs are scheduled, mark a specific job and choose Job → Display. Job start is after event SAP_TRIGGER_RDDIMPDP for job RDDIMPDP or SAP_TRIGGER_RDDIMPDP_CLIENT for all client-specific RDDIMP-jobs (RDDIMPDP_CLIENT_<nnn>, where <nnn> specifies the client). The job frequency is event periodic.

3

3.1 From the Import Overview screen, double-click on QAS. Choose Queue → Close. The end mark is set at the end of the listed requests.

3.2 To move the end mark, select the request before which you want the end mark to be placed. In this case, select the 11th request in the list and choose Queue → Move end mark. The dialog box Move end mark appears. Select

th

Yes and the end mark will appear after the 10th request.

3.3 The only requests that are waiting to be imported are the requests before the end mark.

The Import Overview screen only shows 10 requests ready to be imported. However, there are many more requests in the queue. Only requests that are before the end mark in the import queue are imported.

3.4 From the Import Queue: System QAS screen choose Queue → Start import. The Start Import dialog box appears. Supply the target client 300 and choose Start import. To proceed, choose Yes from the Start import screen.

If authorization to the quality assurance system has not yet been provided, the instructor will need to log onto the quality assurance system QAS with TMS rights.

Choose Yes from the Information dialog box and monitor the progress of the imports.

3.5 From the Import Queue: System QAS screen, choose Goto → Import monitor. The TMS Import monitor shows the current import process. Use Refresh to follow the progress of the import process.

3.6 The end mark is removed after the successful completion of the import. The import queue is open and more requests are ready to be imported into the quality assurance system QAS.

3.7 From the Import Queue: System QAS screen choose Queue → Start import. The Start Import dialog box appears. Supply the target client 300 and choose Start import. To proceed, choose Yes from the Start import screen.

If authorization to the quality assurance system has not yet been provided, the instructor will need to log onto the quality assurance system QAS with TMS rights.

Choose Yes from the Information dialog box and monitor the progress of the imports.

3.8 From the Import Queue: System QAS screen, choose Goto → Import monitor. The TMS Import monitor shows the current import process. Use Refresh to follow the progress of the import process

4

4.1 You can monitor the import process in one of the following three ways:

From the screen Import Queue: System QAS, choose Goto → Import monitor. The TMS Import monitor shows the current import process. To follow the progress of the import, choose Refresh.

From the screen Import Queue: System QAS, choose Goto → tp system log. Go to the bottom of the SLOG listing. To follow the progress of the import, choose Refresh.

From the screen tp System Log - System QAS, choose Goto → Transport steps. Go to the bottom of the ALOG listing. To follow the progress of the import, choose Refresh.

4.2 To check whether there are obvious set up errors, from the TMS menu, choose Monitor → Alert monitor. No errors are recorded for the time frame of

this import.

To determine the success of imports, from the screen Import Queue: System QAS, choose Goto → tp system log. You can see that, as the last step, an ”imp all” (import all) stopped with a return code of 0008.

To view the action log file ALOG, choose Goto → Transport steps. To locate the change request(s) or generic phase(s) that produced error 0008, go to the bottom of the listing and check the return codes of all individual transport steps. You can now detect which request caused problems: change request DEVK900390, displaying a return code of 8 (error) for step G (generation).

4.3 You can view the log files for the change request that generated an error during import in one of three ways:

1. To review the individual log files of the transport steps, from the screen Import Queue: System QAS, choose Goto → tp system log, then choose Goto → Transport steps. The ALOG file contains all transports with individual return codes. The number in brackets in the last column indicates the success of the imports. You can now determine the request that caused problems: transport request DEVK900390, which displays a return code of 8 (error) for step G (generation). Now you can go directly to the transport log file by double clicking on the return code of the change request in the ALOG file.

2. From either the Customizing Organizer or the Workbench Organizer, choose Goto → Tools. Expand the Request/tasks hierarchy, and double-click the option Display transport logs. Enter the complete change request number (in this case DEVK900390), and choose Execute .

3. View the generation log file DEVG900390.QAS at operating system level using Transaction AL11.

To display the log file that report the return code of 8, double-click ABAP/scrn. Generation. Choose Edit → Expand → At highest level. The red lines indicate where the problem is: program ZATM_2 has a syntax error in line 000018. For information on how to proceed, position the cursor on the corresponding line and choose Edit → Display long text.

To check the indicated program, use the ABAP editor (Transaction SE38). Enter the name of the program and choose Program → Check → Current program. You will see that the text literal "." is longer than 255 characters, and you are asked to check whether it ends with a quotation mark. Output text has to be put in quotation marks.

The object (an APAP program) was imported, but could not be generated due to a syntax error.

4.4 Corrections should always be made in the development system. Therefore, correct the syntax error in the development system. Take advantage of the program check to assure that the program is correct. Release and export the new request. Then import the request into the target system.

5

5.1 For details on how to monitor the import process, see the solution for Exercise 4.1.

5.2 For details on how to locate the specific cause of the problem, see the

solution for Exercise 4.2.

For this exercise, change request DEVK900402 returned a 0008 during the activation phase – the “A” phase.

5.3 For details on how to view the log files for a change request that generated an error during import, see Solution 3.3. Note that you are looking for the log files for change requests DEVK900402 and DEVK900404.

After locating the import logs for DEVK900402, to display the log file that reports the return code of 8, double-click Dictionary activation. Choose Edit → Expand → At highest level.

The red lines indicate where the problem is: table ZDEMO_EXC4 includes field CUSTOMER. During the ABAP Dictionary activation step of the import process, the system detected that either the field's data element or its underlying domain is either not active in the ABAP Dictionary for QAS, or does not exist. Therefore, the runtime object (nametab) of the table could not be generated and the table could not be activated.

5.4 This error occurred because the table ZDEMO_EXC4 and the corresponding data element ZDTEL2 were developed and transported in two different change requests, and the data element was not imported together in the same import step as the table that refers to the data element. Such problems can occur if imports of single requests are triggered and so the correct sequence is not considered.

To prevent such problems, developers should always be encouraged to transport all related objects in the same change request to ensure proper activation.

5.5 Corrections should always be made in the development system! In this case, a new change request should be created in the development system that contains the content of all 3 change requests, that is, for the table structure, the data element, and the table entries. Release each request and import it into the target system. The import should not produce any errors during import.

6

6.1 When trying to close to import queue for PRD using the user LOSER, the logon continues to fail. If unable to make an appropriate logon, TMS does not perform the requested action. Thus the queue for PRD was not closed.

6.2 Use Transaction STMS and choose Monitor → Alert Monitor to see the error generated. Note the recent message USER_ACCESS_DENIED that occurred on function TMS_TP_MAINTAIN_BUFFER on system QAS. Click on the message to get more detailed information. It states that command TMS_MGR_MAINTAIN_TR_QUEUE could not be executed, because user access was denied for user LOSER. If you choose the Help button, you learn that LOSER has no authorization for the tp command setstopmark. Authorization S_CTS_ADMIN in profile S_A.SYSTEM is needed for user LOSER to allow for TMS actions such as setting end marks.

7

7.1 To transport an entire development class from one R/3 System to another, use object lists and freely select the objects based on the selection criteria of the development class.

7.2 The object catalog (table TADIR) contains data on each Repository object in an R/3 System, such as the system in which the object originated and the development class for the Repository object.

7.3 Transporting a Repository object (or an entire development class) using either the Workbench Organizer or Customizing Organizer, will not change the object’s catalog entry in table TADIR. In other words, if an object is created on DEV and transported to QAS, its catalog entry on both R/3 Systems will be identical. The object will be "owned” by DEV. To verify this, check the Object Catalog on both DEV and QAS for all your transported objects.

7.4 Technically, the developers could simply transport the Repository objects using the Workbench Organizer and change requests. However, this would mean that the Repository objects are still owned by the system TMP and that changing the objects on DEV requires tasks of type repair. In addition, the development classes used by these objects are not assigned to a defined transport route, therefore objects are not transportable.

Rather than transport the objects from TMP to DEV, SAP recommends relocating them. Relocation of objects not only transports the objects but also changes the original system entry in the object catalog for each Repository object.

7.5 To relocate Repository objects, use the Transport Organizer. From the R/3 initial screen, choose Tools → Administration → Transports → Transport Organizer (or use Transaction SE01). Select the option Copy transport and relocs. You can relocate objects with or without a change to their development class. You can also relocate an entire development class, assigning a new transport layer to the development class and its Repository objects.

SAP AG 1999








Client Tools

SAP AG 1999

Client Tools

Contentsl Concept and functions of client tools

l Error handling and limitations

ObjectivesAt the end of this unit, you will be able to:l Explain and differentiate between client copy tools

l Identify and remedy error situationsl Use the log information to identify and solve error situations

l Perform a client delete and a client compare

SAP AG 1999

Appl.data

Use

r

Customizing

Client Client

l The client copy and client transport tools:

n Are designed to replace the data of one client with datafrom another client

n Are not designed to combine thedata of different clients

l Client data is categorized as either:

n Customizing data

n User master data

n Application data as defined by thedata table’s delivery class

l Application data can only be copied with thecorresponding Customizing data

Client Tools: Overview

n Profiles define the tables to be copied through the delivery class of the table. Special data like user masters and variants can be selected by specifying criteria. For details of delivery classes, see also the Appendix.

SAP AG 1999

MAST

R/3 Repository

Cross-client Customizing Cross-client Customizing

Local client copyLocal client copy Remote client copyRemote client copy

ClientClienttransporttransport

….. …..

Source System Target System

Appl.data

Use

rCustomizing

Appl.data

Use

r

Customizing

Appl.data

Use

r

Customizing

R/3 Repository

(optional)

Client Copy and Transport Tools

n SAP provides three tools for copying data between clients:

� Local client copy between clients in the same R/3 System

� Remote client copy between clients in different R/3 Systems

� Client transport between clients of different R/3 Systems

n Remote client copy and client transport differ according to the way in which data is transferred:

� In a remote client copy, data is transferred directly between the source and target client using remote function calls (RFCs) through a network connection.

� In a client transport, data is exported to a file at the operating system level. At some future time, the client is imported from the file system to the target system.

n When using the client copy tools, the data you can select to be copied includes: user master data, client-specific Customizing, and application data.

n R/3 Repository objects, such as ABAP programs, are not transported with the above tools. Development objects can only be transported using change requests.

SAP AG 1999

ProfilesProfiles

Client CopyClient Copy

Copy Copy in background

SAP_APPL

000

Selected profile

Source client ProfilesProfilesProfile SAP_APPL

Data selection

User masters

Customizing

Master & application data

Copy mode

Initialize and recreate

Copy variants of reports

Source client user masters 000

Source client

Target client

000SAP client

In the target client, perform a Local

Client Copy

X

X

X

X

Local Client Copy

n A local client copy copies between clients within the same R/3 System. Both a local and remote client copy must be initiated from the target client using the following steps:

� To create an entry for the target client in the client maintenance table, choose Tools → Administration → Administration → Client Admin. → Client Maintenance.

� Log on to the target client as SAP* with the initial password PASS. Perform the client copy using the menu options found under Tools → Administration → Administration → Client Admin. → Client Copy.

� Select the data to be copied using a profile.

� Assign the source client for Customizing data, application data, and user master records.

� Begin the client copy. As copying is a lengthy process, use background processing.

n To ensure data consistency, you may not logon to the target client during a client copy. SAP also recommends that you do not work in the source client during a client copy.

n Note that SAP delivers the software with standard clients 000 and 001. You may not work in client 000, but may use client 001. However, SAP recommends that you begin R/3 implementation by creating a new client as a copy of client 000.

SAP AG 1999

Copy of dataCopy of datausing RFCusing RFC

remote remote copycopy

Consistency-Consistency-check using check using

RFCRFC

Remote Client CopyRemote Client Copy

COPY Copy in background

SAP_APPLSelected profile

Source RFCdestination RFC_CLIENT

R/3 Repository


Appl.data

Use

r

Customizing

ADOs

R/3 Repository


Appl.Data

Use

r

Customizing

ADOs

R/3 Repository structures must be identical

in source and target clients

Remote Client Copy

n A remote client copy allows you to copy between clients in different R/3 Systems.You can use a remote client copy to, for example, transport client-dependent as well client-independent Customizing data between R/3 Systems.

n A remote client copy proceeds in the same way as a local copy, but sends the data through a remote function call (RFC) connection to the target client.

n A remote client copy is easy to use, and does not require file system space on operating system level. The limitations of a remote client copy are as follows:

n A remote client copy does not create a file at operating system level, so there is no "hard copy" of the client to be copied. Therefore, the same, identical client copy cannot be duplicated at a later date.

n As of 4.6A, cross-client Customizing objects are copied during a remote client copy.

n To be able to transport all data during the client copy, the structures of all copied or transported tables in both systems must be identical. During remote client copy, an automatic Repository consistency check is performed. If inconsistencies are detected, the client copy is terminated and an error message is displayed.

n On remote client copies, see also SAP Note 47502 in SAPNet.

SAP AG 1999

…..

R/3 Repository


Appl.data

Use

r

Customizing

SAPscript

Source system <S-SID>

Data files

RX<no.>

RT<no.>

RO<no.>

Commandfiles

KT<no.>

KO<no.>

Client Transport: Export Process

KX<no.>

XImport Queue: Target System X

Number Request Short text

1 <S-SID>KO<no.> Cross-client tables

2 <S-SID>KT<no.> Client-specific tables

3 <S-SID>KX<no.> Client-specific tables

n A client transport differs from a remote client copy in that it does not use RFC. Like a remote client copy, however, a client transport is used to copy data between different R/3 Systems.

n A client transport consists of two steps. First, a client export extracts client data from the source client to files at the operating system level. Second, the data is imported from the operating system files into the target client.

n To perform a client export, proceed as follows: Log on to the source client. From the R/3 initial screen, choose Tools → Administration → Administration → Client Admin. → Client Transport → Client Export. Select the data to be copied using a profile.

n Indicate the target system to which the client will be copied. (The target system must be defined in TMS as part of the transport domain.)

n Begin the client export. As copying is a lengthy process, use scheduled background processing.

n The client export performed in the source system <S-SID>, exports the client data asynchronously by calling the transport program tp at the operating system level. This export process will generate up to 3 data files at operating system level:

� RT< number >; this file contains client-specific data

� RO< number >; this file contains Cross-client data

� RX< number >; this file contains SAPscript texts

SAP AG 1999

XImport Queue: Target System X

Number Request Short text

1 <S-SID>KO<no.> Cross-client tables

2 <S-SID>KT<no.> Client-specific tables

3 <S-SID>KX<no.> Client-specific tables

…..

R/3 Repository


Appl.data

Use

r

Customizing

SAPscript

Target system

2

Generation

l Import the client export requests intothe target client

l Log on to the target client and activatepost-import processing

Import processing(Transaction SCC7)

Client Transport: Import Process

1

n Depending on the type of data selected through the client transport profile, the client copy command files added to the buffer of the target system are

<S-SID>KO<number>; this file is for cross-client data

<S-SID>KT<number>; this file is for client-specific data

<S-SID>KX<number>; this file is also for client-specific data

n The client export change requests are not imported when an Import all takes place. Therefore, you must import these requests into the target client using TMS. You must import the data in the following order: first cross-client data, then client- specific data.

n After the import process has completed, post-import activities are required possible for object generation steps. After completing the import, log on to the target client. From the R/3 initial screen, choose Tools → Administration → Administration → Client Admin. → Client Transport → Import Editing.

n To display client transport logs, use the Transport Organizer.

n During client transport, a Repository consistency check can be performed by clicking the RFC system check button in Transaction SCC8. If inconsistencies are detected, a list of the ABAP Dictionary tables definitions missing in the target system is generated. This will help your recognize in advance formal problems that may occur during the import of the source data.

SAP AG 1999

Profile Selection

Save profilevalues forfuture use

Client Copy - Copy a Client

Copy tables from a client

SAP_ALL All client-specific data

SAP_CUST Copy Customizing data

SAP_CUSV Customizing and report variants

SAP_UAPP User master records, reports

SAP_UCSV Customizing, variants, and users

SAP_UCUS User master and Customizing

SAP_USER User master records and auth.

Client Copy - Copy a Client

Copy tables from a client

Profiles Source Client (data) Client (user)

SAP_ALL 000 000 120 120 000 230

n Although you cannot create new profiles for a client copy or client transport, you can preserve the profile values of the source data client and source user master client. After entering the required profile values for a client copy or client transport, to preserve these values, choose Profile → Save profile value. Once saved, profile values are associated with a profile and can be viewed by double clicking on the column Value in the Profile selection screen.

n SAP delivers all necessary profiles to be used by a client copy or a client transport. In the Appendix of this chapter you find detailed information about the kind of data handled by the various profiles.

n Since Rel. 4.5 activity groups are also copied with the user master records using the profile SAP_USER.

SAP AG 1999

CustomizingCustomizingdatadata

Customizing andCustomizing andapplication dataapplication data

10000 Tables10000 Tables500 - 800 MB500 - 800 MB

> 16000 Tables> 16000 Tables>> 5 GB>> 5 GB

l Runtime (multiple hours):

n Run as a background task

n Run using parallel processes

n Restart possible

l Data consistency:

n Logon prohibited in targetclient

n Logon not recommended insource client

l Database space:

n 500-800 MB for Customizing

n GBs for master andapplication data

n Database analysis in testmode (Informix, Oracle, DB2,SAP DB)

System Requirements

Customizing client Production client

Targetclient

n Use background processing for client copies, since, depending on the profile used during a client copy, the client copy may take several hours.

n As of Release 4.6A, the time required for a client copy is much quicker due to parallel processing.

n To ensure data consistency in the target client, users (except for SAP* and DDIC) cannot log on to the target client during copying. Similarly, no one should work in the source client during client copying.

n When you start a client copy, take into account runtime restrictions and database space:

n The maximum online runtime (parameter max_wp_run_time) must be longer than the time needed to copy the largest table.

n To test whether there is sufficient database space, perform a test client copy, either as a simulation or as a considerably faster resource check; the resulting display shows the database memory requirements (for ORACLE, INFORMIX, SAP DB and DB2/6000).

n On how to copy large production clients, see SAP Note 67205 in the SAPNet

SAP AG 1999

Client Copy Using Parallel Processing

RFC Group

Clientcopy

Applicationserver

Applicationserver

Tables1..10

Tables11..20

Tables21..30

Tables31..40

Tables41..50

Applicationserver

LegendDialog process for parallel processing:

Free Dialog process:QAS

n The client copy functionality can now be used with multiple parallel processing, which speeds up the copying process. Other factors that should be taken into consideration to optimize a client copy include the network performance and the database performance.

n The client copy processes are generated at runtime. They are paralle l RFC processes, managed by server groups. You must specify the maximum number of processes you want to use in the client copy program. Parallel processing can only be used when performing a local or remote client copy, it cannot be used for client transports.

n To specify the maximum number of client copy processes, use Tools → Administration → Administration → Client Administration → Client Copy → Local or Remote Copy → Goto → Parallel processes. Alternatively, use Transaction SCCL for a local copy, or Transaction SCC9 for a remote copy.

n To define a server group, use Tools → Administration → Administration → Network → RFC destination → RFC → RFC Groups. For RFC groups, the limitations on the system parameters are explained in SAP Note 99284 in SAPNet.

n During the execution of client copy using parallel processing, each parallel process checks the other to see if it is still running. If a process has failed it will automatically be restarted by the checking process.

n Note: The value for the parameter "rdisp/max_wprun_time" should be increased; the recommended value is 1800 seconds.

SAP AG 1999

ClientClientcopycopy

l Select target client

l Select run

l Monitor copyprocess

l Show control info

l Show full tabledetails

Status

Data

Copy Logs and Control Information

Client Copy Log Analysis

Target Runs Last date Status100 5 082399 ok

Transport directorylogs

Targetclient

Sourceclient

n To display all log files for a completed local or remote client copy, from the R/3 initial screen choose Tools → Administration → Administration → Client admin. → Client Transport → Copy Logs. Select the relevant target client and the relevant copying process. These copy logs provide:

� Table statistics

� Control information

� Information about each table copied, including the link to the appropriate IMG component

n To display client transport logs, use the Transport Organizer (Transaction SE01).

n Technically, copy log information is located in the view V_CCCFLOW. This view contains, for example, the runtime and processing status of a local client copy, the number of already copied tables, and the name of the table being currently copied.

n All log files are physically stored in the transport log directory at operating system level. Log files are named CC<number>.<SID> , where <number> is the serial client copy number, and <SID> is the source system ID.

n If copying is unexpectedly terminated, the system uses the name of the table being currently copied to restart the copy process.

SAP AG 1999

Client Copy Log Analysis

100 5 070692 error

Target

Runs

LastDate

Status

System Log System Log

System Log

Time Ta User Tcod C Text17:43:31 W3 Miller W Table logging turned off17.43:48 B3 Miller K <CLIENT COPY error message>

l Verify that databaseresources aresufficient

lRestart a terminatedrun if necessary

lCheck tables usingdatabase utility orSQL tools

l Tables not indevelopment class$TMP?

Target Runs Last date Status

Client Copy: Monitoring and Troubleshooting

n When performing client copy error analysis, check not only the copy log, but also the system log, which tells you whether database problems are responsible for the client copy error. Correct any database problems before restarting the client copy.

n When a client copy run terminates abnormally, the Restart option is proposed by default, which continues the run from the point at which it terminated. If the original run was recent, as indicated by the status line, it is advisable to choose Restart. Alternatively, to start the run from the beginning, choose Restart <-> New start.

n To avoid the problem of insufficient free space in the database, perform a simulation test run or a resource check.

n A simulation test run estimates the space required by reading all records to be copied without updating them in the database.

n A resource check estimates the space required by counting the records to be copied.

n Client copies ignore tables in the local development class $TMP. If you want to copy these tables, modify the development class in the object directory.

n If, when checking the copy log or the system log, you notice problems with user exits delivered by SAP, contact the SAP Hotline.

n On error analysis with client copy tools, see also SAP Notes 22514 and 69444 in SAPNet.

SAP AG 1999

Deleting a client:

l Use background processing

l What is deleted:

n DATA

n SAPSCRIPT

n BATCH INPUT

Client DeleteClient Delete

Delete online Background

Test run

Delete entry from T000

Delete client

Client to be deleted

Client Delete

n To delete a client from within R/3:

� Log on to the client to be deleted.

� Use the menu option use Transaction code SCC5 or from the R/3 initial screen choose Tools → Administration → Administration → Client admin → Special functions → Delete client.

� Start the deletion of the client, preferably using background processing.

� When you delete a client entry from table T000 with client maintenance (Transaction SCC4), you can no longer log on to the client or update it using change requests. The deletion process, however, does not eliminate the data belong to the client. This means the client-dependent data remains in your R/3 System, occupying space in the database. Therefore, to eliminate an R/3 client entirely, that is, to delete both the client and the client-dependent data, use the client delete functionality (Transaction SCC5).

n Deleting a client entry with client maintenance (Transaction SCC4) allows you to temporarily lock the client. The deletion procedure preserves the data for the client but prevents users from logging on to the client or accessing the data belonging to the client. To restore the client and allow logon, recreate the client entry using client maintenance.

n The amount of time required for the deletion of a client can be reduced by performing the deletion using parallel processes.

SAP AG 1999

R/3 Repository


Logon system

Appl.data

Use

r

Customizing

Appl.data

Use

r

Customizing

MASTCross-client Customizing

…..

Comparison system

Appl.data

Use

r

Customizing

R/3 Repository

Logon clientReference client Comparison client

RFC RFC

Compare

RFC

Compare

Compare

Client Compare

n When several R/3 Systems and clients are being implemented, it may be necessary to compare and adjust Customizing settings between different systems and clients. The Compare function enables you to compare and adjust the contents of a table or view in two different clients, using RFC connections.

n To use the Compare function, from the R/3 initial screen choose Tools → Administration → Administration → Client admin. → Customizing Organizer → Cross-System Viewer.

n Use Compare for example, to:

� Compare a client with a reference client, such as a customer owned client or the SAP client 000. This is especially useful after an upgrade or language import, since only client 000 is provided with data from tables belonging to table delivery class C.

� Compare clients during a rollout scenario. For example, if subsidiaries wish to adjust their Customizing with respect to the reference Customizing of a master client.

� Compare cross-client Customizing before combining different clients into one R/3 system (in a roll in scenario). For example, if subsidiaries wish to receive Customizing changes from the reference, master client of their parent organization.

SAP AG 1999

Transaction SCU0Transaction SCU0

l Objects

l Differences

l Table entries

Transaction SCU0 lists:

Client Compare: Selection Options

n To select the objects to be compared in a client compare, you can use a project oriented approach utilizing the IMG to define the objects, or select from application components, Customizing object list or change request, or select the objects manually.

n To start a client compare, use Transaction SCU0 in background processing. From the initial screen, select the component and choose Create. In the dialog box or boxes that appear, make the appropriate entries. SCU0 can be restricted to, for example, client-dependent data.

n Transaction SCU0 first displays an overview of the tables belonging to views for the selected IMG, application component or request. Next, the comparison itself is performed. The system creates a list of differences and indicates whether these differences are encountered in the table structure or in the table content.

n To display the differing table entries, select an object. This enables you to perform a detailed comparison.

n The comparison client is generally an external environment, so you must access it through a remote function call (RFC). On how to use an RFC call, in the selection dialog box for the RFC destination choose Info.

n On client Compares, see also SAP Note 91096 in SAPNet.

SAP AG 1999

Selection type: Manually Filter: Active Comparison run: 0000000019Logon system: Comparison system:DEV/300/46A <-> QAS/200/46A Last action: 08/24/1999

Selection type: Manually Filter: Active Comparison run: 0000000019Logon system: Comparison system:DEV/300/46A <-> QAS/200/46A Last action: 08/24/1999

V_TVKO V Sales org. 7 6 0 0 SD-SLS

Object orsubobject

Descrip-tion

Comp. Entriesinlogonsystemtotal

Entriesonly inlogonsystem

Entrieschanged

Entriesonly incomp-arisonsystem

Comp-

onent

Client Compare: Difference List

TransactionSCU0

Comparison StatusProcessing Status

n The results of each comparison run is an overview of existing differences between the logon client and the comparison client. This overview serves as a starting point for subsequent processing of differences. The comparison runs are stored in a worklist or difference list.

n For each compared object in a comparison run, the objects compared are listed along with a description. The most important information are the status indicators. The comparison status indicates the existence and nature of any differences and is set automatically.

n Process status allows you to distinguish between the objects which have already been processed, that is, have been made identical in both clients, and those which have not. This kind of processing is also called "adjusting" the respective object. The processing status is indicated by a traffic light, where red indicates not processed, yellow indicates the objects in both clients are in the process of being made identical, and green indicates the completion of this adjustment process.

n An explanation of the possible statuses under comparison status and process status can be obtained by clicking the Legend icon.

n For a detailed analyzes of a comparison run, choose Comparison.

SAP AG 1999

Adjusting Customizing Objects

S001 Sales org 001 DEM ………..



SOrg. Name Curr Address

S004 Sales org 004 DEM .………..

R

R

R

R

Comparison status

l Adjustment ofIndividual objectswith SCU0:

n Generates detailedinformation inworklist

n For certain recordsthat can bemaintained inSM30

n Displays acomparison statusfor each record inworklist

n To understand thecomparison status,choose the Legendicon

View: V_TVKOLogon system: Comparison system: DEV/300/46A <-> QAS/200/46A Last action: 08/24/1999

n Adjusting the objects revealed by a Compare means making them identical or partly identical in both clients. As of R/3 release 4.5, adjustments can be made using the same tool that was used to perform the Compare, that is, the Cross-System Viewer (Transaction code SCU0).

n You can adjust one object at a time. The objects that can be adjusted are some of the tables and views that can be maintained using Transaction SM30. All other objects can only be compared. For more information on the adjustability criteria, see SAP Online Documentation under Basis Components → Customizing → BC - Generate Table Maintenance Dialogue → Create a maintenance dialog → maintaining and changing an existing table maintenance dialog → Technical background → Adjustability criteria from Release 4.5B.

n To perform an adjustment, from the Comparison screen choose choose Edit → Interact copy. The Overview Adjustment screen is displayed, showing the details of the differences between the two clients, record by record. To the left of each record in this adjustment worklist is the comparison status, which indicates whether or not each respective entry in the record exists in the comparison client and the logon client.

n An explanation of the possible statuses under comparison status and process status can be obtained by clicking the Legend icon.

SAP AG 1999

Client Maintenance Settings

Protection reg. client copy / comparison

Description

Protection level 0: No restriction

Protection level 1: No overwriting

Protection level 2: No overwriting, no external availability

l Set client option: Protection regarding clientcopy/comparison

l Default value is: No restriction

n The client option Protection regarding client copy/comparison can be set to prevent a client from being overwritten by the client copy or client compare/adjustment. It can also be set to ensure that sensitive data is not viewable from another client during a client compare.

n To set this option, from the R/3 initial screen choose Tools → Administration → Administration → Client admin. → Client maintenance. You can select:

� Protection level 1: No overwriting This ensures that the client cannot be overwritten by the client copy program. This setting should be used if Customizing is being performed in this client or the client contains critical settings or data that should not be overwritten.

� Protection level 2: No overwriting and no external availability This also protects the client against overwriting and against read access from another client during a client copy or Customizing comparison. This setting should be used if the client contains sensitive data. All production clients should use this setting.

n To set the option Protection regarding client copy/comparison, you need the full authorization for the Workbench Organizer (authorization S_CTS_ADMIN).

SAP AG 1999

Authorization Objects for Client Tools

S_TABU_CLI: Cross-client table maintenance

S_TABU_DIS: Generic table maintenance

S_CLNT_IMP: Data import during client copy

S_DATASET: File access

S_USER_PRO: Profile maintenance

S_USER_GRP: User groups

S_TRANSPRT: Change and Transport Organizer

S_TABU_RFC: RFC access to tables

n To perform a client copy or transport, you need the appropriate authorizations:

� S_TABU_CLI allows you to maintain cross-client tables.

� S_TABU_DIS allows you to maintain table V_CCCFLOW.

� S_CLIENT_IMP allows data import when performing a client copy.

� S_DATASET_ALL allows you to write logs to the file system.

� S_TABU_RFC allows client comparison and copy: Data Export with RFC

n To copy user profiles or user master records, you need the following authorizations:

� S_USER_PRO for user profiles

� S_USER_GRP for user master records

n If you want to export a client, or if you want to copy object lists between two clients, you need the transport authorization S_TRNSPRT. This allows you to use the Workbench Organizer, the Customizing Organizer, and the Transport Organizer.

SAP AG 1999



l Explain and differentiate between client copy tools

l Identify and remedy error situations

l Use the log information to identify and solve errorsituations

l Perform a client delete and a client compare

SAP AG 1999

Appendix: SAP Standard Client Copy Profiles

SAP_USER X SAP_CUST X XSAP_UCUS X X XSAP_UAPP X X X XSAP_ALL X X X X XSAP_CUSV X X XSAP_UCSV X X X XSAP_EXBC* X X X X XSAP_EXPA* X X X X X XSAP_EXPC* X X X X

User Custo- Master & Initialize Var- Client-indep.Master mizing trans. data & Recreate iants Tables

* Client transport profile only.

n For all typical client copy scenarios, SAP provides profiles affecting various kinds of data in the R/3 system and using various copy functions (as shown above).

n In the Client Copy environment, master and transaction data are commonly known as application data.

SAP AG 1999

Table delivery classes:A Application table (master and transaction data)

C Customizing table, maintenance only by customer, not SAP import

L Table for storing temporary data, delivered empty

G Customizing table, protected against SAP update, only INS all

E Control table, SAP and customer have separate key areas

S System table, maintenance only by SAP, change = modification

W System table, contents transportable through separate TR objects

These classes affect:l Client copy within a system (client specific tables only)

l Client copy between systems

l Transports from SAP systems to customer systems

l Transports between customer systems

Table delivery classes:A Application table (master and transaction data)

C Customizing table, maintenance only by customer, not SAP import

L Table for storing temporary data, delivered empty

G Customizing table, protected against SAP update, only INS all

E Control table, SAP and customer have separate key areas

S System table, maintenance only by SAP, change = modification

W System table, contents transportable through separate TR objects

These classes affect:l Client copy within a system (client specific tables only)

l Client copy between systems

l Transports from SAP systems to customer systems

l Transports between customer systems

Appendix: Table Delivery Classes

n To understand the effect of table delivery classes during upgrading, transport, or client copy, especially if there are development projects that create new tables, see:

� R/3 Online Documentation: From the R/3 initial screen, choose Help → SAP Library → BC - Basis Components → ABAP Workbench → BC ABAP Dictionary.

� SAP Note 2857

n Table delivery classes are assigned to tables as follows:

� In general tables containing application data should have delivery class A.

� Tables containing Customizing data have different delivery classes, depending on how SAP changes the Customizing settings in them.

� Delivery class C may not contain new entries from SAP.

� Delivery class G may be changed by SAP.

� Delivery classes S, E, and W are for tables containing control and R/3 System data, such as tables TADIR, VARI, TSTC, and CCCEXIT.

� Delivery class L is for tables for temporary data such as spool data and background processing data, for example, tables TSP* and TBT*.

SAP AG 1999


l SAP Notes:

n 70128

n 70547

n 47502

n 22514

n 99502

n 91096

l Appendix: Table Delivery Classes

SAP AG 1999

l Do the exercises?


Unit Actions

Client Tools : Exercises

No. Exercise

1 Create your own sandbox client in the development system.

1.1 Log on to the Customizing client 300 as project leader. Using the client maintenance tool, create a new client in the development system. Assign the number 3## to your client, where ## is the number assigned to your group.

1.2 Log on to the newly created client 3##.

1.3 Set the correct client change options for your sandbox client. This client is for client-specific changes only.

1.4 From within client 3##, execute a job that creates a sandbox client by copying all user master records from client 300. Only copy user master records. Schedule the client copy to run immediately, in the background.

1.5 Monitor the client copy. After completion of the client copy, review the log files.

2 Comparing the contents of one client with another and make adjustments in order to synchronize two clients.

2.1 What data does your new client 3## contain?

2.2 Test whether the client copy in the pervious exercise was successful. Log on to client 3## in the development system as project team leader.

2.3 During Customizing, you and the other project teams made changes to basic functions for sales and distribution. For example, you created a distribution channel and a sales group (as did other users). These changes to different Customizing settings were recorded to a change request and transported.

Using the Cross System Viewer, compare the changes that were recorded in your Customizing change request in client 300 and client 3##.

2.4 What are the differences between client 300 and client 3## with regards to distribution channels and sales group data?

2.5 Copy your sales group S## from client 300 to client 3## using the adjust functionality.

2.6 To perform a client compare, the client 300 and client 3## need special client maintenance setting. What are the appropriate settings for these clients?

3 Copy a client from the development system to the quality assurance system.

3.1 What tools exist for copying a client from one R/3 System to another R/3 System? What are the advantages and disadvantages of the different methods?

3.2 What steps are required to perform a client transport of all Customizing settings and Customizing objects from a client on the development system to a client in the quality assurance system? (Do not perform the client transport; simply list the steps.)

3.3 In the quality assurance system, log on to the quality assurance client as project leader.

3.4 Using the client maintenance tool, create a new client in the quality assurance system. Assign number 3## to your client, where ## is the number assigned to your group.

3.5 In the quality assurance system, log on to the newly created client 3##.

3.6 To transfer the user master records from client 300 in the development system to client 3## in the quality assurance system, perform a remote client copy using the RFC connection DEV_300. Copy only user master records.

3.7 Review the results of the remote client copy.

Client Tools: Solutions

No. Solution

1

1.1 To create and set up a new client, from the R/3 initial screen, choose Tools → Administration → Administration → Client Administration → Client Maintenance. Choose Table/view → Display<->Change to switch to change mode. To create a new client, choose New entries (or choose Edit → New entries).

Complete the entries required to create client 3##. Choose Save.

1.2 By default, the new client contains only the user SAP* with the default password PASS.

1.3 From the R/3 initial screen, choose Tools → Administration → Administration → Client admin. → Client maintenance. Set the new test client's change options to No transports allowed and No changes to Repository and cross-client custom. objects.

1.4 To perform the client copy, from the R/3 initial screen choose Tools → Administration → Administration → Client administration → Client copy → Local copy.

Select profile SAP_USER and client 300 for the source client and source for user master records. To perform the client copy in the background, choose Schedule as a background job. Choose Schedule job. The dialog box Verification is displayed. Ensure that only user master records are copied, and choose Continue. In the dialog box Start time, choose Immediate and then Save. You will be prompted for a printer. Choose Continue. Pass the printer warning. The client copy will begin in the background.

Note: If you do not specify the client that is the source of user master records, by default, the client copy uses client 000.

1.5 To view all client copy logs for past and present jobs, from the R/3 initial screen choose Tools → Administration → Administration → Client administration → Copy logs. Select client 3## and drill down on the log files for more detail. To see exactly what tables and how many entries were copied choose Detail.

2

2.1 Because the client was created as a client copy of user master records only, client 3## does not contain any Customizing or application data. It does not contain any SAP reference data. This client only knows who can log on and the assigned authorizations.

2.2 Log on to client 3## as LEAD-## with the password you use in client 300.

2.3 To access different compare methods, choose Tools → Administration → Administration → Client administration → Customizing objects → Cross system viewer.

To compare the objects recorded in a change request, choose the option Customizing piece list/transport. To create a new comparison run, choose Create. In the dialog box Selection by: Transport Request, provide the

change request that contains the Customizing changes you wish to compare – this is the Customizing change request to which you recorded your distribution channel and sales group. You can use F4 to help locate the released change request.

After providing a valid change request, choose Continue. A sequential number is assigned to your comparison run. Make note of this number. Provide a description for the comparison and the RFC connection DEV_300. To start the comparison, choose Total comparison. Because an RFC connection is being used and this connection does not have log on information, you must log onto client 300 on DEV with your account LEAD-##. After successful log on to client 300, the comparison will take place.

2.4 Because client 3## contains no Customizing data, the sales group and distribution channel you created in client 300 do not exist in client 3##. From the Customizing Cross-System Viewer: Change Mode screen you see to the right that the entries are only in the comparison system – in other words, client 300 in DEV.

To see the actual entry, mark the table view you wish to detail and choose Comparison. For example, mark V_TVKGR and choose Comparison. After a RFC login screen the Overview: Comparison screen appears and you see the sales group you created in client 300 (as well as other sales group entries). Use Utilities → Legend to see that the “R” represents that the sales group only exists in the comparison client. Choose Back to return to the Cross-System Viewer: Change mode screen.

2.5 To perform an adjustment between two clients, from the Cross-System Viewer: Change Mode screen select the view V_TVKGR and choose Edit → Interact. copy.

Mark your sales group and choose Adjust. The Detail View: Adjust screen appears. At this time you can choose to adjust the entire entry, just a given field, or all entries. Choose Copy entry to adjust this one entry. Choose Back to return to the Overview: Adjustment screen. Note that the entries are now identical in both clients. Choose Save to save your change. Confirm the dialog box Update individual status with yes.

2.6 To ensure that Customizing changes from another client are not mistakenly copied from another client, the client change setting for client 300 should be at least Protection level 1. As client 3## is simply a sandbox client, you can use the default client maintenance setting of Protection level 0. To see a client’s protection level, use Tools → Administration → Administration → Client Administration → Client maintenance.

3

3.1 To copy a client from one R/3 System to another, you can use either a remote client copy or a client transport. A remote client copy uses RFC technology to communicate directly with the target client. A client transport means exporting the source client to the operating system level and then importing the client to the target client. Like a remote client copy, a client transport can copy cross-client data. As well, a client transport provides you with a "copy" of the client at the operating system level. This allows the client to be imported to more than one client or to be imported again at a later date. When determining the method used to copy the client, consider your network and system resources. A remote client copy requires a stable connection

between R/3 Systems. A client transport may require considerably more than 2 GB of disk space.

3.2 A client transport involves the following activities:

If the target client does not exist within the quality assurance system, log on to the quality assurance system and create the target client.

Log on to the source client in the development system. From the R/3 initial screen, choose Tools → Administration → Administration → Client administration → Client transport → Client export. To transport client- specific and cross-client data, select the profile SAP_EXPC. For the target system, supply the system ID for the quality assurance system. Start the client export in background processing as it may take some time.

After the client export is completed, there are potentially 3 change requests in the import queue of the quality assurance system – one for cross-client changes, one for client-specific data and another for special objects. Use the TMS to import the request into the target client – TMS will see that all requests are imported together.

After the import of the client export, in the quality assurance system you need to perform post-import steps. Log on to the target client for which the client import was issued. To perform the final steps of the import, choose Tools → Administration → Administration → Client administration → Client transport → Import editing. You will be prompted to perform process for the imported client. Choose Execute.

3.3 Log on to client 300 on QAS using your account LEAD-##.

3.4 To create and set up a new client, from the R/3 initial screen choose Tools → Administration → Administration → Client administration → Client maintenance.

To switch to change mode, choose Display/Change. To create a new client, choose New entries (or choose Edit → New entries). Enter the information required to create client 3##. Choose Save.

3.5 The new client in QAS contains by default only the user SAP* with a default password of PASS.

3.6 To begin the remote client copy, choose Tools → Administration → Administration → Client administration → Client copy → Remote copy.

Select the copy profile SAP_USER and provide the RFC connection DEV_300. To begin the client copy, choose Start immediately. The dialog box Verification is displayed. Ensure that only user master records are copied, and choose Continue.

3.7 To view all client copy logs for past and present jobs, from the R/3 initial screen choose Tools → Administration → Administration → Client Administration → Copy logs. Select client 3## and drill down in the log files for more detail. To see exactly what tables and how many entries were copied, choose Detail.

SAP AG 1999








OCS Patches and R/3 Upgrades

SAP AG 1999

OCS Patches and R/3 Upgrades

Contentsl The SAP Online Correction Support (OCS)l Planning an R/3 upgrade for your system landscape

l Performing an R/3 upgrade and modification adjustments

ObjectivesAt the end of this unit, you will be able to:l Understand the SAP Software Components Model

l Apply OCS patches to your system landscape

l Plan an R/3 upgrade for your system landscapel Perform an upgrade and use Transactions SPDD and SPAU for

modification adjustmentsl Explain different ways of avoiding

modifications

SAP AG 1999

Going livewith R/3

Support, Customizing and development

R/3 ReleaseUpgrade

Support Packages

Evolution of an R/3 Production System

n The evolution of a typical production R/3 System is marked by:

� Changes to Customizing and new development

� The application of patches from SAP's Online Correction Support (OCS)

� Upgrades to newer R/3 Releases

SAP AG 1999

Controlled AvailabilityControlled

Availability


Availability

General Availability



Availability



Release and subsequentpatches shippedto all customers


General Availability. . .

I/1 I/2 I/3 . . . I/n patches

. . .

A/1 A/2 A/3 . . . . A/n patches

. . .

A/1 A/2 A/3 . . . . A/n

. . .

A/1 A/2 . . . A/n

. . .

. . .

. . .





Shipped on request only

Shipped on request only

Release

R/3 Release Strategy

3.1I

4.0A

4.0B

4.5A

4.5B

4.6A

4.6B

Release

n R/3 Functional Releases, such as R/3 Release 4.5A and 4.6A:

� Provide new functionality

� Receive only limited OCS maintenance. Only very urgent corrections to functional releases are made available in Support Packages

n The R/3 Functional Release roll-out begins with a First Customer Shipment (FCS). Only a limited number of customers receive the FCS. During this phase, productive use of the R/3 System is not allowed. After receiving feedback from customers, SAP will ship FCS Final Delta Patches (FFDP). The next phase for a Functional Release is a Controlled Availability (CA) shipment, which is available to every customer who requests it. Customers can use a CA shipment for production after agreement with SAP. SAP normally offers a Correction Release after each functional release.

n R/3 Correction Releases such as R/3 Release 4.5B and 4.6B:

� Provide only corrections and no new functionality

� Receive full OCS maintenance

n The R/3 Correction Release receives the status of General Availability (GA) when customers are able to use the system for production without limitations. The general shipment phases follows shortly after the GA. In this phase, the release will be automatically sent to all R/3 customers with a valid support contract. A correction release is SAP's recommended release for production use.

SAP AG 1999

OCS: Hierarchy of SAP Software Components

BASIS (Basis)BASIS (Basis)

ABA (Cross application)ABA (Cross application)

HR (Human Resources)

HR (Human Resources)

APPL(Core applications

w/o HR)

APPL(Core applications

w/o HR)

Plug-InsPlug-Ins IBUAdd-On

IBUAdd-On

CRM(Customer

Relationship Management)

CRM(Customer

Relationship Management)

BW(Business

Warehouse)

BW(Business

Warehouse)

SEMSEM APOAPO BBPBBP

CRT

n The new Support Package model is based on SAP's new Software Components model.

n The objects of a software component correspond to a number of development classes that are unique for that component. This enables each software component to be provided with patches.

n The hierarchy in the diagram shows the dependencies between SAP's software components. SAP tries to minimize these dependencies. The Patch Manager recognizes these dependencies and determines which patches are required for further components.

n Conflict Resolution Transports (CRTs) supply adapted objects to resolve conflicts between R/3 and SAP add-ons. These dependencies are also recognized by the SAP Patch Manager automatically. The CRTs are requested to be applied to the system in the same step as the add-on Support Packages that causes the conflict.

SAP AG 1999

Online Correction Support (OCS)

R/3 Support Package (APPL)

Application Interface Support Package (ABA)

R/3 HR Support Package (HR)

Basis Support Package (Basis)

APO Support Package

Product and Support Packages (New dimension products)

BW Support Package

B2B Support Package

Add On Support Package

Basis FCS Support Package

SPAM Update

Conflict Resolution Transport

SAP Support Packages

Component Support Packages

n Online Correction Support (OCS) comprises tools and standard advance corrections called Support Packages. A Support Package eliminates an error in an R/3 System. It is made available before the next R/3 Release that contains the correction. A Support package replaces the objects affected by the error, rendering their old versions obsolete. OCS makes Support Packages available to all customers and enables them to apply them before the errors can affect a system. Thus OCS provides preventive support. Unlike manual corrections, OCS patches are not recognized as modifications during upgrade and are overwritten. This is no problem, as each new R/3 Release contains all previous OCS corrections which were made before the new R/3 Release was built.

n With R/3 Release 4.6, SAP introduces a new nomenclature for the OCS based on the new Software Components concept. The former Hot Packages are replaced by Support Packages. Whereas Hot Packages covered the area corresponding to the current software component types ABA, APPL and BASIS, each Support Package covers only one software component type. Support Packages:

� Contain full patches, that is, patches for ABAP Dictionary objects and Repository objects

� Apply to a single R/3 Release, but are not operating-system specific or database specific

� Are named according to the form: "SAPK<Patch type><Release no.><serial no.>". They are applied in order of serial number. New patch types introduced by SAP will follow a new 20 digit naming convention.

� Technically correspond to an upgrade, that is, require modification adjustments using Transactions SPDD and SPAU.

SAP AG 1999

SPAM

SAP Patch Manager (Transaction SPAM)

l SPAM is used to apply patches supplied by OCS

l SPAM's Patch queue processing:

n Ensures correct sequencing of patches including the application of Conflict Resolution Transports (CRT)

n Enables you to apply more than one patch at a time

n Provides restart capabilities after failures

l SPAM protects both customer modifications of SAP objects and SAP add-ons

n To apply Support Packages, use the SAP Patch Manager (Transaction SPAM) in R/3 client 000, which is the interface between the customer's system and the OCS.

SAP AG 1999

111

333

222222

333

111 Request patch fromSAPNet

Get patch from SAPNetvia download or PatchCollection CD

Use SPAM tol Define patch queuel Select SPAM settingl Apply patch queue to

the R/3 Systeml Perform adjustments

(if necessary)l Verify generated logsl Confirm the patch

queue

Test and validate result

TransactionSPAM

444444

SAPNet

Applying Support Packages

PatchCollection CD

Transport directoryEPS

n To apply a Support Package, request it from SAPNet.

n To download the Support Package from SAPNet, use Transaction SPAM in the customer's R/3 System.

n The SAP Patch Manager lets you apply the Support Packages in the correct order by creating a patch queue. You must confirm each successive Patch queue before the next one can be set up.

n To simplify implementation, Support Packages are periodically grouped together in Collections and sent to customers on a single CD.

SAP AG 1999

DEV QAS PRD

OCS Patch OCS Patch OCS Patch

SPAUchangerequest

111

333

444

666

999

777

Applying Patches in a Three-System Landscape

PerformSPDD

PerformSPDD

PerformSPDD

888555222

n When applying patches, you may need to perform modification adjustments using Transactions SPDD and SPAU. Modifications to ABAP Dictionary objects that are adjusted with SPDD can currently be included in a change request but cannot be used for automatic adjustment during SPDD in the subsequent systems. Thus, the SPDD adjustment has to be repeated manually on each system in the system landscape.

n Note that the enhancement concept covers also append structures for ABAP Dictionary objects that are not recognized as modifications. Modification adjustment to Repository objects performed with SPAU can be included in appropriate change requests.

n To determine in advance whether a modification adjustment is necessary, perform a test import using the test scenario ‘T’ in the SAP Patch Manager.

n After the patches have been applied to the development system, they can be applied to the quality assurance system and subsequently to the production system. After patch application (not before), import the SPAU adjustments created in the development system using the change requests.

SAP AG 1999

l Verify the need for the correctionbefore applying the SAP Note

l Document your changes, the SAPNote number, and releasedependencies, set CTS attributes tothe change request

l Apply the correction only in thedevelopment client in thedevelopment system

l Verify that the correction solved theproblem

l Distribute the correction to allsystems in the system landscapeusing the standard transport path

SAPSAP Note No. 139811 Note No. 139811

Symptom

Cause and preconditions

SolutionSupport Package not possible.

Source code correctionsREPORT UTIL02 LINE-SIQ 132TABLES: T681, TMC1T.

Manual Corrections Based on SAP Notes

n Alternatives to the SAP Patch Manager include:

� Modifying an SAP object with manual corrections based on SAP Notes from SAPNet.

� Downloading and importing a modification of an SAP object from FTP servers such as sapserv3, sapserv4, or sapserv5

n Prior to making any modification based on SAP Notes, verify that the SAP Note is applicable to your R/3 Release and that the symptoms in the SAP Note are the same as the symptoms apparent in your R/3 System. In the case of uncertainty, contact the SAP Hotline.

n All modifications of SAP objects should be performed in the development client, tested in the quality assurance client, and distributed to production clients only after thorough testing and verification.

n Because modifications lead to the need for a modification adjustment during R/3 Release upgrade or when applying an OCS patch, document the modification changes to help to speed up the modification adjustment process. When documenting, be sure to include the SAP Note number and R/3 Release dependencies.

n With Release 4.6 you can set attributes for change requests to help you identify them. For example, after setting appropriate attributes, you can identify which change request in the import queue contains a manual advance correction according to an SAP Note.

SAP AG 1999

Upgrade Project Overview

Hardware checkRun PREPAREInclude Support Packages for target releaseOS upgrade? (depends on R/3 release and platform)DB upgrade? (depends on R/3 release and platform)System downtimeUpgrade strategy

Planning

Performupgrade

Post-upgradeActivities

OS upgrade (if necessary)DB upgrade (if necessary)R/3 upgradeAdjust modifications DEVImport modifications QAS PRD

Check upgrade manual for platform-specific activitiesNew authorizations DEVImport new authorizations profiles QAS PRDBackup complete system and databaseUpgrade acceptance testing

Activity Upgrade project tasks Perform in allsystems unless noted

n In the standard three-system landscape, each of the systems is updated in the standard transport sequence. Tasks such as Customizing, applying patches, and performing modification adjustments are performed in the development system and transported to the quality assurance and production systems. The modification adjustments are performed with Transactions SPDD and SPAU.

n As described in the upgrade guideline documentation, mandatory tasks prior to an R/3 Release upgrade include verifying the OS version required for the upgrade, check if OS kernel parameters require adjustment, check relevant OSS notes, perform backups, possibly install new frontend software and delete redundant clients to reduce upgrade time.

n One of the most important pre-upgrade tasks is running PREPARE to automatically perform many important checks (see appendix of this unit). Run the PREPARE script as early as possible. It can be repeated as often as required before the actual upgrade is started.

� All available Support Packages should/must be included for the target release so they are integrated as part of the upgrade. They can be included in the BIND_PATCH phase of PREPARE.

n One of the most important tasks during upgrade is Post-upgrade tasks include:

� Perform a complete system and database backup

� Testing the new R/3 Release and possibly distributing new authorizations

� Customizing for the new R/3 Release

SAP AG 1999

System Upgrade Process

Initialization Data transfer ApplicationAdjustment

and Activation

Completion

Adjust Data DictionaryObjects withSPDD

UpgradedeterminesDDIC objectsto beadjusted

AdjustRepositoryObjects withSPAU

Old Release New Release

PREPARE

Include allavailableSupportPackages

R3up

n PREPARE automates many checks to prepare for the upgrade. The upgrade itself is performed by the R3up program. See Appendix for more details.

n Initialization repeats most of the PREPARE checks in case something recently changed in the system which would effect the upgrade, such as free space , open corrections, etc.

n The data-transfer segment of the upgrade transfers new R/3 Repository objects to the system from the shipped CDs. The new objects are compared them with objects in the customer system's Repository to identify customer-developed objects and modifications (SAP-developed objects that have been changed by the customer).

n All modifications that customers want to keep and whose corresponding objects in the new Release have also been changed by SAP must be merged with the new SAP object. This merging is known as modification adjustment. It is essential that adjustments to ABAP Dictionary objects are performed with transaction SPDD during the R/3 upgrade to avoid data loss.

n Different types of modification adjustment are positioned before and after the activation phase. The system is not available during the activation phase, which may take several hours. After activation, the new Repository objects and the new R/3 kernel are active.

n Repository objects are adjusted with transaction SPAU after completing the upgrade. You have a maximum of 14 days after completing the upgrade to execute transaction SPAU to adjust the repository objects without a key check.

n After upgrade, the R/3 System is successfully running at the new R/3 Release. Customer developed objects and modifications have been preserved.

SAP AG 1999

Pre-updateR/3 Repository

Customerobjects

Modification

Modification

SAP ObjectsSAP Objects

Modificationsare customer-

changedSAP objects

Upgrade

Preserving Customer Objects and Modifications

Changed by SAP

Changed by SAP

New R/3 Repository

SAP ObjectsSAP Objects

n At the heart of the upgrade is the Repository switch. First, a complete new Repository is set up in the customer's system and initially remains inactive. This requires temporary disk space which is freed up again once the switch is made, that is, after the new Repository has been activated and the old one deleted.

n An important aspect of an R/3 upgrade is preserving customer developments and modifications. Thus, during Repository switch, an old Repository containing such objects is not simply overwritten. To preserve these objects, customer objects are transferred to the new Repository and modifications are transferred to the corresponding new SAP objects and require modification adjustments.

n Modification adjustments are necessary only if both of the following conditions are met:

� The object corresponding to the modified object in the new Release has also been changed by SAP.

� The customer does not want to discard the modification (if the new SAP object already has the required functionality, for example, the customer no longer requires the modification)

n If the object corresponding to the modified object in the new Release has not been changed by SAP, the old object is retained by transferring it to the new Release.

SAP AG 1999

Versiondatabase

Modification

Modification

Customerobjects

Customerobjects

Changed by SAP

Modification

Changed by SAP

Pre-updateR/3 Repository New R/3 Repository

SAP objectsSAP objects SAP objectsSAP objects

SAP objects changed by

customer and by new Release

SAP objects changed by

customer but not by new

Release

All customerobjects

Preparing the Repository Switch

n To ensure that development work is not lost during the upgrade, the following will occur before the Repository switch:

� The SAP objects that were unchanged by SAP, but were changed by the customer, are added to the new R/3 Repository.

� All customer objects are added to the new R/3 Repository.

� All modifications whose corresponding objects in the new Release were changed by SAP are backed up to the version database. This enables them to be later used to adjust the new R/3 Release.

� Objects generated through Customizing are copied into the new Repository

� All inactive ABAP Dictionary object versions, documentation on customer developments, and local objects are transferred to the new Repository. After upgrade, these objects can be restored to their pre-upgrade state or compared with the current version and adjusted.

n As soon as these tasks have been performed, the Repository switch can occur.

SAP AG 1999

Versiondatabase Customer

objects

Modification

Modification

Customerobjects

Changed by SAP

Modification

Customerobjects

Changed by SAP

Modification

Changed by SAPSAPSAP Changed by SAP SAP objectsSAP objects

SAP objectsSAP objects

Switched R/3Repository

prior to activation

New R/3Repository

Performing the Repository Switch

n If the customer has no modified SAP objects or own developments, the Repository switch upgrade is a simple replacement of the existing Repository. This kind of upgrade is faster than if modification adjustments are required.

n Objects which have been modified by both the customer and SAP have been replaced by the new SAP version and are later adjusted to reincorporate the modifications.

n Note: Customer modifications to specific Repository objects such as background and spool objects, which are regarded as essential to the normal functioning of R/3, are lost in the upgrade.

SAP AG 1999

Transaction Transaction SPDDSPDD

• Domains

• Dataelements

• Tables

• Reports

• Menus

• Screens

• Views

• Lockobjects

If you omitusing SPDD

wherenecessary, yourisk data loss

Transaction Transaction SPAUSPAU

Different modifiedobjects requiredifferent transactionsfor modificationadjustment

For most ABAP Dictionary objects

For all other Repository objects

Modification Adjustment Transactions

n Transaction SPDD is use to perform modification adjustment to certain ABAP Dictionary objects such as domains, data elements, table structures, transparent tables, pooled tables, cluster tables, and table technical settings. Not performing modification adjustment for these objects would cause data loss.

n After activating the new Repository, Transaction SPAU is use to perform modification adjustment for objects for which omitting modification adjustment would NOT lead to data loss. These objects include:

� Some ABAP Dictionary objects (lock objects, matchcodes, and views)

� All other Repository objects (such as module pools, ABAP programs, function modules, menus, and screens)

� After running Transactions SPDD and SPAU , all modifications have been incorporated in the new R/3 Release.

n As of R/3 Release 4.0, pre-upgrade use of PREPARE to upgrade tools to check which modified objects need adjustment enables you to better plan the time required for using Transactions SPDD and SPAU.

SAP AG 1999

New SAP standard

Customer version

Compare

Return to SAPstandard

Adjust

Mark asProcessed

Modification Adjustment Process (1)

Mark asProcessed

Mark asProcessed

Mark asProcessed

Collected in one transport

Mark fortransport

n At the start of the adjustment process, R/3 Repository objects from the pre-upgrade Repository are compared with objects from the Repository of the new Release.

n For each object, Transactions SPDD and SPAU, will guide you through the adjustment process, offering you the alternative of performing modification adjustment or returning to the SAP standard. To assist you in organizing your work, as you work through the list of objects, mark each object as processed after you are finished with it.

n The adjusted objects are collected in a change request. Note, that there can be only one change request for SPDD adjustments and only one change request for SPAU adjustments.

n When all modified objects are marked as processed, you must mark the change request as being ready for export. By transporting the change request, you avoid needing to make the same adjustments again in each system. Ideally, all the systems in the landscape must contain identical modifications before the upgrade. This requirement is met, for example, if all modifications were created in the development system and were transported into all downstream systems before the upgrade.

SAP AG 1999

SPDDchange request

SPAUchange request

Perform modificationadjustments during thedevelopment system upgrade

Mark for transport

DEV QAS

R3upapplies theadjustmentsduring thetargetsystemupgrade

Upgrade: OCS and Modification Adjustment

SupportPackage

Integrate all available SupportPackages in the upgrade

Mark for transport

Transportdirectory

SupportPackageSupport

Package

n As of Release 4.6, the upgrade process includes the option of applying all Support Packages that are already available for the new R/3 Release. This enables you to avoid losing changes and data (especially for Dictionary objects) that correspond to patches you applied to the old Release, if these patches were created after the pressing of the CDs for the new Release. The Support Packages available for the new Release also contain the applicable changes in the patches created for the old Release. As of Release 4.6, during the upgrade PREPARE checks the patch level in the old Release and enables you to apply any relevant Support Packages.

n The respective change requests for SPDD adjustments and SPAU adjustments are transported automatically to the other R/3 Systems. This example shows the modification adjustment process for the quality assurance system, QAS.

n During the QAS upgrade, in the ADJUSTCHK phase, you are presented with the imported adjustments from the development system upgrade and decide whether to accept them. If you accept the imported adjustments, they are integrated into the current upgrade.

n A check is performed to find out whether all the modifications identified in the pre-upgrade QAS system are covered by the adjustments that were imported from the development system. If this is the case, no new adjustments need to be made for QAS using SPDD or SPAU.

SAP AG 1999

DEV QAS PRD

1

DEV QAS PRD

Pre-upgrade

R/3Release

NewR/3

Release

Upgrade and performmodificationadjustments

2

Upgrade orcopy PRD

and upgrade

3

Upgrade Transport

modificationadjustments

Transportmodificationadjustments

Upgrading a Three-System Landscape

n In a three-system landscape, upgrades are performed strictly in the order dictated by the transport path. Modification adjustments are performed during development system upgrade and transported to downstream systems along the transport path.

n The sequence of tasks in upgrading a three-system landscape is as follows:

� Upgrade DEV and perform modification adjustments in DEV

� Upgrade QAS or better, upgrade a copy of PRD; import modification adjustments into QAS and test and validate system functionality

� Upgrade PRD; import modification adjustments into PRD

n Numerous, complex modifications significantly increase the time required for a development system upgrade.

n Modification adjustments should be performed by developers and not by R/3 System administrators or technical consultants. The persons responsible for the modifications must be involved in and present during the upgrade process, and should examine the complete documentation for each modified object.

SAP AG 1999

Avoiding Modifications in Future Upgrades

SAP table_1 ZZCUST SAP table_1 ZZCUST

append structure

Upgrade:Add new field

+ =

PROGRAM B220MAIN MESSAGE-ID SE.TABLES SCOUR.

MODULE CLEAR_SCOUR OUTPUT. CLEAR SCOUR.ENDMODULE.

MODULE READ_SCOUR INPUT. SELECT SINGLE * FROM SCOUR CALL CUSTOMER FUNCTION ...

PROGRAM B220MAIN MESSAGE-ID SE.TABLES SCOUR.

MODULE CLEAR_SCOUR OUTPUT. CLEAR SCOUR.ENDMODULE.

MODULE READ_SCOUR INPUT. SELECT SINGLE * FROM SCOUR CALL CUSTOMER FUNCTION ...

Program exitProgram exit

ABAPprogram

Function moduleFunction moduleFunction module

Automaticupdate

l Use the Online Correction Support (OCS) to apply patchesautomatically

l Use SAP enhancements, for example:

n Append structures for ABAP dictionary objects

n User exits for R/3 Repository objects

n SAP recommends avoiding modifications as much as possible. When a customer changes the source code of a standard program, these changes can cause errors or have unwanted effects in other parts of the application. SAP can no longer guarantee that the system will run without serious errors. To avoid manually keying in corrections provided by SAP, use the OCS.

n With the SAP enhancement concept, consisting of user exits and append structures, you can enhance SAP objects without these enhancements being overwritten by future SAP developments. Thus, no modification adjustments are required when using these technologies.

n Append structures let you add fields to tables and structures in R/3 without changing the original ABAP Dictionary object. To ensure that append structures are protected against being overwritten when the system is upgraded, append structures should be located in the customer name range. After an upgrade, the new versions of the standard tables are imported into the system. When these are activated, the fields in the append structures are added to the new standard tables. Append structures cannot be added to pool tables, cluster tables, or tables with LONG RAW fields.

n User exits enable customers to avoid creating modifications in R/3 Repository objects. These user exits can be used to call up external, customer-developed programs. The source code of the SAP standard Release does not need to be changed, as the connected customer objects are located in the customer name range. The different types of user exits include: program exits (coding extensions enabling customer includes); menu exits (supplementary menu options); screen exits (additional screens); and field exits (customer programming of function modules, connected to a screen field – unlike the other user exit types, field exits do not need to be created by SAP).

SAP AG 1999



l Apply OCS patches to your system landscape

l Plan an R/3 upgrade for your system landscape

l Perform an upgrade and use Transactions SPDDand SPAU for modification adjustments

l Explain different ways of avoiding modifications

SAP AG 1999

Initialization ImportRepository

Analysis and

copying

Repositoryswitch

and dataadjustment

Importcontrol

data

Completionand

databasebackup

A_ON

A_SWITCH

Production Downtime

A_OFF

Downtime

Archiving OFF

Production Downtime

Archiving OFF

Appendix: Upgrade Planning Strategies

Production

n Prior to upgrade you need to decide how to perform logging dur ing a Repository switch upgrade. There are three alternative settings for logging:

� A_OFF: To save disk space, this setting deactivates logging for the entire upgrade period. This means the system cannot be used for normal business transactions, and requires offline backups before and after the upgrade.

� A_ON: This setting activates logging for the entire upgrade period. The system remains available for business transactions except during the activation phase for the new R/3 Repository. The disadvantage of this setting is that database logging requires several GB of disk space and therefore requires you to monitor the log space.

� A_SWITCH This setting lets you switch off logging during the activation phase for the new R/3 Repository, thereby saving disk space. An offline backup is required after the activation phase.

n A_SWITCH is the setting recommended by SAP.

n After A_OFF and A_SWITCH deactivate logging, the system must be backed up and so that, if required, it can be restored to that time (known as the synchronization point).

n See also upgrade guideline documentation.

SAP AG 1999

Central Instance HostUAGUI

UAGUI

UAGUI

Text I/O

Firewall

HTMLbrowser

DocumentationURL (HTTP)Observer

Observer

Administrator

Start

Read

R/3 Central Instance

R3up (PREPARE)

UA Server

Appendix: Planning with the Upgrade Assistant

n As of R/3 Release 4.0, a frontend called the Upgrade Assistant is available for the upgrade program R3up. This provides an alternative to the text-console user interface. The Upgrade Assistant is a distributed program consisting of one server component and several GUI components. The server component is the link between the upgrade control-program R3up and the GUIs of the Upgrade Assistant.

n The GUIs can be run on any other servers. From a GUI, you can log on to the server in two possible roles: the role of observer or the role of administrator. The observer role means you are only looking at, for example, the current status and error messages for the upgrade. The administrator role means you are controlling the upgrade, for example, to enter commands, or to start and stop the upgrade. Only one GUI can support the role of the administrator. However, the roles of the GUIs can be changed dynamically. Whether the GUIs are used for display or administration is controlled by passwords.

n The Upgrade Assistant can also be used for remote upgrades. The connection to R3up can additionally be protected by securing the network port.

n Both parts of the Upgrade Assistant, that is, both the server and the GUI, are implemented in JAVA and therefore require an appropriate runtime environment on the central R/3 host and on the hosts of the GUIs.

n The GUI can also be run on a JAVA-compatible browser. A browser is also used to access the relevant online documentation, which is in HTML format.

SAP AG 1999

General checks

Necessary checks for

conversions

Activationchecks

Optional checks for

conversions

Pre-processing

Overview ofPREPAREModules

Appendix: Upgrade Preparation with PREPARE (1)

Parameter input

ModificationSupport

Initialization

CD read

Import

n One of the most important parts of preparing an upgrade is using a check program known as PREPARE. It can be executed during production operation and should be executed as early as possible in the upgrade planning process. PREPARE can be repeated as often as required to account for any changes that occur during production operation of the system.

n All the actions performed by PREPARE are executed in phases that are combined into PREPARE modules. These modules are largely independent of one another and are processed in a fixed sequence. The PREPARE modules can be optional or mandatory, and can be executed individually. One major advantage of dividing the script into distinct modules is the separation of long-running and short-running checks. PREPARE can be started from the Upgrade Assistant. The results of the PREPARE checks are written to the file CHECKS.LOG in the upgrade subdirectory LOG. In case of errors, rerun PREPARE after removing the cause of the error. A pre-existing CHECKS.LOG will be overwritten.

n Once the upgrade is in progress using R3up, PREPARE cannot be used.

n PREPARE does not check all requirements for the upgrade. There are still manual checks that need to be performed. For detailed information on how to use the PREPARE modules, see the appropriate Release Upgrade guide.

SAP AG 1999

Update GUI software?

Only update needed clients?

Need for modif. adjustments?

Enough database/disk space?

Determine SAP objectslocked in repairs or requests

Which languages supported?

Any unconfirmed patches?

Does the user have all required operating system permissions,

and does the SAP* and DDICaccounts have proper

authorizations?

These checks must be performed by the personperforming the upgrade

Checked by PREPARE

/usr/sap/put/log/CHECKS.LOG

System backup OK?

Correct versions of database, operating system, R/3, and

R/3 kernel?

Relevant R/3 notes available?

Appendix: Upgrade Preparation with PREPARE (2)

n PREPARE performs checks to ensure, for example, that:

� You have the correct version of the operating system, the database, R/3, and R/3 kernel.

� There is sufficient disk space (for an R/3 Repository upgrade you temporarily need 4 GB to 6 GB of additional disk space)

� There are no open repairs in your R/3 System

� All applied Support packages have been confirmed.

� Whether the source Release contains patches that are more current than the version of the target release.

n Before an upgrade to R/3 Release 4.6, PREPARE imports upgrade tools to the database. Meanwhile, PREPARE can check which modifications require adjustment. This enables you to better plan the time required later for Transactions SPDD and SPAU.

n PREPARE also performs an extended free space check of the database. This check determines the free space in each table, independent of where it is stored. A dynamic variation of this check determines free space requirements as tables are processed.

n Pre-upgrade tasks not performed by PREPARE include performing backups, installing new frontend software, and deleting redundant clients to reduce upgrade time. In addition to these manual checks, to get the latest upgrade information, you must read all relevant R/3 notes for the upgrade.

SAP AG 1999

l Do the Exercises?


Unit Actions

OCS Patches and R/3 Upgrades: Exercises

No. Exercise

1 Applying two Support Packages to the development system as a class.

The objects imported by Support Packages SAPKH46B95 and SAPKH46B96 include the objects that have been changed during this course. The Support Packages have already been downloaded from OSS/SAPNet and are located in directory \\hostname\sapmnt\trans\EPS\in.

1.1 Call SAP Patch Manager and check the current patch status. Have SAP patches previously been applied? If so, which types of patches were applied?

1.2 Before applying Support Packages SAPKH46B95 and SAPKH46B96 they must be uploaded and a patch queue defined for them. The instructor will demonstrate this now.

Note: As SPAM administration can only be performed in client 000, the administrator imports the Support Packages to this client.

1.3 When applying the patches in the queue, the system checks if DDIC modification adjustments are necessary. If they are necessary, the system requires you to use Transaction SPDD to perform the adjustment or return to the SAP standard for table BC325X##. In this exercise, after uploading the required patches, the instructor chooses Call SPDD to display the objects to be adjusted and requests participants to adjust their objects individually.

When instructed, perform the modification adjustment and save your changes to the change request created by the instructor for SPDD adjustments. Accept the SAP proposal for modification adjustment. Activate the table and assign the retained modification to the change request for SPDD adjustment, which is provided by the instructor. Check if your modification adjustment was recorded to your task. Do not release your task.

(After all participants have completed the adjustment, the instructor returns to the SAP Patch Manager and activates the ABAP Dictionary.)

1.4 Some of the ABAP Repository objects included in the patch have been repaired in the system during previous exercises. This causes Transaction SPAM to stop for you to make a modification adjustment with Transaction SPAU. Check whether you want to keep the changes caused by previous repairs. Start Transaction SPAU and choose to return to the SAP standard. Save your changes to the change request for SPAU adjustment that is provided by the instructor. Check if your modification adjustment was recorded to your task. Do not release your task.

(After all participants have completed the adjustment, the instructor returns to the SAP Patch Manager and chooses Continue to conclude patch application.)

1.5 After having applied successfully the patches in the queue, the instructor checks the logs before confirming the patches. How does the instructor do this?

OCS Patches and R/3 Upgrades: Solutions

No. Solution

1

1.1 To access the SAP Patch Manager, use Transaction SPAM. In selection area Directory, choose Applied patches then choose Display. For detailed information about the applied patch types, position the cursor on the relevant patch type and choose F1.

1.2 Log on to client 000. To upload the patches from directory "…\EPS\in", choose Patch → Upload. Confirm the dialog box SPAM: Confirm upload by choosing Continue. To exit from screen SPAM: Upload Patches from Operating System, choose Back. To define a queue in the field Patch queue, in the SAP Patch Manager choose Display/define queue. In the screen Component Selection, select the component SAP_APPL. In the resulting screen, define the queue by marking the check box of the most recent patch that you wish to apply. Choose Enter to confirm the queue. The status for the queue for the component SAP_APPL is now displayed with a yellow traffic light beside the corresponding step prolog in the SPAM initial screen. To apply the patches, choose Patch → Import patch queue.

1.3 Log on to the development system as team member in client 300 and start Transaction SPDD

Expand the tree structure in the SPDD initial screen, and double click object BC325X##. An adjustment proposal is displayed. You must select either Edit or Accept. If you accept the proposal, this adds a new field (GEBJAHR) to the new version of the table in the patch. Assign your changes to the change request used for SPDD adjustments. To mark the table as completed, position the cursor on the object and choose Completed. For this exercise, do not choose Select for transport (this is a function intended for upgrades).To leave Transaction SPDD, choose Back. Use Transaction SE09 to check if your modification adjustment was recorded in your task.

If you exit before fully completing the SPDD procedure, you lose all changes made to ABAP Dictionary objects after activating the objects imported with the patch.

1.4 Log on to the development system as team member in client 300 and start Transaction SPAM. Although a message is displayed indicating that only display functions are possible in SPAM, you are allowed to perform modification adjustment with SPAM. To perform modification adjustment, choose Extras → Adjust modifications. The screen, Modification adjustment: Object selection is displayed. Select the objects to be adjusted by entering suitable select criteria. Expand the tree structure in the SPAU initial screen. To return to SAP Standard, mark the object and choose Modifications → Reset to original. If you want to retain the modification, click the traffic light beside object BC325X## in order to enter the adjustment process using the modification assistant. Choose the change request created by the instructor for the modification adjustment. In the modification assistant, both versions of the object (the new original delivered by SAP and the modified version) are displayed. After completing the adjustment, choose Save. The resulting dialog box Save original - End adjustment of program BC325X## asks you

whether all modifications have been compared. Choose Yes. The reports traffic light is replaced by a green checkmark to indicate that the adjustment process is complete. Use Transaction SE09 to check if your modification adjustment was recorded in your task.

If you want to discard the changes and thus return to the SAP standard, mark the objects by positioning the cursor on the relevant object in the tree, and choose Select subtree. Then choose Reset to original. Save your change to the change request for SPAU adjustment that was provided by the instructor. After this, the dialog box Reset object asks you to confirm that all selected objects can be reset. Choose Yes.

1.5 To check the logs, choose Queue logs (or use Shift+F8). If the imports were successfully imported, to confirm the patches and complete patch application choose Confirm queue (or use Shift+F6). In this exercise, this is done by the instructor.

SAP AG 1999








System Landscape Strategies

SAP AG 1999

System Landscape Strategies

Contentsl Examples of system landscapes

l Strategies for setting up a system landscape

ObjectivesAt the end of this unit, you will be able to:l Explain the advantages and disadvantages of various client and

system strategies

l Outline the methods for setting up a system landscape, based on thecustomer's environment and needs

l Describe procedures for setting up andmaintaining a complex environment

SAP AG 1999

Repository objects


Advantages• Requires minimal hardware

resources• Requires less administration

effort

Disadvantages• Development directly affects productive

environment• Cross-client Customizing directly affects

production• No test environment for Repository objects• Production performance impacted by other

clients• Production is upgraded without

comprehensive testing

CUSTCUST TESTTEST QTSTQTST PRODPROD

R/3 in a Single-System Landscape

n The following limitations apply to a single -system landscape:

� Other clients such as the Customizing and quality assurance clients share the same hardware resources as the production client and therefore can affect production performance

� Reset reports for test data may accidentally be started in the production client

� Developers can create reports which access all production data

� The system administrator does not benefit from performing upgrades on a non-production system before upgrading the production system

� Changes to Repository objects are cross-client, and immediately affect the runtime environment, regardless of which client contains the Repository object; therefore, changes are tested in the runtime environment of your production system

n As a consequence of these limitations, no further development is possible after production work has started. Changes to Repository objects can only be made when production operations are stopped for development and testing. The Single -System Landscape is not supported for a productive environment.

SAP AG 1999

Repository objects


Repository objects


PRODPROD

Development Production

Advantages• Development and production

performed in separate R/3 Systems • Production data security• Production performance not

affected by other clients

Disadvantages• Development and quality assurance are

performed in the same R/3 System• Unable to fully test Repository objects and

cross-client Customizing before these aretransported to production

• No verification of transports before deliveryto production

CUSTCUST TESTTEST QTSTQTST

R/3 in a Two-System Landscape

n A two-system landscape allows development and production to be performed in two separate environments. Development and testing, however, are performed in the same R/3 System.

n The limitations of the two-system landscape arise because no separate quality assurance system is available. Thus, all objects transported to the consolidation system immediately become part of the production system.

n Complex development projects often involve transporting partial functionality, without always taking dependencies into account. Change requests and the functionality in the change requests are not fully tested until after the import process. Therefore, in a two-system landscape, the contents of the change request cannot be fully tested before it is imported into production. This can cause inconsistencies in the consolidation system, and affect the production system.

SAP AG 1999

Repository objects


CUSTCUST TESTTEST

Repository objects


QTSTQTST

Repository objects


PRODPROD

Development Quality Assurance

Advantages• Development, quality assurance, and production are

performed in separate R/3 Systems• Production data security• Production performance not affected by other clients• Stand-alone test environment• Verification of transports before delivery to

production

Production

R/3 in a Three-System Landscape

n In any software implementation, there should ideally be three distinct environments:

� An environment where Customizing and development can be performed

� An isolated environment for testing the Customizing and development changes

� A stand-alone production environment

n These distinct environments are recommended when implementing R/3 and are best realized by a three-system landscape for the following reasons:

� New developments can be tested without affecting the production environment

� Upgrades can be simulated and tested before applying to production

� A quality assurance system enables you to integrate development efforts and to check the validity and consistency of transported objects before delivery to production

n Some implementations may require more R/3 Systems, for example, a large, multinational implementation, or a phased implementation. Some customers may have constraints that require them to implement a one-system or two-system landscape. These customers should look carefully at the limitations and disadvantages of such landscapes.

SAP AG 1999

Consistent setup strategy for system landscape:

l Production system is set up in the same way as the qualityassurance system

l Distribution of Customizing through appropriate transport process

l Method for distributing and maintaining master data

System Landscape Requirements (1)

n Although clients are considered as independent data environments, clients within the same R/3 System share certain central resources. Thus, when distributing, administrating, and developing specific clients within the system landscape, you must pay particular attention to:

� Cross-client Customizing settings

� Repository objects

� Security of critical data

� A true quality assurance environment

� A stable, productive environment

� High performance and system availability

n Setting up a system landscape requires a well-defined strategy that ensures that all clients receive the same Customizing and development efforts.

SAP AG 1999

Prior to the start of Customizing and development:

lSet up the Transport Management System (TMS)

lUse a single client for all Customizing activities

lAllow changes only in the development system

lDefine quality assurance procedures

lDetermine transport schedule

lDefine implementation standards

System Landscape Requirements (2)

n Many implementations begin with a single R/3 System and add additional systems subsequently. When setting up the initial R/3 System, you should define the full system landscape. This helps to ensure that all Customizing and development changes are recorded and will be correctly distributed to future systems and clients.

n When planning the setup and maintenance of a system landscape:

� Define and establish the appropriate Transport Management System (TMS)

� Use a single client for all Customizing activities (client-specific and cross-client) and ensure that there is automatic recording of changes; do not allow Customizing changes in any other clients

� Establish a single R/3 System for development efforts (preferably the Customizing client); in all other systems, do not allow changes to Repository objects

n Define change management and transport procedures, for example, quality-assurance testing and post-testing sign-off procedures

n Define development procedures using code-freezes, naming conventions, and use of development classes.

SAP AG 1999

CUST

Development

TEST

SAP Client000

ClientcopyClientcopy

QualityAssurance

QTST

SAP Client000

TRNG

PROD

SAP Client000


Production

ASAP System Landscape Setup (1)


n SAP recommends a three-system landscape and has standardized the implementation procedures for a three-system landscape in the ASAP Roadmap.

n The ASAP Roadmap is the result of SAP best practices and the recommendations of implementation partners. This approach can be used as a template for other client and system strategies that are required if a customer has special needs. Many of the principles defined in the ASAP Roadmap should be applied regardless of the size of the implementation.

n SAP delivers the software with standard clients 000 and 001 and the EarlyWatch client 066. You are not allowed to work in client 000 nor client 066. Although you may work in client 001, SAP recommends that you create a new client as a copy of client 000 and work in this new client.

n Each new client in the ASAP three-system landscape is created from client 000 with the client copy tool.

n After post-installation activities are completed in the development system, the client copy tool is used to create clients CUST and TEST.

n At some point in the implementation process, the quality assurance system is installed and requires at least one client, the quality assurance test or QTST client. In addition, a training client or TRNG may be required.

n During the final stages of implementation, the production system is installed and the production client PROD is created.

SAP AG 1999


CUST

Development

TEST

QualityAssurance

QTST

TRNG

PROD

Production

CUST client change options are ‘Automatic recording of changes’ and‘Changes to Repository and cross-client Customizing allowed’.

The client setting for all other clients in the system landscape is ‘No changes allowed’ and ‘No changes to Repository objects and cross-client Customizing’.

n CUST is client in which all Customizing (client-specific and cross-client) and development is performed. To ensure that all changes are recorded to change requests, set the client change option for CUST to Automatic recording of changes and Changes to Repository objects and cross-client Customizing allowed. Make these settings before performing any Customizing or development.

n TEST is the unit-test client, where the contents of change requests are unit tested.

n SAP recommends keeping CUST free of data, to avoid situations in which Customizing settings are not modifiable because transaction data is linked to previous Customizing. The client TEST, however, should contain a variety of data with which customizers can test transactions and developers can test reports and programs.

n QTST is the client where integration testing is performed.

n A training client, TRNG, is optional.

n Note that the client change options for all other clients in the system landscape are No changes allowed and No changes to Repository objects and cross-client Customizing.

n Since changes to Repository objects are not allowed in any of the clients in the quality assurance or production system, the global setting of the system change option is set to Not modifiable for these systems.

SAP AG 1999

Transport directory

CUST

Development

TESTSCC1SCC1

Change requestrelease andexport



QualityAssurance

QTST

ImportImport

TRNG

PROD

Production

ImportImport

n Use transaction SCC1 to copy the contents of tasks and change requests to client TEST. After verifying the changes in TEST, the change requests are released and exported from CUST to the operating system level.

n Before and during the installation of the quality assurance system, change requests of unit tested changes are released and exported to the operating system. These requests are in the buffer of the quality assurance system. Once QTST has been created and appropriate client change options established, the entire buffer of the quality assurance system is imported into QTST.

n Changes also need to be distributed to client TRNG. Use one of the following methods:

� Client-specific transport routes provided by extended transport control. Client-specific transport routes guarantee that clients in the system landscape are delivered with change requests that originate in client CUST.

� If not using client-specific transport routes: After importing all change requests to QTST, import the same change requests to TRNG. This requires careful management of the transport buffer to ensure that all change requests are imported into each client in the same order.

n Once PROD has been created and appropriate client change options set, the entire buffer of the production system is imported into PROD.

SAP AG 1999

ASAP System Landscape: Summary (1)

l Advantages:

n Documentation and history of changes

n Procedures for change requests and transport managementestablished from the beginning of the implementation process

n Change requests are in testable units

n Complex Customizing is transportable

n Project coordination effort is simplified

n The most significant advantage of the ASAP system landscape approach is that the setup process is identical with the maintenance stream. No additional training or procedures are required after the start of production. The procedures defined during project preparation are valid for the implementation cycle and future upgrades or the addition of new functionality.

n History and documentation of all changes to change requests is maintained

n Establishes procedures for change request/transport from the beginning, thus starting and stabilizing the learning curve early

n Distribution of completed and verified Customizing and development efforts in testable units (change requests)

n Project coordination efforts can be mapped to change requests and allow for easy movement of completed projects only

SAP AG 1999

ASAP System Landscape: Summary (2)

l Disadvantages:

n ALL changes made in development must be recorded tochange requests

n No support for an R/3 Release upgrade until change requestsare distributed

n No clear method for distributing master data

n Because the ASAP system landscape strategy relies largely on change requests, the following disadvantages exist:

� Change requests are R/3 Release dependent. You cannot transport changes from one R/3 Release to another. If you decide to upgrade to a new release of R/3 during implementation, you must wait until all R/3 Systems are implemented using the initial development system release, apply pending change requests, and then upgrade to the newer release. In some situations, this may be a tedious process.

� All Customizing and development must be saved to change requests. This requires that all change management procedures and policies are clearly defined prior to implementation, and customizers and developers are trained to follow them.

� Change requests transport Customizing and development changes; they do not normally transport master data. Therefore, master data must be distributed either manually, through the IMG (for some modules), or using interface technologies such as BDC, EDI and ALE.

SAP AG 1999

CUST

Development

SAP Client000


Initially,Automatic recording

of changes notrequired

in client CUST

Alternative System Landscape Setup (1)

QualityAssurance Production

n Although SAP recommends the ASAP approach, the alternative strategy may be required if either:

� All customizing and development changes were not recorded to change requests, either because of inappropriate client change option or unclear change management procedures; or

� There is a need to upgrade the development environment after the release of change requests and before the installation of the quality assurance and production systems

n Following post-installation activities for the development system, the client CUST is created for use by customizers and developers as a client copy of client 000. The client change option for CUST is set to Changes without recording and Changes to Repository objects and cross-client Customizing allowed.

n As customizers begin their mapping of business processes, all changes are saved but not recorded to change requests. After this has occurred, the only way to transport these changes to other clients in the system landscape is either:

� A manual transport of all changes from the IMG. In a manual transport, it is difficult to be sure that all changes have been included.

� Copying the client using client transport tools. Instead of a remote client copy, use a client transport, that is, export of the client from CUST to the operating system level, with import into QTST. The benefit of this is that it places a defined state of client CUST in the export file. This export file can then be used to set up the production client later in the same way that QTST was set up.

SAP AG 1999

CUST

Development

TEST


When a secondclient is required,set client CUST to

Automaticrecording of

changes



n Because CUST is initially the only client in the development system, it is used for Customizing, development, and unit testing, and therefore requires application data.

n At some point in the implementation process, an additional client is required. Typically, a TEST client is required in the development system, due to the fluctuation of configurations in CUST and the need for better application data for testing.

n Client TEST is created as a client copy of client CUST. The choice of data for copying to client TEST may vary; however, copying Customizing data is usually preferable to copying both Customizing and application data.

n When the a second client such as TEST is created in the system landscape, changes in client CUST must be recorded in change requests because change requests provide the only means of moving additional Customizing changes from one client to another.

n Prior to the creation of client TEST:

� Customizers are trained in the use of change requests.

� The client change setting for CUST is set to Automatic recording of changes.

n Set the client change options for TEST to No changes allowed and No changes to Repository objects and cross-client Customizing.

SAP AG 1999

CUST

Development

TESTSCC1SCC1




Import change requestsImport change requests

QualityAssurance

QTST

Production

Transport directory

n TEST is the unit test client, where contents of change requests are unit tested. Use Transaction SCC1 to copy the contents of tasks and change requests to client TEST. After verifying the changes in TEST, the change requests are released and exported from CUST to the operating system level.

n Note: Some change requests may have been released to the operating system prior to the creation of client TEST. These changes were copied to TEST with the client copy, or are simply client-independent changes that affect TEST.

n When the quality assurance system is installed, it requires at least one client, the quality assurance test or QTST client.

n Import the change requests from the buffer of the quality assurance system to QTST.

n Note: the contents of the quality assurance buffer may contain Repository objects, client-specific Customizing, and cross-client Customizing: all three types of change requests should be imported to ensure that the Repository of the quality assurance system is consistent with the Repository of the development system.

SAP AG 1999

CUST

Development

TEST



TRNG

QualityAssurance

Production

ClientexportClientexport

Client importClient import

QTST

Transport directory

n Next, a client export of CUST is performed that includes both client-specific Customizing data and cross-client Customizing data. It is recommended that application data is not included. Changes should not be made in client CUST during a client export.

n Note: the previous task of importing the change requests is critical since they may contain cross-client changes and repository objects. Some change requests previously imported from the buffer of the quality assurance system may have added Customizing changes to QTST, but these are replaced by the Customizing during the client import.

n The exported data from client CUST is imported into QTST (client import).

n To protect QTST against changes, set the client change options to No changes allowed and No changes to Repository objects and cross-client Customizing.

n Because Repository changes not are allowed in the quality assurance system, the global setting of the system change option is set to Not modifiable.

n In addition to QTST, a training client or TRNG may be required in the quality assurance system.

n In order to ensure consistency, the optional TRNG client is created as a client copy of client QTST.

n TRNG is protected against changes by setting the client change option to No changes allowed and No changes to Repository objects and cross-client Customizing.

SAP AG 1999

Transport directory

CUST

Development

TEST

QTST

TRNG

PROD

ProductionQualityAssurance


1) Import change requests1) Import change requests 2) Client

import2) Client import

3) Import change requests3) Import change requests

n In order to provide a consistent environment and ensure that the production system will be the same as the tested and verified quality assurance system, the production system must be set up using the same method used to set up the quality assurance system.

n Therefore, you must import the same client export from CUST, that was imported into the quality assurance system. The order of change requests and the client import is critical. Change requests cannot be omitted because they may contain cross-client changes and repository objects. The correct procedure is:

1) Import the change requests in the buffer of the production system that were released before the client export.

2) The client export from client CUST, that was imported into QTST, is imported into PROD.

3) Import the change requests in the buffer of the production system that were released after the client export of CUST.

n PROD is protected against changes by setting the client change options to No changes allowed and No changes to Repository objects and cross-client Customizing.

n Because Repository changes are not allowed in the production system, the global setting of the system change option is set to Not modifiable.

SAP AG 1999

Alternative System Landscape: Summary (1)

l Advantages:

n Supports distribution of master data and test transactionaldata

n Allows R/3 System upgrade during implementation

n Changes need to be recorded to change requests only afteradditional clients have been created

n The alternative system landscape has the following advantages:

� Client copy and client transport enable you to transport master data. It is not recommended that you select application data (= master data + transaction data) to be included in a client transport of client CUST. However, if master data needs to be distributed, you can include application data in a client transport. By selecting application data, you also distribute transaction data. This may require some clean-up efforts after the import.

� Prior to the client transport of CUST, the development system can be upgraded to a new R/3 Release. All change requests released prior to the upgrade are discarded. After the upgrade, a change request for all modified Repository objects must be released from the development system to ensure that all Repository changes are transported to the quality assurance and production systems.

� The recording of changes to change requests is not necessary until a second client is added to the system landscape.

SAP AG 1999

Alternative System Landscape: Summary (2)

l Disadvantages:

n No complete change history

n Change management procedures change duringimplementation

n Unfinished Customizing is transported

n Dependency on remote client copy

n The alternative system landscape strategy has the following disadvantages:

� All changes are not recorded to change requests. Therefore, you lack complete documentation and a history of changes.

� At some point in the implementation process, customizers are required to use a new tool – change requests. More likely than not, change requests will be required at an inconvenient time when learning new procedures will not be a high priority.

� A client transport selects all Customizing entries, even those that provide partial functionality. There is no way to select only completed functionality prior to the client transport.

� Because there are some complex Customizing activities which client transports cannot manage, manual transports are used to support a client transport. For each functional area in which client transport problems can occur, look for SAP Notes in SAPNet.

SAP AG 1999

Maintenance of the system landscape is the same regardless of whether the landscapewas set up with the ASAP strategy or with the alternative strategy.

CUST

DevelopmentQualityAssurance Production

TEST

QTST

TRNG

PRODSCC1SCC1

ImportImportChange requestrelease andexport


System Landscape Maintenance

Transport directory

ImportImport

n Regardless of whether the ASAP setup strategy or the alternative method is used, the maintenance strategy is the same.

n The change management maintenance strategy is as follows:

� All changes originate in CUST.

� Unit testing takes place in TEST.

� Once confirmed in TEST, change requests are released and exported from CUST.

� The buffer of the quality assurance system is imported into QTST.

� Change requests are copied from QTST to TRNG using client-specific transport routes

� After verification and sign-off, the change requests in the production system buffer are imported into PROD.

n The only way of maintaining a system landscape with multiple clients during and after implementation, is to save all changes to change requests and distribute them using TMS. It is advantageous to use client-specific transport routes.

SAP AG 1999

CUST

Development Production

TEST

QTST

TRNG

PROD

SystemCopySystemCopy

This strategyNOT

recommendedby SAP!

This strategyThis strategyNOTNOT

recommendedrecommendedby SAP!by SAP!

Database Copy for System Landscape Setup (1)

SystemCopySystemCopy

n A database copy can be used to create an identical copy of an existing R/3 System. Therefore, many people mistakenly think that a database copy is a viable method for establishing additional R/3 Systems within a system landscape. SAP does not recommend using a database copy to set up a quality assurance system or a production system.

n This strategy is presented here to help highlight its limitations.

n After performing the database copy, you need to delete any clients, programs, or application data that is not required in your new system. However, it may be very difficult to fully delete unwanted data.

SAP AG 1999

Database Copy for System Landscape Setup (2)

Limitations:

n Unfinished Customizing and unwanted development effortsare distributed

n Clean-up is required after the database copy

n No verification or documentation of changes

n Nuances of transporting procedures are not learned

n Procedures for change management and transporting areestablished late

n Because a database copy duplicates the entire Repository, performing a database copy requires careful attention to the following issues:

� User management

� Client management

� Ownership of and need for Repository objects (clean-up)

� Review of configuration (unwanted entries or partial functionality)

� Distribution of application data

n Check client contents before performing a database copy.

n Many unwanted objects and Customizing are distributed, therefore, an R/3 Repository clean-up is required after the database copy. It may be difficult to find everything that needs to be deleted.

n While SAP does not recommend using database copies to establish new systems within a system landscape, a database copy is useful for copying an existing system for an upgrade test or for creating a training environment.

SAP AG 1999

•• Delivery routes Delivery routes

IntegrationIntegration

DEVZDEV

DeliveryDelivery

PR2

SAP

ZDEV

DeliveryDelivery

PR1

ConsolidationConsolidation& Delivery& Delivery

TRNZTRN

•• Consolidation Consolidation routes routesThe Transport

Management System (TMS) enables you

to realize morecomplex systemenvironments.

The Transport Management System (TMS) enables you

to realize morecomplex systemenvironments.


QAS

Complex System Landscapes

n System landscapes are considered complex landscapes if they cannot be categorized according to a one-system, two-system, or three-system landscape.

n For complex system landscapes, you need to define additional consolidation routes and delivery routes SAP recommends that you use the standard three-system configuration as a basis for configuring these routes. After making the initial settings, additional entries can easily be made to accommodate a more complex landscape.

n The graphical editor of TMS simplifies the creation of additional transport routes by enabling you to "draw" the required system landscape.

SAP AG 1999

Consolidation DeliveryIntegration

DeliveryDeliveryConsolidation DeliveryIntegration

Development QualityAssurance

ProductionSupport


Phased System Landscape

Phase N production supportPhase N + 1 implementation

Manualre-entry

of changes

1 Production ready to become Phase N + 1

2 Promote Phase N + 1 changes to Phase N production support

3 Production is at Phase N + 1 and Phase N + 2 implementation can be promoted tothe quality assurance system.

n A phased environment is required when a customer either performs an R/3 release upgrade for additional functionality or implements a new SAP module (such as PP, MM, HR). This new Phase is N+1. While configuring for this new Phase, the customer is must support the current production release (Phase N) . The production support for Phase N and the development and Customizing for Phase N+1 must be performed in separate R/3 environments.

n For the support of Phase N, all work takes place in the three-system landscape for Phase N. To ensure that any changes made to support Phase N production are also part of the Phase N+1 rollout, the changes also need to be realized in the Phase N+1 development system. SAP recommends that these changes be manually applied to avoid conflicts with the current configuration in the N+1 environment.

n Phase N+1 Customizing and development is distributed to the Phase N+1 quality assurance system using standard change request management. When it is time to switch production to Phase N+1, all changes generated from the Phase N+1 development system are applied to the Phase N quality assurance system for testing. (Note: If the Phase N and N+1 environments are not at the same R/3 Release level, then the Phase N system must be upgraded first). Once the changes are tested and verified in the Phase N+1 quality assurance system, the changes are then applied to the production system and eventually to the production support system.

n Production is now running Phase N + 1. At this point in time, changes in the development system for Phase N + 2 can be promoted to the quality assurance system, to prepare for the testing of the next phase that will be rolled into production at a later date.

SAP AG 1999

Integration Consolidation

Consolidation DeliveryIntegration

EuropeQuality

Assurance

AsiaQuality

Assurance

GlobalQuality

Assurance

GlobalDevelopment

USADevelopment

EuropeDevelopment

AsiaDevelopment

USAProduction

EuropeProduction

AsiaProduction

USAQuality

Assurance

Global System Landscape

n In this scenario, the system landscape is layered corresponding to the various subsidiaries of an international company. The starting point for development work is a centralized integration system for developing globally applicable functionality. Downstream from this integration system is a consolidation system where the global developments are tested.

n The global consolidation system supplies the changes to the country-specific integration systems. In these downstream development systems, country-specific development is added. Both global and country-specific changes are then transported to the country-specific quality assurance and production systems.

n For Repository objects, multi-layered development can be managed by creating appropriate development classes and assigning name ranges to the development classes.

n Because Customizing settings do not have any concept of "ownership", management of these changes in a multi-layered scenario is difficult. SAP currently does not provide a method for "locking" global Customizing so that it is not changed by country-specific implementation efforts. However, you can use the Cross-System Viewer in conjunction with Business Configuration Sets (BC Sets) to determine if global Customizing from the centralized integration system was changed in country-specific implementations.

SAP AG 1999


l Outline the benefits of a three-system landscape and thelimitations of a one-system and two-system landscape

l Explain the importance of a well-managed R/3 implementationwith clear strategies for setup and maintenance

l Describe the ASAP client and system strategy

l Use R/3 tools to set up and maintain a system landscape


SAP AG 1999


l SAP Notes:

n 31557

n 67205

l ASAP: The R/3 System Landscape

SAP AG 1999

l Do the Exercises?


Unit Actions

System Landscape Strategies: Exercises

No. Exercise

1 Optional exercise: Reviewing client strategies.

1.1 Assume that Customizing for Sales and Distribution is being performed in the development system client 500, and Customizing for Production Planning is being performed in client 600.

Can the change requests from these two clients be released and imported into client 700 on the quality assurance system for verification and testing?

1.2 Many developers prefer to have a client in which they unit test their programs and reports. What considerations should be taken into account when providing a client for developers that is separate from the client where Customizing is performed?

1.3 In some situations, developers set up their own R/3 System in which to develop their programs and reports. This means that Customizing is performed in a different R/3 System than development. What considerations should be taken into account for such a scenario?

2 Optional exercise: Reviewing system landscape strategies.

2.1 After going live, when R/3 is in production, how can changes be delivered to the production client?

2.2 The implementation lead suggests that, as the Basis administrator, you perform a client transport of the Customizing client to the appropriate quality assurance client every Friday night. The implementation lead thinks that this will provide the quality assurance team with an up-to-date, clean test environment each week without having to use change requests.

What concerns do you have with this suggestion?

System Landscape Strategies: Solutions

No. Solution 1 1.1 The answer is: "Technically, yes". You can release changes from two

different clients. By default, these changes will follow the standard transport route. The TMS function for starting imports will import the changes from two different origins into a single client. Although, technically, a release from two different clients is possible, SAP advises the customer: "No". SAP recommends that all Customizing is performed in a single client. Due to the highly integrated nature of R/3, Customizing different functional areas depends on many common settings. Customizing in multiple clients allows persons to configure without consideration of other functional demands. To merge two customized clients into a single client produces unpredictable results.

1.2 Whenever another client is added to a system landscape, you must carefully evaluate how and when that client receives the latest changes. If developers have their own client, they must recognize that they will not always be working with the latest Customizing settings. True testing will be required in either the unit test client (TEST) or once their client has been updated with the latest Customizing settings.

1.3 The need for an additional R/3 System for development efforts may be appropriate for a complex implementation with a lot of development and interface needs. If developers have their own R/3 System, they must recognize that they will not always be working with the latest Customizing settings. In addition, careful attention must be paid to version management and change history. The two R/3 Systems – the R/3 System for development and the R/3 System for Customizing – must be maintained in such a way as to provide a complete change history.

2 2.1 The only way of safely providing development and Customizing changes to

an existing client or system is through change requests. 2.2 You should ask the implementation lead:

How is master data and test transaction data updated in the quality assurance system maintained, or must it be recreated each week? How will the production client be kept up-to-date? How are problems debugged? In other words, if a problem occurs in the quality assurance system that did not exist in the previous week, how can the cause of the problem be identified? What if there are changes that need to be transferred to the quality assurance system immediately, that cannot wait until Friday night? Once in production, the client copy tool cannot be used because productive data would be lost. Therefore, changes will have to be distributed to production using change requests. Will the customizers and developers be comfortable supporting production using change requests? How will a complete history of changes be provided?

SAP AG 1999








Upgrade Guide

SAP AG 1999

Upgrade Guide

Contentsl Discussion of the Upgrade Guide

l Upgrade planningl Upgrade preparations

l Upgrade tools

ObjectivesAt the end of this unit, you will be able to:

l Describe the necessary steps to plan a SAPupgrade

l Describe the necessary steps to prepare a SAPupgrade

l Describe the upgrade tools

SAP AG 1999

Section: R/3 Technical Implementation andOperation Management

Implementationwith ASAP

Overall Design

Going Live

Technical Operation

SAP AG 1999


Overall Design

Going Live

Technical Operation

Implementation with ASAP

SAP AG 1999

Implementation with ASAP

Contentsl TeamSAP

l Implementation strategies

l Introduction to ASAP Methodology

n ASAP project

n Phases

n Roles

n Project schedule

ObjectivesAt the end of this unit, you will be able to:l Outline the TeamSAP framework

l Indicate criteria for selecting an implementation strategy

l Explain ASAP methodology and its organizational requirements

SAP AG 1999

Choosing a Suitable Implementation Strategy (1)

Who will be responsible for project management? You or your consulting partner?

Nu

mb

er o

f IT

sta

ff m

emb

ers

Nu

mb

er o

f IT

sta

ff m

emb

ers

Num

ber

of e

xt. c

on

sult

ants

Project team setup

n The first step in the R/3 implementation process is to decide on an implementation and operation strategy. Before selecting a strategy and determining the number of IT staff needed, ask yourself these questions:

� How much will I, the customer, be involved in the implementation process?

No involvement: In this case, you require a strong implementation partner with sufficient capabilities. Additionally, you outsource the IT data center.

You provide the project leader and system administrator: In this case, you need an implementation partner and training.

You provide resources for Customizing or development at power-user level.

You provide all resources for Customizing or development and only need SAP consulting support.

You have your own Customer Competence Center (CCC) for company rollout and need no support.

� Who will operate and support R/3 after implementation? End users may require:

Help Desk (internal or through outsourcing)

Support from the IT staff – for network, PCs, R/3, or for the specific application components

SAP AG 1999


Implementation strategy depends oncomplexity of planned implementation

Possible strategies:

•Global ASAP

•ASAP

•Ready to Run

Co

mp

lexi

ty

n Possible implementation strategies include:

� AcceleratedSAP (ASAP): This is SAP's comprehensive solution for streamlining R/3 implementation projects. It is continuously being improved and updated by an international consulting team that collects very detailed feedback from customers already using ASAP. ASAP optimizes implementation time and quality, and ensures efficient use of resources.

� Variations of ASAP, such as:

Ready to Run: This strategy offers preconfigured R/3 Systems for smaller-scale operations.

Fixed Price Projects: These projects usually use Ready to Run systems and offer a predefined package of functions and support services.

Global ASAP: SAP developed Global ASAP as the standard implementation methodology for global implementations of R/3. With Global ASAP, all activities not taking place at a local level are mapped onto a special structure called the Global Roadmap. This roadmap follows the AcceleratedSAP principles and includes How-To’s, accelerators, modeling methods and tools. The global roadmap is then linked to the individual AcceleratedSAP project roadmaps for the projects at the local level.

SAP AG 1999

PhasedImplementation


Big BangApproach

APO

BW

SAP Oil & Gas

R/3 FI

R/3 SDTreasury

Business processes?Required interfaces?Implementation time schedule?

??

n The R/3 implementation approach you select depends on the business processes you require in R/3 and their communication with other processes on other systems.

n If you choose a phased implementation and thus continue to run certain business processes on your legacy system temporarily, you need to create and maintain interfaces between R/3 and the legacy system.

n The Big Bang approach requires fewer interfaces and provides maximum business process integration. It is used when:

� One or more SAP application components are implemented throughout an entire enterprise or business unit

� A series of SAP application components are to be implemented on a given date (for example, all Financial Accounting or Logistics components offered by SAP)

n A third approach, a roll-out implementation, is a mixture of both the Big Bang and phased implementation approaches. The choice of approach varies for particular application components, company site locations, operational business units, material types, or customer types.

SAP AG 1999

TeamSAP Components

Peop

le

Processes

Products

People:People:Solutions expertiseQualityn SAPn Consulting partnersn Complementary

software partnersn Technology &

hardware partners

Processes:Processes:AcceleratedSAPConsistencyn AcceleratedSAP Roadmaps or

powered by methodologiesn SAP Review Programn Support, services

& education

Products:Products:The Business FrameworkStrengthn R/3 product familyn Complementary software productsn Technology partner productsn Industry solutions

TeamSAP

n TeamSAP represents a total organizational commitment by SAP and partners to the overall success of customers by helping them define the right business solution, by providing assistance during implementation and by guiding them as their business changes.

n TeamSAP projects have the following standards to assist in the success of customers:

� TeamSAP Coach - single point of contact for customer, providing fast answers to any questions.

� ASAP or ”powered-by”* implementation methodologies - ASAP is a clearly defined implementation strategy that ensures customers a quick and predictable implementation, regardless of size or complexity of environment. * Powered-by implementation methodologies are SAP Partner methodologies incorporated into the ASAP methodology.

� Managed by SAP or TeamSAP Partner - the TeamSAP Partner certification program represents the commitment between SAP and its partners to work together for the overall benefit of the customer.

� Quality Assurance Check - this program allows SAP to proactively measure how the project is progressing, how well the implementation methodology is being followed, to verify performance and to make sure customers are getting the solution presented in the software selection process.

� Steering Committee Representation - SAP representation on the customer's project steering committee will help provide strategic direction to the customer's implementation and for future business changes.

SAP AG 1999

Training, Licensing Training Material(Knowledge Warehouse), Support, Project Reviews

Training, Licensing Training Material(Knowledge Warehouse), Support, Project Reviews

l ImplementationAssistant

l Q&Adb

l ImplementationGuide

l Profile Generator

l Transport System

AcceleratedSAP - SAP´s Full Life-Cycle Solution

l ProjectManagement

l OrganizationalChangeManagement

l Risk Analysis

l Review

Methodology

Services

Project-Related

KnowledgeTools

ASAP RoadmapProject

PreparationBusiness Blueprint

RealizationFinal Preparation

Go Live &Support

ContinuousImprovement

ASAPASAP

n AcceleratedSAP (ASAP) is the implementation solution provided by SAP. ASAP integrates several components that work in conjunction to support the rapid and efficient implementation of the SAP’s R/3 System, Industry Solutions and New Dimension products. The components that make up ASAP are :

� Methodology - The ASAP Roadmap defines the phases of the implementation process and supports these with a comprehensive project plan. The project plan comprises MS Project templates providing complete work breakdown structures and resource assignments.

� Tools - The ASAP process is supported by a comprehensive set of both PC-based and R/3-resident tools.

� Service - Hotline, Consulting, Training, Project Reviews, SAPNet

� Project related Knowledge like Project Management, Change Management, Risk Analysis and Review Programs.

SAP AG 1999

What Does ASAP Offer You?

ASAP Roadmap

Project Preparation

Business Blueprint Realization

Final Preparation

Go Live &Support


n The ASAP Roadmap is a project plan with detailed descriptions about:

� The different implementation activities that need to be performed

� Methods for carrying these activities out

� Who should be responsible for an activity

n Tools include project management tools, questionnaires for the business process consultants, and numerous technical guidebooks and checklists. The corresponding configuration tools in the R/3 System are contained in the Business Engineer.

n The Roadmap consists of the five ASAP phases: (1) Project Preparation, (2) Business Blueprint, (3) Realization, (4) Final Preparation, and (5) Go Live and Support. After the ASAP phases have been completed, your system will be in the operation phase with continuous Customizing and development improvements.

n Whenever possible, ASAP provides accelerators such as examples, checklists, or templates, to get you started. This means each successive implementation team does not have to ‘reinvent the wheel’.

n The Toolkit contains the ASAP tools, including the accelerators and the Question and Answer database, which help you assess your requirements and create the Business Blueprint.

n Relying on the R/3 Business Engineer with its implementation tools, ASAP does not replace existing tools. Instead, it makes them easier to use.

SAP AG 1999

l ASAP Phase

l Work Package

l Activity

l Task

Activity

Task 1Task 2Task 3

Project Phase June, 4

20 30 40 50 0 10

Project PlanTask Hierarchy

ASAP Implementation Assistant Hierarchyand Scheduling

n The five ASAP phases comprise the top level of the ASAP hierarchy. Each phase consists of a number of Work Packages, each of which is divided into Activities. Each Activity consists of a number of Tasks. Each Task has (a) defined:

� Purpose

� Step-by-step procedure

� Prerequisites

� Result

� Set of tools

� Person or persons who are responsible for performing the task

� Set of links to implementation accelerators, such as guidelines and questionnaires

n ASAP provides a link to a six- or nine-month implementation project plan (in MS Project format). This reference project plan shows the time required for each Task, Activity, and Work Package. Its templates can be adapted to your specific needs and time allocation.

SAP AG 1999

l Roadmap

l Implementation accelerators

l Project plan

l Question and Answer database

l Issues database

l Business process procedures

l Knowledge corner

l Glossary

The ASAP Implementation Assistant

n The Implementation Assistant is a tree structure containing:

� Home Page: Links to the roadmap graphic

� What's New: Explains ASAP version changes and R/3 Release changes

� Roadmap: Outlines the ASAP phases and the following tools and accelerators:

Implementation Accelerators: An alphabetical listing of accelerators

Project Plan: The entire ASAP project schedule as a Microsoft Project document. It contains templates for six- and nine-month implementations. Your project manager must tailor the project plan to meet your needs.

Question and Answer Database: Answer the questions in this tool to create your Business Blueprint, Business Process Master List, and the initial Baseline Scope document. This is the major tool used in phase 2. It contains an Open Issues Database to help you track open issues.

Business Process Procedures: Templates for business processes. This can also be used as documentation for users.

Knowledge Corner: Further documentation, such as simplification guide books

SAP AG 1999

l Explain ASAP roles and procedures

l Prepare your Project Charter

l Define your schedule, budget, and resources

l Provide initial training for project team

l Define technical requirements

l Prepare executive kickoff meeting

ASAP Roadmap

Project Preparation

Business Blueprint

Realization

Final PreparationGo Live &Support

ContinuousImprovement1

Phase 1: Project Preparation

n In ASAP phase 1, you should:

� Explain ASAP roles and procedures ASAP defines roles and procedures which should be observed.

� Prepare your Project Charter The Project Charter clarifies your business-related project goals.

� Define your schedule, budget, and resources Use the corresponding ASAP tools.

� Provide initial training for your project team This training corresponds to the Level 1 training in the SAP training curriculum.

� Define technical requirements Evaluate your hardware sizing requirements and create an appropriate hardware supply contract.

� Prepare executive kickoff meeting This meeting should stimulate motivation and outline the necessary procedures and responsibilities.

n By addressing these issues early on, you can establish a solid foundation for the success of your R/3 implementation.

SAP AG 1999

ASAP Roadmap

Project Preparation

Business Blueprint

Realization



l Assess your requirements using interviews, questionnaires, andmodels in the Business Blueprint

l Provide Level 2 training for project team

l Install your R/3 development system

l Review the Business Blueprint

2

Phase 2: Business Blueprint

n The Business Blueprint document is a detailed assessment of your business process requirements based on interviews, questionnaires, and workshops.

SAP AG 1999

ASAP Roadmap

Project Preparation

Business Blueprint

Realization



l Customizingn First perform Customizing for the "Baseline" system

(100 % of organizational structure and 80% of all daily businessoperations)

n Perform first integration test to validate this Customizing

l Final Integration Testn Check other business processes that may be indirectly affected

n Design, develop, and test interfaces, reports, and data conversions

3

Phase 3: Realization

n In the Realization phase, you set up the business processes outlined in your Business Blueprint by performing the necessary Customizing.

n Configure the system in two parts:

� Baseline (majority of functional scope, as defined in ASAP's Question and Answer Database)

� Final (remaining functional scope, usually of a more complex nature)

In this way, you can confirm the essential functions before moving on to other areas.

n The implementation objectives of this phase are:

� Completing R/3 implementation

� Integration testing

� Ensuring System operability

� Allowing the project team to gain detailed knowledge of their R/3 System

SAP AG 1999

ASAP Roadmap

Project Preparation

Business Blueprint

Realization



l Plan for the going-live date

l Train end users

l Test integration, volume, and stress

l Establish an internal Help Desk

l Cut over to production environment

4

Phase 4: Final Preparation

n Final Preparation involves planning the following:

� Testing

� End-user training

� System management

� Cutover tasks

n Final Preparation is also the phase in which you must resolve important open issues.

n On successful completion of this phase, you are ready to run your company's business with R/3.

SAP AG 1999

ASAP Roadmap

Project Preparation

Business Blueprint

Realization



l Start production operation

l Set up support

l Verify the accuracy of the production R/3 System

l Measure business benefits

l Optimize R/3 performance

Phase 5: Go Live and Support

5

n In phase 5, you move from a pre-production environment to a live production operation.

n Set up a long-term support organization for users, not just for the first days of production. All users must have easy access to this support.

n In this phase, you can also monitor system transactions to optimize overall system performance.

n The completion of this phase closes the implementation project.

SAP AG 1999

New business requirements

New R/3 functionalityChanges in market technology

ProjectPreparation

11 22 33

5544

BusinessBlueprint

RealizationFinal Preparation

Go Live &Support

Continuous Improvement

ASAP Implementation

ASAP Supports Continuous Improvement

n Change and improvement are integral parts of today’s business environment. R/3 supports and embraces the process of continuous change as:

� New R/3 functionality becomes available

� Market technology changes

� New business requirements are defined

SAP AG 1999

The Project TeamSteering committee

Processteam lead

ExternalAccounting

and FinanceManagement

Process teamlead

SalesLogistics

Process teamlead

Organizationand HumanResources

SAP project manager

Technical team lead

Project sponsor

Process teamlead

BusinessPlanning and

Control

Process teamlead

ProductionLogistics

Change management team

Process teamlead

ProcurementLogistics

Project engineer/administration

Project manager

SAP consulting mgr

ASAP Roles (1)

n The roles defined in ASAP can be assigned to your staff or external personnel.

n The steering committee consists of the project sponsor, project manager, SAP consulting manager, and SAP project manager. Its primary responsibilities are to commit resources to the project, monitor progress, monitor organizational impact, approve major deliverables, authorize the project team to make decisions and address escalated problems, and support the project manager. Time commitment: Two to four hours per month.

n The project sponsor has ultimate control of the steering committee and is the final budget authority. When conflicts arise in the execution of responsibilities, the sponsor is empowered to negotiate and promote a solution. Time commitment: One to three hours per week

n The project manager is responsible for the project deliverables and the day-to-day management of the project. He or she should define the implementation strategy, ensure maintenance of the project plan, define and manage project resources, communicate the project status to all concerned, and streamline issue resolution. Time commitment: Full time.

n The SAP project manager assists the project manager in defining and completing project deliverables, as well as in the day-to-day management of the project. He or she should provide guidance in using the ASAP methodology and assist the project team in understanding the ASAP Implementation Roadmap. Time commitment: Varies between full time and part time.

SAP AG 1999

OS administrator

FIABAP developer

Logistics ABAP developer

HRABAP developer

Cross applicationdeveloper

Forms/SAPScriptdeveloper Network administrator

Database administrator

Security administrator

System administrator

Functional team lead(s)

Technical Team (at a High Complexity Customer)

Project manager

Technical team lead

ASAP Roles (2)

n The system administrator configures, monitors, tunes, and troubleshoots the R/3 technical environment on an ongoing basis; as well as performs daily checks and maintenance tasks. Time commitment: Part time or full time.

n The security administrator manages the R/3 security environment (user administration and profile creation), and the security of the environment surrounding R/3. Time commitment: Part time or full time.

n The database administrator is responsible for backup and recovery management, database tuning and configuration, ABAP Dictionary management, and database security. Time commitment: Part time or full time.

n The network administrator is responsible for network installation, upgrades and patches, management of network backups, system performance and tuning, the network operating system and related security, access to SAPNet Services, and network recovery. Time commitment: Part time or full time.

n The operating system administrator is responsible for the operating system environment and its installation, upgrades, patches, backups, performance and tuning, and security. Time commitment: Part time or full time.

SAP AG 1999

Project Duration: Example

1

2

3

5

4

Project Preparation Project Preparation

Business Blueprint Business Blueprint

Realization Realization

Final Preparation Final Preparation

Go Live & Support Go Live & Support

Baseline Baseline

Final configuration Final configuration

Integration test Integration test

3

4

4

5

3

5

2+

26

12

15

15

19

12

19

8

100Total

Weeks% Total

Time

For a 6-month project

n Your SAP consultant or SAP partner can make a preliminary estimate of project duration.

SAP AG 1999

You are now able to:

Implementation with ASAP: Unit Summary

l Discuss the TeamSAP framework

l Indicate criteria for selecting an implementationstrategy

l Explain ASAP methodology and its organizationalrequirements

n Critical Success Factors for R/3 Implementation with ASAP:

� Ensure strong support within your company. Provide:

A committed steering committee that makes quick decisions

A dedicated project team including power users and decision makers

A company-wide decision-making structure

� Implement a manageable scope of functionalities, that is, implement core functionality first.

� Avoid business process reengineering by basing your implementation on R/3’s flexible “best business practices”. This limits the number of modifications.

SAP AG 1999


l Knowledge Product CD

n R/3 Technical Implementation and OperationManagement

l SAP Expert Knowledge Book Series

n SAP R/3 Technical Implementation withASAP

l ASAP CD

l SAPNet

n Alias ASAP

n Alias TEAMSAP

n Alias TEAMSAPSUPPORT

SAP AG 1999

ProjectPreparation

BusinessBlueprint

Realization

FinalPreparation

Go Live andSupport


R/3 ConversionService

R/3 ConversionService Remote UpgradeRemote Upgrade

Remote ArchivingRemote ArchivingOS / DB MigrationOS / DB Migration

EarlyWatchEarlyWatch

RemoteConsultingServices

Appendix: ASAP and SAP Consulting Services

GoingLiveCheck

GoingLiveCheck

n SAP Services cover all consulting, education, and support services, including the Hotline, EarlyWatch Service, remote upgrades, and remote archiving.

n The SAP GoingLive Check is a technical monitoring service to facilitate the going live process. SAP experts log on to your SAP System by remote connection, inspect the configuration of individual system components, and provide valuable recommendations for system optimization.

n The SAP EarlyWatch Service helps you ensure a high level of system availability, performance, and problem-free operation through regular remote diagnoses of the entire system environment. This involves detailed analyses of:

� R/3 application components and their configuration

� Database, operating system, and network components

n The SAP R/3 Conversion Service provides comprehensive conversion solutions, for example, when corporate divisions are merged and R/3 is required to import externally created data.

SAP AG 1999

ProjectPreparation

BusinessBlueprint

Realization

FinalPreparation

Go Live andSupport


EducationServices

Project team trainingProject team training User trainingUser training

Developing training courses

Developing training coursesApplication training Application training Basis training and

SAP TechNet

Basis training andSAP TechNet

Appendix: ASAP and SAP Education Services

n During the first three phases of ASAP implementation, the project team and power users should receive R/3 application training and R/3 Basis training.

n End users are usually trained on-site by consultants and power users, using company-specific training material, in phases 4 and 5. Other information sources for end-user training include:

� SAP TechNet From the SAP homepage, click through to either TechNet's up-to-date discussion forum or its ever-growing library of practical documentation on R/3 Basis and applications.

� Advanced Training Solution By acquiring a license, customers can access the wealth of SAP training courses and information objects.

� R/3 Basis Knowledge Products A range of CDs is available on Basis topics to build on the knowledge acquired in workshops and seminars.

Exercises

Unit: Implementation Phases with ASAP

Topic: ASAP Tools

At the conclusion of this exercise, you will be able to:

• Navigate the ASAP tools

• Locate the fundamental accelerators for technical implementation

1-1 In which work package in the Implementation Roadmap can you find the activity “Implement the Authorization Concept”?

Hint: Try Realization → …

1-2 Which tasks are assigned to the activity “Establish System Administration Functions”?

Hint: Try System Management → …

1-3 Locate a 9-month ASAP Project Plan. Which formats do the project plans have?

1-4 Where can you find the guidebook “Authorizations Made Easy”?

Hint: Try the Knowledge Corner → SAP Products ...

1-5 Find the Report Navigator.

Hint: Look at the Alphabetical File List.

1-5-1 Find the Spool Request Contents report. Which transaction can you use to view the listing of spool requests?

1-5-2 What are the six status indicators for Output Status?

1-6 Name four key attributes of a network administrator.

Solutions

Unit: Implementation Phases with ASAP

Topic: ASAP Tools & Accelerators

1-1 In which work package in the Implementation Roadmap can you find the activity “Implement the Authorization Concept”?

The work package is “Establish Authorization Concept”.

To find this work package and activity, from the ASAP Implementation Assistant initial screen, drill down the tree structure as follows: Implementation Roadmap → Realization (Phase) → Establish Authorization Concept (Work Package) → Implement Authorization Concept (Activity)

1-2 Which tasks are assigned to the activity “Establish System Administration Functions”?

The tasks include:

- Verify Client Copy Procedures

- Verify Daily Check Procedures

- Verify Transport Procedures

- Verify Backup and Recovery Procedure.

To find these tasks, from the ASAP Implementation Assistant initial screen, drill down the tree structure as follows: Implementation Roadmap → Realization (Phase) → System Management (Work Package) → Establish System Administration Functions (Activity)

You can also find the answer to both questions 1-1 and 1-2 by using the Find Tool. Select the Find tab and then type in the name of the activity. Choose the appropriate topic and click Goto Step

1-3 Locate a 9-month ASAP Project Plan. Which formats do the project plans have?

The two available formats are MS Project (.mpp) and MS Excel (.xls).

On the ASAP Implementation Assistant initial screen, select Project Plan in the tree structure. A list of project plans appears in the Attachment window.

If the Attachment window is not visible, on the toolbar select Options → Show Attachment Area.

1-4 Where can I find the guidebook “Authorizations Made Easy”?

Access the Knowledge Corner by clicking the KC tab. Then drill down the tree structure as follows: Knowledge Corner → SAP Products → Cross Application → Authorization

1-5 Find the Report Navigator.

Select the menu options View → Report Navigator. Click Launch File or double-click Report Navigator.

1-5-1 Find the Spool Request Contents report. Which transaction can you use to view the listing of spool requests?

You can use transaction SP01 to view the listing of spool requests.

Within the Report Navigator, select the Index tab and search for spool request contents. Alternatively, drill down the following tree structure: Report Navigator → Basis → Print and Output Management → Spool Request Contents

1-5-2 What are the six status indicators for Output Status?

- Wait

- Process

- Print

- Compl (eted)

- Problem

- Error

1-6 Name four key attributes of a network administrator.

The four key attributes include:

- At least three year’s experience with network administration

- The ability to work in diversified teams

- Strong analytical skills

- Knowledge of the company’s network environment

Use the Find Tool to search for network administrator. Double-click the Network Administrator (Accelerator).

SAP AG 1999


Overall Design

Going Live

Technical Operation

Overall Design

SAP AG 1999

Overall Design

Contentsl Key sizing considerationsl Network designl Securityl Interfacesl High availability

ObjectivesAt the end of this unit, you will be able to:l Discuss sizing considerationsl Describe network requirements for R/3l List fundamental security considerationsl List requirements for different interface technologiesl Relate central issues regarding high availability

SAP AG 1999

System Sizing: Key Questions

l Complete technical questionnaires

l Size initial hardware

l Order a GoingLive CheckHOW?

WHAT?l Implement sizing process

l Implement scalable system components

l Project managerl Technical team leadl Technical consultantl System administratorl Database administrator

WHO?

n Optimum sizing is a prerequisite for acceptable response times.

n Your hardware partners will initially size your hardware based on data you provide. The sizing process should also include a data volume forecast, which determines how long you can operate your system with the initial hardware. R/3's scalability allows you to easily expand the system later.

n The ASAP technical questionnaires provide a starting point for making sizing decisions. You should do the initial sizing and procure the necessary hardware in ASAP phase 1. In phase 3, Realization, size your production environment. SAP strongly recommends a GoingLive Check, which includes sizing checks, in phase 4, Final Preparation.

n It is your project manager’s responsibility to complete the technical questionnaires. Your technical team lead, your system administrator, your technical consultant, and your database administrator perform the initial hardware sizing.

SAP AG 1999

Customer Hardwarepartner

SAPGoingLive Check

Hardwaresizing

Customerload profile

Requirem

ents

Con

figur

atio

npr

opos

al

Customerconfiguration

A

TestsExperience

SAP benchmark

The Sizing Process

n Factors that you must consider when sizing your R/3 System include workload (peak versus average), number of users, user behavior, amount of batch processing, business process Customizing, reporting, and data transfer using interfaces.

n The hardware sizing process has three stages:

� Stage 1: Analyze business requirements and then use the Quick Sizer to roughly estimate the size of the system you need. This rough estimate is suitable for a feasibility check and initial budget planning.

� Stage 2: Complete the hardware-sizing questionnaire provided by your hardware vendor. Using your responses, the vendor then estimates the size of the system you require. The vendor makes this estimate based on past experience and various SAP-standard benchmark tests. Then, you receive the hardware vendor’s recommendations for specific models that ensure your required performance regarding memory, CPU, and I/O. Since hardware sizing is based on the average behavior of SAP-standard transactions, it will not necessarily reflect individual Customizing and customer-defined applications or enhancements.

� Stage 3: Configure the system and, during ASAP phase 4, Final Preparation, run stress and volume tests as well as schedule a GoingLive Check. If necessary, adjust your configuration. Remember, as your system grows, your sizing needs will change. Hence, system sizing is an iterative process.

SAP AG 1999

R/3Release

DB Version

OS Version

Hardware

Performance /Sizing

• Throughput• Response times

SAP or SAP Partner Customers

Number of users

Transactionvolume

Load profile

Customizing

Reporting

Dialog / Backgr.

Factors Affecting Sizing

n Initially, your minimum system size is determined by your R/3 Release level, your selected hardware, and your database platform. You can install your system on a number of different platforms. Each platform has its own specific installation requirements.

n The decisive factors to consider when sizing are:

� Quantity structure estimations for transaction volume

� Number and type of application components

� Number of active users

� Typical workload profiles (workload peaks and troughs)

� Customizing

� Expected throughput of core transactions

� Recovery windows and backup times


� Future business transaction growth

n Since the development and production systems have different types of workloads, size them individually.

SAP AG 1999

Quick Sizer

User input

• Active application components• Active users

Quantity structure fordialog processing: - Aver. # of FI documents- Aver. # of line items- High load phase- Retention period

Quantity structure for background processing

Sizing result

Minimum and optimummemory for databaseserver and applicationserver

CPU sizing categoryDisk sizing category

Link tohardware partners’

sizing service

Quick Sizer on SAPNet

n The Quick Sizer (Quick Sizing Service) calculates CPU, disk, and memory resource categories based on the number of users working with the different components of the R/3 System and the data throughput that is achieved in these components. The results are independent of the type of hardware or database. This tool gives you an estimate of the system size necessary to run the required workload and therefore provides input for initial budget planning. Links to hardware partners allow you to easily request hardware sizing proposals.

n The Quick Sizer is only an approximate guide to sizing. It helps you when initially planning your budget for hardware and functions as an initial feasibility check. However, it cannot replace proper sizing by the hardware vendor and sizing verification through the GoingLive Check Service.

n For more information and to access the sizing tool, see SAPNet, alias QUICKSIZER.

SAP AG 1999

ASAP Phases: System Sizing

1

2

3

cont

5

4

Project managerTechnical project leadSystem administratorTechnical consultant

Technical team leadBusiness process team lead

Project manager

Database administratorTechnical team leadTechnical consultant

l Complete technical questionnairesl Complete technical questionnaires

l Define technical infrastructure needsl Define technical infrastructure needs

l Procure hardwarel Procure hardware

l Size initial hardwarel Size initial hardware

l Review and approve system sizingl Review and approve system sizing

l Define production system designl Define production system design

l Verify workload and data storage estimatesl Verify workload and data storage estimates

l Define production system disk layoutl Define production system disk layout

l Design archiving management strategyl Design archiving management strategy

l Conduct GoingLive Checkl Conduct GoingLive Check

tasks roles

n In phase 1, Project Preparation, your project manager completes the technical questionnaires. Your technical team lead, your system administrator, and your technical consultant size the initial hardware. When sizing your hardware, they consider the following:

� Scalability

� Hardware product release cycles

� Delivery speed

n Stipulate in a service level agreement with your hardware vendor the delivery time for urgently required hardware components.

n In phase 3, Realization, your database administrator and your technical team lead define the production system design including workload, disk layout, and archiving strategies. As part of your archiving strategy, calculate how long the disk space on your database server will suffice.

n In phase 4, Final Preparation, your database administrator and your technical team lead verify the system workload and data storage requirements. Your technical team lead and your technical consultant design the disk layout for the production system. The technical team lead, the respective business process team leads, and the project manager participate in a GoingLive Check.

SAP AG 1999

Network Design: Key Questions

l System administratorl Technical team leadl Technical consultantl Network administrator

WHO?

l Plan technical requirementsl Configure and document network topologyl Train system administration staff

HOW?

WHAT?

l Provide necessary bandwidth for all client/servercommunication

l Implement optimal throughput between all systemlayers

l Implement secure and stable network

n Your network design must allow for security, stability, and an optimum flow of data between all client/server layers.

n Sources of network load include:

� Dialog processing, which involves all three layers: presentation, application, and database

� Printing

� Faxing

� Data exchange in distributed systems that have applications located on separate servers and communicate using a variety of interface techniques

SAP AG 1999

Presentation

Application

DatabaseDB processes

Network Load Caused by User Interaction

Work processWork

processWork

processWork

processWork

processWork

process

Dispatcher

Data quantity: On average 20 KB

per processing request using LAN

Data quantity: On average 2.6 KB

per dialog stepusing LAN/WAN

n Communication in SAP Systems occurs between:

� The front end and the application layer

� The application layer and the database layer

n The front end layer and application layer can communicate using LANs and WANs, as data compression makes the communication load very small. This compression also prevents the message from being sent in plain text. This is a useful technique for WANs because it hinders unauthorized interception.

n The application layer and database layer communicate using remote SQL commands and ideally rely on a separate network for two reasons:

� High bandwidth requirements (the amount of data exchanged between database and application server is large)

� Need for greater security (when front ends connect using a SAProuter to the application servers, these are to a certain extent protected from unauthorized access)

SAP AG 1999

C = Required line capacity measured in bit/sec

L = Line utilization (0 < L < 1)

TThink = Think time between two dialog steps

TRes = Response Time

N = Total number of users with think time TThink and response time TRes

C = 28,000 x N / [L x (TThink

+ T Res

)] bits/sec

Calculating Line Capacity

n This formula can be used to calculate the required line capacity for the network traffic between the presentation and application servers. This formula is based on measurements of the R/3 FI, MM, and SD Standard Application Benchmarks for R/3 Release 4.6.

n In order to ensure acceptable network response times, the line utilization should not be higher than 50% (that is, L < 0.5). This is the case, because data is not transferred in a continuous stream but fluctuates statistically with several peak times.

n We recommend not using lines with a capacity less than 9,600 bits per second.

n Example:

� 12 users, 10 seconds think time, 2 seconds response time

� N = 12 , L = 0.5

� C = 28,000 x 12 / [0.5 x (10 + 2)] bits/sec = 56,000 bits/sec

� A 64,000 bits/sec line is needed.

SAP AG 1999

Router

Application/databaseserver LAN

Front end LAN/WAN Firewall

SAProuter Program

Route Permission Table:

D host1 host2 serviceXD host3P host4 host5 * PasswordP 155.56.*.* 155.56

Router and SAProuter

n Hardware or software routers link networks and provide firewall functions at a physical level. They provide secure communication between the front end LAN/WAN and the Server Network (LAN) connecting the machines that host the application servers and the database server.

n Hardware or software routers are used to restrict communication with individual ports or all ports. They usually possess two interfaces and/or specialized routing software. They act as a firewall at a physical level.

n SAProuter is another type of router that gives you control over who accesses your R/3 System. However, it is no substitute for hardware or software routers. The SAProuter program should be used in addition to a hardware router and runs on all R/3 platforms. It channels communication through a central point and is required for remote connection to the SAPNet R/3 Front End. It acts as a firewall for R/3 at the application level.

n SAProuter follows a route permission table such as the one shown above. It denies communication between host1 and host2 using serviceX and communication originating on host3. It permits communication between host4 and host5 using all services as long as the provided password is correct. It also permits all routes within subnetwork 155.56. For more information on denies and permits, refer to Basis Components >> Kernel Components (BC-KRN) >> BC SAProuter in the SAP Library.

SAP AG 1999

Network Structure: An Example

R

R R

R

Server LAN

BackboneSubnet1 Subnet2

WAN

n If you are planning to establish a connection to company subsidiaries using WAN networks, you must ensure sufficient bandwidth, network security, data integrity, and the network availability for each subsidiary. Compare the cost of the different possibilities.

n BAPIs (Business Application Programming Interfaces) are available for many R/3 business transactions and allow R/3 to be used through the Internet in conjunction with a browser and the Internet Transaction Server (ITS).

n When planning a network:

� Estimate and measure the average and peak network load.

� Check the availability of network hardware components.

� Confirm the reliability of remote connections.

� Train your network administrator.

� Discuss a backup solution (worst case scenario ).

n Connections between your R/3 System and external systems affect the performance, availability, and security of your R/3 System. There are several ways of implementing such connections. For more information, see the White Paper Network Integration Guide in SAPNet using the alias NETWORK.

SAP AG 1999

ASAP Phases: Network Design

1

2

3

cont

5

4

R/3 project leadSystem administratorNetwork administrator

Technical team

Technical team leadNetwork administrator

O/S administratorTechnical Consultant

l Install and configure network environmentl Install and configure network environment

l Determine failure scenariosl Determine failure scenarios

l Plan technical requirementsl Plan technical requirements

l Order remote network connectionsl Order remote network connections

l Create and approve technical designl Create and approve technical design

l Configure remote network connectionl Configure remote network connection

l Document network topologyl Document network topology

l Conduct Basis & system administration workshopl Conduct Basis & system administration workshop

Network administrator

l Conduct stress testl Conduct stress test

l Train system administration staffl Train system administration staff

n In phase 1, Project Preparation, your project lead coordinates the planning of technical requirements for your implementation, including network sizing and hardware acquisition. Be sure to plan a remote network connection with SAP to enable remote service delivery. Your system administrator completes the technical questionnaires.

n In phase 2, Business Blueprint, your technical team lead documents your network topology in cooperation with your network administrator and your operating system administrator. Use the communication requirements for each business area to create a blueprint for your hardware, your operating system, your database, and your network. Set up the remote connection to SAP. Your technical consultant usually provides a system administration workshop for the implementation project team, who will subsequently be the power users.

n In phase 3, Realization, your network administrator installs and configures the network for the production environment and provides input on network system availability requirements. In addition, plan for network failure scenarios and test the availability of your network.

n In phase 4, Final Preparation, your technical team prepares and conducts the stress test. Train the system administration staff for the post-going live period using on-site workshops or with the help of power users.

SAP AG 1999

Security: Key Questions

l System administratorl Database administratorl Operating system administratorl Network administratorl Technical consultant

WHO?

l Secure system environmentsl Establish authorization conceptHOW?

WHAT?l Provide security for the system layers

l Provide security for the communication layers

n The purpose of system security is to protect business data from unauthorized access and unintentional changes. It involves all three layers of the R/3 System and the network connecting them.

n In the ASAP methodology for implementing R/3, the development system and the quality assurance system are secured first. Next, authorizations are set up to ensure R/3 users can only access a specific set of transactions and only perform certain predefined activities.

n It is the responsibility of your system and network administrators to plan your system security strategy. Your technical consultant should provide them with technical advice about security matters.

SAP AG 1999

Layer Components Security Aspects

SNC: Secure Network Communications interface

Security Aspects

Authorizations, locking usedobjectsApplication

Access control / password,SNC, Integrity Check

Presentation GUI, front end

Application modules,work processes,enqueue server

Access protection of R/3 data,logging, administration

Database Relational database

Access protection of R/3 data,operating system commands,

administration

Operatingsystem

UNIX, WindowsNT, OS/400, S/390

Access control lists,SNC, GSS-API V2,

SAProuterCommunication SAProuter, network,

SNC

n Secure the presentation layer by restricting access to the SAP GUI and other user interfaces connecting to your R/3 System.

n Secure the application layer by restricting the access logged-on users have to transactions and data.

n Secure the operating system layer by restricting the execution of operating system commands affecting R/3 directories.

n Secure the database layer by restricting access to the database.

n Secure the communication layer by restricting communication between the presentation layer and the R/3 application server, and between R/3 and external systems.

SAP AG 1999

Security: Presentation and Application Layers

Presentation Layer

Application Layer

Make use of the SAPsystem authorizationconcept

Security concerns:l Virus affecting SAP GUIl Malicious logon attemptsl Information theftl Viruses in general

Protective measures :l Integrity check of SAP GUIl Password-protected screensaverl Remove floppy drivesl Anti-virus software

R

R

Securing the desktop layer

n Unauthorized users can access R/3 data through unattended workstations logged on to the system. To prevent this, SAP recommends using auto-logout features and screen savers with password control. All passwords should have limited validity and an obligatory number of characters. Analyze and use the security features of the operating system of your front end to secure locally stored data and remote access. Also consider the danger posed by viruses. Supply the front end with appropriate anti-virus software and update it regularly.

n R/3 authentication during logon has security options (for example, password validity time) defined by the system parameters, which can be easily changed.

Securing the application layer

n Use the R/3 authorization concept to secure your system. Do NOT issue the following authorizations for the production system:

� Editor authorization for ABAP objects

� Debugger replace authorization

� Assign authorization for using the Workbench Organizer to create, change, or release/export change requests

n In addition, do not allow Repository and client-independent Customizing in the production system. Do this using transaction SE06 (system change option) and transaction SCC4 (client change option).

SAP AG 1999

Security: Database and Operating System Layers

Database Layer

Operating System Layer

Protective measures:l Strictly control user SAPR3l Strictly control database super userl Control non-R/3 access to the databasel Separate development and production

Security concerns:l Physical access to hardwarel Predefined users such as <SID>adm and <DB>adml Operating system users such as root and sysadml File system structure and directory access attributes

R

R

Securing the database layer

n At database level, the SAP database user SAPR3 can access, change, and delete any kind of data in the R/3 System. Therefore, you must carefully protect this user's password. SAP recommends changing the preset password for this user immediately after R/3 installation. Each database provides its own super user or administrator IDs. These users should be managed with the same care as the SAPR3 user. For non-R/3 access to the database through the database interface, create specific users that have read-only access. Changes to data in the SAP System from the ‘outside’ can cause data inconsistencies in your database. This results because SAP’s data model, including all relationships between data objects, is stored in the SAP Repository, not in the database dictionary.

n Backup tapes should be kept locked in a fireproof safe.

n Provide two separate systems for development and production to ensure production stability.

Securing the operating system

n You must strictly control passwords. Enforce regular password changes. NO root/root-access.

n An SAP System requires very few operating system user IDs. To simplify your password control procedures, avoid creating new user IDs for the operating system and database of a production R/3 System. The file system and file attributes configured by the R/3 installation procedure should be well understood and restricted.

n Prevent unauthorized access to hardware and the rooms housing it.

SAP AG 1999

�ydfghg�rmv\

SAP GUI

Other R/3applicationserver orexternalprogram

SAP's Secure Network Communication (SNC)

Security: Communication Layer

Database

SAP's Secure Store and Forward (SSF)

Security concerns:

l Unauthorized network cable access, network spying

l Connections to offsite destinations such as subsidiaries

l Access to hardware and software routers

l Use of SAProuter to access the SAPNet R/3 Front End

Printers

n Network security concerns include hardware (such as network cables) and remote connections (such as those used by field employees).

n To secure remote connections, use dial-in or call-back procedures, as well as hardware and software routers. Only authorized staff should have access to the routers.

n SAProuter, delivered with the standard installation, is a security tool that checks connections allowed by the hardware routers and offers an additional password check. SAProuter should always be installed together with a software or hardware router or another firewall-implementing software. SAProuter controls access to R/3 using a route list. For more information, see the topic Network Design in this unit.

n Secure Network Communications (SNC) is an R/3 interface that allows you to use external security products providing, for example, cryptographic mechanisms, smartcards, and single sign on. The features of SNC can be implemented in addition to the standard function provided by your SAP System. Authorizations are not affected by SNC and are still handled in the system.

n Secure Store and Forward (SSF) is another SAP System interface that enables communication with external security products using digital signatures and digital envelopes.

SAP AG 1999

ASAP Phases: Security

1

2

3

cont

5

4 Technical team leadSystem administrator

Technical team leadSystem administratorTechnical consultant

l Secure development systeml Secure development system

l Configure remote network connectionl Configure remote network connection


Authorization administrator

l Secure production environmentl Secure production environment

l Secure quality assurance systeml Secure quality assurance system

l Define production system securityl Define production system security

l Secure operating system and databasel Secure operating system and database

l Define interface test proceduresl Define interface test procedures

l Establish authorization conceptl Establish authorization concept

SAP AG 1999

Interfaces: Key Questions

l Technical team leadl Application consultantl Interface developerl Power user

WHO?

l Determine required interfacesl Create interface programsl Define interface test procedures and strategiesl Check interface test results

HOW?

WHAT?

l The right interface for the right purposel Fast, reliable and secure interfacesl Easy-to-monitor interfacesl Restart and recovery capabilitiesl Certified interfaces

n Interfaces are fast, reliable, secure, and useful if they:

� Are easy to monitor

� Have restart and recovery capabilities

� Use standard techniques

� Are upward-compatible (they require no more than minor changes after an R/3 upgrade)

� Are certified through SAP's Complementary Software Partner (CSP) program

� Are necessary (you should avoid nice-to-have or unnecessary interfaces)

� Affect the correct business objects and no more than the minimum required number of business objects

n Perform interface maintenance when:

� You have new requirements or want new functions

� You need a release upgrade or bug fixing

n Interfaces play a role in the following ASAP phases:

� Project Preparation: You determine the required interfaces.

� Business Blueprint: You choose an interface technology and perform detailed interface design

� Realization: You implement and test interfaces.

SAP AG 1999

Permanent or temporary interfaces?lBig Bang needs only a few permanent interfaceslPhased Roll Out needs many temporary interfacesl To connect individual branches or satellite systems, you

may need both permanent and temporary interfaces

Standard or self-made interfaces?l Are standard non-SAP interfaces available?l Will the 3rd party interface be certified by SAP?l Are SAP-standard interface techniques used?

Mass data or time-critical data?l Mass data needs asynchronous interfaces(background processing interfaces)l Time-critical data needs synchronous interfaces(online interfaces)

Determine Required Interfaces

n When determining which interface to use, weigh the advantages and disadvantages of:

� Synchronous and asynchronous interfaces

� BAPIs, Batch Input, Direct Input, RFC, ALE, and OLE interfaces

� Mass data and time-critical data interfaces

� Temporary and permanent interfaces

n Test the interface throughput with realistic data under a realistic load. This is one example of a realistic test situation for a given company: 25,000 debits and 50,000 purchase orders must be transferred overnight from an external system to R/3. The chosen interface is Batch Input. Batch operations must be performed between 8 p.m. and 6 a.m. Additionally, a full offline backup must be performed, and new material masters must be transferred from R/3 to another external system. Will all these jobs finish before 6 a.m.?

n To determine which interfaces you need and how to implement them, make use of the examples and case studies shown on the Interface Adviser CD (mat. no. 50026902). Also see the related material on SAPNet under the alias \INT-ADVISER.

SAP AG 1999

R/3R/3 R/3R/3

non-SAPnon-SAP

InterfaceInterface

Restart and Recovery

If the interface fails, can I restart it or do I need to recover the database?

n Establish procedures for determining:

� Which systems must be restarted

If the interface fails

If non-SAP systems fail

If one of the SAP Systems fails

� Which systems must be recovered

If sent data never arrived at the target system

If data was sent twice

n You must define these procedures in the ASAP phase, Business Blueprint.

SAP AG 1999

OLERFCSequential files

ALE, BAPIsRFC, CPI-CABAP Open SQL, ABAP Native SQL Batch input (BDC)CALL TRANSACTION ..., Direct InputSequential Files

Database operations (SQL)

R/3 Interfacing Techniques

SAP System Possible interfaces:

Presentation Layer

Database Layer

Application Layer

n Data communication options include:

� Communication with the database using DB SQL (not recommended) or ABAP Open SQL

� Asynchronous communication using file transfer

� Synchronous communication through the network

n At database level, although ABAP supports Native SQL, table updates usually cause data consistency problems because of the complexity of business data structures, which are stored in the SAP Repository, not the database dictionary. Therefore, direct database accesses to SAP tables should be read-only . Such accesses will, however, bypass the SAP authorization concept. Make changes by using the relevant SAP transaction programs with the function Batch Input or the ABAP statement CALL TRANSACTION ... USING.

n At application level, the following interfacing techniques are available, listed from the highest to lowest level in the communication layer hierarchy: Business Application Programming Interface (BAPI), Application Link Enabling (ALE), RFC, CPI-C, and accessing sequential files on the application server and the front end.

n At front end level, the following Basis techniques are available, listed from highest to lowest level: Object Linking and Embedding (OLE), RFC, and accessing sequential files.

n SAP recommends using interfaces certified by the SAP Complementary Software Program (CSP).

SAP AG 1999

SalesAsia

SalesAsia

Manu-facturing

+Sales US

Manu-facturing

+Sales US

SalesEuropeSales

Europe

ApplicationApplication

R/3 or non-SAP system

Application ApplicationR/3 System

BAPIBAPI BOR

Interface Integration: Two Examples

2. BAPI

1. ALE

ALE

n Local purchasing, invoiceverification

n Inventory Management

ALE

n Reference system formaster data and controltables

n Financialsn Central controlling

PRODUCTION

n Sales, shipping,and billing

n Purchasing oftrading goods

SALES

R/3 R/3 R/3

HEAD OFFICE

n Example 1: Application Link Enabling (ALE)

� Connects R/3 Systems and enables exchange of application data

� Must have client-independent and global Customizing that is compatible (country-specific Customizing can be incompatible)

� Requires setting up logical systems and RFC destinations

� Does not require that all R/3 Systems are running or that all R/3 application components are implemented on each R/3 System

n Example 2: Business Application Programming Interfaces (BAPIs)

� Object-oriented approach for accessing R/3

� Defined in the R/3 Business Object Repository (BOR), as are the business processes that can be used through BAPIs

� Can link, for example, different sales subsidiaries of an international company

SAP AG 1999

Scalability for Internet Transactions

ITS

AS

DB

Web client

Web server

R/3 applicationserver

AS

ITS

WebS WebS WebS

SAP InternetTransaction

Server(on Windows NT)

R/3 internet transactionserver topology

ITS

R/3 databaseserver

ASAS

n The Internet Transaction Server (ITS) provides great scalability, because you can use multiple ITS servers.

n Memory requirements for the R/3 application server depend on the:

� Number of active, simultaneously logged-on users in the application server

� Time-out parameter, which automatically logs off inactive users after a certain time

n The network load between the ITS and the R/3 application server is equal to, or preferably less than, the network load between the SAP GUI and the R/3 application server.

SAP AG 1999

Internet Application Components (IACs)

n Internet Application Components (IACs) are complete solutions for connecting an R/3 System to the Internet. They enable R/3 business functions to be executed using a Web browser.

n The technological basis for IACs is the Internet Transaction Server (ITS). The ITS forms the interface between an HTTP server and an R/3 System. The software is available as of R/3 Release 3.1G and runs under Windows NT 4.0 (server version).

n To help users connect the R/3 System to the Internet, SAP is continuously creating new IACs for important business applications. These can be used either directly or as a template for your own developments.

n The advantages of offering business services on the Internet, include:

� Business processes can be extended to involve the public through the Internet. You can use components like Warehouse Management with direct data input by the buyer.

� Direct data entry by the customer speeds up business processes and reduces costs.

� The user interface of an IAC can be designed in such a way that it is self-explanatory, thus eliminating the need for time-consuming and costly training courses.

SAP AG 1999

ASAP Phases: Interfaces

1

2

3

cont

5

4

Technical team leadApplication consultant

Interface developerPower user

R/3 technical project leadApplication consultant

l Design interface in detaill Design interface in detail

l Select interface techniquel Select interface techniqueTechnical team lead

Application consultantInterface developer

l Develop interfacesl Develop interfaces

l Test interfacesl Test interfaces

l Ensure interface maintenancel Ensure interface maintenance

l Test performance under realistic loadl Test performance under realistic load

l Determine required interfacesl Determine required interfaces

l Plan how to use resources efficientlyl Plan how to use resources efficiently

n In phase 1, Project Preparation, you and your technical project lead decide on company process distribution and integration scenarios Your application consultant helps you realize the selected scenarios in the R/3 Systems.

n In phase 2, Business Blueprint, your project team determines the affected business objects (such as material master or vendor master records). The technical team lead and interface developer select the interface technology (for example, BAPI or RFC), the interface design (Online or background processing? Used for time-critical data? Synchronous or asynchronous?), and the restart and recovery scenarios.

n In phase 3, Realization, your technical team lead and application consultant define and document recovery procedures to achieve short recovery downtimes. They also determine whether any upstream or downstream interfaces are affected during recovery and check the restart procedure. The interface developers write the code for all interfaces. In the development system and then in the quality assurance system, you must test each interface for the following:

� Data consistency (no double records or data losses)

� Performance (under realistic production load and when all interfaces are active)

� Workload distribution between application servers (to avoid a database server overload)

� Restart and recovery

SAP AG 1999

High Availability: Key Questions

l Technical teaml Project leadWHO?

l Ensure availability of system componentsl Set up service level agreementsHOW?

WHAT?l Reduce planned and unplanned downtimel Develop procedures for failure scenarios

n There are a variety of high availability solutions that you can choose from. Determine the amount of availability you require for your R/3 System and then analyze different possible solutions.

n The High Availability Questionnaire focuses on the causes of planned or unplanned downtime to help you make your system more available.

n Before adopting high-tech solutions for the high availability of your database, network, or operating system, consider:

� Simple measures for improving the availability of the R/3 services

� External service level agreements with your hardware providers to ensure fast hardware replacement

� Internal service level agreements between the IT department and other departments in your company to specify what degree of availability is ensured internally and what the costs are

n System availability is important for all application areas. It is the responsibility of your project manager to coordinate the planning for high availability. The technical team is responsible for keeping the system running and performing recovery of the system or its components.

SAP AG 1999

What is High Availability?

l Costs of a high availability solution versus costs ofunplanned downtime

l Effect of reducing maximum tolerable unplanned downtimeon the cost of a high availability solution

l Effect of a high availability solution on costs of planneddowntime for maintenance

Goal: 100% Uptime?

n As more and more customers use R/3 to support critical business functions such as sales, order entry, and continuous manufacturing for their global operations, the need for maximized system availability becomes increasingly important. Many companies now require 24 x 7 reliability for their R/3 Systems, that is, 24 hours a day, 7 days a week.

n System availability is defined as the percentage of time a system can be used for its intended purpose. Availability is not dependent on a single piece of hardware or software, but is affected by all system components.

n In addition to the time a system is up and running, system availability also involves the degree of required throughput and the acceptable response times for core business processes that are achieved. Therefore, performance monitoring and tuning measures should also be included in a high availability solution.

n High availability is a technically complex area, and implementation considerations vary according to the nature of your system setup. For detailed technical guidance when implementing a specific product or feature, contact your TeamSAP consultant or your hardware vendor.

SAP AG 1999

What are your singlepoints of failure?

What does downtime costyou?

What preventativemonitoring procedures do

you need?

Considerations for High Availability

Does your network havebuilt-in redundancies?

n Make a list of all single points of failure (SPOFs) in your systems before you start to build high availability functions into your system. The way your system is configured defines what is a SPOF. For example, a disk drive that is a SPOF in a given system may no longer be a SPOF when mirrored. Check for SPOFs in R/3 Services, your database, your network, your hardware, and your operating system software. Ask yourself if you can afford the failure of each SPOF.

n To determine which network components must be redundant, see the White Paper Network Integration of R/3 Servers (mat. no. 51006371).

n Once you have determined the preventative monitoring procedures required, ensure all appropriate staff members receive training in these procedures. Also document these procedures in your technical operations manual.

n For help identifying areas that need preventative monitoring, see the Database Layer unit, the SAP System Administration Assistant (transaction SSAA), and SAP Note 16083.

n By obtaining assistance from SAP’s proactive remote services, you can identify potential future failure situations. For more information on the SAP EarlyWatch Service, SAP GoingLive Check Service, and SAP EarlyWatch Alert, see the unit Technical Operation or SAPNet under the alias TEAMSAPSUPPORT.

SAP AG 1999

Hardware Service Failure of

Hardware/operating sys./network

Electrical Power supply

Presentation layer Server (for example PC)

Application layer Server

Database layer Server

CPU+

Server network LAN Card(database & application server)

LAN cables, network computers bridges, routers, and so on

Access network LAN card(application server & PC

LAN cables, network computersbridges, routers, and so on

Hard disk

High Availability Solution

Uninterruptable power supply)

Central Instance switchable, no. of Appl.servers >1

Database switchable, disaster recovery mechanisms

Disk mirroring

SAP GUI Reconnect

Redundant network technology

•Physical layer•Redundant physical network path, bridges, routers•Redundant Network Interface Cards (NIC)

Crash Kit

n Setting up an uninterruptable power supply is relatively inexpensive and should be done early to avoid the effects of power failure.

n For the application layer and the database layer, set up:

� Standby servers, in case of server failure

� Hardware clusters to increase both availability and performance. Use symmetrical multi-processing (SMP) with SMP servers as the cluster nodes

n There are two principal technologies for storing data redundantly in high availability disk systems:

� Hardware-driven redundancy with a redundant array of independent disks (RAID)

� Software-driven redundancy using, for example, Logical Volume Manager (LVM) software, which ensures data is written to physically redundant (mirrored) locations on disks

n High availability is required in the network connecting the application servers to the front ends.

n The application servers should be connected to the database server through at least two different routes to avoid having a single point of failure.

n In addition to the above hardware components, a crash kit should include everything you need to rebuild, reinstall, or recover your R/3 server, database, and related files. This could include a disaster recovery script, installation instructions, installation kits, documentation, key phone numbers, and copies of your tpparam and saprouttab files. For more information, refer to the System Administration Made Easy Guidebook.

SAP AG 1999

SAP support network

Notification, Escalation, and Recovery

R/3production

CCMS Monitor

System AdministrationAssistant

System management softwareAll CCMS ALERTS

R/3 interface Monitoring andtroubleshooting

Customer and partner experts

n Clearly define and test in advance your notification, escalation, and recovery procedures. Your administrators can automate much of the notification process. By using SAP’s CCMS (Computing Center Management System) and CSP (Complementary Software Program) system management solutions, your administrators can monitor and even automate the R/3 Alert Monitor information to ensure they are notified as soon as a problem arises.

n Management procedures are required for the following important areas: system configuration, change management, R/3 upgrades, system failure, switchover software, R/3 archiving, cluster administration, R/3 System monitoring and tuning, database administration (backup, upgrades, monitoring, tuning, and disaster recovery), network failure recovery, error reporting with follow up, and system load assessment for mission-critical applications.

n Determine the persons who may access SAPNet Support Services or the SAP Hotline, and the relevant procedures well before going into production.

SAP AG 1999

ASAP Phases: High Availability

1

2

3

cont

5

4


Technical team leadTechnical consultant System administrator

Technical team leadTechnical consultantSystem administrator

Database administrator

l Define backup strategyl Define backup strategy

l Define disaster recovery proceduresl Define disaster recovery procedures

l Design production system disk layoutl Design production system disk layout

l Develop system test plansl Develop system test plans

l Define service level commitmentl Define service level commitment

l Plan technical requirementsl Plan technical requirements

n In phase 1, Project Preparation, your technical team lead and your technical consultant clarify your expectations, review the hardware sizing, and arrange for the supply of hardware. Your system administrator completes the High Availability Questionnaire and discusses high availability solutions regarding the database server or switch-over solutions with your hardware partners.

n In phase 2, Business Blueprint, your database administrator, your technical team lead, and your system administrator define backup strategies for the development and production systems. The possible downtimes for backups and maximum downtimes for recoveries included in your backup strategy must be acceptable to all members of the project team.

n In phase 3, Realization, your steering committee defines the maximum acceptable downtimes. Check whether these downtime figures can be achieved with the hardware currently installed. Your technical consultant, your technical team lead, and your system administrator define, test, and document backup strategies and disaster recovery procedures, including restart procedures (for example, for interfaces and background jobs) and system disk layout. Your network, database, and operating system administrators test all high availability components. For further information on disk layouts, network design, and switchover technologies, see SAP Library BC >> Computing Center Management System (BC-CCM) >> BC SAP High Availability. In the ASAP Activity Define Service Level Commitment (in the Work Package System Management), determine possible failure scenarios for each system component and define the service level commitment for internal and external service contracts.

SAP AG 1999


Overall Design: Unit Summary

l Discuss sizing considerationsl Describe network requirements for R/3l List fundamental security considerationsl List different interface technologiesl Relate central issues regarding high availability

n Critical Success Factors for:

� Sizing: Ensure you have sufficient initial sizing, allowing for business volume growth. Recognize the need for re-sizing throughout the entire life cycle of your system. Rely on the assistance SAP provides in the form of GoingLive Checks, the EarlyWatch Service, and EarlyWatch Alert.

� Network Design: Determine and test your network load. Check the availability of network components and the reliability of remote connections.

� Security: Implement user authentication by password and authorization checks during transaction use in R/3. At database level, protect all R/3 data. At the communication layer level, rely on compression, SAProuter, and Secure Network Communications.

� Interfaces: Establish maintenance and monitoring procedures for each interface. Determine the effect interfaces have on overall workload. Check whether interface throughput is sufficient. Use interfaces that are recoverable. Determine how other systems are affected in a recovery case, and document recovery procedures for all interfaces.

� High Availability: Determine a realistic uptime, taking into account the need for planned downtime and the probability of unplanned downtime. Use the Checklist for Single Points of Failure (SPOF). Take advantage of SAP functionality supporting high availability.

n A more detailed list of Critical Success Factors for these topics is provided in the appendix.

SAP AG 1999

Further Documentation (1)





l SAP Library

n BC >> Computing Center Management System >>BC SAP High Availability

l SAPNet

n Alias QUICKSIZER

n Alias INT-ADVISER

n Alias TEAMSAPSUPPORT

SAP AG 1999

Further Documentation (2)

l SAP Notes

n 16083: Standard jobs, reorganization jobs

l SAP’s Integration of R/3 Servers in TCP/IPNetworks

l Interface Adviser CD (mat. no. 500 26 902)

l White Paper

n Network Integration of R/3 Servers (mat. no. 510 06371)

Exercises

Unit: Overall Design

Topic: Sizing


• Roughly estimate your R/3 System requirements

The Quick Sizer is a tool accessed using SAPNet - Web Front End. It has been developed by SAP in close cooperation with all platform partners to make the sizing of an R/3 System easier and faster.

This tool will help you translate your business requirements into technical requirements. Based on the results, you can select an economically balanced system that matches your company's business goals.

1-1 Use the Quick Sizer to approximate your sizing requirements.

Access the Quick Sizer on SAPNet using the alias QUICKSIZER.

Customers: http://sapnet.sap.com/quicksizer

Internal: https://intranet.sap.com/quicksizer

Enter your customer ID and a project name. The project name can be the actual name of your implementation project or any fictitious name.

The answers to the questions depend on your company’s specific system structure and business practices.

Solutions

Unit: Overall Design

Topic: Sizing

The answers to these questions depend on your company’s specific standards, installation, and system requirements.

1-1 The Quick Sizer calculates CPU, disk and memory resource categories based on the number of users working with the different components of the R/3 System in a hardware- and database- independent format. The tool gives you a sizing estimate of the system necessary to run the required workload. This is also useful for initial budget planning. Direct links to SAP's hardware partners help you get information on prices and availability.

For more information, see the Quick Sizer Fact Sheet (mat. no. 50 028 963) in the appendix.

Frequently Asked Questions about Sizing Can I download the sizing tool? The Quick Sizer is a SAPNet-based tool that cannot be downloaded. However, you can download an offline questionnaire as the basic input for the tool.

Shouldn't my hardware vendor do the sizing? SAP´s hardware partners are still responsible for the final sizing and configuration of your systems. By teaming up with all hardware partners to develop a joint sizing tool for collecting all hardware neutral input parameters, SAP has simplified the sizing process.

How do I size the new components such as APO and Procurement? Sizing Papers with information about new products are available for all customers and partners. In the future, we will add questions about the new products to the Quick Sizer.

Does your sizing incorporate upcoming upgrades? Sizing is always based on the most current level of the R/3 product. Delta sizing can be handled using relevant SAP Notes, such as SAP Notes 89305 or 113795.

What is the critical/limiting hardware piece? In most benchmark tests and customer production systems, the CPU power of the database server was the limiting factor. Therefore, we recommend that you ensure an accurate sizing of the database server.

How accurate will the sizing estimate be? The more detailed the input to the sizing tool, the better the sizing results will be. Sizing is not a one-time job; it is an iterative process. Investing time in re-evaluating your sizing is time well spent.

SAP AG 1999


Overall Design

Going Live

Technical Operation

Going Live

SAP AG 1999

Going Live

Contentsl Cutover to a production R/3 System

l Data conversion for transfer to a production systeml Testing and verifying a production system

l GoingLive Checks

ObjectivesAt the end of this unit, you will be able to:l Indicate the key issues in achieving a smooth transition

from a pre-production to a live production R/3 System

SAP AG 1999

FinalPreparation


Go Live &Support

Going live Specific date to start production operation

Going live project Project phase to prepare for going live

GoingLive Check A three-session SAP service before and afterproduction start

ASAP Phases for Going Live

Going Live Project

Going Live Project

Go LiveGo Live

n The weeks immediately before and after going live, that is, the beginning of production activities, are the most critical in the R/3 implementation process. During this time, you need to set up a going live project that encompasses systematic checks for performance or functional problems. SAP’s GoingLive Check complements your going live project by giving your project team additional support.

n At the beginning of ASAP phase 5, Go Live & Support, your production R/3 System goes live.

n Your help desk and the intensive support of the going live project team during the first few weeks of operation ensure that your business and technical processes run smoothly. After the third session of the GoingLive Check, normal support for end users begins.

n Routine maintenance ensures stable operation and must include:

� Scheduled backups

� System performance monitoring

� Database growth management

� User administration

� Support for additional changes

SAP AG 1999

FinalPreparation


Go Live &Support

4 Weeks

Verify systemenvironment and

changemanagement

Cutover Verify andfine-tune

4 Weeks4 Weeks

Conduct:• System tests• Volume test

• Stress test

CoreTransactionAnalysis

GoingLiveCheck

GoingLiveCheck

GoingLiveCheck

A Model Going Live Project

Go LiveGo Live

n During the going live project, you have to:

� Verify your system environment

� Verify sizing during the GoingLive Analysis Session prior to going live (based on your quantity estimates)

� Verify change management

� Conduct system tests, such as volume tests of core transaction performance and the stress test

� Verify system sizing and fine-tune the system after going live (based on actual system utilization)

n The example going live project shown here lasts 12 weeks. It begins eight weeks before the start of production, after all implementation efforts have been completed.

n The system checks before going live require eight weeks.

n Based on our experience, after going live, you need approximately four weeks for system observation and fine-tuning.

n SAP provides GoingLive Checks to offer you support during all of these tasks.

SAP AG 1999

Going liveproject

Verification Goal

• Identical objects and Customizing in all systems within the landscape

Final PreparationGo Live

& SupportRealization

System Landscape Verification

• Transport paths• System and client change options

Change Management Verification

• Change requests originate only in thedevelopment system

• No direct changes to production system

• Successful import of change requeststested in the quality assurance system

• No exceptions to modification strategy

• Documentation of change request history

Verifying Change and Transport Management

Realization Final Preparation Go Live & Support

n To verify change management, you must:

� Record all changes to change requests (which ensures the change history is documented)

� Verify change requests in the quality assurance system before transporting them to the production system

� Use only change requests for Customizing and Repository objects, as well as data imported with data conversion techniques to set up your production system

n For all Customizing changes, you must:

� Verify that changes originate in a single Customizing client

� Set client change attributes according to the role of the respective client

� Use Implementation Guide (IMG) project management and documentation features

n When you make your own developments, you should:

� Use system and client change options to restrict development to a single R/3 System

� Group developments logically and functionally using development classes

� Maintain documentation standards for all development work

� Avoid modifications and repairs

SAP AG 1999

Define corebusiness

transactions

Monitorperformance of

core transactions

Unacceptable test results?• Conduct transaction analysis• Make required changes• Test and verify changes

Monitor performance ofcore transactions during

stress test

Start of Production

System Tests: Core R/3 Transactions

n The analysis of core R/3 transactions is a critical part of the going live project. Perform this analysis prior to the stress test. A stable production system ensures accurate analysis results.

n Core transactions include transactions that are:

� Frequently used (and therefore performance critical)

� Critical to daily business activities

� The result of your own modifications or development

n Examples of core transactions in the following application areas include:

� Sales and Distribution (SD): Create Sales Orders (transaction VA01), Create Outbound Delivery (transaction VL01), Create a Billing Document (transaction VF01)

� Material Management (MM): Post Goods Receipt (transaction MB01)

� Finance (FI): Create a Document (transaction FB01)

n Transactions with slow response times (for example, greater than two seconds) even on a stable, low-load production system need your special attention. To improve transaction performance, you may have to make a Customizing or development change. Make changes in the development system and transport them to the quality assurance system for testing. After verifying the resulting improvements, transport them to the production system and repeat the performance analysis.

SAP AG 1999

System Tests: Stress Test

What?Simulate expected workload

Verify system configuration and robustness

When?Prior to production start (initial start, new applicationcomponents, sites, rollouts)

Prior to major changes, such as hardware migration

Why? To prepare the production environment forproduction activities

Set realistic expectations for workload throughput

Detect potential performance bottlenecks

How?

n A stress test is a high workload simulation that allows you to monitor and analyze the behavior of your system when you apply a representative workload to it.

n A stress test reveals:

� Whether specific system components are appropriate (for example, CPU, memory, or database)

� How your system configuration performs, enabling you to ensure high transaction throughput in a multi-user environment

� How your system behaves under different workload scenarios

� Whether your expectations regarding workload throughput are realistic

� Where performance problems could occur

� Whether alternative configurations may be more effective for handling the expected workload (for example, reserving certain application servers for a specific workload type)

� Whether important system administration procedures (such as backup and recovery) are effective

SAP AG 1999

System Tests: Stress Test Methodologies

Real User Approach

Simulation using actual users

Scripting Tools

Artificial usersimulation

More realistic typing speeds,think times, etc.

Tests your Customizing

Difficult to replicate

Only limited number of active users possible

Easy to repeat

Number of active users onlylimited by hardware

Only tests small subset oftransactions

Assumes ideal userinteraction

n The real user approach is a simulation using actual, logged-on users. Alternatively, using scripting tools, you can artificially simulate multiple users by creating scripts to simulate standard transactions in application components, such as FI, SD, MM, and PP.

n Other advantages of the real user approach:

� You use actual data.

� You have direct user feedback for easily identifying any inefficient user code.

� You can easily detect data consistency issues.

n Other advantages of scripting tools:

� You can easily verify tuning measures.

� You have greater control over the stress test.

Other disadvantages:

� The system can have only little or no Customizing.

� The setup time can be quite long.

� The tests are release-dependent.

SAP AG 1999

Installproduction

system

Create productionclient by applyingchange requests

Run dataconversionroutines formaster data

Verifydata

Performstress test

Perform finaldata

conversionactivities

Backup R/3 System

Restore R/3 SystemRestore R/3 System

Conduct systemtests:

• Backup/Recovery• System Admin.• Printing/Fax

Conductvolume test

of legacydata

conversions

Start of Production

Cutover: Testing and Data Conversion

n Cutover to production has several stages, including data conversion and testing.

n Prior to data conversion and migration of the configuration data and development objects to the production system, you have to perform several system tests on the production environment, including a backup/recovery test, output management tests (printing/faxing), and the validation of all system administration procedures outlined in your technical operations manual.

n Cutover tasks for data conversion include the following:

� Defining the type, structure, and quantity of the legacy data

� Performing test data conversion to ensure conversion preserves data integrity

� Confirming data consistency and quality by checking random samples

� Performing import tests with small data volume for runtime estimate

� Running tests in the (mirrored) production system

� Running a stress test with support from SAP Consulting

� Confirming required resources for real data conversion

� Converting real data

n After each stage of the cutover phase, make offline backups of the database to ensure data integrity. If data integrity is lost, for example, during data imports or data conversions, you can use backups to restore your R/3 System to its state prior to the start of each stage.

n Check the runtime behavior of important business processes. This can be achieved with the assistance of the GoingLive Service and on-site consulting support during stress or volume tests.

SAP AG 1999

QTST

PPRD

Productionsystem

Quality assurancesystem

Manual

Automatic

Legacysystem

PRODData load

verification

l Develop interfaceprograms

l Testl Validate datal Ensure resource

availability

Data loadverification

l Develop interfaceprograms

l Testl Validate datal Ensure resource

availability

Cutover: Preproduction Data Load

n You can transfer data into your R/3 System from other R/3 Systems or legacy systems either manually or automatically. The automatic method is faster. Both methods can use the batch input function to ensure data integrity.

n When transferring data automatically:

� Create a data backup of the entire system, in case errors occur during transfer

� Carry out data transfer according to the deadlines and sequence described in your going live project plan

� Verify the data transfer

n You may prefer manual entry of historical or master data for small quantities of data or when it is too expensive to write conversion programs.

n When transferring data manually:

� Enter data according to the deadlines and sequence described in your going live project plan

� Create checklists to verify the correctness and completeness of the data entered

SAP AG 1999

Application areasApplication areas60%60%

Database and R/3 BasisDatabase and R/3 Basis30%30%

OperatingOperatingsystemsystem

10%10%

Potential for optimizing performance

Verification and Fine Tuning

n System response times are mainly impacted by:

� User requests to application servers

� Customizing transactions

n Therefore, you should focus your fine-tuning efforts on the applications to obtain the biggest performance gains for your R/3 System.

n Tune your database and operating system when:

� You have completed all possible application tuning.

� Application tuning cannot be successfully completed before going live. In this case, database and operating system tuning provide a quick fix.

SAP AG 1999

1st Session-2 Months

Analysis• Sizing• Configuration• Load distribution• R/3 Basis

Optimization• Central business

processes• Transactions with

high resourceconsumption

• Sizing

Verification• Configuration• Sizing• System usage and

bottleneck analysis

RegularEarlyWatchanalysis

2nd Session-1 Month

3rd Session+1 Month

Go Live& Support

FinalPreparation

Start of Production

GoingLive Check Sessions

n A GoingLive Check consists of three sessions:

� Analysis Session: In this first session, a GoingLive specialist checks the major R/3 System components for consistency and reliability. The check focuses on the configuration of your operating system, database, and R/3 Basis, as well as on how users and SAP processes are distributed among your individual servers. The integrated Sizing Plausibility Check evaluates the sufficiency of the existing hardware resources. In order to allow you sufficient time to obtain any necessary additional hardware, your GoingLive Check should be performed approximately two months before you go live.

� Optimization Session: This application-area analysis focuses on core business processes and identifies transactions with high resource consumption. Recommendations about application tuning are made in the session report. Additionally, recommendations are made about possible adjustments to your database configuration and system sizing. Ideally, this check should be performed four weeks before you go live.

� Verification Session: After you go live, your system components are re-examined. The changes based on recommendations from the two previous sessions are validated during production operation.

n For small R/3 installations, SAP offers the GoingLive Check as a remote service. For more complex R/3 installations, a more extensive Optimization Session may be conducted on-site.

SAP AG 1999

6 Weeks ??? Weeks

Time

Customizing and development not completed on schedule= Unstable pre-production environment

Customizing and development not completed on schedule= Unstable pre-production environment

Go Live& Support

Realization FinalPreparation

Start of Production

Going Live: Typical Problems

Number of problemsNumber of open issues

n Customizing and development must be completed before the start of phase 4, Final Preparation, to ensure:

� Sufficient time for adequate testing

� A stable pre-production environment for the GoingLive Check

n Even after you complete your implementation project, you may have to perform Customizing or make developments to solve functional or performance problems. This will require the transport of changes into the production environment during the going live project. To ensure the quality of these transports and limit the impact they have on going live, you should schedule regular transport periods. Too frequent imports have a negative effect on the performance of a production system.

SAP AG 1999


Going Live: Unit Summary

l Explain the important criteria for a successfulGo Live phase

n Critical Success Factors for Going Live:

� Verify sizing for the production system.

� Test a realistic volume of core business processes.

� Provide your production system administration staff with thorough training.

� Test data conversion programs, perform data transfer/conversion on schedule, and verify consistency of imported business data.

� Have your User Support Team ready to provide quick support.

SAP AG 1999


l White Paper

n SAP GoingLive Check



l SAP Made Easy Guidebook

n Initial Data Transfer Made Easy Guidebook(mat. no. 500 27 223)

l SAPNet

n Alias: TEAMSAPSUPPORT

n Alias: GOINGLIVECHECK

Exercises

Unit: Going Live

Topic: GoingLive Questionnaire


• List important considerations for going live.

1-1 Fill out the GoingLive Questionnaire for the Analysis Session.

Choose either the questionnaire for a standard GoingLive Check or for a GoingLive Functional Upgrade Check. Both versions are part of the appendix.

The answers to these questions depend on your company’s specific system structure and business practices.

Solutions

Unit: Going Live

Topic: GoingLive Questionnaire

Your answers to the questions included in the questionnaire will depend on your company’s specific standards, installation, and system requirements.

Pay particular attention to the paragraph that introduces each question. This short introduction explains how SAP will use the information you provide to better analyze your system needs and requirements.

SAP AG 1999


Overall Design

Going Live

Technical Operation

Technical Operation

SAP AG 1999

Technical Operation

Contentsl Technical operations manualsl Service level agreementsl Support organizationl Escalation management

ObjectivesAt the end of this unit, you will be able to:l Explain how to create and use a technical operations manuall Organize R/3 support and escalation procedures in your company

SAP AG 1999

AdministrationAdministrationPrefacePreface Global System DescriptionGlobal System Description SummarySummary

System LandscapeSystem Landscape

HardwareHardware

Document MaintenanceDocument Maintenance

Responsible AuthorResponsible Author

AboutAbout

SectionsSections

How to UseHow to Use

Document AccessDocument Access

DB AdministrationDB Administration

DB MonitoringDB Monitoring

Backup/RecoveryBackup/Recovery

SectionsSections SectionsSections SectionsSections

System AdministrationSystem Administration

Background ProcessingBackground Processing

User AdministrationUser Administration

Software LogisticsSoftware Logistics

UpgradeUpgrade

ChangeChangeManagementManagement

SecuritySecurity

In each section include:l Policiesl Proceduresl Roles and responsibilities

Your R/3 Technical Operations Manual

n The R/3 Technical Operations Manual is a documentation template that helps you document:

� System landscape and hardware configuration

� System administration tasks and guidelines

� Daily operation procedures

n When creating your technical operations manual, record:

� Which tools are used for database backup

� Whether the backup is offline/online, once a day, full or partial

� Who is authorized to reset passwords

� How frequently passwords are reset

� Which printer devices are reserved for which type of printing (for example, mass printing or time-critical printing)

� Roles and responsibilities

SAP AG 1999

PartnerSAP

External agreement with SAP

l Service level of yourchoice

l Remote connection

l SAPNet access

l Service options including:n GoingLive Checksn EarlyWatch Servicen Remote Services

Internal agreement

l Internal help desk

l Coordination with otherimplementation project teams

l Procedures for problemmanagement and escalation

l Customer Competence Center(CCC)

Customer

Department

CCC

External agreement withhardware or CSP partner

l Stipulated reaction times

l Delivery of spare parts

l Service connections toother companies

l Categorize proceduresby problem type

Service Level Agreements

n A Service Level Agreement is signed between:

� Customer and SAP (external agreement)

� Customer and hardware partner (external agreement)

� Customer and Complementary Software Program (CSP) partner (external agreement)

� Customer department and Customer Competence Center (internal agreement)

� Customer department and customer IT department (internal agreement)

n Each Service Level Agreement should cover:

� Application area description

� Required service procedures (including responsibilities and timing)

� System layout, for example, for desktop, network, application, database

� Obligatory reaction time of service provider

� Reporting and response procedures

� Escalation procedures

� For further information, see the Service Level Agreements in the ASAP Implementation Guide. For more information on establishing a Customer Competence Center, see SAP’s Customer Competence Center Manual.

SAP AG 1999

SAP Support

What does SAP offer you?

Help and CustomerEmpowerment

Prevention

Innovation

Proactivecorrections

Continualmonitoring

Thoroughsystem analysis

Newsoftwarereleases

Cooperationwith partners

Continuousmessage

processing

n You can rely on TeamSAP Support for:

� Innovation

New software releases with new functionality, new technology, and legal changes

� Help and customer empowerment

Customer message processing 24 hours a day, seven days a week

Integration of operating system and database partners in the support process

Proactive provision of corrections in the form of HotNews, OCS Packages, and Correction Releases

Help in setting up a Customer Competence Center

Free access to SAPNet Online Services

� Prevention

Continual monitoring of your R/3 System with EarlyWatch Alert

Thorough analysis of your R/3 System either periodically or at crucial points in the life cycle with GoingLive Checks and the EarlyWatch Service

SAP AG 1999

Remote ConsultingOther services

Implementation OperationGo live

UpgradeNew plantEuro conversion

7x24 supportnetwork

Continualmonitoring

Life cycle ofyour R/3 System

Assistance Throughout the Entire Life Cycle

GoingLive Check GoingLive Upgrade

Check

EarlyWatch EarlyWatchThoroughanalysis

EarlyWatch Alert

n TeamSAP Support offers a wide range of services to assist you in achieving your individual service level requirements:

� Higher system availability and performance

� Lower total costs of ownership through

Optimal use of system resources and protection of current investments

Reduced need for your own technical IT specialists

Lower risk of unforeseen performance bottlenecks and the associated costs

� Better response times leading to higher user satisfaction

� Technical optimization of core R/3 business processes leading to increased competitiveness

SAP AG 1999

Project teamSAP Local

Support

End user Help deskLog

Classify

Immediatesolution

SAP OnlineSupport

Customertop management

Support and Escalation

n Set up end-user support, distinguishing between support for network problems, PCs, and each R/3 application area.

n Set up a help desk for your end users:

1. The end user calls your help desk.

2. Help desk classifies the requests.

3. If the problem cannot be immediately solved, the project team contacts SAP through SAPNet Service and Support or the local SAP support office.

n For more information on setting up a help desk, see the ASAP documentation; search for the keyword ‘help desk’.

n Define escalation procedures within your company and include top-level management.

SAP AG 1999

Local supportRegional supportPartner support

SAPNet

Training workshopsInformation Database

Basis Knowledge ProductsPartner Academy

Development

Consulting:remote, on-site

Remote upgradeRemote archiving

EarlyWatch ServiceGoingLive Checks

Conversion Services OS/DB Migration

SAP Services

n R/3 Services include all consulting, education, and support services.

n Support services include local and regional SAP support, and the services of SAP partner companies. You can obtain technical support through SAPNet (R/3 frontend or Web frontend).

n The SAP EarlyWatch Service provides remote or on-site support to achieve problem-free operation of R/3 Systems worldwide through regular remote diagnoses.

n The SAP R/3 Special Conversion Service assists in the transfer of data from legacy systems.

n The SAP GoingLive Check Service enables you to ensure a smooth transition from the implementation phase to production operation.

n The SAP education services include:

� Classroom training for your project team members

� On-site training for end users provided by consultants, partners, or power users

n Other available training products include:

� Advanced Training Solution

� R/3 Basis Knowledge Products

SAP AG 1999

ASAP Phases: Technical Operation Tasks

1

2

3

cont

5

4

l Define strategy for using R/3 Servicesl Define strategy for using R/3 ServicesProject steering committee

Technical project leadIT management

Project managerBusiness process team lead

Technical team lead

Project managerBusiness process team lead

Help desk providerTechnical team lead

Project managerPower users

Help desk providers

l Define post implementation service & supportstrategy

l Define post implementation service & supportstrategyl Determine system problem standards & error handling procedure

l Determine system problem standards & error handling procedure

l Determine production support planl Determine production support plan

l Define service level commitmentl Define service level commitment

l Create R/3 Systems Technical Operation Manuall Create R/3 Systems Technical Operation Manual

l Refine production support planl Refine production support plan

l Provide production supportl Provide production support

l Execute long-term service and support strategyl Execute long-term service and support strategy

n The documentation for ASAP phase 1, Project Preparation, defines your strategy for using SAP's R/3 Services during and after R/3 implementation. Set up a service planning table with a schedule for the necessary services. Ensure that your budget includes these services. To plan a company internal help desk, determine system problem standards and error handling procedures. Roles: The project manager, the business process team lead, and the technical team lead determine the requirements for production support

n In ASAP phase 3, Realization, you set up the support plan for your production system. The service level agreement complements your company's internal problem processing structures and builds on your experiences during early R/3 implementation phases. Potential failure scenarios are determined and disaster recovery procedures defined. Roles: The project manager, the business process team lead, and the technical team lead determine the requirements for production support.

n In phase 4, Final Preparation, refine the production support plan to include help desk procedures and create the help desk facility. In addition, define the long-term production support strategy. Roles: The project manager, the business process team lead, the technical team lead, and the help desk provider refine the production support plan.

n In phase 5, Go Live and Support, it is crucial to provide production with both internal support for end users and R/3 Services. Roles: Power users and the help desk providers provide support during and after going live. The project manager is responsible for the long-term service and support strategy.

SAP AG 1999


Technical Operation: Unit Summary

l Plan your technical operations manuall Explain and organize the R/3 support and

escalation procedures necessary for yourcompany

n Critical Success Factors for Technical Operation Management:

� Define and test support procedures in detail.

� Set reaction times in your service level agreement.

� Create a technical operations manual for your operating staff.

� Determine escalation procedures to quickly and effectively deal with system failures that cannot be remedied with standard procedures.

� Actively use SAP's R/3 Services to analyze, forecast, and optimize your system behavior.

SAP AG 1999





n SAP R/3 Technical Implementation with ASAP

l ASAP CD Content

n Help Desk White Paper

n Service Level Agreements in the ASAPImplementation Guide

n SAP’s Customer Competence Center Manual