Basis Training

THE 1 WEEK TRAINING BOOK

© 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

Trademarks: 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.

Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation. Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc. ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc. TouchSend Index ® is a registered trademark of TouchSend Corporation. Visio ® is a registered trademark of Visio Corporation. IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation. Indeo ® is a registered trademark of Intel Corporation. Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape Communications, Inc. OSF/Motif ® is a registered trademark of Open Software Foundation. ORACLE ® is a registered trademark of ORACLE Corporation, California, USA. INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated. UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation. ADABAS ® is a registered trademark of Software AG 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.

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

© SAP AG TABC10/11 ii

© SAP AG TABC10/11 iii

Contents Course Overview................................................................................................................................................... 1

Target Group..................................................................................................................................................... 2 Course Prerequisites.......................................................................................................................................... 3 Course Goals ..................................................................................................................................................... 4 Course Composition.......................................................................................................................................... 5 TABCUO - Sections ......................................................................................................................................... 6 TABCNS - Sections .......................................................................................................................................... 7 TABCNO - Sections ......................................................................................................................................... 8

Section: SAP Basis Technology............................................................................................................................ 9 Basis System and System Environment .......................................................................................................... 10

Basis System and System Environment: Contents...................................................................................... 11 Basis System and System Environment: Objectives ................................................................................... 12 SAP Products in the Business Framework .................................................................................................. 13 Client / Server Principles ............................................................................................................................ 14 R/3 System Client / Server Configurations ................................................................................................. 15 SAP Basis.................................................................................................................................................... 16 Overview of the SAP Basis System ............................................................................................................ 17 Basis System and Environment: Summary ................................................................................................. 18

Navigation....................................................................................................................................................... 19 Navigation................................................................................................................................................... 20 Navigation: Unit Objectives........................................................................................................................ 21 Navigation: Business Scenario.................................................................................................................... 22 Logging on to the R/3 System..................................................................................................................... 23 Screen Elements .......................................................................................................................................... 24 SAP Easy Access - Standard....................................................................................................................... 25 Selecting Functions... .................................................................................................................................. 26 Role-Based User Menu ............................................................................................................................... 27 Field Help - F1, F4...................................................................................................................................... 28 SAP Online Help......................................................................................................................................... 29 System Functions - Services ....................................................................................................................... 30 System Functions - User Profile.................................................................................................................. 31 Table Settings - Example ............................................................................................................................ 32 Personalizing the Frontend.......................................................................................................................... 33 Navigation: Unit Summary ......................................................................................................................... 34 Exercises ..................................................................................................................................................... 35 Solutions ..................................................................................................................................................... 38

System Kernel ................................................................................................................................................. 41 System Kernel: Contents............................................................................................................................. 42 System Kernel: Unit Objectives.................................................................................................................. 43 The System Kernel...................................................................................................................................... 44 The System Kernel...................................................................................................................................... 45 Processing User Requests ........................................................................................................................... 46 R/3 Presentation Interface ........................................................................................................................... 47 R/3 Database Interface ................................................................................................................................ 48 R/3 Application Services............................................................................................................................. 49 The Dialog Work Process ........................................................................................................................... 51 Work Process Multiplexing and SAP Transactions .................................................................................... 52 Locks in R/3 at the Business Process Level ................................................................................................ 53 Requesting a Lock From the Enqueue WP ................................................................................................. 54 Asynchronous Update ................................................................................................................................. 55 Updating Log Records ................................................................................................................................ 56 Long-Running ABAP Programs ................................................................................................................. 57 Background Processing............................................................................................................................... 58 R/3 Printer Services..................................................................................................................................... 59 The R/3 Instance ......................................................................................................................................... 60 System Kernel: Unit Summary ................................................................................................................... 61 Exercises ..................................................................................................................................................... 62 Solutions ..................................................................................................................................................... 64

Development Using ABAP Workbench.......................................................................................................... 65 Development Using ABAP Workbench: Contents ..................................................................................... 66

© SAP AG TABC10/11 iv

Development Using ABAP Workbench: Objectives .................................................................................. 67 R/3 System Data Structure .......................................................................................................................... 68 R/3 System Customizing............................................................................................................................. 69 Changes to Repository Objects ................................................................................................................... 70 Three-System Landscape Recommended By SAP...................................................................................... 71 Project Management in the Workbench Organizer ..................................................................................... 72 Workbench Tools ........................................................................................................................................ 73 The ABAP Dictionary................................................................................................................................. 74 Modeling ..................................................................................................................................................... 75 Models......................................................................................................................................................... 76 What is the ABAP Dictionary? ................................................................................................................... 77 Table Definition .......................................................................................................................................... 78 Two-Level Domain Concept....................................................................................................................... 79 Use of Foreign Keys to Ensure Data Consistency....................................................................................... 80 Views .......................................................................................................................................................... 81 R/3 Standard Function: Input Help ............................................................................................................. 82 Programming Interfaces .............................................................................................................................. 83 ABAP Language ......................................................................................................................................... 84 Navigating to the Source Code.................................................................................................................... 85 ABAP Editor ............................................................................................................................................... 86 Object Navigator ......................................................................................................................................... 87 Actions at the End of a Project.................................................................................................................... 88 Writing an Application................................................................................................................................ 89 Development Using ABAP Workbench: Summary .................................................................................... 90

Communication............................................................................................................................................... 91 Communication: Contents........................................................................................................................... 92 Communication: Unit Objectives................................................................................................................ 93 Communication Interfaces .......................................................................................................................... 94 Communication: R/3 is an Open System .................................................................................................... 95 Remote Function Call ................................................................................................................................. 96 RFC From SAP System to SAP System ..................................................................................................... 97 Office Integration Using OLE..................................................................................................................... 98 Business Objects and BAPIs ....................................................................................................................... 99 Overview of mySAP.com ......................................................................................................................... 100 Business Scenarios .................................................................................................................................... 101 mySAP.com Workplace Architecture ....................................................................................................... 102 EDI Architecture ....................................................................................................................................... 103 External Data Transfer Using Batch Input ................................................................................................ 104 Communication: Unit Summary ............................................................................................................... 105 Exercises ................................................................................................................................................... 106 Solutions ................................................................................................................................................... 107

Section: Technical Core Competence - UNIX & NT........................................................................................ 108 Introduction................................................................................................................................................... 109

Introduction............................................................................................................................................... 110 Data Structure of R/3 Systems .................................................................................................................. 111 R/3 System Logon Steps ........................................................................................................................... 112 Defining Instance and Application Server ................................................................................................ 113 System Dialog Step................................................................................................................................... 114 Work Process Multiplexing....................................................................................................................... 115 Summary of this Unit ................................................................................................................................ 116 Further Documentation ............................................................................................................................. 117

Starting and Stopping - UNIX....................................................................................................................... 118 Starting and Stopping................................................................................................................................ 119 Starting the R/3 System............................................................................................................................. 120 Starting an R/3 Instance ............................................................................................................................ 121 Process Overview at the Operating System Level .................................................................................... 122 Assigning Parameter Values ..................................................................................................................... 123 R/3 Startup Logs and Traces ..................................................................................................................... 124 Startup Diagnostics ................................................................................................................................... 125 Database Startup Logs and Traces ............................................................................................................ 126 Before Stopping the R/3 System ............................................................................................................... 127 Stopping the R/3 System........................................................................................................................... 128 Stopping R/3: Error Diagnostics ............................................................................................................... 129

© SAP AG TABC10/11 v

Summary of this Unit ................................................................................................................................ 130 Unit Actions .............................................................................................................................................. 131 Starting and Stopping: Exercises............................................................................................................... 132 Starting and Stopping: Solutions............................................................................................................... 133

Starting and Stopping - NT ........................................................................................................................... 135 Starting and Stopping................................................................................................................................ 136 Overview of Processes and Services ......................................................................................................... 137 Starting R/3: Operating System Tasks ...................................................................................................... 138 Starting R/3: R/3 Administrator Tasks...................................................................................................... 139 Starting R/3: Process Startup Sequence .................................................................................................... 140 Parameter Read Sequence ......................................................................................................................... 141 Startup Logs and Traces in Windows NT ................................................................................................. 142 MMC SAP R/3 Systems Snap-In .............................................................................................................. 143 Startup Logs and Traces in R/3 ................................................................................................................. 144 Startup Diagnostics ................................................................................................................................... 145 Logs and Traces for Database Startup....................................................................................................... 146 Before Stopping the R/3 System ............................................................................................................... 147 Stopping the R/3 System........................................................................................................................... 148 Stopping R/3: Error Diagnostics ............................................................................................................... 149 Summary of this Unit ................................................................................................................................ 150 Unit Actions .............................................................................................................................................. 151 Starting and Stopping: Exercises............................................................................................................... 152 Starting and Stopping: Solutions............................................................................................................... 154

System Administration Assistant .................................................................................................................. 156 System Administration Assistant .............................................................................................................. 157 System Administration.............................................................................................................................. 158 Starting the System Administration Assistant........................................................................................... 159 Administer Using View Worklist.............................................................................................................. 160 Using the System Administration Assistant .............................................................................................. 161 Interpreting the Listing.............................................................................................................................. 162 Maintain the System Administration Assistant ......................................................................................... 163 Administer a System Landscape ............................................................................................................... 164 Troubleshooting Roadmap ........................................................................................................................ 165 Authorizations........................................................................................................................................... 166 Summary of this Unit ................................................................................................................................ 167 Further Documentation ............................................................................................................................. 168 Unit Actions .............................................................................................................................................. 169 System Administration Assistant: Exercises ............................................................................................. 170 System Administration Assistant: Solutions ............................................................................................. 171

CCMS Configuration .................................................................................................................................... 173 CCMS Configuration ................................................................................................................................ 174 CCMS: Overview...................................................................................................................................... 175 Setting Up the CCMS................................................................................................................................ 176 Using the System Administration Assistant .............................................................................................. 177 Transaction RZ10: Profile Maintenance ................................................................................................... 178 R/3 Profiles ............................................................................................................................................... 179 Maintaining R/3 Profiles ........................................................................................................................... 180 Changing R/3 Profile Parameters .............................................................................................................. 181 Checking and Comparing R/3 Profiles...................................................................................................... 182 Operation Modes: Concept ....................................................................................................................... 183 Choosing an Operation Mode 1 ................................................................................................................ 184 Choosing an Operation Mode 2 ................................................................................................................ 185 Using the System Administration Assistant .............................................................................................. 186 Setting Up Operation Modes/Instances..................................................................................................... 187 Adapting Instance Definitions and Operation Modes ............................................................................... 188 Operation Mode Switch: Advantage ......................................................................................................... 189 Scheduling Operation Modes .................................................................................................................... 190 Switching Operation Modes Manually...................................................................................................... 191 Operation Mode Switch Diagnostics......................................................................................................... 192 Starting and Stopping Instances with the CCMS ...................................................................................... 193 CCMS Monitoring Authorization ............................................................................................................. 194 Summary of this Unit ................................................................................................................................ 195 Further Documentation ............................................................................................................................. 196

© SAP AG TABC10/11 vi

Unit Actions .............................................................................................................................................. 197 CCMS Configuration: Exercises............................................................................................................... 198 CCMS Configuration: Solutions ............................................................................................................... 200

Background Processing................................................................................................................................. 203 Background Processing............................................................................................................................. 204 Why Background Processing? .................................................................................................................. 205 What is a Background Job?....................................................................................................................... 206 Scheduling of Jobs and Workload Balancing............................................................................................ 207 Reservation for Class A Jobs .................................................................................................................... 208 Using the System Administration Assistant .............................................................................................. 209 Defining a Job Using the Job Wizard........................................................................................................ 210 Executing Programs as Job Steps.............................................................................................................. 211 Start Conditions of a Job ........................................................................................................................... 212 Definition and Triggering of Events ......................................................................................................... 213 Status of a Job ........................................................................................................................................... 214 Job Monitoring: Text Form....................................................................................................................... 215 Job Monitoring: Graphical Form............................................................................................................... 216 Overview: Extending the Standard ........................................................................................................... 217 Authorizations 1........................................................................................................................................ 218 Authorizations 2........................................................................................................................................ 219 Summary of this Unit ................................................................................................................................ 220 Further Documentation ............................................................................................................................. 221 Unit Actions .............................................................................................................................................. 222 Background Processing: Exercises............................................................................................................ 223 Background Processing: Solutions............................................................................................................ 225

Users and Authorizations .............................................................................................................................. 228 Users and Authorizations .......................................................................................................................... 229 Users in the R/3 Environment ................................................................................................................... 230 Authorization Concept 1 ........................................................................................................................... 231 Authorization Concept 2 ........................................................................................................................... 232 Authorization Objects ............................................................................................................................... 233 Authorization Check ................................................................................................................................. 234 Profile Generator Introduction .................................................................................................................. 235 Activity Group Creation and Maintenance ............................................................................................... 236 Menu and Transaction Selection ............................................................................................................... 237 Maintenance of Authorization Values....................................................................................................... 238 User Assignment ....................................................................................................................................... 239 The User Master Record ........................................................................................................................... 240 Central User Administration ..................................................................................................................... 241 Controlling User Logon ............................................................................................................................ 242 Security ..................................................................................................................................................... 244 Information System................................................................................................................................... 245 System Trace for Authorizations............................................................................................................... 246 User Administration Authorizations 1 ...................................................................................................... 247 User Administration Authorizations 2 ...................................................................................................... 248 User Administration Authorizations 3 ...................................................................................................... 249 Summary ................................................................................................................................................... 250 Further Documentation ............................................................................................................................. 251 Unit Actions .............................................................................................................................................. 252 Users and Authorizations: Exercises......................................................................................................... 253 Users and Authorizations: Solutions ......................................................................................................... 255

Spool and Print - UNIX................................................................................................................................. 257 Spool and Print.......................................................................................................................................... 258 Information Flow ...................................................................................................................................... 259 Access Methods: Local Printing ............................................................................................................... 260 Access Methods: Remote Printing ............................................................................................................ 261 Access Methods: Frontend Printing .......................................................................................................... 262 Using the System Administration Assistant .............................................................................................. 263 Creating a New Output Device ................................................................................................................. 264 Device Types............................................................................................................................................. 265 Logical Spool Servers ............................................................................................................................... 266 Creating a Logical Spool Server ............................................................................................................... 267 Feature 1: Spool Server Switchover.......................................................................................................... 268

© SAP AG TABC10/11 vii

Feature 2: Workload Balancing................................................................................................................. 269 Feature 3: Transporting the Printer Architecture....................................................................................... 270 Selecting Spool or Output Requests.......................................................................................................... 271 Monitoring Spool and Output Requests .................................................................................................... 272 Maintaining the Spool Database ............................................................................................................... 273 Authorizations 1........................................................................................................................................ 274 Authorizations 2........................................................................................................................................ 275 Summary of this Unit ................................................................................................................................ 276 Further Documentation ............................................................................................................................. 277 Unit Actions .............................................................................................................................................. 278 Spool and Print: Exercises ........................................................................................................................ 279 Spool and Print: Solutions......................................................................................................................... 280

Spool and Print - NT ..................................................................................................................................... 282 Spool and Print.......................................................................................................................................... 283 Information Flow ...................................................................................................................................... 284 Access Methods: Local Printing ............................................................................................................... 285 Access Methods: Remote Printing ............................................................................................................ 286 Access Methods: Frontend Printing .......................................................................................................... 287 Using the System Administration Assistant .............................................................................................. 288 Creating a New Output Device ................................................................................................................. 289 Device Types............................................................................................................................................. 290 Logical Spool Servers ............................................................................................................................... 291 Creating a Logical Spool Server ............................................................................................................... 292 Feature 1: Spool Server Switchover.......................................................................................................... 293 Feature 2: Workload Balancing................................................................................................................. 294 Feature 3: Transporting the Printer Architecture....................................................................................... 295 Selecting Spool or Output Requests.......................................................................................................... 296 Monitoring Spool and Output Requests .................................................................................................... 297 Maintaining the Spool Database ............................................................................................................... 298 Authorizations 1........................................................................................................................................ 299 Authorizations 2........................................................................................................................................ 300 Summary of this Unit ................................................................................................................................ 301 Further Documentation ............................................................................................................................. 302 Unit Actions .............................................................................................................................................. 303 Spool and Print: Exercises ........................................................................................................................ 304 Spool and Print: Solutions......................................................................................................................... 305

Installation Check - UNIX ............................................................................................................................ 308 Installation Check ..................................................................................................................................... 309 Installation Check ..................................................................................................................................... 310 Installation Check: Part 1 .......................................................................................................................... 311 Installation Prerequisites ........................................................................................................................... 312 Check Assistance ...................................................................................................................................... 313 Installation Check: Part 2 .......................................................................................................................... 314 Technically Correct Installation: Requirements........................................................................................ 315 Technically Correct Installation: Profiles.................................................................................................. 316 Oracle Directory Structure ........................................................................................................................ 317 Example 1: Minimal Disk Layout............................................................................................................. 318 Example 2: High Availability RAID Disk Layout .................................................................................... 319 Database Security...................................................................................................................................... 320 Database Performance............................................................................................................................... 321 Installation Check: Part 3 .......................................................................................................................... 322 R/3 Release and System Name.................................................................................................................. 323 R/3 Basis Parameters................................................................................................................................. 324 R/3 Directory Structure ............................................................................................................................. 325 R/3 Instance Numbers ............................................................................................................................... 326 Transport Management System Setup Process.......................................................................................... 327 Transport Domain ..................................................................................................................................... 328 Common Transport Directory ................................................................................................................... 329 Transport Routes ....................................................................................................................................... 330 R/3 Network Configuration....................................................................................................................... 331 Checking the Installation: Further Steps ................................................................................................... 332 Backing Up the R/3 Installation ................................................................................................................ 333 Summary of this Unit ................................................................................................................................ 334

© SAP AG TABC10/11 viii

Installation Check - NT................................................................................................................................. 335 Installation Check: Contents ..................................................................................................................... 336 Installation Check: Objectives .................................................................................................................. 337 Installation Check: Part 1 .......................................................................................................................... 338 Installation Prerequisites ........................................................................................................................... 339 Check Assistance ...................................................................................................................................... 340 Operating System Security: Registry Backup ........................................................................................... 341 Installation Check: Part 2 .......................................................................................................................... 342 Technically Correct Installation: Requirements........................................................................................ 343 Technically Correct Installation: Profiles.................................................................................................. 344 Oracle Directory Structure ........................................................................................................................ 345 Example 1: Minimal Disk Layout............................................................................................................. 346 Example 2: High Availability RAID Disk Layout .................................................................................... 347 Database Security...................................................................................................................................... 348 Database Performance............................................................................................................................... 349 Installation Check: Part 3 .......................................................................................................................... 350 R/3 Release and System Name.................................................................................................................. 351 R/3 Basis Parameters................................................................................................................................. 352 Domain Concept ....................................................................................................................................... 353 R/3 Domain Security Concept................................................................................................................... 354 R/3 Directory Structure ............................................................................................................................. 355 Shared Directories..................................................................................................................................... 356 Name Resolution on Windows NT ........................................................................................................... 357 R/3 Instance Numbers ............................................................................................................................... 358 Transport Management System Setup Process.......................................................................................... 359 Transport Domain ..................................................................................................................................... 360 Common Transport Directory ................................................................................................................... 361 Transport Routes ....................................................................................................................................... 362 Checking the Installation: Further Steps ................................................................................................... 363 Back Up the R/3 Installation ..................................................................................................................... 364 Summary of this Unit ................................................................................................................................ 365

Installation Guide.......................................................................................................................................... 366 Installation Guide...................................................................................................................................... 367

SAP Data Archiving...................................................................................................................................... 368 SAP Data Archiving.................................................................................................................................. 369 What is Data Archiving?........................................................................................................................... 370 Why Archive Data?................................................................................................................................... 371 Data Archiving Process............................................................................................................................. 372 Archiving Objects ..................................................................................................................................... 373 Archive Development Kit (ADK) ............................................................................................................. 374 Safekeeping of Archive Files .................................................................................................................... 375 Accessing Archived Data .......................................................................................................................... 376 Archive Information System ..................................................................................................................... 377 Preparations for Data Archiving ............................................................................................................... 378 Data Archiving Steps ................................................................................................................................ 379 Monitoring an Archiving Run................................................................................................................... 380 Error Handling .......................................................................................................................................... 381 Phases of an Archiving Project ................................................................................................................. 382 Data Archiving Authorization................................................................................................................... 383 Summary of this Unit ................................................................................................................................ 384 Further Documentation ............................................................................................................................. 385 Unit Actions .............................................................................................................................................. 386 Data Archiving: Exercises......................................................................................................................... 387 Data Archiving: Solutions......................................................................................................................... 388

System Monitoring........................................................................................................................................ 390 System Monitoring.................................................................................................................................... 391 Monitoring: What, Why, Who, When....................................................................................................... 392 Part 1: Monitoring Concept and Alert Monitor......................................................................................... 393 Monitoring Architecture Terminology...................................................................................................... 394 The Alert Monitor (Transaction RZ20)..................................................................................................... 395 Thresholds and Analysis Methods ............................................................................................................ 396 Creating Your Own Monitor ..................................................................................................................... 397 Monitor Remote Systems.......................................................................................................................... 398

© SAP AG TABC10/11 ix

Part 2: Analysis Methods .......................................................................................................................... 399 R/3 Syslog................................................................................................................................................. 400 R/3 Syslog: Details.................................................................................................................................... 401 R/3 Services .............................................................................................................................................. 402 Monitoring: R/3 Servers and Instances ..................................................................................................... 403 Monitoring: R/3 Work Processes .............................................................................................................. 404 Monitoring: R/3 Users............................................................................................................................... 405 Logon Groups ........................................................................................................................................... 406 Update Processing 1.................................................................................................................................. 407 Update Processing 2.................................................................................................................................. 408 Monitoring: Asynchronous Update........................................................................................................... 409 Monitoring: R/3 Locks.............................................................................................................................. 410 Monitoring: ABAP Dumps ....................................................................................................................... 411 Time Definitions for a Dialog Step ........................................................................................................... 412 Monitoring: Workload Analysis................................................................................................................ 413 R/3 Basis System ...................................................................................................................................... 414 Monitoring: Buffers .................................................................................................................................. 415 Buffer Synchronization ............................................................................................................................. 416 Database Monitoring................................................................................................................................. 417 Operating System...................................................................................................................................... 418 Using the System Administration Assistant .............................................................................................. 419 Troubleshooting Roadmap: Problem Oriented View ................................................................................ 420 Troubleshooting Roadmap: Technical View............................................................................................. 421 Example: Technical View Application ..................................................................................................... 422 ABAP Programs for Checks and Cleanup ................................................................................................ 423 CCMS Monitoring Authorization ............................................................................................................. 424 Summary of this Unit ................................................................................................................................ 425 Further Documentation ............................................................................................................................. 426 Unit Actions .............................................................................................................................................. 427 System Monitoring: Exercises .................................................................................................................. 428 System Monitoring: Solutions................................................................................................................... 430

SAPNet ......................................................................................................................................................... 433 SAPNet ..................................................................................................................................................... 434 SAPNet - Web Frontend versus R/3 Frontend .......................................................................................... 435 SAPNet - Web Frontend - Overview ........................................................................................................ 436 SAPNet - R/3 Frontend - Overview .......................................................................................................... 437 Access to SAPNet - R/3 Frontend............................................................................................................. 438 User Administration.................................................................................................................................. 439 Notes Search ............................................................................................................................................. 440 Messages ................................................................................................................................................... 441 SSCR Keys................................................................................................................................................ 442 CD Registration......................................................................................................................................... 443 SAP Patch Service .................................................................................................................................... 444 Training Information................................................................................................................................. 445 TechNet..................................................................................................................................................... 446 Summary of this Unit ................................................................................................................................ 447

© SAP AG 1999

Course Overview

© SAP AG TABC10/11 1

© SAP AG 1999

Target Group

Audience:future SAP R/3 Technical Consultants

experienced System Administrators

experienced Database Administrators

with no or less R/3 knowledge

Duration: 5 weeks


© SAP AG 1999

Course Prerequisites

In-depth knowledge of the UNIX or NT operating system,the ORACLE or MS SQL Server database and TCP/IPnetwork administration.

Practical experience with these issues is essential forpassing the SAP R/3 Certified Technical Consultant exam.


© SAP AG 1999

Course Goals

Course participants receive comprehensive expert leveltraining in R/3 System management

The course prepares participants for the AP R/3 Certified揝Technical Consultant? exam.


© SAP AG 1999

Course Composition

UNIX/ORACLE: TABCUO = TABC10 + TABC20 + TABC30

NT/ORACLE: TABCNO = TABC11 + TABC20 + TABC30

NT/MS SQL Server: TABCNS = TABC11 + TABC21 + TABC30

5 weeks = 3 weeks + 1 week + 1 week


© SAP AG 1999

TABCUO - Sections

TABC10Section SAP Basis TechnologySection Technical Core Competence - UNIXSection Software LogisticsSection R/3 Technical Implementation and Operation ManagementSection Advanced R/3 System AdministrationSection Ready-to-RunSection Technical Core Competence - WorkplaceTABC20Section Database Administration ORACLESection SQL Cache Analysis - CBO - ORACLETABC30Section Workload AnalysisSection Technical Optimization of ALE Processing


© SAP AG 1999

TABCNS - Sections

TABC11Section SAP Basis TechnologySection Technical Core Competence - NTSection Software LogisticsSection R/3 Technical Implementation and Operation ManagementSection Advanced R/3 System AdministrationSection Ready-to-RunSection Technical Core Competence - WorkplaceTABC21Section Database Administration MS SQL ServerSection SQL Cache Analysis - CBO - MS SQL ServerTABC30Section Workload AnalysisSection Technical Optimization of ALE Processing


© SAP AG 1999

TABCNO - Sections

TABC11Section SAP Basis TechnologySection Technical Core Competence - NTSection Software LogisticsSection R/3 Technical Implementation and Operation

ManagementSection Advanced R/3 System AdministrationSection Ready-to-RunSection Technical Core Competence - WorkplaceTABC20Section Database Administration ORACLESection SQL Cache Analysis - CBO - ORACLETABC30Section Workload AnalysisSection Technical Optimization of ALE Processing


© SAP AG 1999

Section: SAP Basis Technology

Basis System andSystem Environment

Navigation

System Kernel

Development UsingABAP Workbench

Communication


© SAP AG 1999


Navigation

System Kernel


Communication

Basis System and System Environment


© SAP AG 1999

Basis System and System Environment: Contents

Basic concepts of the SAP Basis System

Applications that use the SAP Basis System (forexample, R/3)

Outline of the architecture of the SAP Basis System


© SAP AG 1999

Basis System and System Environment: Objectives

Describe the concept of the SAP BusinessFramework

Logically place the SAP Basis System and theapplications (such as R/3) that build on the BasisSystem in your system landscape

Explain the client / server concept used in SAPsoftware

Describe the basic technical structure of the SAPBasis System

At the conclusion of this unit, you will be able to:


© SAP AG 1999

SAP Products in the Business Framework

SAP product family within a common infrastructure

LO 4.6

FI 4.6......

......

......

Add-onDevelop-

ment

Add-onDevelop-

ment

Comple-mentarySoftware

Comple-mentarySoftware

............

......

Intranet

ALE

ALEBusinessInformationWarehouse

InternetApplications

Core 4.5

EmployeeSelf-

Service

HR 4.6

Internet

The Business Framework is SAP’s new product architecture providing companies with a flexible, comprehensive software infrastructure. This allows companies to easily add new business applications to enterprise software without interrupting day-to-day business.

SAP’s Business Framework technology offers customers a new platform for simple configuration and connection of business processes and information flow for all components in the Business Framework; this supports you regardless of whether these components are installed on separate hardware, come from different suppliers, or are components you created yourself.

Applications included in the Framework communicate using the Application Link Enabling (ALE) protocol. An example of an application is the R/3 System.

Data selected when configuring the ALE integrated system is transferred between applications using SAP-certified BAPI interfaces. These applications can be SAP products, such as the Business Information Warehouse (BW) or the Advanced Planner and Optimizer (APO), or non-SAP products. A company Intranet, such as “Employee Self Service”, can be connected. It is also easy to connect to the Internet to provide products or services on the Web. mySAP.com provides comprehensive functions for connecting to the Internet.

Using interfaces certified by SAP, third-party products can also be seamlessly connected to SAP software. For more information, see “Complementary Software Program” in SAPNet under the alias “csp”.


© SAP AG 1999

Client / Server Principles

Process 1 Process 2

Service requested Software-orientedview

Hardware-oriented

view

LAN / WAN

Client Server

Client Server

Service provided

In SAP terminology, a service means a service provided by a software component (software-oriented view). This component can consist of a process (compare work process) or a group of processes (compare application server) and is then called a server for that service.

Software components that use this service are called clients. At the same time, clients can also be servers for specific services.

A server often also means a computer (host) on which software components that provide specific services are running (hardware-oriented view).


© SAP AG 1999

R/3 System Client / Server Configurations

ApplicationApplication

DatabaseDatabase

PresentationPresentation

Database, application, presentation processes

One-tier configuration

Two-tier configuration

Three-tier configuration

Presentation processes

Database, application processes

Database processes

Application processes

The fundamental services in a business application system are presentation services, application services, and database services.

In a one-tier R/3 System configuration, all processing tasks are performed on one server, as in classic mainframe processing.

Two-tier R/3 System configurations are usually implemented using special presentation servers that are responsible solely for formatting the graphical user interface. Many R/3 System users use Windows PCs for example as presentation servers. An alternative two-tier configuration (not shown) is to install powerful desktop systems and to use these for presentation and applications also (two-tier client/server). This type of configuration is particularly useful for processing-intensive applications (such as simulations) or for software developers, but due to the additional administration requirements is usually used for test purposes only.

In a three-tier configuration, separate servers are used for each tier. Using data from the database server, several different application servers can operate at the same time. To ensure that the load on individual servers is as even as possible and to achieve optimal performance, you can use special application servers for individual application areas such as distribution or financial accounting (logon and load balancing).


© SAP AG 1999

SAP Basis

Customerprograms

Applications,such as APO

SAP BasisSAP BasisSAP BasisSystem software

Using the SAP Basis System, applications can run on different platforms with high performance and can be adapted to meet individual user requirements.

SAP Basis:

Provides the runtime environment for all SAP applications

Optimally embeds the application in the system environment

Defines a stable architecture framework for system enhancements

Contains the tools for administering the entire system

Allows the distribution of resources and system components

Provides interfaces for decentralized system parts and external products.

The architecture of the SAP Basis System is especially well-suited for client / server configurations.


© SAP AG 1999

ScreenInterpreter

Operating System and Hardware PlatformOperating System and Hardware Platform

ABAPDictionary

Programming Interfaces

ApplicationsApplications

Com

mun

icat

ion

Inte

rfac

eC

omm

unic

atio

n In

terf

ace

Use

r Int

erfa

ceU

ser I

nter

face

Runtime EnvironmentRuntime Environment

ABAPInterpreter

Overview of the SAP Basis System

To ensure the portability of SAP applications, the interfaces for the system are combined on an separate layer. The functions of all SAP products sit on top of this layer, independent of the software and hardware environment.

The flow control handles services such as scheduling and memory management, among others. Some of these services may be provided by the operating system software, but for reasons of portability and performance they are handled within the Basis System.

The user interface is the presentation layer for the applications.

The communication interface defines the channels used for the electronic exchange of information, such as transfer of external data, program-to-program communication through the RFC protocol, and the exchange of application data through ALE.

All application programs in the R/3 System are written in SAP’s own interpretative ABAP language. The dynpros (dynamic programs) are the controlling components during dialog processing. The interaction of screen interpreter and ABAP interpreter forms the software basis of R/3 applications. Both interpreters use the complete R/3 data picture stored in the ABAP Dictionary.


© SAP AG 1999

Describe the concept of the SAP BusinessFramework

Logically place the SAP Basis System and theapplications (such as R/3) that build on the BasisSystem in your system landscape

Explain the client / server concept used in SAPsoftware

Describe the basic technical structure of the SAPBasis System

You are now able to:

Basis System and Environment: Summary


© SAP AG 1999


Navigation

System Kernel


Communication

Navigation


© SAP AG 1999

Basic features

User-specific settings

Contents:

Navigation


© SAP AG 1999

Identify the elements of a typical window

Navigate in the system

Make personal system settings

At the conclusion of this unit you will be able to:

Navigation: Unit Objectives


© SAP AG 1999

New users need to familiarize themselves with thescreens in the R/3 System and define theirpersonal default settings

Navigation: Business Scenario


© SAP AG 1999

Logging on to the R/3 System

Log off New password

User System Help

SAP R/3SAP R/3

Client

User

Password

Language

iwdf4042 OVR

The R/3 System is a client system. The client concept enables the joint operation, in one system, of several enterprises that are independent of each other in business terms. During each user session you can only access the data of the client selected during the logon.

A client is, in organizational terms, an independent unit in the R/3 System. Each client has its own data environment and therefore its own master data and transaction data, assigned user master records and charts of accounts, and specific customizing parameters.

A user master record linked to the relevant client must be created for users to be able to log on to the system.

To protect access, a password is required for logon. The password is hidden as you type (you only see asterisks).

SAP systems are available in several languages. Use the Language input field to select the logon language for each session.

Multiple logons are always logged in the system beginning with Release 4.6. This is for security as well as licensing reasons. A warning message appears if the same user attempts to log on twice or more. This message offers three options:

Continue with current logon and end any other logons in the system

Continue with current logon without ending any other logons in the system (logged in system)

Terminate current logon


© SAP AG 1999

Screen Elements

I42 (1) (400) iwdf4042 INS

Input field

1st selection2nd selection3rd selection

4th selection5th selection

ChangeDisplay

2nd selection1st selection 3rd selection

Green light; positive

Yellow light; neutral

Overview

Execute

Message

PushbuttonPushbutton

Status barStatus bar

CheckboxesCheckboxes

Command fieldCommand field Standard toolbarStandard toolbar

Radio buttonRadio button

Menu barMenu bar

Title barTitle bar

Application toolbarApplication toolbarInput fieldInput field

TabTab

Menu Edit Favorites Extras System Help

System function name : ActivitySystem function name : Activity

This screen is madeup of various screenelements. It does notexist in the system.

OptionsOptions

Command field: You can use the command field to go to applications directly by entering the transaction code. You can find the transaction code either in the SAP Easy Access menu tree (see next slide) or in the relevant application under System→ Status.

Menu bar: The menus shown here depend on which application you are working in. These menus contain cascading menu options.

Standard toolbar: The icons in the system function bar are available on all R/3 screens. Any icons that you cannot use on a particular screen are dimmed. If you leave the cursor on an icon for a moment, a small flag will appear with the name (or function) of that icon. You will also see the corresponding function key. The application toolbar shows you which functions are available in the current application.

Title bar: The title bar displays your current position and activity in the system.

Check boxes: Checkboxes allow you to select several options simultaneously within a group.

Radio buttons: Radio buttons allow you to select one option only.

Status bar: The status bar displays information on the current system status, for example, warning and error messages.

A tab provides a clearer overview of several information screens.

Options: You can set your font size, list colors, and so on here.


© SAP AG 1999

SAP Easy Access - Standard

SAP Easy AccessSAP Easy Access

OfficeLogisticsAccountingHuman Resources

PPMDT - Manager Desktop憇

Personnel managementTime managementPayroll accountingTraining and eventsOrganizational managementTravel managementInformation system

Information SystemsTools

InboxAccounts payable

Create FD01Change FD02Display FD03

Accounts receivableFavorites

SAP standard menu

Other menu Create menu Assign users Documentation

I42 (1) (400) iwdf4042 INS


SAP Easy Access is the standard entry screen displayed after logon. Using the menu path Extras→ Set start transaction you can select a transaction of your choice to be the default entry screen after logon.

You navigate through the system using a compact tree structure that you can adapt to your own specific requirements. Use the menu path Extras→ Settings to change your view of the tree structure. You can use this to display technical names (transaction codes).

You can also create a Favorites list of the transactions, reports, files and Web sites you use most.

You can add items to your favorites list using the Favorites menu option or by simply dragging & dropping them with the mouse.


© SAP AG 1999

Selecting Functions...

Favorites

SAP standard menu

SAP Easy AccessSAP Easy AccessOther menu Create menu Assign users Documentation

/nFD03

sing the menu path卽

sing the technical name卽 (transaction codes)

sing卽Favorites or thetree structure

Create sessionEnd sessionUser profileServicesUtilitiesListWorkflowLinksPrivate notesOwn spool requestsOwn jobsShort messagesStatus...Log off


You can select system functions in the following ways:

Use the mouse to choose

Menu options

Favorites

Other options in the tree structure (tree control)

Use the keyboard (ALT + the underlined letter of the relevant menu option)

Enter a transaction code in the command field:

A transaction code (T-Code) is assigned to each function in R/3 (not each screen).

You can access the assigned transaction code from any screen in the R/3 System.

You can find the transaction code for the function you are working in under the Status option of the System menu.

For example, to display Accounts receivable master data, enter “/n” and the appropriate transaction code (in this case “/nfd03”).

Other possible entries: “/n” ends the current transaction. “/i” ends the current session. “/osm04” creates a new session and goes to the transaction specified (SM04).

You can also use the keyboard to get to the command field. Use the CTRL + TAB key combination to make the cursor move from one (input) field group to the next. Use TAB to move between fields within a group.


© SAP AG 1999

Role-Based User Menu

SAP Easy AccessSAP Easy Access

Other menu Create menu Assign users Documentation

I42 (1) (400) iwdf4042 INS

FavoritesUser menu

Schedule ManagerInformation systemClosingAccount master data

CreateChangeDisplayDisplay changesBlock / unblockSet deletion flagConfirmation of changeCompareMaintain centrally

Account balances and account itemsEntryPayment and clearingEditing options


A role describes a set of logically linked transactions. These transactions represent the range of functions users typically need at their workstations.

Activity groups (user roles) have to be set up using the Profile Generator so that users of the SAP System can work with user-specific or position-related menus. The authorizations for the activities listed in the menus are also assigned to the users using activity groups. With Release 4.6, predefined activity groups (user roles) from all application areas are included in the standard system.

Users who have been assigned to an activity group can choose between the user menu and the SAP standard menu.

The above screen shows the role-based user menu for the “Accounts Receivable Supervisor” as an example. You can find other roles that are supplied in the standard SAP System with the corresponding activity groups using the Other menu pushbutton in the SAP Easy Access initial screen.


© SAP AG 1999

Field Help - F1, F4

Display Customer: Initial ScreenDisplay Customer: Initial Screen

Display Customer: Initial Screen

Customer

Company code

1000

1000 IDES

Becker Berlin

Customer account numberA unique key is used to clearly identify the customerwithin the SAP system.

ProcedureWhen creating a customer master record, the usereither enters the account number of the customer orhas the system determine the number when therecord is saved, depending on the type of numberassignment used..

Application help Technical info

F1 F4

Possibleentries

FD03 iwdf4042 INSMessage

Hit listHit list

Display Customer: Initial Screen

Help - Display Customer: Initial Screen Restrictions

Customer

Company code

Company name

City

Currency

Restrict number to No restriction

Restrict Value Range

Use F1 for help on fields, menus, functions and messages.

F1 help also provides technical information on the relevant field. This includes, for example, the parameter ID, which you can use to assign values to the field for your user.

Use F4 for information on what values you can enter. You can also access F4 help for a selected field using the button immediately to the right of that field.

If input fields are marked with a small icon with a checkmark, then you can only continue in that application by entering a permitted value.

You can flag many fields in an application to make them either required entry fields or optional entry fields. You can also hide fields using transaction or screen variants or Customizing.


© SAP AG 1999

SAP Online Help

Application help

SAP library

Glossary

SAPNet

Release notes

Settings...

Feedback

SAP LibrarySAP Library

Getting started

Release notes

Basis

Service

Cross-Application Components

Financials

Human Resources

Logistics

Copyright and Conventions


The R/3 System provides comprehensive online help. You can display the help from any screen in the system. You can always request help using the Help menu or using the relevant icon.

The Help menu contains the following options:

Application help: Displays comprehensive help on the current application. Selecting this menu option in the initial screen displays help on getting started with R/3.

SAP Library: This is where all online documentation can be found.

Glossary: Enables you to search for definitions of terms.

Release notes: Displays notes which describe functional changes that occur between R/3 releases.

SAPNet: Enables you to log on to SAPNet.

Feedback: Enables you to send a message to the SAPNet R/3 Frontend, SAP’s service system.

Settings: Enables you to select settings for help.


© SAP AG 1999

System Functions - Services

Favorites

SAP standard menu

SAP Easy AccessSAP Easy AccessOther menu DocumentationReporting

Quick ViewerOutput controllerTable maintenanceBatch inputFast entryDirect inputCATTJobsQueueSAP ServiceAppointment calendarBusiness Workplace


Create sessionEnd sessionUser profileServicesUtilitiesListWorkflowLinksPrivate notesOwn spool requestsOwn jobsShort messagesStatus...Log off

The System menu contains, among others, the following options:

Create/end session: Enables you to create and end sessions. You can work with up to 6 sessions at a time.

User profile: This is where you can enter user-specific settings.

Services: Takes you to important service functions (see below).

List: Contains important list functions, such as searching for character strings, saving in PC files, printing, and so on.

Status: Enables you to display important user and system data.

Log off: Ends the SAP R/3 session with a confirmation prompt.

The System → Services menu contains, among others, the following options:

Reporting: Starts reports (ABAP programs).

Output controller: This is where you manage user-specific print requests.

Table maintenance: This is where you process tables and views.

Batch input: Administers batch input sessions and data transfer.

Jobs: This is where you can administer jobs that are processed in the background.

SAP Service: Enables you to log on to SAP’s SAPNet R/3 Frontend.


© SAP AG 1999

System Functions - User Profile

UserLast changed by

Start menu

Logon language

Output immediatelyDelete after output

MUSTERADMIN

Decimal notation

01.01.2000 12:00:00 Status Saved

Date format

CATT

DD.MM.YYYYMM/DD/YYYYMM-DD-YYYYYYYY.MM.DDYYYY/MM/DD

Personal timezone

Output controller

Address Defaults Parameters

1.234.567,891,234,567.891 234 567,89

Maintaining your user profileMaintaining your user profile

I42 (1) (400) iwdf4042 INS

User Edit Goto System Help

Use the menu option System→ User profile→ Own data to set your own personal profile. You can choose between the Address, Defaults and Parameters tabs.

Address: You can create and maintain personal data here, for example, name,function, room number, telephone number, e-mail addresses and so on.

Defaults: Defaults include the date display format, the decimal notation format, the default printer, the logon language, and so on.

Parameters: Use this to assign entries to commonly-used fields. This is only available for input fields that have been allocated a parameter ID. Procedure for finding out a field’s Parameter ID: Go to the input field to which you want to assign a value. Choose F1, then the “Technical info” pushbutton. This opens a window that displays the corresponding parameter ID (if one has been allocated to the field) in the “Field data” section.

The User profile menu also contains, among others, the following options:

Hold data, Set data, Delete data. Use Hold data to keep data values that you have entered in fields in an application for the duration of a user session. When you call up the application again, you can overwrite these values. Once you have Set data, you can no longer overwrite these values and have to use Delete data if you want to enter different values.


© SAP AG 1999

Table Settings - Example

Parameters Value Text

Company codeProcessing groupBank key

Sales order type

Choose Variants

Maintain Variants

Use as standard settingVariant

Save

Standard setting

Current setting

Create

Delete

Administrator

My variant

Basic setting

Table Settings

Use the Table Settings function to change, in the table control, the individual basic table settings that are supplied with the system. This is particularly useful for tables where you do not need all the columns. You can use the mouse to drag & drop column positions and widths, or even make the column disappear.

Save the changed table settings as a variant. The number of different variants you can create per table is not restricted.

The first variant is called the basic setting; the SAP System defines this setting. You cannot delete the basic setting (you can delete the variants you define yourself).

The table settings are stored with your user name. The system uses the variant currently valid until you exit the relevant application. If you then select the application again, the system will use the standard settings valid for this table.

Note: you can change table settings wherever you see the table control icon in the top right-hand corner of a table.


© SAP AG 1999

Create Sales Order: Initial ScreenCreate Sales Order: Initial Screen

Create with reference Sales Item overview Besteller

Organizational data

Sales organization

Distribution channel

Division

Sales office

Sales group

Order type

R/3 Standard ...R/3 Standard ...

Create Sales Order: Initial ScreenCreate Sales Order: Initial Screen

Create with reference Sales Item overview

Remember ...Advertising articles 471199 and 471299 (valid until end of May)

Product 34611 must be replaced by product 34611_S!!!

Standard order

Rush order

Returns

Free of charge

Order type

Distribution channel

Ordering party

... and with GuiXT... and with GuiXT

Final customer sales

Sold for resale

Frankfurt sales organization

Sales document Edit Goto Environment System Help

Personalizing the Frontend

Sales document Edit Goto Environment System Help

The R/3 System provides numerous options for settings and adjustments:

Define default values for input fields

Hide screen elements

Deactivate screen elements (shaded out). You can do this by, for example, defining transaction variants. If you preallocate all necessary parameters for parameter transactions, you do not need to go through the initial screen. These functions have been available in R/3 for several releases.

SAP now also includes the GuiXT. In addition to all the above functions, you can now:

Include graphics

Convert fields and add pushbuttons and text

Change input fields (or their F4 help results) into radio buttons

The GuiXT scripts are stored on the frontend. In accordance with local scripts, the GuiXT scripts determine how data sent from the application server is displayed. These scripts can be standard throughout a company, or they can be different for each frontend.

As of Release 4.6, GuiXT is part of the SAP standard system.


© SAP AG 1999


Navigation: Unit Summary

Identify the elements of a typical window

Navigate in the system

Make personal system settings


Exercises

Unit: Navigation Topic: Basic features

At the conclusion of this exercise, you will be able to:

• Log on to a given R/3 System

• Find transaction codes • Access the SAP Library

• Use F1 help to find field information

• Use F4 help to search for possible field entries

As a new user of the R/3 System, you begin to navigate the system using the menu paths and transaction codes. You also begin to access various online help and discover the kinds of information each provides.

1-1 Logging on to the R/3 System

Select the appropriate R/3 System for this course. Use the client, user name, initial password and logon language specified by the instructor. The first time you log on, you will get a prompt in which you must enter your new password twice. Make a note of the following:

Client: _ _ _ User: _ _ _ _ _ _ _ _ Password: ____________ Language: _ _

1-2 What is the maximum number of sessions you can have open simultaneously? __

1-3 Identify the screen names and find the transaction codes that correspond to the following menu paths?

1-3-1 Tools → Administration → Monitor → System Monitoring → User Overview

Name of screen: ________________________________________

Transaction: ___________

1-3-2 Accounting → Financial Accounting → Accounts receivable → Master records → Display


Enter Customer 1000 and Company code 1000 to get to the next screen.

Name of screen: _______________________________________

Transaction: __________

1-4 Help

1-4-1 If you choose Application help in the SAP Easy Access screen, which area of the SAP Library does it take you to ?

_________________________________________________________

To answer the questions below, you will need to go to the Display Customer: Initial Screen

1-4-2 Use F4 help on the Customer field to find the customer number for Becker ##.

Note: ## corresponds to your assigned group number.

_________________________________________________________

1-4-3 Use F1 help on the Customer field. What is the use of this field? Please write a brief summary of the business-related information.

_________________________________________________________

1-4-4 Use F1 help on the Company code field. If you choose the Application help button from the F1 help screen, which area of the SAP Library does it take you to?

_________________________________________________________

1-4-5 Which pushbutton do you need to use on the F1 help screen to find the parameter ID for the Company code field?

_________________________________________________________


Unit: Navigation Topic: User-specific settings


• Set a user parameter for a field

• Set various user defaults such as language, date format, and decimal notation

• Create folders and add transactions to your Favorites

• Select a start transaction of your choice as the default displayed after logging on (optional)

You begin to set various user-specific settings to personalize the system to your liking.

Exercises marked * are optional.

2-1 Setting user parameters.

2-1-1 Assign a parameter value for the Company code field to your user profile.

Note: The instructor will tell you what parameter value to enter.

Parameter ID: ___ ___ ___

Parameter value: ___ ___ ___ ___

2-2 Setting user defaults.

2-2-1 In your user profile, set your logon language to the value used for the course.

2-2-2 In your user profile, select the decimal notation and date format that you desire.

2-3 Defining favorites of your choice.

2-3-1 Insert at least one new folder under the Favorites folder.

2-3-2 Add any two of your “favorite” transactions to the corresponding folder(s).

2-3-3 Add the Internet address “http://www.sap.com” under the text “SAP Homepage”.

2-3-4 Add the Internet address for the online evaluation (the instructor will tell you the URL) under the text “Online Evaluation”.

*2-4 Setting a start transaction.

2-4-1 Enter a transaction of your choice as the initial transaction. You will then need to log off and on again for the change to take effect.

Note: If desired, you can change the initial transaction back to the system default (SAP Easy Access).


Solutions

Unit: Navigation Topic: Basic features

1-1 Log on to the system specified by the instructor and change your initial password.

1-2 You can open and close sessions using System → Create session (or using the appropriate icon) and System → End session. The maximum number of sessions you can have open simultaneously is 6.

1-3 To find the transaction code, select System → Status. These screen names and transaction codes correspond to the menu paths:

1-3-1 Transaction: SM04 for Screen Name: User list

1-3-2 Transaction: FD03 for Screen Name: Display Customer: General data

1-4 Help

1-4-1 The entire SAP Library is available including Getting Started.

Help → Application help

1-4-2 T-CO05A## (## corresponds to your assigned group number)

When you select F4 in the Customer field, the Restrict Value Range window appears. You can explore the various tabs to see the different search criteria available. Find a tab that includes the Name field and enter the following:

Field Name Values

Name Becker ##

Select the Continue Enter pushbutton. A window now appears listing the customer account numbers that match your search criteria. Select the line that corresponds to Becker ##, then select the Copy Enter pushbutton. This automatically copies the customer account number into the Customer field.

1-4-3 Suggestion: The customer is a unique key (account number) used to clearly identify the customer within the system.

1-4-4 FI – Accounts Receivable and Accounts Payable

1-4-5 Use the Technical Info pushbutton to find the Parameter Id: BUK.


Unit: Navigation Topic: User-specific settings

2-1 Setting user parameters.

2-1-1 To assign a parameter value to a field you will need the parameter ID of the field. First you need to select a transaction that contains this field. For example, Company code can be found in transaction FD03. Next, place the cursor on that field (just click on it with the mouse). Accessing:

F1 → Technical Info → Parameter ID

gives you the required information. For the Company code field, the parameter ID is BUK.

Finally, you enter the parameter ID and desired value in your user profile:

System → User profile → Own data

On the Parameter tab you enter the parameter ID and value that you want to be entered into the field. Save your entries.

2-2 Setting user defaults.

2-2-1 To set the logon language, go to your user profile:

System → User profile → Own data

On the Defaults tab, enter the language of your choice in the Logon language field.

2-2-2 To set the decimal notation and date format, remain on the Defaults tab in your user profile. Select the indicator adjacent to the notation and format you desire. Save your selections.

2-3 Defining favorites of your choice.

2-3-1 Favorites → Insert folder

Type any name for the folder then select Enter. You can add as many folders as you desire. Once created, folders can be dragged and dropped to position them where you want.

2-3-2 To create favorites, select specific applications (transactions) that you need as favorites for your daily work from the menu tree of the SAP standard menu. Add them to your Favorites list by selecting them and choosing Favorites → Add from the menu bar. Alternatively, use the mouse to drag & drop favorites to a folder. You can also use the menu path Favorites → Insert transaction to add using a transaction code.. Finally, you can move existing favorites to different folders later using Favorites → Move or using drag & drop.



2-3-3 Create Internet addresses using Favorites → Add Web address or file. When you select SAP Homepage from your favorites, an Internet browser will open and you will be connected to SAP’s homepage.

2-3-4 Favorites → Add Web address or file

You will use this link at the end of the course to fill out the course evaluation.

2-4 Setting a start transaction.

2-4-1 Extras → Set start transaction

Enter a transaction of your choice then select the Enter pushbutton. Notice the system message on the status bar indicates that your selected transaction has been set as the start transaction. The next time you log on, the system will go directly to your start transaction.

Note: To change back to SAP Easy Access as the initial screen, follow the menu path again, delete the transaction code and select Enter. The next time you log on, SAP Easy Access will be the initial screen.

© SAP AG 1999


Navigation

System Kernel


Communication

System Kernel


© SAP AG 1999

System Kernel: Contents

Flow of user requests through the system

Communication between the application layer and thedatabase

The processes on the frontend and application layers

Asynchronous update

Background processing and the spool system


© SAP AG 1999

System Kernel: Unit Objectives

Explain the relationships between the processeson the different client / server layers in the R/3SystemDescribe the basic structure of the R/3 Systemusing the appropriate technical terms



© SAP AG 1999

Presentation interface

Database interface

Dialog processing

SAP transaction concept

Asynchronous updating and the lock concept

Background processing

Spool

R/3 instance

The System Kernel


© SAP AG 1999

Screen Interpreter

The System Kernel

Operating System and Hardware Platform

ABAPDictionary

Programming Interface

Applications

Com

mun

icat

ion

Com

mun

icat

ion

Inte

rfac

eIn

terf

ace

Use

r U

ser i

nter

face

inte

rfac

e

Runtime Runtime EnvironmentEnvironment

ABAPInterpreter

In this unit, we discuss the central processes of the R/3 Basis System. This includes an explanation of how a user request is sent to and processed by the application layer, and which process types are involved in processing the request. Data entered by the user is sent through the user interface (the SAP GUI) to the dispatcher, which coordinates further processing. The work processes used are those that map to the same source code as the dispatcher and whose substructures such as Screen Interpreter and ABAP Interpreter are presented here. Another topic is data exchange with the database.


© SAP AG 1999

Presentation

Application

Buffer

Database

Communication

SAP GUISAP GUI SAP GUISAP GUI

Workprocess

Workprocess

Workprocess

DBDatabase processes

Processing User Requests

Dispatcher

The central process in the R/3 application layer is the dispatcher. Together with the operating system, the dispatcher controls the resources for the R/3 applications. The main tasks of the dispatcher include distributing transaction load to the work processes, connecting to the presentation layer, and organizing communication.

User screen input is received by the SAP presentation program SAP GUI, converted into its own format, and then sent to the dispatcher. The processing requests are then saved by the dispatcher in request queues and processed according to “first in / first out”.

The dispatcher distributes (dispatches) the requests one after the other to the available work processes. Data is actually processed in the work process. The user that sent the request through the SAP GUI is usually not assigned the same work process, because there is no fixed assignment of work processes to users.

Once the data has been processed, the processing result from the work process is sent through the dispatcher back to the SAP GUI. The SAP GUI interprets this data and generates the output screen for the user with the help of the operating system on the frontend computer.

During initialization of the R/3 System, the dispatcher executes the following actions, among others: it reads the system profile parameters, starts work processes, and logs onto the message server (this service will be explained later).


© SAP AG 1999

R/3 Presentation Interface

Presentation

Application

SAP GUIprocess

SAP GUIprocess

NC terminal

Terminal server

NC terminal

LAN / WAN

SAP GUIprocess

Windows PCJava

environment

Workstation/PC

Dispatcher

SAP GUI

The presentation interface SAP GUI (GUI = Graphical User Interface) implements the platform-specific input and output functions of the R/3 System. The SAP GUI is primarily based on the Windows Style Guide and is available for several platforms providing the same functions for each. If you have learned to use the R/3 System on one platform, with the exception of a few small platform-specific GUI attributes, you can use the system on another platform exactly the same as before.

The R/3 presentation software displays the graphical user interface using the tools provided by the relevant presentation environment (frontend operating system).

As of Release 4.6B you have a choice between the “classic” SAP GUI (a software package that runs on the frontend) and the SAP GUI for HMTL, controlled using a Web browser.

Data flow between the presentation layer and the application does not consist of prepared screens, but rather logical, compact information using control elements and user input.

The amount of data transferred during each screen change is usually only a few KB, which means that you can easily connect presentation servers across wide-area networks (WAN).


© SAP AG 1999

Native SQL

Database data

Application server Database server

ABAPinterpreter

SELECT *FROM ...

EXEC SQL.SELECT ...END EXEC.

Database data

Native SQL

OPEN SQL

Data

DBinterface

Localbuffers

Data

Database

R/3 Database Interface

Today, large amounts of data are usually administered using relational database management systems (RDBMS). These systems store the data and the relationships between the data in two-dimensional tables, which are known for their logical simplicity. The definitions of the data, tables, and table relationships are stored in the data dictionary of the RDBMS.

Within ABAP, SAP OPEN SQL is used to access application data in the database, independent of the corresponding RDBMS. The R/3 database interface converts the open SQL statements from the ABAP statements into the corresponding database statements. This means that application programs written in ABAP are database-independent. Native SQL commands can be used in ABAP.

When interpreting open SQL statements, the R/3 database interface checks the syntax of these statements and automatically ensures the local SAP buffers in the shared memory of the application server are utilized optimally. Data frequently required by the applications is stored in these buffers so that the system does not have to access the database server to read this data. In particular, all technical data such as ABAP programs, screens, and ABAP Dictionary information, as well as some business process parameters usually remain unchanged in a running system, making them ideal buffering candidates. The same applies to certain business application data, which is accessed as read-only.


© SAP AG 1999

R/3 Application Services

V2

DialogD

SAP Dispatcher

SpoolS

Background12

9

6

3

11 1

7 58 4

210

B

UpdateV

Lock admin.

E Gateway server

R/2 R/3

Message serverDisp.

Disp.

Disp.

Disp.

MSMS

GWGW

The operating system views the R/3 runtime system as a group of parallel, cooperating processes. On each application server these processes include the dispatcher as well as work processes; the number of work processes depends on the available resources. Work processes may be installed for dialog processing, update, dialog free background processing and spooling.

In addition to these work process types (dialog processing (D), update (V: for the German “Verbuchung”), lock management (E), background processing (B), spool (S), the R/3 runtime system provides two additional services for internal and external communication (below are the restrictions on the number of work processes):

The message server (MS or M) communicates between the distributed dispatchers within the R/3 System and is therefore the prerequisite for scalability using several parallel-processing application servers.

The gateway server (GW or G) allows communication between R/3, R/2 and external application systems.

Dialog: Every dispatcher requires at least two dialog work processes

Spool: At least one for each R/3 System (more than one allowed for each dispatcher)

Update: At least one for each R/3 System (more than one allowed for each dispatcher)

Background processing: At least two for each R/3 System (more than one allowed for each dispatcher)

Enqueue: Only one enqueue work process is needed for each system



© SAP AG 1999

The Dialog Work Process

Workprocess 1

Shared memory

Requestqueues

Frontend: SAP GUI

Dispatcher

Factory calendarScreensABAP programsTablesDictionary objects...

Applications buffer

Roll fileUser context

Roll area

Screenprocessor

ABAPprocessor

Databaseinterface

Taskhandler

Inte

rnal

mem

ory

Roll inRoll outBuffer access

LAN / WAN

Workprocess n

...

The following components on the application level are involved in processing a dialog request:

The dispatcher

Work process queues (administered by the dispatcher) for incoming requests

One of the dialog work processes

Buffers in shared memory and also possibly the roll file

The task handler coordinates activity within a dialog work process. It activates the screen processor or the ABAP processor (which control the screen flow logic and process ABAP statements, respectively) and executes the roll-in and the roll-out of the user context.

The memory management system differentiates between main memory areas that are available exclusively to a work process, and memory areas that can be used by all work processes. The memory space used exclusively by a work process stores session-specific data that must be kept longer than the duration of a work step. This data is automatically made available to the process at the start of a dialog step (rolled-in) and saved at the end of the dialog step (rolled-out). This data characterizes users (user context), such as their authorizations, administration information and additional data for the ABAP and dialog processor. Also it contains data collected by the system in the preceding dialog steps in the running transaction (see following slide). Additional memory areas used by all processes in shared memory include areas for the factory calendar, screen, table, and program buffers.


© SAP AG 1999

Work Process Multiplexing and SAP Transactions

Dialog-WP 0

Dialog-WP 1

Dialog-WP 2

PBO100

PAI100

PBO105

PAI110

PAI105

PBO110

PAIPBO

Screen

PBOPAI

PBOPAI

User chooses:Save / Cancel

Screen105

Screen100

Screen110

Business transactions areprocessing units that have related function; these transactions execute consistent database changes meaningful for the business. Typical examples are credit and debit postings, which only make sense together, or creating an order and reserving the relevant material.

Accordingly, an SAP transaction is implemented as a series of consistent, connected dialog steps. A user dialog step is represented by a screen (or a dynpro, which is a dynamic program = mask and flow logic).

In dialog processing, one transaction can use more than one dialog work process (work process multiplexing, only for dialog work processes). Asynchronous update is used for processing the dialog part of the transaction and the corresponding database update in different work processes and perhaps even on different servers.

In an SAP System, a dialog step starts with the processing of the data entered by the user [(Process After Input (PAI)] and the processing and sending of the next screen mask (Process Before Output (PBO); the system then receives the next screen processed by the user and once again analyzes and processes the input data on this screen. Dialog steps for the user and the system run asynchronously. For the system, a dialog step consists of two parts: the PBO and the PAI.


© SAP AG 1999

Locks in R/3 at the Business Process Level

DBDB XXX xxxx xxxx xxx xxx xx


UUU uuuu uuuu uuu uuu uu

UU uuuu uuu u

D WP E WP WP D WP

Change access At most read access

The lock mechanisms in today’s relational database systems are usually not able to handle business data objects (such as customer orders) that affect several database tables. To coordinate several applications simultaneously accessing the same business object, the SAP System provides its own lock management, controlled by the enqueue work process.

In order for the system to execute lock requests, you must first define a lock object in the ABAP Dictionary. The lock object contains tables whose entries are to be locked. A lock object consists of a primary table. You can also define additional secondary tables using foreign key relationships (the name of a user-defined lock object must begin with "EY" or "EZ").

You can specify the lock mode ("S”: shared lock or "E”: exclusive lock) for a lock object. An exclusive lock (mode "E") can only be set if no other user has set a lock (“E” or “S”) on the data record. The same user can request additional "E" or "S" locks within a program call sequence (call chain).

If a lock object is activated, the system generates an ENQUEUE and a DEQUEUE function module. These function modules are called ENQUEUE_<object_name> and DEQUEUE_<object_name> and are used in ABAP code to lock and unlock data.

© SAP AG 1999

Requesting a Lock From the Enqueue WP

Call Function'ENQUEUE_E...'

Enqueue server

. . .. . .

Dialog server

Lock table inmain memory

. . .

MSMS

D-WP

Dispatcher Dispatcher

E-WP

When a lock is requested, the system checks to determine whether the requested lock conflicts with any entries in the lock table. If there are conflicts, the lock request is rejected. The application program then informs the user that the operation cannot currently be executed. A message appears, for example, “Data is currently in use. Change not possible.”

The locks (enqueues) are administered by the enqueue work process using the lock table. The lock table is stored in the main memory of the server where the enqueue work process is running. If the dialog work process and enqueue work process are not running on the same server, they communicate through the message server.

Locks set by application programs are reset either by the application program itself or by a special update program (in the second part of SAP-LUW, see the next slide).


© SAP AG 1999

Asynchronous Update

PBO100

Screen100

PAI100

PBO105

PAI110

Screen105

PAI105

PBO110

Screen110

First change

D-WP 0 D-WP 1 D-WP 2 D-WP 2

commitcommit commit

Second change Save / Cancel

COMMITWORK

WP

XX

X X

Change noted Change noted

Changes to BWL tables

DBLUW

DBLUW

DBLUW

DBLUW

DBLUW

SAP Logical Unit of Work

A transaction corresponds to a logical unit of work (LUW).

However, as today’s database systems do not support cross-process transaction flow, we must differentiate between the elementary processing steps (LUWs) in the SAP System and those in the database system (SAP - LUW / DB - LUW). A DB - LUW is either committed or not updated (rollback). The DB - LUW moves the database from one consistent state to the next. This means that the data must be logical and correct before as well as after the LUW; this applies to both DB - LUW and SAP - LUW.

The start of an SAP transaction is also the start of an SAP - LUW. SAP - LUWs are completed either by a "COMMIT WORK" in the ABAP code, or by the completion of the corresponding asynchronous update (second part of the SAP - LUW). As explained previously, each dialog step in an SAP - LUW is processed by one work process, as is the case for the DB - LUW. Each database change is executed in its own DB-LUW.

The asynchronous updating usually used in an SAP - LUW allows the system to temporarily collect changes made by users and then, at the end of the dialog phase (in the second part of the SAP - LUW), make the necessary changes to the database in a separate update work process. To ensure data consistency, the resulting database change (which includes every “dialog step change”) is executed in only one final DB - LUW.


© SAP AG 1999

Updating Log Records

DBDB XXX xxxxXXX xxxx xxxx xxx xxx xx


UUU uuuu uuuu uuu uuu uu UU uuuu uuu uVB*VB*

Second part ofSAP- LUW

Update server

Call Function... in updatetask

. . . . . .

MSMS

. . .

Dialog server

D-WP

Dispatcher Dispatcher

V-WP

When the ABAP keyword CALL FUNCTION “…” IN UPDATE TASK is processed during asynchronous update the data changes are stored as log records in temporary tables VB*. These system tables store data changes made by a user within an SAP transaction. The log record contains the name of the update routines to execute, and all the data required to make the changes to the database.

The update itself is triggered by the ABAP statement COMMIT WORK specified in the last dialog step of an SAP transaction. The locks set by the application program using the enqueue work process are passed onto the update work processes. If the user cancels the SAP transaction during the dialog phase, or if the transaction terminates for another reason, the database changes to make are discarded. In the second part of the SAP-LUW, the update work process reads the log records from the VB* tables and updates the corresponding application tables in the R/3 database according to the changes buffered in the VB* tables.

During the update, errors cannot be corrected interactively by the user. Instead, the system terminates processing of the current update components. Users are automatically notified by express mail when an update terminates. The administrator can then analyze why the update terminated, and fix the problem (see “Administration” unit).

© SAP AG 1999

Long-Running ABAP Programs

D-WP D-WP D-WP D-WP D-WP D-WPD-WPD-WP12

9

6

3

11 1

7 58 4

21012

9

6

3

11 1

7 58 4

21012

9

6

3

11 1

7 58 4

21012

9

6

3

11 1

7 58 4

21012

9

6

3

11 1

7 58 4

21012

9

6

3

11 1

7 58 4

21012

9

6

3

11 1

7 58 4

210

Dialog Work Processes for Dialog Transactions

Two users are blocking 7 dialog work processes with long-running transactions

Dispatcher

Dialog work processes should not be loaded down with long-running dialog steps, as these work processes would then not be available to other users. The remaining dialog work processes would have to handle many more users, thus considerably increasing response times.

This is the reason for the parameter rdisp/max_wprun_time (default setting: 300 seconds), which sets the maximum time a dialog step is allowed to remain in a dialog work process. If this time is exceeded by more than double, the dialog step is terminated and the started transaction terminates with an error. This allows the administrator to ensure that users execute long-running actions only in the background work processes, which are designed for these types of long-running actions.


© SAP AG 1999

Background Processing

DBDB

11

44

12

9

6

3

11 1

7 58 4

210

Job

22

Dialog server

. . . D-WP

Background processing server

. . .

XXX xxxxXXX xxxx xxxx xxx xxx xx


UUU uuuu uuuu uuu uuu uu UU uuuu uuu u

Scheduling tableScheduling table

Job1Job1 CC ...... ......

33

Batch scheduler(every 60s)

Dispatcher

D-WP

Dispatcher

B-WP B-WP B-WP

Background work processes are designed for periodic tasks such as reorganization or the automatic transfer of data from an external system to the R/3 System.

Background processing is scheduled in the form of jobs. Each job consists of one or more steps (ABAP reports, external programs, or other operating system calls), that are processed sequentially. You can also set priorities (from "C" to "A") so that certain jobs are prioritized.

Job processing is not generally triggered immediately (immediate start). Instead you specify a start date and time when you schedule the job. It may also be necessary to start jobs periodically, for example, system control jobs repeated on a fixed cycle. Using the program SAPEVT, you can trigger a job start at the operating system level.

The background scheduler is responsible for automatically triggering the job at the specified time. The background scheduler is an ABAP program that regularly looks in the scheduling table for jobs to be executed and then ensures that they are executed (RDISP/BTCTIME, default 60 s).

© SAP AG 1999

R/3 Printer Services

Printer server

D-WP S-WP

LAN WAN

Spool server

. . .

Operating systemspool

TemSeTemSe

Database / file system

ABC

XYZ

1B ...41 4243 ....0D 0A

1B ...41 4243 ....0D 0A

Operating systemspool

Triggering of print process, for example from SAP GUI: Printing a list

ABC

XYZ

Dispatcher

Spooling refers to the buffered transfer of data to output devices such as printers, fax devices, and so on. In distributed systems, networked administration is necessary for this output.

The R/3 System spool mechanism can supply print requests to printers and external spoolers both within a local network as well as across wide-area networks (WANs). The spool mechanism works with the local spool system on each server.

Spool requests are generated in dialog mode or during background processing and are then set in the spool database with details about the printer and the print format. The data itself is stored in the TemSe (TEMporary SEquential object) database.

When data is to be printed, a print request is generated for a spool request. This print request is processed by a spool work process.

Once the spool work process has formatted the data for output, it returns the print request to the operating system spool system.

The operating system spool takes over queue management and ensures that the required data is passed to the output device.


© SAP AG 1999

The R/3 Instance

D-WP

Dispatcher

Instance (a) Instance (b)

entral? instance (c)揅

Dispatcher

. . . D-WPD-WP. . .

. . .MSMS

Dispatcher

D-WP B-WP

V-WP E-WP B-WP S-WP

An instance is an administrative unit that combines R/3 System components providing one or more services. The services provided by an instance are started or stopped together. You use a common instance profile to set parameters for all the components of an instance.

A central R/3 System consists of a single instance providing all the necessary R/3 System services.

Each instance has its own SAP buffer areas.

The example illustrates how an additional background processing server (a) and dialog server (b) are set up. These instances, which provide specific services, generally run on separate servers, but can also run on the same server, if needed.

The message server provides the application servers with a central message service for internal communication (for example, trigger update, request and remove locks, trigger background requests).

The dispatchers for the individual application servers communicate through the message server, which is installed once in each R/3 System (it is configured in the R/3 System profile files).

Presentation servers can also log on to an application server through the message server. This means that you can use the message server performance database for automatic load distribution (logon load balancing).


© SAP AG 1999

System Kernel: Unit Summary

Explain the relationships between the processeson the different client / server layers in the R/3System

Describe the basic structure of the R/3 Systemusing the appropriate technical terms



Exercises

Unit: System Kernel Topic: Architecture of the SAP Basis System

At the conclusion of these exercises, you will be able to:

• Analyze the architecture of the SAP Basis System using various transactions.

• Execute programs in dialog and background sessions.

No scenario

1-1 System overview: Answer the following questions using transactions SM50, SM51, and SM04.

1-1-1 Which application server are you working on?

1-1-2 What are the types of work processes in the training system?

1-1-3 How many dialog work processes does the system have?

1-1-4 How many users are currently logged on to the system?

1-1-5 How many sessions do you have open?

1-2 Dialog processing: Executing jobs

1-2-1 Run report RSPFPAR in dialog mode.

Hint: Choose System→ Services → Reporting (transaction SE38). Enter program RSPFPAR; this report displays the profile parameters of your system. Choose Execute (F8). On the following screen, restrict the selection to parameters rdisp* and then choose Execute again. What information does the parameter rdisp/mhost provide?

1-2-2 (Optional): Create a variant of report RSPFPAR. To do this, choose Goto → Variant (F7). On the following selection screen, enter a name for the variant (for example, TEST##, where ## is your seat number) and choose Create. Restrict the view (as in 1-2-1) to the parameters rdisp*. Choose Attributes and enter a meaningful short description of the variant. Then choose Save to save the variant.

1-2-3 Execute report RSPFPAR in transaction SE38 by choosing Execute with variant. Choose the variant you created or a variant provided by the instructor. What has changed?

1-3 Background processing: Scheduling jobs



1-3-1 Execute report RSPFPAR in the background using the variant you created in 1-2-2 or a variant provided by the instructor. Enter a name such as 1_RSPFPAR##, where ## is your seat number.

Hint: Choose Background. On the following screen, enter the variant of report RSPFPAR and choose Execute immediately. What happens?

1-3-2 Look at the details of your background job. Hint: choose System → Services → Jobs → Job overview (transaction SM37). On the following screen, choose Execute (F8). Select your job and look at the spool list the report created.

1-3-3 (Optional): Redo 1-3-1, but this time schedule the job to start five minutes in the future. Enter a name such as 2_RSPFPAR##. What does the job overview look like now?

Solutions

Unit: System Kernel Topic: Architecture of the SAP Basis System

1-1 System overview

1-1-1 Call transaction SM51 and determine the name of the instance (Server names column)

1-1-2 From transaction SM51, list the types of work processes (Ty. column). You can also use transaction SM50 to answer this question. SM50 provides detailed work process information.

1-1-3 Use transaction SM50 to determine the number of dialog work processes (count the processes displayed). SM50 displays the work processes for one dispatcher. You can display all the work processes in the entire system using transaction SM66 (choose Process selection)

1-1-4 Use transaction SM04 to display a user overview for one dispatcher. To display all the users in the entire system, use transaction AL08.

1-1-5 Use transaction SM04 to determine how many sessions you are using (Sess. column) Alternatively, enter /o in the command field.

1-2 Dialog processing: Executing jobs

1-2-1 For procedure, see exercise description. Parameter rdisp/mshost specifies on which server the message server is running.

1-2-2 For procedure, see exercise description. When executing using a variant, the selection screen is pre-filled with the variant data.

1-2-3 Due to the preset variant, you do not need to make any additional entries. The report results are the same as before.

1-3 Background processing: Scheduling jobs

1-3-1 For procedure, see exercise description. A message appears in the status bar indicating report RSPFPAR was started as a background job.

1-3-2 For procedure, see exercise description. The spool list displays an overview of the profile parameters rdisp*.

1-3-3 For procedure, see exercise description. If you execute transaction SM37 (job overview) within the specified five minutes, you will see your job with status “Released”.


© SAP AG 1999


Navigation

System Kernel


Communication

Development Using ABAP Workbench


© SAP AG 1999

Development Using ABAP Workbench: Contents

R/3 data structure

Recommended R/3 System landscape

Transport of developments

ABAP Dictionary

Table structure and relationships

Workbench tools

ABAP Editor


© SAP AG 1999


Explain the data structure of the R/3 System

Explain why transports are required

Describe the function of the ABAP Dictionary

Navigate in the ABAP Workbench

Name the basic Workbench tools

Development Using ABAP Workbench: Objectives


© SAP AG 1999

R/3 System Data Structure

Client

Users(Authorizations,

masterrecords,...)Client-specific Customizing

(Company codes, plants, warehouses, Salesorganizations, human resources, ...)

Application data(Orders, .......)

Client-independent Customizing

Developmentclasses

MMFI CO HR PPBasis SD ...

Repository(Dictionary, reports, transactions, function

modules, ...)

The R/3 System contains different types of data.

Some data can only be accessed from one client, such as business application data (documents, material masters, and so on), and most Customizing settings. Customizing is used to define a customer’s organizational structures, such as distribution channels, company codes, and so on, and to set customer-specific parameters for SAP transactions.

The client-specific data is closely related. At input, application data is checked against the Customizing settings in the client. If inconsistencies are found, the input is rejected. This is why application data usually makes sense only in its own Customizing environment.

In addition to the client-specific Customizing settings, there are other settings in the R/3 System that are set once and are active for all clients. These client-independent Customizing settings include printer settings, for example.

The Repository is also client-independent. It contains all ABAP Dictionary objects (tables, data elements, and domains) as well as all ABAP programs, menus, screens, and so on.

Because they are client-independent, Repository objects developed in one client are identical in all other clients in the same system.


© SAP AG 1999

Customizing

ASAP Roadmap

R/3 System Customizing

Customizing

. . .

.Customizing

CoCd. Company name

ViewView: : ChangeChange CompanyCompany Code Code

New entries

In addition to the various data types in the R/3 System, there are also different types of changes and adaptations in the R/3 System.

As the R/3 System is standard software, it must be adapted to the individual needs of each company that uses it. This tailoring process is called Customizing, which includes the client-specific and client-independent data shown in the slide. A small amount of Customizing may also be required after an R/3 System upgrade.

Customizing is not developed and tested in the same client in which it will be in production. This means that several clients are required during an R/3 implementation. Customizing is executed and tested in one client. In a large installation, it may make sense to combine and test Customizing subprojects in another client. Production occurs in its own client.


© SAP AG 1999

Changes to Repository Objects

Development

EnhancementsModifications

. . .

Repository

DEV

PRD

QAS

In contrast to Customizing, the Repository does not need to be changed or enhanced for an R/3 System implementation:

Customers can add their own developments to the Repository.

The customer modifications or enhancements (customer objects added to the SAP standard system) modify the Repository. SAP provides the interfaces for these enhancements in the SAP standard system.

Modifications change SAP objects, such as reports and table definitions. The Repository delivered from SAP is not only enhanced, but changed as well. This is why the modifications may need to be adjusted to a new Repository installed during the next R/3 upgrade. This adjustment may take some time.

Whether this client and any other clients are distributed in the R/3 Systems primarily depends on whether any changes are to be made to the Repository.

If this is the case, development and production environments must be in separate R/3 Systems. Otherwise, any ABAP programs created in the development client that still needed to be tested would be immediately available in the production client. This would be a critical security and performance problem.

If changes are to be made to the Repository, we recommend two (even better three) R/3 Systems. The third R/3 System can be used for testing and quality assurance.


© SAP AG 1999

Three-System Landscape Recommended By SAP

ProductionDevelopment Quality Assurance

SAND

TEST CUST TRNGQTST PROD

To ensure system consistency, we recommend you set up a system landscape consisting of three systems. These three systems include the "production" clients (for development, Customizing, and production) and any other clients desired (training, sandbox client, and so on).

A three-system landscape supports the following recommended process:

Development of customer-specific programs as well as required Customizing takes place in the development system.

All Customizing settings as well as changes (developments, corrections, or modifications, if required) to the Repository are transferred to the quality assurance system (or "test system") to be checked there without affecting production.

All objects and settings imported into the test system can then be transferred into one or more production systems.

A three-system landscape also allows testing of upgrades and helps to minimize downtime during upgrades of the production system.

The systems within a system landscape must have unique three-character names.


© SAP AG 1999

Project Management in the Workbench Organizer

Change requestChange request

Task

Project Project leaderleader

Developer

Developer

Developer

Task

Task

When a new development project starts, the project leader creates a change request, and assigns the project team members to it. The Workbench Organizer assigns a project number to the change request using the naming convention <sid>K9<nnnnn> (for example, C11K900001).

The Workbench Organizer then creates a task for each team member. Whenever a team member assigns a Repository object to the change request, it is entered in his or her task. At the end of the project, the task contains all of the objects that the team member has worked on.

When they have finished with their part of the development project, each team member releases his or her task. The task objects are then passed to the change request. Once all team members have released their tasks, the project leader can release the change request. A change request combines all Repository objects that were created or changed during a development project.


© SAP AG 1999

Workbench Tools

Report zreport.

data field like spfli.parameters p_carr like spfli-carrid.* ...* ... select * from spfli into field where carrid = p_carr. write: / field-carrid, field-connid, ... . endselect.

call screen ? 100? ... ...

Key 1

.

.

.

Key 2

.

.

.

Key n

.

.

.

F 1

.

.

.

F 2

.

.

.

F n

.

.

.

ABAP Editor

ScreenPainter

FunctionBuilder

ABAPDictionary

Repository objects are created and edited using the ABAP Workbench.

When editing Repository objects, you can either call the ABAP Workbench tool directly and then choose the relevant Repository objects, or you can navigate forward from the Repository objects to the tools.

The Repository Browser provides access to the Repository objects.

The ABAP Workbench contains tools for the entire software development cycle.

Using the ABAP Workbench, developers can create client / server applications without any problems and without having to deal with communication and distribution aspects.


© SAP AG 1999

Screen Interpreter

The ABAP Dictionary


ABAPDictionary


Applications

Com

mun

icat

ion

Inte

rfac

e

Use

r Int

erfa

ce

Runtime Environment

ABAPInterpreter

The ABAP Dictionary is a central component of the ABAP Workbench. It contains the business and technical definitions and descriptions of the SAP data. The ABAP and Screen Interpreters continuously accesses the dictionary information store.

The ABAP Dictionary contains tables, views, lock objects, and F1 and F4 help, among other objects.

Each database system also has its own dictionary. However, in the following we are referring exclusively to the R/3 data dictionary.


© SAP AG 1999

Modeling

Real World

Abstraction

Modeling

A person or group can only cope with a limited level of complexity. This is why the relevant business processes are abstracted from the real world. All unimportant information is discarded.

Models allow you to reduce the complexity of a system down to its essential components. While creating the models, you determine what is “important” and “relevant”. The models allow you to build new and increasingly complex systems and solve more demanding problems.

Modeling is based on a segment of the real world that is significant for business-oriented operations.

The SAP application models document the business processes and how they relate in R/3 applications. They allow you to create more transparency than ever before in your application software. The structures of business objects and their business processes are clearly described and graphed according to how the relevant enterprise uses them. The models mirror clear structures and describe who in an enterprise does what, when, how, and with which objects.


© SAP AG 1999

Models

Materialmaster creation

Set materialtype

Material typeset

Transactions

Processes

ABAP

11003Plant

Material11027

Plant-specificmaterial

11006

Tables andrelationships

Data

ABAPDictionary

The process model describes the dynamic aspects of the business information system and the time dependencies of functions. The triggering mechanism for a function is called an event. An event determines the flow logic of event-controlled process chains (EPCs). In addition to representing the time-dependent sequence of functions, the input and output functions as well as the organizational units used for executing the function can be described.

Data models are created to formally map the data needed within the business processes in a global functional context. The SAP data model represents the information objects that are relevant for the company along with their relationships to each other from the business point of view, using a Structured Entity Relationship Model (SERM). An entity type maps real world objects that have a business significance and a corresponding object in the R/3 System.

The SAP-SERM provides rules and design principles needed to clearly describe relevant business objects along with their semantics, SAP specifications in a model [(SAP Enterprise Data Model (EDM)].

Using the ABAP Workbench, data models can be displayed using text or graphics. The detail of a data model displayed can be changed dynamically. Users can create their own individual detailed views of data models.


© SAP AG 1999

What is the ABAP Dictionary?

ABAPEditor

ScreenPainter

FunctionBuilder

ABAPDictionary

- Description

- Meaning

- Data

linkage

The ABAP Dictionary is used to create and manage data definitions. It allows you to describe all data and its relationships used in the system and store this data centrally without redundancies. The activation mechanism ensures that any changes made here are instantly used by all affected system components.

The ABAP Dictionary is an integrated, active dictionary, that is, it is fully integrated into the SAP development environment. Every definition in the dictionary only needs to be created once and is then available everywhere in the system. Any information created or changed in the active ABAP Dictionary is automatically available, ensuring up-to-date runtime objects, data consistency, and data security.

The way the ABAP Dictionary is integrated in the program flow is based on the interpretive R/3 runtime environment. The ABAP processor does not use the original ABAP program. It interprets a runtime object created from the program text prior to the first time the program was executed. If the timestamp comparison recognizes a difference between the program and the ABAP Dictionary, the runtime object is automatically regenerated before being executed.

All performance-critical information is stored in the runtime objects (programs, masks, and so on). The system ensures that this information is always up-to-date at the time of execution.


© SAP AG 1999

Table Definition

Key 1 Key 2 Key n

.

.

.

.

.

.

.

.

.

F 1

.

.

.

F 2

.

.

.

F n

.

.

.

Table

Function fieldsPrimary key

Lines


Data elementsemantic attribute

Domaintechnical attribute

A table is a two-dimensional matrix. It has a name and attributes, such as the table type. Every SAP table has a primary key consisting of a combination of columns that uniquely identify a table record. This means a table cannot contain two records with the same primary key.

A field has a name and attributes. For example, it can be a primary key field. A field is dependent on a table and is, therefore, not an independent object and can only be maintained within the table. A table field is defined using domains and data elements.

A domain is used to define the technical attributes of a table field and contains technical attributes of the table field, such as field length, field type, output attributes, and any value restrictions based on default values.

A data element is the semantic definition of a table field and can contain a short description of the table field, for example, displayed when the user chooses F1. As of Release 4.6, the technical attributes of a field can be defined in the data element, without having to use a domain.

Tables, data elements, and domains are maintained centrally in the ABAP Dictionary. When a table is activated, it is stored under the same name in the database.

© SAP AG 1999

Two-Level Domain Concept

Table SPFLIMANDT CONNIDCARRID ... ...AIRPFROM AIRPTO ...

Domain S_AIRPID

Data element S_FROMAIRP Data element S_TOAIRP

The two-level domain concept allows you to define and maintain technical field attributes at domain level. A domain can pass its field attributes to any number of fields, whereby only the domain, but not the individual fields, must be explicitly changed when the defined field attributes are modified. This also ensures that if domains are identical, field values can be compared without requiring conversion.

The data element describes the semantic attributes of a field in the context of the table. These are attributes that are only important at that location and not globally (such as the technical attributes).

The example here shows the table SPFLI from the ABAP flight booking model. The table is a central store of flights, such as Lufthansa flight XY from Frankfurt to New York. The table contains the departure airport (AIRPFROM) and arrival airport (AIRPTO) fields. From a business viewpoint the departure airport and the arrival airport are two separate entities, which is why two data elements, S_FROMAIRP and S_TOAIRP, are defined. As both columns contain names of airports, both data elements are related to the same domain, S_AIRPID.


© SAP AG 1999

Use of Foreign Keys to Ensure Data Consistency

CARRID CONNID ...

SCARR (check table)

CarrnameAAAFLH

UA......

American AirlinesAir FranceLufthansa

United Airlines.....

CARRID

Airline

Flight number

Maintain flight

AB

0020

AA 0400AAAZAZ

040204102402

. . . . . .

...

Foreign key relationship

...

SPFLI (foreign key table)

Relationships between tables can be defined in the ABAP Dictionary. These relationships are called foreign keys and must be explicitly defined at field level.

Foreign keys are primarily used to ensure data consistency. New data entered in a table is checked against existing data to ensure that the data is consistent with existing data. The new data is created in a foreign key table. The data is checked for data consistency against check tables.

There are several technical prerequisites that must be met before foreign key relationships between tables can be created. These are described in detail in course BC430 “ABAP Dictionary”.

Example: In a dialog transaction, a new flight is created for the airline “AB”. Flights are stored in table SPFLI, in which foreign key relationships for other tables in the flight model are stored. The system uses the foreign key relationship to check whether the specified airline is already contained in the central airline table SCARR. In our example, airline “AB” does not exist. This means no flights can be defined for this airline. The system denies this entry on the input screen.


© SAP AG 1999

Views

User view 1

Join

Projection

Selection

Table 1


Table 1Table 3

ABAPDictionary

Despite the close logical relationship between the SAP data model and the ABAP Dictionary, it may be necessary to distribute entity types among several tables in the ABAP Dictionary, or to combine several entity types in one table. To do this, views are defined in the ABAP Dictionary. These views create the connection between the entity types in the data model and the tables in ABAP Dictionary.

A view is a logical view of one or more tables. Data for a view is not physically stored but is derived from one or more tables when the view is accessed. If a table contains a large number of fields, but you only want to read some of the fields, you can define a view to restrict the access to only those table fields in which you are interested. Views allow quick access to specific data.

Views are defined in the ABAP Dictionary. You can use the relational operators JOIN, PROJECTION, and SELECTION. JOIN defines the connection between the Basis tables used in the view. PROJECTION specifies which Basis table columns to add to the view. SELECTION defines which table entries to add to the view.

The ABAP Dictionary includes several view types distinguished by their task and output amount. As of Release 4.0, view data can also be buffered on the SAP application layer.

© SAP AG 1999

R/3 Standard Function: Input Help

Airline

Flight number

Maintain flight

LH

F4F4

No. Departure city Arrival city

AirlineAirline

04000400 FrankfurtFrankfurt New YorkNew York

04020402 FrankfurtFrankfurt New YorkNew York

LHLH

24022402 FrankfurtFrankfurt BerlinBerlin

...... ......

Input help

Input help (F4 help) is a standard function in the R/3 System. It allows the user to display a list of possible values for a screen field. A value can be directly copied to an input field when the user selects it from the list.

Fields with input help are indicated in the R/3 System with a combo box to the right of the field. This combo box appears when the cursor is in the corresponding screen field. The help can be called either by clicking this box or by choosing F4.

If the number of possible entries in a field is very large, the user can restrict the number of values displayed by defining restrictions. The input help provides additional information in the display for fields where the input choices are not self-explanatory.

Input help can be programmed in ABAP or defined in the ABAP Dictionary. Input help defined in the latter is known as search help as of Release 4.0. A search help is defined in the ABAP Dictionary and assigned to various types of table fields. Screen fields with these types of underlying table field definitions automatically provide F4 help.

As of Release 4.6, customers can add their own search paths to an SAP search help, without having to modify the system.


© SAP AG 1999

Screen Interpreter



ABAPDictionary


Applications

Com

mun

icat

ion

Inte

rfac

e

Use

r Int

erfa

ce

Runtime Environment

ABAPInterpreter

The development environment in R/3 provides full access to the R/3 development tools; these are the tools available to the SAP developers.

You can also view the source code and change it, if necessary.

Using the tools, you can also create your own programs and can fully integrate them in the R/3 System. The ABAP programming language used in the R/3 System can only be executed within the R/3 runtime environment.


© SAP AG 1999

+++ List +++ List +++ List +++ List +++1st line of list2nd line of list3rd line of list4th line of list5th line of list.........

ABAP Language

S 1a

.

.

.

S 2a

.

.

.

F 1a

.

.

.

F 2a

.

.

.

F 3a

.

.

.

F 4a

.

.

.

S 1b

.

.

.

S 2b

.

.

.

S 3b

.

.

.

F 1b

.

.

.

F

.

.

.

.

.

.

Report zreport.data field like spfli.* ...parameters pca

select *

write: /

call screen ?

ABAP

r like spfli-carrid.* ...* ...

from spfli into field where carrid = pcar. field-carrid, field-connid, ... .endselect.

100?* ...

TablesTables ScreensScreens

ListsListsSelectionScreens

SelectionScreens

Advanced Business Application Programming (ABAP) is SAP’s own programming language. All business applications and a part of the Basis System are written in ABAP.

ABAP stores all metadata in the ABAP Dictionary, which supports business data types.

The database is accessed through ABAP usually using OPEN SQL, which means program development is independent of the database system used in the system.

ABAP supports the simple and effective creation of graphical user interfaces. ABAP objects can also be used for object-oriented programming.

The separation of text elements such as list headers, texts for input fields, and so on, allows ABAP to support multiple languages.


© SAP AG 1999

Create session

End sessionUser profile

ServicesUtilities

ListsWorkflow

LinksPersonal notes

Own spool requestsOwn jobs

Short messageStatus...

Log off

System Help

Repository data

Transaction ZTA01

Report ZREPORT

Program(screen) ZREPORT

Screen number 1000

Program(GUI) RSSYSTDB

GUI status %_00

Navigating to the Source Code

Double-click

ABAP Editor

Screen Painter

Menu Painter

SAP delivers the entire source code for the ABAP programs. Customers can look at the code and even use it as a template for their own programs.

By double-clicking a field on the System status screen, you can navigate directly to the ABAP Workbench. The Workbench displays the source code for the relevant context (assuming you have the proper authorization).

The most important development tools are:

The Object Navigator (transaction SE80)

The ABAP Editor (SE38) for writing programs

The Screen Painter and the Menu Painter for creating graphical user interfaces

The Function Builder (SE37) for developing function modules

The Class Builder for object-oriented programming

Test and optimization tools

- Debugger

- Runtime analysis

- SQL trace

- Test Workbench: Computer Aided Test Tool (CATT)


© SAP AG 1999

DictionaryData ModelerInterfaceABAP EditorFunction BuilderClass BuilderContext BuilderProgramming environmentBusiness Object BuilderWorkflowOther tools

OverviewDevelopment

TestUtilities

ABAP WorkbenchTools

ABAP Editor

Pretty Printer Template

Report ZWORLD

ABAP Editor: ABAP Editor: ChangeChange Report ZWORLD Report ZWORLD

SE38

REPORT zworld.

* Isn 憈this a great report? ;-)* ...

WRITE ello World扝 ! ?

* ...* ...

You use the ABAP Editor (transaction SE38) to create and edit programs.

When you use the ABAP Editor, always keep in mind that ABAP programs are not stored as ASCII files, but as entries in database tables. Therefore, we recommend that you only use the ABAP Editor when writing ABAP programs, and not any other word processor.

The Editor provides a syntax check as well as the option of writing ABAP key words (commands) in CAPITAL LETTERS.

Double-clicking a Repository object in the code takes you out of the Editor to another tool in the development environment, such as the ABAP Dictionary, Screen Painter, or Menu Painter.

The ABAP Editor works in conjunction with the modification assistant, which logs customer changes to SAP code and simplifies the adjustment required at an upgrade if any modifications were made to the system. The adjusted is simplified as the source comparison occurs at the level of program blocks, such as subprograms or modules (PAI and PBO, for example). The modification assistant also provides a clear overview of modifications that can be particularly helpful for large projects.


© SAP AG 1999

Object Navigator

Object list Edit Goto Utilities Environment System Help

ObjectObject Navigator Navigator

Development classProgramFunction groupClassLocal object

Program objectsFunction group objectsDictionary objectsBusiness EngineeringOther objects

Display

Edit

Object list

Single object

SE80 iwdf4041 INS

Using the Object Navigator (transaction SE80) you can clearly organize and administer your developments.

The Object Navigator’s user interface is very similar to a file manager.

The Object Navigator is separated into a navigation area and a work area. The navigation area displays the objects; the work area starts the tools for the corresponding development objects. The following tools can be used in the work area: the ABAP Dictionary, the Class Builder, the ABAP Editor, the Function Builder, the Screen Painter, the Menu Painter, and text element maintenance.


© SAP AG 1999

Actions at the End of a Project

Quality Assurance / Production Systems

Export ImportProject Leader

TMS

Release change Release change requestrequest

Create objectCreate object

Assign object toAssign object todevelopment classdevelopment class

Assign object to Assign object to change requestchange request

ReleaseReleasetasktaskAutomatically Automatically

assigned to taskassigned to task

DEV

QAS PRD

While developers are working on objects in a change request, these objects are reserved exclusively for those developers.

When the developers have finished their work, they release their tasks. The objects and their locks are passed from the task to the change request. The objects can still be changed by all project team members, as the Workbench Organizer (WBO) automatically creates additional tasks as required.

When the project is complete, the project leader releases the change request. The locks on the objects in the change request are released.

Change requests may be transportable or local. The WBO classifies them automatically depending on their development class. The following steps are performed only after transportable change requests are released:

As soon as the change request has been exported, a test import determines whether all of the objects can be imported into the target system

The Repository objects are exported to a transport directory.

The export and test import results are written to the transport log for the change request, which is then checked by the developers.

Import into the target system is not automatic. It is triggered in the Transport Management System (TMS). After the import, you can check the import logs.


© SAP AG 1999

Writing an Application

The ABAP Workbench supports the entire software development cycle

Modeling

RepositoryBrowser

ABAPDictionary

Screen Painter

Menu Painter

FunctionBuilder

ABAP Editor

Debugger

Testsequences

Performancetools

WorkbenchOrganizer

Versionmanagement

AnalysisAnalysis//designdesign ImplementationImplementation TestTest AdministrationAdministration

SAPsolution

ProjectProject management management - - Workflow model Workflow model - - Documentation Documentation - - Prototyping Prototyping

The ABAP Workbench is SAP’s development environment for client/server enterprise business solutions. It supports the entire software development cycle with tools for modeling, programming using the 4GL language, ABAP, defining data and table structures, and for designing graphical user interfaces. It also contains comprehensive tools for testing, fine-tuning, and maintaining software, as well as supporting large development teams.

In the concept phase of a project, you enter the results of your analyses into the SAP data model. This enables you to turn your concepts into fields, tables, and so on. You can then develop your program components in any sequence you choose — they do not have to be combined into a single application until you want to run it. The development cycle concludes with program tests and transport into the production system.

In addition to the development tools, SAP also provides a library of pre-defined business and utility software components, which you can easily incorporate into your own programs.


© SAP AG 1999

Development Using ABAP Workbench: Summary

Explain the data structure of the R/3 System

Explain why transports are required

Describe the function of the ABAP Dictionary

Navigate in the ABAP Workbench

Name the basic Workbench tools



© SAP AG 1999


Navigation

System Kernel


Communication

Communication


© SAP AG 1999

Communication: Contents

Interfaces to the R/3 System:

Remote Function Call (RFC)

Object Linking and Embedding (OLE)

Connecting R/3 to the Internet

Electronic Data Interchange (EDI)

Data transfer interfaces


© SAP AG 1999

Communication: Unit Objectives

Name the most important interfaces in the R/3System

Describe the importance of the RFC interface

Describe how the R/3 System can be connected tothe Internet

Name interfaces for data transfer



© SAP AG 1999

Screen Interpreter

Communication Interfaces


ABAPDictionary


Applications

Com

mun

icat

ion

Inte

rfac

e

Use

r Int

erfa

ce

Runtime Environment

ABAPInterpreter

The R/3 System ensures portability by using industry-standard interfaces that support the interaction of applications, data, and user interfaces. The system can interact with various operating systems, databases, and networks. The R/3 System uses open industry standards, such as TCP/IP, EDI, OLE, and open interfaces.


© SAP AG 1999

Communication: R/3 is an Open System

RFC

CPI-C

TCP/IP LU6.2

OLEOpen Interfaces

EDI

ALE

HTTP

The R/3 System is an open system. It supports a variety of network communication protocols. Information can be exchanged between R/3 Systems and other R/3, R2, or non-SAP systems across a network.

SAP supports the Transmission Control Protocol / Internet Protocol (TCP/IP) and System Network Architecture: Logical Unit 6.2 (SNA LU6.2) protocols. Communication within the R/3 System uses the standard protocol TCP/IP. LU6.2 was developed by IBM and is used to communicate with mainframe-based R/2 Systems.

R/3 application programming supports the following communication interfaces: common programming interface communication (CPI-C), remote function call (RFC), and object linking and embedding (OLE) automation.

For more information about communication, see the online documentation. You can also order an “Interface Adviser” Knowledge CD from SAP that uses many practical examples to explain communication in the R/3 System. SAPNet also contains additional information, such as under the alias /int-adviser.


© SAP AG 1999

Remote Function Call

R/3 System

R/3 System R/2 SystemExternal System

SNA Gateway

ABAP program ABAP programABAP program

ABAPprogram

Externalprogram

ABAPprogram

RFC interface RFC interface RFC interface

RFC interface

Remote Function Call (RFC) is a communications interface based on CPI-C, but with more functions and easier for application programmers to use. You can use R/3 and R/2 Systems as well as external applications as RFC communication partners.

For communicating with R/2 Systems, additional software (SNA gateway) is required on at least one application server. See also R/3 Note 13903.

RFC is the protocol for calling special subroutines (function modules) over the network. Function modules are comparable with C functions or PASCAL procedures. They have a defined interface through which data, tables and return codes can be exchanged. Function modules are managed in the R/3 System in their own function library, called the Function Builder.

The Function Builder (transaction SM37) provides application programmers with a useful environment for programming, documenting and testing function modules that can be called locally as well as remotely. The R/3 System automatically generates the additional code (RFC stub) needed for remote calls.

You maintain the parameters for RFC connections using transaction SM59. The R/3 System is also delivered with an RFC-SDK (Software Development Kit) that uses extensive C libraries to allow external programs to be connected to the R/3 System.


© SAP AG 1999

RFC From SAP System to SAP System

Calling system

...CALL FUNCTION XY DESTINATION DEST EXPORTING... IMPORTING......

Called system

FUNCTION XY....

ENDFUNCTION.

RFC DESTINATION R/2 R/3 DEST ...

RFC interface RFC interface

The only difference between a remote call of a function module to another server and a local call is a special parameter (destination) that specifies the target server on which the program is to be executed.

There are three types of RFC calls:

Synchronous RFC call: The calling program stops until the function module has been processed on the target server and any results have been returned to the caller. Only then does the calling program continue processing.

Asynchronous RFC call: The calling program runs parallel to and independently of function module processing in the target system. Programmers are responsible for the processing of the results. In addition, the target system must also be available at the time of the RFC call.

Transactional RFC call: Several function modules can be grouped into one transaction. They are processed only once in the target system, within an LUW, and in the sequence in which they were called. In the case of an error, a message is sent to the calling system that you can analyze using transaction SM58. For transactional RFC, the target system does not have to be available at the time of the RFC call. In addition, you can configure the frequency and intervals of individual queries.


© SAP AG 1999

Office Integration Using OLE

Frontend SAP System

PC program

PC program

SAP GUIABAP program

Function module OLE

ser

ver

Function module

Function module OLE

clie

nt

RFC interface RFC interface

Object linking and embedding (OLE) is an object-oriented method for program-to-program communication. You can connect office applications that support OLE2 automation (for example, Word and Excel) to the R/3 System. In this way, users can use the R/3 functions within their usual desktop environment.

The office programs’ OLE functions are specified in the R/3 System in the type information. This information contains a description of the methods, attributes and parameters. Type information can be language-independent.

When using OLE, the R/3 System can play two separate roles:

If the R/3 System is acting as an OLE client, then the user calls the desktop program from the ABAP application. OLE commands are transferred from the ABAP code as remote function calls (RFC) through the SAP GUI to the PC. The SAP GUI maps RFC calls to OLE commands for the PC application.

If the R/3 System is acting as an OLE server, R/3 functions can be called from the desktop application. OLE commands are sent to the SAP automation server. The server converts them into RFC calls and passes them on to the R/3 System. In the R/3 System, function calls and BAPIs are triggered by business objects. After the data is processed successfully, the business object sends the data back to the desktop program through the SAP automation server.


© SAP AG 1999

Business Objects and BAPIs

Business Object Repository (BOR)

Business Object (BO)(for example, sales order)

Business ApplicationProgramming Interface (BAPI) (for example, create an order)

cont

ains

cont

ains

met

hod

BORBO

BO

BO

BAPIs are used for:

Distributed scenarios (ALE)

R/3 components

Internet / Intranet

Business workflow

External programs

Customer and partner developments

...

HR FI

CO

Business objects form the basis for communicating on high (user-friendly) network layers. For example, they enable the R/3 System to support the Internet, and desktop programs to be connected. The goal of SAP’s object-oriented strategy is to integrate objects at a business level rather than on a purely technical level.

Business objects:

Form the basis of well-defined communication between client / server systems.

Are business-oriented: there are objects such as “customer", “order” or “employee”.

Provide business functions (methods). For a “customer” object, for example, there are “Create customer” and “View customer” methods. These names support clear and therefore error-free programming.

Are managed centrally in the R/3 System in the Business Object Repository (BOR).

Business Application Programming Interfaces (BAPIs) are functional interfaces. They use the business methods from the business objects. BAPIs may be addresses within or outside the R/3 System.

For specifications and more information about BAPIs, see the alias “bapi” in SAPNet.


© SAP AG 1999

Overview of mySAP.com

Company /organization

boundary

Information and services within the company context

Information and servicesoutside the company context

Hosted Applications

Workplace Marketplace

Community

Business Scenarios

Web Services

mySAP.com combines new and existing SAP products and services in intranet and Internet. The main components are:

The Workplace provides each employee with an easy-to-use, standard user interface. Within a Web browser, users have all the tasks assigned to them by their user role. In addition, each user can customize their individual view (users “personalize” their workplace). E-mail, search engines, and other Web services can also be integrated.

The Marketplace is an electronic marketplace found at www.mysap.com where companies can provide information, content, and products. Offers for specific groups can be found in the corresponding Business Community (for example, for a particular industry). Business partners can connect their business processes, such as buying and selling, in the Marketplace. This is known as One-Step Business.

SAP provides a variety of electronic business solutions (Business Scenarios) for Internet and intranet. A list arranged by business criteria is on the next page.

The fourth component of mySAP.com is Application Hosting: SAP or SAP partners set up / or run the business systems for the customer. The customer decides whether this should only be for the evaluation phase, implementation phase, or also during production.


© SAP AG 1999

Business Scenarios

Consumer to Business

Business to BusinessIntranet Services

The Internet is a global network of computer networks. It is a standardized platform for exchanging data between individuals and organizations.

As part of mySAP.com, we provide a number of Business Scenarios. They are easy to use and do not require any training to use them. Business scenarios can be organized into groups describing which groups are communication:

Intranet Services: Employees within one company context (for example, Employee Self Services)

Consumer to Business: Customer with a company

Business to Business: Business partners

Some of the scenarios are already included in R/3 as Internet Application Components (IAC). R/3 has been Internet-enabled since Release 3.1G. Customers can also create their own IACs. The development tool used is the SAP@Web Studio.

Other scenarios are independent components (for example, Business-to-Business Procurement and Selling), some of which work together with R/3 or other backend systems.

For more information about SAP’s e-commerce products, see the alias “e-commerce” in SAPNet.


© SAP AG 1999

mySAP.com Workplace Architecture

Client Web Server Backend

Web Browser

SAP GUIfor Windows

SAP GUIfor JAVA

TerminalClient

BackendSystems

BW

KW

APO

W Gate

...

A Gate(incl. SAP GUI

for HTML)

HTTPServer

TerminalServer

SAP GUIfor Windows

Internet Transaction Server

Frontend Server

WorkplaceServer

R/3

WorkplaceEngine

The following components are involved when employees access backend systems (such as R/3):

The Web browser on the employee’s PC (client) communicates with the HTTP server, which runs on a different physical server (Web server). The connection is through the Internet or intranet.

The Workplace information (user role and personalization) is stored on the Workplace server. The Workplace Engine in front of the Workplace handles the Workplace display. Employees only need to log on once to the Workplace(Single-Sign On). Additional (optional) components such as Drag & Relate Servlet + SAP DCOM CC provide Drag & Relate functions allowing connections across system boundaries.

The Internet Transaction Server (ITS) creates the connection between the HTTP server and an SAP Backend System. The ITS consists of the W Gate (runs on the Web server) and the A Gate (can run on separate hardware); these are software components. A special service provided by the A Gate is the SAP GUI for HTML, which at runtime converts the screens of an R/3 dialog transaction into HTML pages.

Other methods for accessing an SAP Backend System are through:

SAP GUI for JAVA: Can run in the Web browser; allows direct access

Windows terminal client: Can run in the Web browser; access through Frontend server

SAP GUI for Windows: Direct access from Windows PC


© SAP AG 1999

EDI Architecture

Documents

Ext. application

EDI messages

EDI subsystem

IDoc type

IDoc interface R/3 application

SAP documents

Datarecord

Control record

Control record

Electronic Data Interchange (EDI) describes the electronic exchange of structured business data between applications.

EDI architecture consists of:

EDI-enabled applications:

- They allow business transactions to be processed automatically.

The IDoc interface:

- This was designed as an open interface and consists of the intermediate documents (IDocs) and the corresponding function modules, which create the interface to the application..

The EDI subsystem:

- This converts the intermediate documents into EDI messages and back. SAP does not supply this element of the EDI architecture, but provides a list of certified programs, see alias “csp” in SAPNet.

The main component of the IDoc interface is the IDoc type. An IDoc is an SAP standard that specifies the structure and format of the data to be transferred electronically. It was developed to support the EDIFACT and ANSI X12 standards. IDocs are identified uniquely using a control record. The application data records form the core. The status records log the status of an IDoc as it is passed from the application to the trading partner and back.

XML will most likely be used more and more for transferring business information between enterprises.


© SAP AG 1999

External Data Transfer Using Batch Input

Sequential file SAP interfacesand checks

External system R/3 System

Batch input

When you transfer data from one R/3 System to another, or from an external system to an R/3 System, you must ensure the integrity of the data that is transferred. This means the external data must be subjected to the same checks and controls as data that was entered manually online.

As the online checks in transactions are very comprehensive and are partly used across applications, it is very difficult to program them yourself.

The best and easiest way is to use the online checks in SAP transactions, which also includes using SAP transactions for data transfer.

The methods used to transfer external data are known as "batch input” methods.

For many areas in the R/3 System, SAP provides standardized external data transfer methods. These methods use batch input, call transaction and direct input programming methods. The SAP standard direct input methods are controlled using the Data Transfer Workbench (transaction SXDA). If no SAP standard transfer method is available, you can program transfers using batch input or call transaction.


© SAP AG 1999

Communication: Unit Summary

Name the most important interfaces in the R/3System

Describe the importance of the RFC interface

Describe how the R/3 System can be connected tothe Internet

Name interfaces for data transfer



Exercises

Unit: Communication


• Execute RFC communication using RFC-enabled function modules

• Use the Business Object Browser to look at the BAPIs in the system • Call and use an Internet Application Component (IAC)

The R/3 System needs to communicate with external systems. Use the RFC interface to do this.

The Business Object Repository (BOR) is a central store for all business objects and their methods. Some of these methods are BAPIs.

Internet Application Components, for example, use BAPIs for the business logic.

1-1 Communication using RFC: 1.1.1. Use the Function Builder to display the definition of function module

RFC_READ_TABLE. What does this function module do?

1.1.2. Ensure that the function module is RFC-enabled. (Hint: the solution is not in the name of the function module.)

1.1.3. Execute the function module locally, that is, without entering an RFC destination. Read the table T000 (by entering the name of this table for the parameter query table)

1.1.4. Execute the call on a remote R/3 System, entering the RFC destination provided by the instructor. You could also use the destination NONE. This means the RFC call is started on your system.

1.2. Business Object Repository (BOR):

1.2.1. Search for “sales order” in the BOR

1.2.2. Which methods does this business object include? Which of the methods are BAPIs?


Solutions

Unit: Communication

1-1 Communication using RFC:

1-1-1 Choose SAP standard menu → Tools → ABAP Workbench → Development → Function Builder (transaction SE37). Enter function module RFC_READ_TABLE and choose Display. The function module definition appears. To go to the function module documentation, choose Function module documentation.

1-1-2 The name of the function module indicates it supports RFC. However, there are many function modules that support RFC that are named differently (for example, BAPI_*). The critical point is that the developer selected Remote-enabled module for Processing type under Attributes.

1-1-3 After choosing Test / Execute, you can manually specify parameters and then start the module. Under Query table, only enter T000 and then execute the module (F8).

1-1-4 Same procedure as before. However, this time specify an RFC target system. This uses function module RFC_READ_TABLE to display information about the table SFLIGHT in the target system.

1-2 Business Object Repository (BOR):

1-2-1 Choose SAP standard menu → Tools → ABAP Workbench → Overview → Business Object Browser (transaction SW02). You can perform a manual search of the displayed component hierarchy, or you can use the search function (Choose Binoculars icon or Edit→ Find). For details about the business object SalesOrder, double-click the line.

1-2-2 BAPIs are indicated using green dots in the method list for the business object. Hint: To navigate directly to the ABAP code behind the BAPI, click the green dot.


© SAP AG 1999

Section: Technical Core Competence - UNIX & NT

Introduction Spool and Print(UNIX or NT)

Starting and Stopping(UNIX or NT)

Installation Check(UNIX or NT)

System AdministrationAssistant Installation Guide

CCMS Configuration SAP Data Archiving

Background Processing System Monitoring

Users and Authorizations SAPNet


© SAP AG 1999

Introduction









© SAP AG 1999

Introduction

ContentsReview of essential R/3 terms and conceptsOutline of some basic R/3 System steps(as described in SAP50)

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

Explain certain important R/3 concepts and terminologyDescribe the system steps triggered during an R/3 logonor while a transaction is being executed


© SAP AG 1999

Data Structure of R/3 Systems

Client

User(Authorizations,

User MasterRecord, ...)Client-specific Customizing

(Company Code, Plant, Warehouse,Sales Organization, Personnel Area, ...)

Application Data(Sales Orders, ...)

Cross-client Customizing

Developmentclasses

MMFI CO HR PPBasis SD ...

RepositoryRepository((DictionaryDictionary, Reports, , Reports, TransactionsTransactions,,

Function ModulesFunction Modules, ...), ...)

R/3 System clients are organizationally independent. Each client has its own data environment with its own master data, transaction data, user master data, and customizing parameters.

Users in different clients co-exist in the same R/3 System, but their data is isolated and cannot be accessed from another client. Only users with the necessary authorizations can view or process data in a specific client. This isolation concept is reflected in R/3 table design, both at the application level and in Customizing, which is a customer-specific adaptation of the R/3 System. This adaption is called client-specific customizing. Apart from this, there are also system-wide adjustments (which usually have to be made only once, such as printer settings) that affect all clients of an R/3 System. This adjustment is called cross-client customizing.

Client 000 is defined as the SAP standard and the customer cannot change it. This client serves as a copy template for the creation of further clients.

The repository is also cross-client. It consists of ABAP reports, menus, dynpros, all dictionary objects (tables, data elements, and domains), CUAs, and so on. Like cross-client customizing, repository objects affect all clients of an R/3 System.


© SAP AG 1999

DatabaseDatabase

V E

R/3 System Logon Steps

IP: X.Y.Z.20 IP: X.Y.Z.101

Ex.: IP: X.Y.Z.102

3

4

6

5

10

9

8

7

D B S ... D V B D ...

Database processesDatabase processes

DispatcherMM

Dispatcher

SAP GUIEx.: IP: a.b.c.73

When a SAP GUI process is started on the front end, a command line parameter is sent, indicating one of the following:

A specific dispatcher can be accessed directly (go directly to 3)

The logon must first be sent to the message server (1) for logon load balancing

When logon load balancing is used, the message server returns the IP address and instance number (2) of a specific dispatcher. The number of dispatchers available for a particular logon is configured in the system. Logon load balancing is useful if certain user groups are assigned to work on specific servers.

The message server returns the IP address of one of the assigned dispatchers, for example the dispatcher that has shown the best response time during the last five minutes. Response times are stored in the collected workload data.

The frontend process then connects to the assigned dispatcher (3), which selects a free dialog work process (4) to compare the logon user data with the user data stored in the database (5, 6).

If the logon user data does not agree with the stored user data, no logon is allowed. If the logon is successful, the SAP GUI is established with the user (7-10). This dispatcher and its work processes are used for the duration of the session.

If a user logs off and then logs on again to the system, logon load balancing may cause the message server to select another dispatcher for the user to work with.


© SAP AG 1999

Instance A Instance B

Central Instance C

MessageMessageserverserver

B

Defining Instance and Application Server

S S ...

Dispatcher

...

Dispatcher

D V E B S ...

Dispatcher

An instance is a group of R/3 services that are started and stopped together. Usually, an instance is one dispatcher with its work processes, although other standalone services such as a gateway can be called an instance.

A central instance is a dispatcher offering all the R/3 System processes: DVEBMGS. In the graphic, Instance C shows all the processes except the gateway (G).

An R/3 application server is a computer where one or more R/3 instances are running.

An R/3 System consists of one or more R/3 instances. The instances can run on one or more computers. Each instance belongs to exactly one R/3 System.

From the hardware point of view, however, an application server can be defined as a computer on which at least one dispatcher, also called a dialog instance, is running.

The following restrictions apply to the number of each type of work process:

Dialog (D): each dispatcher needs at least 2 dialog work processes (not shown above)

Spool (S): at least 1 per R/3 System (more than 1 per dispatcher allowed)

Update (V): at least 1 per R/3 System (more than 1 per dispatcher allowed)

Background (B): at least 2 per R/3 System (more than 1 per dispatcher allowed)

Enqueue (E): exactly 1 per R/3 System (only 1 E work process is required and allowed)


© SAP AG 1999

Database

System Dialog Step

SAP

GU

ISA

P G

UI

Dialog work processDialog request queue

Taskhandler

Dynpro processor

ABAP processor

Database interface

User context in main memory

1

Roll in4

6

5

9

8

7

12

Roll out11

Dis

patc

her

Dis

patc

her

2

3

10

Once you have established a connection with a dispatcher through the SAP GUI, and a session is started for you in the system, the following steps are executed for each request:

Data is passed from the SAP GUI to the dispatcher using the SAP GUI protocol (based on TCP/IP).

The dispatcher classifies the request and places it in the appropriate request queue.

The request is passed in order of receipt to a free dialog work process.

The subprocess taskhandler restores the user context in a step known as roll-in. The user context contains mainly data from currently running transactions called by this user and its authorizations (that is, you and your authorizations).

The taskhandler calls the dynpro processor to convert the screen data to ABAP variables.

The ABAP processor executes the coding of the process-after-input (PAI) module from the preceding screen, along with the process-before-output (PBO) module of the following screen. If necessary, it also communicates with the database.

The dynpro processor then converts the ABAP variables again to screen fields. When the dynpro processor has finished its task, the taskhandler becomes active again.

The current user context is stored by the taskhandler in shared memory (roll-out).

The resulting data is returned through the dispatcher to the frontend.


© SAP AG 1999

Work Process Multiplexing

Request queues

... ...Request queues

DatabaseDatabase

V E

1

5

4

9

8

7

6

D B S ... D V B D ...

Database processesDatabase processes

DispatcherMM

Dispatcher

Dynpro200Dynpro200

Dynpro100Dynpro100

SAP GUI

2 1110

12

13

14

15

16

17

18

3

If a transaction involves the use of more than one screen, the system dialog steps shown on the preceding page are normally performed by several different dialog work processes in a dispatcher. This is known as work process multiplexing.

Each dialog request is:

First, placed by the dispatcher in the dialog request queue

As soon as possible, assigned to a free dialog work process

The work processes do not perform database operations. They pass data and commands to the assigned database processes using their own database interface.


© SAP AG 1999

In this unit, you have reviewed the following:

The steps executed in R/3 during logon

The terms 搃nstance? and 揳pplication server�as used in the R/3 environment

Processing of a system dialog step

Work process multiplexing as performed bydialog work processes

Summary of this Unit


© SAP AG 1999

SAP50 - Basis Technology

SAP Technology InfrastructureBrochure available in SAPNet under:Information → R/3 System → Basis Technology

SAP Online Documentation

SAP Notes:39412 Number of workprocesses

21960 Two instances on one computer

5424 FAQ: enqueue/locking

and others in BC-KRN-CST

Further Documentation


© SAP AG 1999








Starting and Stopping - UNIX


© SAP AG 1999

Starting and Stopping

ContentsProcesses and services in an R/3-UNIX-OracleenvironmentStart and stop processes and procedures


Describe R/3 start and stop processesExplain the relationship between database processes,R/3 processes, and operating system processesStart and stop an R/3 SystemAnalyze error situations during system startup or shutdown


© SAP AG 1999

Starting the R/3 System

Logon

<sid>adm

1. Start the Central Instance

saposcol CentralInstance

11

2233 44 55

Operating system UNIX

Database

<host>> startsap( startsap_<host>_<instance no>)

UNIX shell .

2. Start additional R/3 instances

startdb script

If not started If not started

The operating system user logs on to the UNIX operating system as user <sid>adm.

To start R/3, run the shell script startsap_<host>_<instance_no> from the home directory of user <sid>adm. The script startsap_<host>_<instance no> has the alias startsap.

startsap starts the saposcol process, which is the statistics collector for operating system resource data, if it is not yet running.

startsap calls the script startdb, which starts the database if it is not already started.

startsap then starts the central instance.

The R/3 System administrator can start additional instances and application servers. To start the instances independently of the database, use the script startsap.

startsap has the following options:

startsap r3: Checks if the database is running; if it is, only the instance is started

startsap db: Starts only the database

startsap all: Default entry; starts both the database and the R/3 instance


© SAP AG 1999

Starting an R/3 Instance

Instance startupsequence

Services

sapstart

Default and instance profile

Start profile

Disp+workProcesses

Database

> startsap_<host>_<nr>UNIX shell .

Connection

WP WP gwrd

MSCOSE

…

This graphic displays the R/3 start procedure in more detail.

Script startsap calls program SAPSTART.

Program SAPSTART reads the START PROFILE and starts the R/3 components and/or services listed in /usr/sap/<SID>/SYS/profile/START_<instance>_<hostname>.

On a central instance, SAPSTART starts the message server, dispatcher, collector, and the sender.

On a dialog instance, only the sender and the dispatcher are started. The collector and sender are used to implement the central R/3 System log.

The dispatcher forks and creates child processes:

The work processes (dialog, background, spool, update, . . .) are created according to the information in the profiles /usr/sap/<SID>/SYS/profile/<SID>_<instance>_<hostname> and /usr/sap/<SID>/SYS/profile/DEFAULT.PFL.

The gateway reader. This does not depend on the profiles, and it is always started.

All the work processes except the gateway reader connect to the database.


© SAP AG 1999

Process Overview at the Operating System Level

UNIX shell X

host> ps -ef | grep oraoratc1 26348 1 0 14:32:23 ? 0:00 oracleTC1 (DESCRIPTION=(LOCAL=NO�…host>ps -ef | grep sap.TC1tc1adm 12812 12804 0 Apr 29 ? 0:07 dw.sapTC1_DVEBMGS00 pf=/usr/sap/tc1adm 12806 12787 0 Apr 29 ? 0:00 se.sapTC1_DVEBMGS00 -F pf=/usr/sap/tc1adm 12805 12787 0 Apr 29 ? 0:00 co.sapTC1_DVEBMGS00 -F pf=/usr/stc1adm 1691 1 0 Apr 22 ? 221:17 /usr/sap/TC1/SYS/exe/run/saposcoltc1adm 12787 1 0 Apr 29 ? 0:00 /usr/sap/TC1/SYS/exe/run/sapstart pf=/ustc1adm 12809 12804 0 Apr 29 ? 58:09 dw.sapTC1_DVEBMGS00 pf=/usr/sap/tc1adm 12811 12804 0 Apr 29 ? 2:27 dw.sapTC1_DVEBMGS00 pf=/usr/sap/tc1adm 12804 12787 0 Apr 29 ? 3:32 dw.sapTC1_DVEBMGS00 pf=/usr/sap

Dispatcher; parent process is sapstart

Sender and collector started by sapstart

R/3 work processforked by the dispatcher

The process IDs of the various R/3 processes clearly show the R/3 startup procedure.

sapstart creates the dispatcher, collector, and sender.

saposcol is started directly from the script startsap.

The UNIX init process has the process ID 1.


© SAP AG 1999

Assigning Parameter Values

Instance profile

Default profile

C source (Kernel)

Parameterread sequence

R/3 work processes

11

22

33<SID>_<INSTANCE>_<hostname>

DEFAULT.PFL

To provide a stable startup procedure, the parameter read sequence (also known as the parameter replace sequence) is defined during startup as follows:

R/3 processes read the appropriate parameters from a C source in the R/3 kernel

The default profile /usr/sap/<SID>/SYS/profile/DEFAULT.PFL is read; profile values already defined in the C source are replaced with the values in the default profile

The instance profile /usr/sap/<SID>/SYS/profile/<SID>_<instance>_<hostname> is read; profile values already defined in the default profile or in the C source are replaced with the values defined in the instance profile

This procedure ensures that system parameter values reflect the instance profile and the values in the default profile and the C source.

To display the replace sequence for a particular parameter, execute report RSPFPAR in transaction SE38 or SA38.

The R/3 kernel (disp+work) reads the default and instance profile. If you change one of these profiles, you must restart the corresponding R/3 instance.


© SAP AG 1999

R/3 Startup Logs and Traces

/sapmnt/<SID>/<Instance><No>/work/ ...

Standard error files of program SAPSTART

Startup log of program SAPSTART

Trace file of the dispatcher

Time

Trace file of the message server

stderr1 ? m

sapstart.log

dev_disp

dev_w0 ? n

dev_ms

sapstart<m>.trc Trace files of program SAPSTART

$HOME/<sid>adm/startsap_<host>_<instance no.>.log

Trace files of the work processes

$HOME/<sid>adm/startsap_<host>_<instance no.>

The R/3 startup scripts log their actions to log files in the home directory of the user <sid>adm.

R/3 work directories contains trace files and error files for messages relating to the startup of work processes. There is a work directory for each R/3 instance. The work directory contains information that may not be found in the R/3 System log.

The work directory files are initialized in chronological order.

To define the level of information written to the trace files, set the profile parameter rdisp/TRACE in the instance profile. The values for this parameter are:

0: Write only errors (no traces)

1: Write error messages and warnings (default)

2: Write error messages and a short trace

3: Write error messages and the complete trace

These files can be viewed at OS level or in R/3:

- At OS level, you can use UNIX command ‘page’, ‘more’, or ‘cat’.

- In R/3, you can use transaction AL11.

- In R/3, you can use transaction SM50 to see the developer trace for a particular work process: choose Process → Trace → Display file (or click on Display file).


© SAP AG 1999

Startup Diagnostics

Program sapstart

Oracle instance <SID> R/3

instance

alert_<SID>.logora_<nr>.trc R/3 tracefiles dev*

c:> sapdba -startup

UNIX shell

Sapdbalogfiles

c:> startsap

UNIX shell

Script startdb

startsap.log

sapstart.*

startdb.log

R/3 System log

This graphic shows the possible points of failure during R/3 System startup. If an error occurs, you must locate the error information and determine the cause of the problem.

If access is denied to resources such as script startdb or sapstart, this could be because:

The file system permissions are not correct

User <sid>adm is not installed correctly

Umask problems exist

If the database has not been started, the work processes cannot connect to the database, and the R/3 System cannot be started. The database could fail to start because:

The environment variables are not correct

The database is running in DBA mode

Database files are lost or corrupt

Data files have been renamed in the database but not at operating system level

If the R/3 System does not start, it may be because:

The UNIX kernel is not configured correctly

There are errors in the memory management configuration

The R/3 profiles are not accessible (file permissions)

If you can log on to the R/3 System, use the R/3 System log to analyze startup problems.


© SAP AG 1999

Database Startup Logs and Traces

Oracle instance <SID>

$ORACLE_HOME (/oracle/<SID>/)

saptrace/background/alert_<SID>.log

saptrace/usertrace/ora_<pid>.trc

sapcheck\�sapreorg\...sapbackup\back<SID> \ ...

Oracle alert file

Oracle trace information

sapdbalog files

$HOME/<sid>adm/startdb.log

UNIX shell

<host> > sapdba

Log filescript startdb

Script startdb

During database startup, startsap calls the script startdb, which writes the appropriate log file startdb.log.

All significant events, such as starting and stopping the database and any database errors, are logged in Oracle alert file /oracle/<SID>/saptrace/background/alert_<SID>.log. Detailed error information is logged in Oracle trace file /oracle/<SID>/usertrace/ora_<pid>.trc.

If the administrator <sid>adm uses sapdba to start the database, sapdba writes additional log files to following directory depending on the actions executed.

/oracle/<SID>/sapreorg

/oracle/<SID>/ sapcheck

/oracle/<SID>/ sapbackup


© SAP AG 1999

Before Stopping the R/3 System

R/3 SystemExternal

application

Check background and batch input jobs with SM37 and SM35

Are any jobs active or planned?

Will R/3 jobs be triggered from external systems?

Check update status with SM13

Send system message with SM02

Check logged-on users with SM04

Check external interfaces

Before the R/3 System is stopped, the R/3 System administrator should check the:

Job overview

Check if any background jobs from any application server are active or have been triggered externally. Use transaction SM37, or choose System → Services → Jobs → Job overview.

Process overview

Check if the background work process BTC is running in any application server. Choose Tools → Administration → Computing Center Management System → Control → All work processes.

Batch input overview

Check if any batch input jobs are running. Choose System → Services → Batch input → Edit → Overview.

Update records

Check if any update records are open when the system is stopped, the records are rolled back and set to status init. At startup, the records are processed again.

The administrator must decide whether to interrupt the jobs or wait until they are finished.

Give system users advance warning of the system shutdown. To create a system message, you can use transaction SM02.

Before shutting down the system, use transaction SM04 to check whether users are still logged on, and ask them to log off.

The R/3 System administrator and administrators of external systems should also inform one another about data transfers between their respective systems.


© SAP AG 1999

Stopping the R/3 System

<sid>adm

R/3 additional instances

R/3 administrator

R/3 central

instance

Choose??

RefreshDetails Choose

Edit Select Monitoring Control Utilities System Help

R/3 CCMSOracle

Server Manager

Oracle instance <SID>

> sapdba -shutdown

UNIX

> stopsap [r3|all]

UNIX

Script stopdb1a1a 1b1b2a2a

2b2b33

To stop the whole R/3 System, the R/3 System administrator should first stop the additional instances and then stop the central instance.

To stop the additional instances, there are two alternatives:

In R/3 - use Control Panel and System Monitor in CCMS (1a in the graphic)

At OS level - use alias stopsap r3 (1b in the graphic)

To stop the central instance, there are two alternatives:

To stop the R/3 instance but not the database, use alias stopsap r3.

To stop both the R/3 instance and the database, there are two alternatives:

- Use alias stopsap all. This shuts down the R/3 instance and the database. (2a)

- Shut down the R/3 instance at the OS level, then use either sapdba (2b) or Oracle Server Manager to shut down the database. (3)


© SAP AG 1999

Stopping R/3: Error Diagnostics

Database

Database cannot stop

> sapdba -shutdown

UNIX shell

Cannot stop

> stopsap all

UNIX shell

If the database cannot be stopped when the R/3 System is stopped, this may be because:

The database is performing a rollback of aborted transactions caused by the shutdown of the R/3 System. Depending on the last commit and the application, this can take a long time.

An online backup is running. You should wait until the online backup is finished.

The archiver becomes stuck at exactly the time you are stopping the R/3 System. To free the file system, you should save the archives in the correct order to tape.

If there is no obvious reason why the database cannot be stopped, the database administrator should use transaction SM21 to check the R/3 System log and the database alert file.

Before you try again to stop the database, ensure that the problem is solved.

For further information, see the R/3 Online Documentation on database backup, reorganization, and recovery.


© SAP AG 1999


Now you are able to:

Describe R/3 start and stop processes

Explain the relationship between database processes,R/3 processes, and operating system processes

Start and stop an R/3 System

Analyze error situations during system startup orshutdown


© SAP AG 1999

Unit Actions

Exercises?

Solutions



Starting and Stopping: Exercises

No. Exercise 1 Starting 1.1 Log on to the UNIX operating system as user <sid>adm.

1.2 Check if your R/3 System is up and running.

1.3 If your R/3 System is running, stop it. First stop all additional instances, then stop the central instance.

1.4 Restart your system. Did your instance start properly?

1.5 What areas should you check to make sure the system came up properly? 1.6 From saplogon, log on to your system.

1.7 Log on to the R/3 System.

2 Displays 2.1 Display the name of your server and find out which R/3 process types the

server has been configured for.

2.2 How many instances are configured in your system? 2.3 Display the job overview.

2.4 Display the batch input overview.

2.5 Display the overview of active users.

3 Stopping 3.1 Send the following message to the active users:

"System Stop at 14:00. Please save your work and log off."

3.2 Stop your R/3 instances (not the database). What command did you issue?

3.3 How would you check if your database is still running?

3.4 Now stop the database. What two methods can you use to shut down the database?

3.5 Restart the R/3 instance.


Starting and Stopping: Solutions

No. Solution 1 Starting 1.1 Log on to the UNIX operating system as user <sid>adm. Make sure you use

the SID assigned to you by the instructor.

1.2 Use the following commands. To check all the work processes: ps -ef | grep <SID> | grep dw

To check the message server: ps -ef | grep <SID> | grep ms

To check the SAP OS collector: ps -ef | grep sapos

1.3 As user <sid>adm, issue one of the following commands. To stop the R/3 instance only: stopsap r3

To stop the R/3 instance and the database: stopsap all or stopsap

1.4 As user <sid>adm, issue the startsap command. You may see messages about saposcol already running (command stopsap does not stop the saposcol process). If your instance started properly, you will see the message: "Instance on host <hostname> started"

1.5 You should look at the startsap log in /home/<sid>adm. You can check the developer traces for all the work processes in directory /usr/sap/<SID>/DVEBMGSxx/work, where xx is your instance number. The files are dev_disp, dev_ms, dev_w*., sapstart.log, ... From the R/3 System, you can view these files using transaction AL11. In the system log (transaction SM21), you can also read about the shutdown and startup of R/3 processes.

1.6 You can access your system from saplogon. To execute saplogon, choose Start → Programs → SAP Frontend.

1.7 Your instructor will tell you your system ID.

2 Displays 2.1 To display the server name, use transaction SM51. Information about the

process types is also displayed. For further information, select one of the instances and choose Processes. Alternatively, to display the system processes, use transaction SM66.

2.2 To check how many instances are configured in the system, use transaction SM51.

2.3 To display the job overview, use transaction SM37, or choose System → Services → Jobs → Job overview. Select all jobs with status Released, Ready, and Active.


2.4 To display the batch input overview, use transaction SM35, or choose System → Services → Batch input → Edit → Overview

2.5 To display the overview of all active users on the instance where you are logged on, use transaction SM04. For a user overview of the whole system, call transaction AL08.

3 Stopping 3.1 To send a message to all active users, use transaction SM02, or choose

Tools → Administration → Administration → System messages.

3.2 As user <sid>adm, from the UNIX prompt, run the script stopsap r3.

3.3 To check Oracle processes, use command: ps -ef | grep <SID> | grep ora

Start SAPDBA by issuing command sapdba. You will see that the database has status open.

3.4 Shutdown using stopsap. As user <sid>adm, run the script stopsap all. Shutdown using sapdba. As user ora<sid>, to shut down Oracle, do one of the following:

Call sapdba and choose Startup/Shutdown Instance → b - Shutdown → a - Shutdown normal Issue command sapdba –shutdown.

3.5 As user <sid>adm, issue one of the following commands: To start the R/3 instance with the database, startsap all or startsap

To start the database only, startsap db, then to start the R/3 instances, startsap r3

© SAP AG 1999








Starting and Stopping - NT


© SAP AG 1999

Starting and Stopping

ContentsProcesses and services in an R/3-NT-OracleenvironmentStart and stop processes and procedures


Explain the concept of servicesDescribe R/3 start and stop processesExplain the relationship between database processes,R/3 processes, and operating system processesStart and stop an R/3 SystemAnalyze error situations during startup or shutdown


© SAP AG 1999

Overview of Processes and Services

Operating system: Windows NT

Oracle database processes R/3 processes

Database services...

R/3 services...

Operating system services

...

The graphic shows the structure of processes and services when R/3 is used with an Oracle database on a Windows NT operating system.

The operating system services are implemented with the NT services concept. Oracle and R/3 also require their own services, which are installed during installation of the R/3 System package.


© SAP AG 1999

NT Service Control Manager NTRegistry

SAPOsCOL ..... ServicesOracleService<SID>SAP<SID>_<Instance no.>


Starting R/3: Operating System Tasks

During startup of the operating system Windows NT, the NT Service Control Manager starts all the services in the service list that are configured for automatic startup. The information relevant to these services is stored in the registry and is read by the Service Control Manager during startup.

Several services of type “SAP<SID>_<Instance no.>” (the SAP service) and “Oracle Service<SID>”, but only one SAPOsCOL service, can be run on one computer.

The SAP service, SAPOsCOL, and OracleService<SID> should be configured for automatic startup.


© SAP AG 1999

Logon

<SID>adm

Start

Microsoft Management Consolevia SAP R/3 Systems Snap-in

1122

33 44 55


DatabaseStart

CentralInstance

AdditionalInstance

Starting R/3: R/3 Administrator Tasks

To start the Oracle database and the R/3 System, the administrator performs the following steps:

Log on to the operating system Windows NT as user <sid>adm.

To start the R/3 System, open the Microsoft Management Console (MMC) using the SAP R/3 Systems Snap-in. Right-click on the system icon and select Start. The sapstartsrv.exe executable sends a message using a named pipe to the SAP Service, SAP<SID>_<instance no.>.

The SAP service starts the database by executing an NT script that calls the Oracle Server Manager. The Oracle Server Manager executes an SQL script that starts the database if it is currently not running. Once the database is up and running, the SAP service starts the Message Server (msg_server.exe) and the Central Instance dispatcher (disp+work.exe).

The R/3 System has been started successfully when the icon for the central instance changes color to green. The colors displayed in the MMC have the following meanings: red - the process terminated abnormally; yellow - the process is being started; green - the R/3 System has been successfully started; gray - the process is not running, status unknown.

You can also start the R/3 System with the NT scheduler called “at”. For this kind of start, SAP provides the executables startsap and stopsap which are executed locally. Use

- startsap name=<SID> nr=<nr> SAPDIAHOST=<hostname> to start an R/3 instance and

- stopsap name=<SID> nr=<nr> SAPDIAHOST=<hostname> to stop an R/3 instance (the executables sapstart.exe, sapsrvkill.exe and sapntwaitforhalt.exe must be in the same directory)

See SAP Online Documentation: choose BC Basis Components → Computing Center Management System → BC Computing Center Management System → Starting and Stopping the R/3 System.


© SAP AG 1999

R/3 Processes

SAP<SID>_<instance no.>

Message via named pipe

Default and instance profile

Start profile

Microsoft Management Console

NT Services

MS Disp+work.exe

Starting R/3: Process Startup Sequence

Database Processes

D ...SBV E

3

4

2

56

1

When the start command is issued from the MMC, a message is sent using a named pipe to the SAP Service via the executable sapstartsrv.exe.

To find out which components have to be started, the SAP service reads the Start Profile from directory \\<SAPGLOBALHOST>\sapmnt\<SID>\SYS\profile. To view this profile for an instance from the MMC, right-click on the instance icon and choose All tasks → View Start Profile.

If necessary, the SAP service starts the database; then it starts the message server and the dispatcher.

To determine the runtime configuration for the instance, the dispatcher reads the default profile and the instance profile. The shared memory areas, work processes, and gateway reader are generated accordingly.

Once the necessary resources are configured, the work processes connect to the ORACLE threads of the database as user sapr3.

To view the startup trace file sapstart.trc and the developer traces, right-click on an instance and choose an option under All tasks.

The database may be started using the MMC, the SAPDBA, the Oracle Instance Manager, or the Oracle Server Manager.


© SAP AG 1999

R/3 workprocesses

Instance profile<SID>_<INSTANCE>_<hostname>

Default profileDEFAULT.PFL

• R/3 kernel

• NT system environment variables

• NT Registry environment variables

Parameterread / replace

sequence11

22

33

Parameter Read Sequence

To provide a stable startup procedure, a parameter read sequence (also known as the parameter replace sequence) is defined during startup as follows:

R/3 processes read the appropriate parameters from the R/3 kernel, from the NT system environment variables, and from the NT Registry environment variables.

The default profile “\\<SAPGLOBALHOST>\sapmnt\<SID>\SYS\profile\default.pfl” is read. Profile values already defined in the R/3 kernel are replaced with the values in the default profile.

The instance profile “\\<SAPGLOBALHOST>\sapmnt\<SID>\SYS\profile\<SID>_<Instance>_<hostname>” is read. Profile values already defined in the default profile or in the R/3 kernel are replaced with the values defined in the instance profile.

This procedure ensures that system parameter values reflect not only the instance profile but also the values in the default profile and the R/3 kernel.

To display the replace sequence for a particular parameter, execute the report RSPFPAR in Transaction SE38 or SA38.

The SAP service reads only the start profile and the default profile. The R/3 kernel (disp+work.exe) reads only the default profile and the instance profile. If you change the default profile, you must restart the SAP service (including the R/3 instance). If you only change the instance profile, you only need to restart R/3 using the MMC.


© SAP AG 1999

Startup Logs and Traces in Windows NT

Event Viewer - ? Log on \\Host1

Date Time Source Category Event

25.06. 14:22 SAP None 2405

Windows NT

SAP<SID>_<no>

Services

SAPOsCOL

Oracle Service<SID>

MMC SAP R/3System Snap-in

System log

Securitylog

Application log

EVENTLOG log files

All Windows NT messages generated by any services, by the SAP Service Manager, or by the operating system, are recorded by the NT Event Viewer. The Event Viewer writes the event log, which consists of three log files:

System Log This contains operating system messages and messages produced by R/3 or Oracle applications and returned by the operating system.

Application Log This contains events that occurred in, for example, the R/3 or Oracle applications and returned by these applications.

Security Log This contains such events as logon, logoff, and user file access, depending on the security auditing properties of the file system.

The Event Viewer is located in the group Administrative Tools (Common) or can be called at a command prompt using the command eventvwr.


© SAP AG 1999

MMC SAP R/3 Systems Snap-In

General overview of key SAP processes

Current statistics onmajor system and SAP components

Alert statistics fromCCMS monitoring

sets in RZ20

Information and errors in the

R/3 System log

Process queue statistics

Process overviewinformation

SM50

Using the MMC, an R/3 System administrator can monitor multiple R/3 Systems and application servers remotely from a Windows NT System using the SAP R/3 Systems Snap-in.

The SAP R/3 Systems Snap-in enables you to:

Start and stop all R/3 instances with a mouse click

Display the R/3 Process List (status of message server and all instances)

View all R/3 startup and trace files

Display the R/3 System environment

Display alert status tree (transaction RZ20) and acknowledge current alerts

Start analysis tools in R/3 for nodes in the alert tree

View the R/3 syslog (transaction SM21), for both an online and offline R/3 System

Remote logon to an application server

Displaying the queue statistics (dpmon) and process overview (transaction SM50)

The MMC is shipped as follows:

Windows NT: the MMC is installed with the R/3 Systems Snap-in during R/3 installation.

Windows 2000: the MMC is preinstalled in the operating system. Only the R/3 Systems Snap-in is installed during R/3 installation.


© SAP AG 1999

\\<SAPLOCALHOST>\saploc\<SID>\<Instance><No>\work\ ...

stderr1 ? 3

sapstart.log

dev_disp

dev_w0 ? n

Standard error files of R/3 startup procedureexecuted by SAP service SAP<SID>_<instance-no.>

Startup log and trace files of the database, message server, and dispatcher

Trace file of the dispatcher

Trace files of the work processesTime

dev_ms Trace file of the message server

sapstart.trc Trace files of program SAPSTARTSRV

Startup Logs and Traces in R/3

R/3 work directories contain trace files and error files for messages relating to the startup of work processes. Each R/3 instance has a separate work directory containing information that may not be found in the R/3 System log.

The work directory files are initialized in chronological order. During startup, the SAP service executable SAPSTARTSRV.EXE writes:

Database logs to the file STDERR1

Message server logs to the file STDERR2

Dispatcher logs to the file STDERR3

To define the level of information written to the developer trace files, set the profile parameter “rdisp/TRACE” in the instance profile. The possible values for this parameter are:

0: Write only errors (no traces)

1: Write error messages and warnings (default)

2: Write error messages and a short trace

3: Write error messages and the complete trace

You can also change the trace level for single work processes in the process overview (using transaction SM50).

To view all startup logs and developer traces for an instance using the MMC, right-click on the instance in the console tree and choose All Tasks → View Developer Traces. To see the startup trace files, select the appropriate file type.


© SAP AG 1999

Startup Diagnostics

MMC SAP R/3 System Snap-in

..... ServicesOracle Service<SID>

SAP<SID>_<instance no.>

Oracle instance <SID> R/3

centralinstance

Event Viewer

Date Time Source

25.08.14:22 SAP

<SID>ALRTora<No.>.trc R/3 trace files

c:> sapdba -startup

CMD

Sapdbalog files

R/3 System log

If the R/3 System fails to start correctly, the R/3 System administrator should try to find out why.

The graphic shows the possible points of startup failure, and the locations of the corresponding error messages. If the database has not been started, the work processes cannot connect to the database and the R/3 System cannot be started.

Further reasons for startup failure include:

The MMC SAP R/3 System Snap-ins cannot connect to the SAP service because the SAP service is not running or not properly configured.

Services do not start, as the service executable is not accessible, Registry entries are lost or damaged, or the service is not correctly configured (for example, the user password is wrong).

Database startup fails, for example, if environment variables are not correct, if the database is running in DBA mode, if database files are lost or corrupt, or if data files have been renamed in the database but not at operating system level.

R/3 Startup fails, for example, if NT shares are not accessible, if a service is not correctly configured (wrong user), if there are permission problems on the file system or errors in TCP/IP configuration (hosts, services, DNS, hostname), or if no connections to the database are possible.

R/3 can be configured to write messages both to the R/3 System log and to the NT EVENTLOG using transaction RZ20.

If you can log on to the R/3 System, you can also use the CCMS Monitoring sets to analyze the problems (transaction RZ20).


© SAP AG 1999

Logs and Traces for Database Startup

Oracle instance <SID><drive>:\oracle\<SID>\...

saptrace\background\<SID>ALRT.LOG

saptrace\usertrace\Ora<no>.trc

sapcheck\�sapreorg\...sapbackup\back<SID> \ ...

Command Prompt

Database alert file

Oracle trace information

sapdba log files<drive>:\> sapdba

All significant system events, including database start, stop, and errors, are logged in the Oracle alert file “<drive>:\oracle\<SID>\saptrace\background\<SID>ALRT.LOG”.

Detailed error information is logged in the Oracle trace file, “<drive>:\oracle\<SID>\saptrace\usertrace\Ora<no>.trc”.

If the R/3 System administrator uses sapdba to start the database, sapdba writes additional log files to the following directories according to the activity performed:

<drive>:\oracle\<SID>\sapreorg

<drive>:\oracle\<SID>\sapcheck

<drive>:\oracle\<SID>\sapbackup


© SAP AG 1999

R/3 SystemExternal

application

Before Stopping the R/3 System

Check background and batch input jobs with SM37and SM35:

Are any jobs active/planned?

Will R/3 jobs be triggered from external systems?

Check update status with SM13

Send system messages with SM02

Check logged-on users with SM04

Check external interfaces

Before the R/3 System is stopped, the R/3 System administrator should check the:

Job Overview Check if any background jobs from any application server are active or have been triggered externally. Use transaction SM37, or choose Tools → CCMS → Jobs → Job Overview.

Process Overview Check if a background work process (BTC) is active on any application server. Use transaction SM66.

Batch Input Overview Check if any Batch Input jobs are running. Choose System → Services → Batch input → Edit → Overview (or use transaction SM35).

Update Records Check if any update records are open. When the system is stopped, these records are rolled back and set to status init. At startup, the records are processed again. Use transaction SM13 or RZ20.

In each case, the R/3 System administrator should decide whether to interrupt the jobs or wait until they are finished.

Prior to shutdown, inform users by setting a system message through transaction SM02. Before shutting down the system, use transaction SM04 to check whether any users are still logged on, and ask them to log off. The R/3 System administrator and administrators of external systems should keep each other informed about data transfers between their respective systems.


© SAP AG 1999

<SID>adm

R/3 additional instances

R/3 System administrator

MMC SAP R/3 System Snap-in

R/3 central

instanceDatabase

1a1a 1b1b 2a2a

Choose??

RefreshDetails Choose

Edit Select Monitoring Control Utilities System Help

R/3 CCMSNT ServiceControl Manager

SAP<SID>_<Inst. No.>

SAPOsCOLOracleService<SID>

Oracle Tools

2b2b33

Stopping the R/3 System

SAPDBA

To stop the R/3 System, the R/3 System administrator must:

Stop the application servers (dialog and central instances), by using one of the following:

- The CCMS in R/3 (1a in the graphic)

- The MMC SAP R/3 Systems Snap-in, which sends a message through a named pipe to the SAP service and stops the R/3 instances locally (1b in the graphic)

Stop the SAP service

Stop the database, if necessary, by using one of the following:

- SAPDBA (2a, 2b in the graphic)

- Oracle Instance Manager in command line mode

- Oracle Enterprise Manager

Although the database is started automatically when starting R/3, you must stop the database manually, unless you have specially created your own scripts for shutdown.

See also SAP Online Documentation: choose BC Basis Components → Computing Center Management System → BC Computing Center Management System → R/3 System Administration. Here you will also find examples of startup and shutdown scripts for the entire R/3 System, including the database.


© SAP AG 1999

c:> sapdba -shutdown

Command Prompt

No shutdown

c:> oradim80 -shutdown

Command Prompt

Oracle Instance <SID>

Stopping R/3: Error Diagnostics

Reasons why the database may be unable to shut down when the R/3 System is stopped include:

The database is performing a rollback of aborted transactions caused by the shutdown of R/3. Depending on the last commit and the application, this can take a long time.

An online backup is running. You should wait until the online backup is finished.

The archiver is stuck just at the moment when you are stopping the R/3 System. You should save the archives to tape, in order to free the file system.

If there is no obvious reason, the database administrator should check the R/3 System log (with transaction SM21) and the database alert file. The problem should be solved before further attempts are made to stop the database.

See also SAP Online Documentation: choose BC Basis Components → Database Interface, Database Platforms (BC-DB) → Database administration (Oracle) with SAPDBA.


© SAP AG 1999



Explain the NT services concept

Describe R/3 start and stop processes

Explain the relationship between database processes,R/3 processes, and operating system processes

Start and stop an R/3 System

Analyze error situations during startup or shutdown


© SAP AG 1999

Unit Actions

Exercises?

Solutions



Starting and Stopping: Exercises

The start and stop exercises are divided into two parts: Part 1 requires pcANYWHERE access to the remote server and should be performed first by groups working on development systems (DEV). Part 2 requires Telnet access and should be performed first by groups working on quality assurance systems (QAS). All groups should perform the exercises in both parts.

No. Exercise Part 1 (pcANYWHERE) 1 Log on at your workstation at NT level (ask your trainer for a user name).

1.1 Log on to the NT operating system from pcANYWHERE as user <sid>adm. Which services related to the R/3 System are activated by the operating system?

1.2 Using the Microsoft Management Console, check if your R/3 System is running.

1.3 If your R/3 System is active, shut it down using the Microsoft Management Console.

1.4 The Microsoft Management Console only stops the R/3 instance(s); the database is still running. Shut down the database.

2 Starting 2.1 Start your R/3 System using the Microsoft Management Console. Trace the

startup phase by monitoring the processes of your system.

2.2 Make a list of the R/3 and Oracle process types that are running at the end of the startup phase.

2.3 Look at the log files and the trace files for errors and warnings.

2.4 Log on to your R/3 System.

2.5 Take a look at the Process Overview in R/3 at operating system level and from the WP Table in the Microsoft Management Console.

3 Stopping 3.1 Which users are active in your system? Send a system message that you are

stopping the system.

3.2 Stop the R/3 System using the Microsoft Management Console. Shut down the database using sapdba.

Part 2 (Telnet) 4 Log on at your workstation at NT level (ask your trainer for a user name).

4.1 Log on to the NT operating system using Telnet as user <sid>adm. To see if the R/3 System is running, run sapdba.

4.2 If your R/3 System is active, shut it down (all instances) using the operating system command stopsap with appropriate parameters. Check the result on


sapdba.

4.3 Command stopsap only stops the R/3 instances you specify; the database is still running. Shut down the database.

5 Starting 5.1 Start your R/3 System using the command startsap. If it is not already

running, the database starts automatically.

5.2 View R/3 and Oracle processes at the operating system level.

5.3 Log on to your R/3 System.

5.4 Compare the R/3 work process overview with the process list at the operating system level.


Starting and Stopping: Solutions

No. Solution Part1 (pcANYWHERE) 1 Log on at NT level (ask your trainer for a user name). Then choose Start →

Programs → pcANYWHERE or double-click on the desktop icon. 1.1 Log on to the NT operating system from pcANYWHERE as user <sid>adm.

To determine which services are active, use the NT Services Manager (choose Services or Start → Settings → Control Panel → Services). In addition to other services, the R/3-related services SAPOSCOL and SAP<SID>_<instance number> are displayed.

1.2 Using the Microsoft Management Console (from the icon on the desktop), check the icons for the instances in your R/3 System. A green icon indicates that your R/3 System has been started.

1.3 Using the Microsoft Management Console, right-click on the application server and choose Stop. A dialog box appears: choose Confirm. The instance icon fades to gray, although it may take several minutes for dispatcher to stop.

1.4 To shut down the database, use one of the following methods: - From the MSDOS Prompt, enter command sapdba

- Choose Start → Run and enter command sapdba

- From SAPDBA, choose Startup/Shutdown instance → Shutdown → Shutdown normal.

2 Starting 2.1 Using the Microsoft Management Console, right-click the application server

and choose Start. To monitor the processes, use the tool Quick Slice: choose Start → Run and enter qslice.

2.2 Using the tool Quick Slice, you should see the following R/3 work processes: oracle80.exe, tnslsnr80.exe, saposcol.exe, msg_server.exe, gwrd.exe, and multiple disp+work.exe.

2.3 Use Windows NT Explorer to check the log and the trace files in the directory G:\usr\sap\<SID>\<instance name>\work. Pay particular attention to the dispatcher trace file dev_disp and the trace files of work process 0 and 1 (dev_w0 and dev_w1, respectively). To see these logs and trace files using the Microsoft Management Console, right-click your instance and choose All Tasks → View Trace File.

2.4 From SAP Logon, select the icon for your R/3 System. Use your desktop window (do not start a SAP GUI from pcANYWHERE).

2.5 From the R/3 initial screen, choose Tools → Administration → Monitor → System monitoring → Process overview (transaction SM50) and use Quick Slice at the operating system level. Compare the number of work processes. At the operating system level, you can also see the work processes of the second system running on this server. For each instance, the dispatcher is also displayed as a disp+work process.


3 Stopping 3.1 To display the users active in your R/3 System, from the R/3 initial screen,

choose Tools → Administration → Monitor → System monitoring → User overview (transaction SM04). Or choose Tools → Administration → Monitor → Performance → Exceptions/Users → Active users → Users global (transaction AL08).

To send a message to the active users, choose Tools → Administration → Administration → System Messages (transaction SM02).

3.2 Review solutions 1.3 and 1.4.

Part 2 (Telnet) 4 To access Telnet from your workstation, log on at NT level (ask your trainer

for a user name).

4.1 As user <sid>adm in your Telnet terminal, run command sapdba. In the entry screen, you can see from the system information how many times SAPR3 is connected (if SAPR3 is connected, the R/3 System is not stopped).

4.2 Shut down all the instances in your R/3 System as follows: Change to drive G and enter cd \usr\sap\<SID>\sys\exe\run

To stop first the additional instance and then the central instance, enter stopsap name=<SID> nr=<number> SAPDIAHOST=<hostname>

Run sapdba again or, if you are still in, choose Instance Information → Refresh.

4.3 To shut down the database, run sapdba and choose Startup/Shutdown instance → Shutdown → Shutdown normal.

5 Starting 5.1 Start all the instances in your R/3 System as follows:

Change to drive G and enter cd \usr\sap\<SID>\sys\exe\run

To start first the central instance and then the additional instance, enter startsap name=<SID> nr=<number> SAPDIAHOST=<hostname>

5.2 To view the processes, use command tlist/t | more.

5.3 From SAP Logon, select the icon for your R/3 System. Use your desktop (do not start a SAP GUI from pcANYWHERE).

5.4 From the R/3 initial screen, choose Tools → Administration → Monitor → System monitoring → Process overview (transaction SM50) and compare with the output from step 5.2 at the operating system level. The operating system level also shows the work processes of the second system running on this server, but you can identify the processes by their process IDs. For each instance, the dispatcher is also displayed as a disp+work process.

© SAP AG 1999








System Administration Assistant


© SAP AG 1999

System Administration Assistant

ContentsUsing the System Administration AssistantMaintaining the System Administration AssistantConfiguring the System Administration Assistant


Use the System Administration AssistantMaintain the System Administration AssistantConfigure the System Administration Assistant


© SAP AG 1999

System Administration

Watchthe system

Do daily tasks

Do tasks onuser demand

System monitoring

Daily tasks (Periodic tasks)- Checking the System log - Checking the last Backup- Monitoring Database Growth

Monday, October 4, 1999

Occasional tasks(tasks on demand)

System administrator

SSAA

SSAA

The main tasks of a system administrator are to:

Perform all periodic tasks to check system health

Perform tasks as required (such as “Add user”)

Watch the system for error and alert situations

All the periodic and occasional tasks of a system administrator can be performed using the System Administration Assistant (transaction SSAA)

The System Administration Assistant provides a single point of control for the entire system landscape.


© SAP AG 1999

WorklistEntire viewSelective view:

Select the functionSelect a periodDisplay only customer tasks

Alert view

System administrator

Daily work

Training

Tasks on demand

Find errors

Select your view

Starting the System Administration Assistant

The System Administration Assistant features:

Worklist

- Display only tasks that must be done today

- For use during daily operation

Entire view

- Display all tasks

- For training

- To find an occasional task

Selective view

- Display tasks by function or by period

- Reduce the list and display only customer tasks

Alert view

- Display only tasks for which an alert determination is defined

- Display critical tasks after execution of all daily tasks


© SAP AG 1999

Only tasks that should be done today are displayedTasks that are done are not displayed when callingthe System Administration AssistantTasks can be flagged as doneTask status can be reset

Administer Using View Worklist

Assistant Edit Goto Utilities View Help System - xSystem Administration Assistant (SAA)

|- Running your System | |- PRD: Operations Checklist for the Productive System | | |- PRD: Daily tasks | | |- DB: Monitoring Database Growth | |- DEV: Operations Checklist for the Development System | |- DEV: Daily tasks | |- R/3: Checking the System log

System Administration Assistant (SAA)

Worklists only contain the tasks that must be done today.

You can reset the status of a task:

If not all task activities are done

If you want to start the task more than once

You can flag a task as done:

If a periodic task was done earlier than planned

If more than one task leads to the same transaction and all tasks were done when the transaction was called the first time.

View Worklist is available as of Release 4.6B.


© SAP AG 1999

Use the System Administration Assistant(transaction SSAA)

To perform periodic tasks To perform occasional tasks

Using the System Administration Assistant

Assistant Edit Goto Utilities View Help System - xSystem Administration Assistant (SAA) |- Running your System | |- PRD: Operations Checklist for the Productive System | | |- PRD: Daily tasks | | |- R/3: Checking the System log | | |- DB: Monitoring Database Growth | |- DEV: Operations Checklist for the Development System | |- DEV: Daily tasks | |- R/3: Checking the System log |- Additional tasks |- R/3: System Administration |- User: Copy user Local System (DEV)

Administer


Remote System (PRD)

Transaction SSAA is an administration tool for performing the most important administrative tasks.

The System Administration Assistant contains a set of periodic tasks preconfigured

For a development system

For a production system

The tasks are grouped by period. In a development system, there are relatively few periodic tasks to perform. In a production system, there are many periodic tasks that are designed to prevent system errors or downtime. Therefore, the period of a task in a development system can be different from that of the same task in a production system. Also, the tree structure in a production system is more complex than that in a development system, and paths to the same transactions are sometimes different.

The System Administration Assistant also contains:

Tasks requested by users

Tasks that should be done at irregular intervals.

All tasks are presented in one tool. You do not need to navigate to different menus.


© SAP AG 1999


|- Running your System | |- PRD: Operations Checklist for the Productive System | | |- PRD: Daily tasks | | |- R/3: Checking the System log | | |- DB: Monitoring Database Growth | |- DEV: Operations Checklist for the Development System | |- DEV: Daily tasks | |- R/3: Checking the System log |- Additional tasks |- R/3: System Administration |- User: Copy user

The status displays: Tasks that are already done Tasks that must be done today

Occasional tasks have no status information

Task must be done today


Task was done in time

Interpreting the Listing

Status information for periodic tasks is displayed by a light:

Green if the task was done in time.

Red if the task must be done today.

To see date and user of the last execution, select the green or red light.

Occasional tasks do not have any status information.

The status is set after execution of a task.

If remote access is allowed, status information is also available for remote systems.


© SAP AG 1999

Maintain the System Administration Assistant

Assistant Edit Goto Utilities View Help System - x


|- Running your System | |- PRD: Operations Checklist for the Productive System | | |- PRD: Daily tasks | | |- R/3: Checking the System log | | |- DB: Monitoring Database Growth | |- DEV: Operations Checklist for the Development System | |- DEV: Daily tasks | |- R/3: Checking the System log |- Additional tasks | |- R/3: System Administration | |- User: Copy user |- Customer specific tasks |- PRD: Daily tasks |- Run transaction ZABC

Define customer-specific tasksSAP tasks can be used as templateCustomer tasks remain unchanged after upgradeSAP tasks cannot be modified incustomer systems


You can add new customer tasks at the end of the list by defining your own customer subtree below the first node.

If necessary, copy SAP tasks to the customer subtree.

If tasks are added or copied, they inherit some attributes of the father node (such as period, function, operating system dependence, database dependence, and system dependence). These attributes define the structure of subtrees.

You cannot modify SAP tasks in customer systems.

Starting with Release 4.6B:

A customer tree is offered automatically.

You can define your own customer subtrees depending on customer namespaces.

For further information on this topic, see Appendix 2.


© SAP AG 1999

Administer a System Landscape


|- Running your System | |- PR1: Operations Checklist for the Productive System | | |- PR1: Daily tasks | | |- R/3: Checking the System log | | |- DB: Monitoring Database Growth | |- PR2: Operations Checklist for the Productive System | |- PR2: Daily tasks | |- R/3: Checking the System log | |- DB: Monitoring Database Growth

Remote System 1 (PR1)

Remote System 2 (PR2)

Remote access not allowed

Administer


R/3 connection not open

When the System Administration Assistant is used in a system landscape, the status information for the remote systems is displayed with:

A green light if the task was done in time

A red light if the task must be done today

A gray light if no remote access is allowed for the system

A yellow flash if the R/3 connection is down

For further information on this topic, see Appendix 2.

As of Release 4.6B, you can use the SAA to administer your entire system landscape as configured in TMS.


© SAP AG 1999

Troubleshooting Roadmap

Database

Application

Startup/Shutdown Problems

Net-work

Operatingsystem

Operationalproblems

Performanceproblems

Problem occurred:Find the solution or a hint

The troubleshooting guide has been developed to help you administer your R/3 System. It helps you to find the solutions to some common problems as well as to analyze unusual difficulties.

The guide offers a "roadmap" view of problems. You can use this structured roadmap to analyze the problem through a question-and-answer procedure. You can also use the technical views to go directly to the area that you suspect is causing the problem.

To find the Troubleshooting Roadmap, choose Running your system → Troubleshooting, Service and Support → Troubleshooting


© SAP AG 1999

Object Fields Value Meaning

System Admin.Assistant

(S_SAA_ADMI)

Administratorfunctions in System Admin.Assistant

ADM Administrator authorization:display and execute SSAA, define and maintain new entries

PROJ Project manager authorization:display and execute all tasks in thecustomizing / development areas andclient-specific entries

USER Use authorization:display and execute all tasks in the development and Customizing areas that have been assigned to members of the implementation team.

Transaction SSAA allows you to go directly to other transactions, so you also need authorization for any transactions you want to call from the System AdministrationAssistant

Authorizations


© SAP AG 1999


Work with the System Administration AssistantInterpret status informationMaintain the System Administration AssistantConfigure the System Administration Assistant



© SAP AG 1999


SAP Online Documentation:Use the help icon

or

Use the Help Assistantfor detailed informationon the main topics

4.6B


© SAP AG 1999

Unit Actions

Exercises?

Solutions



System Administration Assistant: Exercises

No. Exercise 1 Working with the System Administration Assistant 1.1 Start the System Administration Assistant (SAA). Which views are available?

Select the view that displays the complete administration tree and display this tree.

1.2 Confirm that (because TMS is configured) the SAA offers you a suggested system landscape for administration. System DEV is treated as a test system, QAS as a production system. What consequences does this have for the administration tree? (Compare subtrees DEV and QAS.)

1.3 Expand the tree of your local system. Where do you find the task SAP: Checking the System Log for systems DEV and QAS? Why is there a difference? Choose Execute. What happens?

1.4 Start the Troubleshooting Roadmap.

2 Administer a System Landscape from the SAA In this exercise, you learn how to configure the SAA so that you can administer both systems of your system landscape from the system you are logged into.

2.1 Verify the current settings by choosing Utilities → Check system landscape. If necessary, change Test system name to DEV and Production system name to QAS. (You cannot include a virtual system such as PRD.)

2.2 Enable remote access to the remote system by choosing Utilities → Define remote access. Which changes do you see in the administration tree?

2.3 Choose Utilities → Check R/3 connection. Maintain the fields in the dialog box that appears (an RFC destination for remote access is created from this data).

2.4 Expand the subtree for the remote system and execute task SAP: Checking the System Log. What happens?


System Administration Assistant: Solutions

No. Solution 1 Working with the System Administration Assistant 1.1 Call transaction SSAA. The tabs shows the available views: Worklist, Entire

view, Selective view, and Alert view. Entire view displays the whole tree for system administration. Select tab Entire view and choose Display tasks.

1.2 When you choose Display tasks for the first time, a dialog box presents a suggested configuration for your system landscape. Choose Save. Because system DEV is defined as a test system and system QAS is defined as a production system in the SAA, the tree shows different subtrees for systems DEV and QAS. Subtree DEV has fewer daily tasks than subtree QAS, and the entire subtree for system DEV contains fewer tasks than subtree QAS. The icons beside the remote systems show that no information is currently available from the remote system.

1.3 Subtree DEV:

Choose Running your system → DEV → DEV: Unscheduled/Occasional Tasks → SAP: Checking the System Log In a test system, you do not normally take a daily look at the system log. Subtree QAS:

Choose Running your system → QAS → QAS: Daily Tasks → SAP: Checking the System Log In a production system, you must monitor the system log daily (QAS is defined as a production system in SAA). Choose Execute. This takes you directly to the system log (transaction SM21). To go back to the SAA, choose Back.

1.4 Choose Running your system → Troubleshooting, Service, and Support → Troubleshooting. Choose Execute. Now you see the initial screen of the Troubleshooting Roadmap. From here, you can perform a structured analysis of problems in different areas.

2 Administer a System Landscape from the SAA To configure SAA for your entire system landscape, perform the following steps.

2.1 In the SAA, choose Entire view and Display Tasks. From the next screen, choose Utilities → Check system landscape to verify that DEV is configured as test system and QAS as production system. If necessary, use the pencil icon and Save to adapt the current settings. If the settings are already correct, choose Continue.

2.2 Choose Utilities → Define remote access and flag Remote for the remote target system. Save these settings. In the next dialog box, choose Continue. Expand the tree Running your system → <SID of the remote system> and notice that the color of the icons has changed from gray to red (this indicates that the status has changed from No information (no remote access) to Function must be executed).


2.3 To define the necessary data for remote access to the remote system, choose Utilities → Check R/3 connection. In the next dialog box, fill in the following data: System number: If remote system is DEV, 00 If remote system is QAS, 10 Server: <hostname of your local system> (because DEV and QAS are on the same hardware installed in the training environment) Client: 200 Save these settings. A dialog box appears: enter a valid user and password for the remote system (client 200). In the next dialog box, choose Continue. Restart transaction SSAA.

2.4 Expand the subtree of the remote system and execute SAP: Checking the System Log. This takes you directly to transaction System log on the remote system.

© SAP AG 1999








CCMS Configuration


© SAP AG 1999

CCMS Configuration

ContentsSetting up the CCMSStarting and stopping instances with the CCMS


Set up the CCMS:Import and maintain profilesDefine operation modesMaintain instance definitionsSchedule operation modes

Start and stop instances with the CCMS


© SAP AG 1999

CCMS: Overview

The Computing Center Management System (CCMS)allows you to monitor, control, and configure R/3

It provides functions for:Profile maintenance

Unattended 24-hour system management using operationmodes, instance definitions, and scheduling

Starting and stopping instances

Processing and controlling background jobs, schedulingdatabase backups

Automatic reporting of system alerts

Dynamic logon load balancing

System and network monitoring and analysis

The Computing Center Management System (CCMS) is an integral part of the R/3 Basis. CCMS provides tools for managing:

R/3 System and performance

Database and archiving

Workload

Output

Security

You can use the CCMS to analyze and distribute client workloads and report on resource consumption for system components. The CCMS also provides graphical monitors and management utilities.

CCMS provides 24-hour unattended system management functions from within R/3 through operation modes and instances.


© SAP AG 1999

Create operation modes

Define instance(s)

DAYNIGHT

Maintain workprocess distribution for the

instance(s)

Maintain timetable

Import/maintain profiles

Setting Up the CCMS

Use transaction RZ10




Use transaction SM63

Before you can work with the CCMS, it must be configured set up correctly for your environment. How you initially configure the CCMS largely determines the consistency and accuracy of its functioning.

Set up the CCMS in the following steps:

Maintain R/3 profiles. Normally, you import the profiles of all active servers after installation. They are then automatically saved to the database and activated.

Define at least one operation mode.

Generate instance definitions for the instances created during R/3 System installation.

If necessary, assign instance definitions to operation modes and adapt the work process distribution.

Define the timetable for normal operation for a full 24-hour cycle.

If operation modes, instances, or timetable are not correctly defined, the CCMS may display incorrect data.


© SAP AG 1999


Running your system

Overview: R/3 System administrationDEV: Checklis for the Development / Test SystemQAS: Checklist for Operationg the Production SystemAdditional Administration Tasks

SAP System Administration

Starting and Stopping the R/3 System from Windows NTPrinting: installing Additional PrintersSending System MessagesProfile Generator: Maintaining Activity GroupsUsers: Copying a UserUsers: Locking and Unlocking UsersUsers: Changing a PasswordUsers: Finding a Missing AuthorizationUsers: Checking Active UsersMaintaining System ProfilesOperation Modes: Creating a New Operation ModeOperation Modes: Adjusting the Time TableOperation Modes: Manually Switching ModesOperation Modes: scheduling Exception OperationJobs: Scheduling JobsJobs: Checking Job Status and Displaying LogsImporting Hot Packages, Legal Change Patch, ...Performance Monitoring

Database Management: Additional Tasks

Trouble Shooting, Service and Support

Use the System Administration Assistant to start transaction RZ10(Profile Maintenance)


You can use the System Administration Assistant to go directly to transaction RZ10 in order to maintain your system profiles.


© SAP AG 1999

Used for maintenance of all R/3 profiles:

Allows you to change profile parameters using basic modeor extended mode

Lets you list the active parameters of application servers

Transaction RZ10: Profile Maintenance

Versions

Instance profile

Default profile

Start profile

Before you set up your R/3 operating modes, import R/3 profiles using transaction RZ10. This transaction is the CCMS tool for R/3 profile maintenance. You can either call it directly, use the System Administration Assistant or, from the main R/3 menu, choose Tools → CCMS → Configuration → Profile Maintenance.

In transaction RZ10, you can display administrative data for each profile, including profile name, type, version, operating system file, reference server, and modification and activation data.

There are two modes for editing profiles:

In basic mode, you can edit a set of parameters that are changed most frequently. You do not need to know the technical parameter names. Interdependent parameters are grouped together. If you change a parameter, any parameters that depend on it are adjusted automatically.

In extended mode, you can use a editing tool. You need to know the technical names of parameters and their dependencies.

Additionally, you can delete a single version or all versions of a profile, compare profiles in the database with active profiles, and check profiles in various ways.


© SAP AG 1999

Global profile directory

Default

profile

Start

profile

Instance

profile

R/3 installation program

R3SETUP

R/3 Profiles

OperatingSystem

The profile parameter values corresponding to resources (such as main memory, start profile, and instance profile) are created automatically during R/3 installation by the R/3 installation program R3SETUP.

When the first R/3 instance is installed, a default profile is generated in addition to the start profile and the instance profile. During installation of subsequent instances, the existing default profile is updated. When the installation is complete, the profiles are used as parameter files for the R/3 instances and the instances are started using the values of the parameters in these profiles.

R3SETUP assigns shared memory on the server where the R/3 instance is installed.

In a distributed R/3 environment consisting of application servers of the same platform type, you should set up a global profile directory in a shared file system.

If you set parameters to incorrect values, you may find that your instances do not start. Always take care when changing parameter values and save the last version of your profiles.


© SAP AG 1999

R/3 profilemaintenance

transaction RZ10


R/3 System

Operating System

INSTANCE_PROFILE

START_PROFILE

DEFAULT_PROFILE

Profiles generated by R3SETUPActive profiles

INSTANCE_PROFILE

START_PROFILE

DEFAULT_PROFILE

Change

Save

ActivateImport

Maintaining R/3 Profiles

111 222

333

444

Database

After installation, profiles are stored at operating system level. Before you can change profiles for different application servers from a single screen, you must store the profiles in the database. To import them into R/3, from the profile maintenance screen, choose Utilities → Import profiles → Of active servers. All three types of profiles are imported and a first check on parameters is performed. The profiles are automatically saved in the R/3 database and are activated when they are written back to the operating system level. If you import single profile files or create profiles, you must check, save, and activate the profiles manually.

You can also create and maintain several profiles in the database under the same name, by assigning different version numbers to different files. Each time you save an altered profile, a separate version is created. The database thus contains mirrored operating system profile files, old versions, modification histories, and parameter documentation.

The R/3 application server is always started using the profile file at the operating system level. A profile consists of two logical parts: entries in database tables and an operating system file in the global profile directory. To activate a profile, you must write it to the operating system level and restart the R/3 System. When you activate a profile from the database, if another profile file exists with the same name, a dialog box asks you to confirm that you want to overwrite the previous file. Additionally, a backup file is written. When the profile is activated, a header is inserted in the operating system file, containing the name of the profile, the user who modified the profile, and date and time of the change. You can only activate the most recent version of a profile.

© SAP AG 1999

R/3 profile maintenancewith transaction RZ10

Start

profile

Change instance services

Change globalinstance parameters

Change instanceparameters

Default

profile

Instance

profile

Changing R/3 Profile Parameters

In almost all cases, you should use the standard profile parameter values proposed by the system. Before changing the standard values, you should obtain the agreement of SAP or a SAP partner. For example, the EarlyWatch service may recommend changing certain parameter settings. You may need to change the standard settings for the following reasons:

To start or delete an additional SAP service process on a given computer, for example, a message service (in this case, change the start profile)

To change a global system parameter that is valid for all instances, for example, if you want to move the R/3 database from one computer to another to improve performance (in this case, change the default profile)

To change a parameter value for an R/3 instance, for example, the number of background work processes (in this case, change the instance profile used at startup)

Before you leave either the basic or the extended maintenance mode, profiles changes are checked automatically and any errors or inconsistencies are displayed. After activation, all parameter changes are documented in the operating system file.

When you modify profile parameters, the changes do not take effect immediately. Dynamic switching (activation of parameters without system restart) is possible only for the memory management parameters of an instance profile.


© SAP AG 1999

R/3 profilemaintenance

(transaction RZ10)

Checking and Comparing R/3 Profiles

Check a single profile

Instance pfl.

Default ProfilStart

profile

Instance

profile

Check all profiles

Operating systemcompare

Database

You can carry out extensive health checks for one or more profiles. You can check profile syntax, the spelling of parameter names, and semantics. When you run these checks, a log is generated for any warnings and error messages.

When you check single profiles, the parameters are divided into classes. For each class, there is a separate check rule. For example, the check rule for parameter class time value reports an error if the value of a parameter in this class (such as rdisp/btctime) is less than 0.

When you check all profiles, you can also check whether all profiles of one type used in an R/3 System are consistent with each other. For example, all start profiles can be checked to see whether exactly one message server is started, or all instance profiles can be checked to see whether an enqueue work process was configured. You can check either all profiles of active servers or all profiles in operation modes.

After an application server has been started, an automatic check is performed to see whether the server's profile data as stored in the database still matches the active profiles at operating system level. If this is not the case, an alert is triggered in the Alert Monitor. This allows you to determine whether the operating system files have been changed manually. You can also perform this check manually.

Parameter attributes and documentation are available in transaction RZ11.


© SAP AG 1999

Dialogprocessing

Background processing12

9

6

3

11 1

7 58 4

210

DAY

NIGHT

12

9

6

3

11 1

7 58 4

210

BTC

Operation Modes: Concept

Typically, customers require more dialog processes during the day and more background processes during the night. To adjust the proportions of the various R/3 work processes to suit different phases of system activity, you can:

Maintain the instance profile and restart the system (for unusual changes)

Define operation modes and use the operation mode switch (for daily changes)

Operation modes optimize system resources for different phases of system activity. Operation mode switching reconfigures your R/3 System dynamically, so you do not need to change the instance profiles for your server and you experience no system downtime.

An operation mode configures the use of resources for all the instances in your R/3 System based on:

The services or work processes you need

The time interval you choose


© SAP AG 1999

D

DAY_OPERATION

Server 1 Dialog 3 Background 2


D B

Dispatcher

BD D D B

Dispatcher

BD

Server 1 Server 2

D

Choosing an Operation Mode 1

Day operation usually requires more dialog processes. Good response times must be guaranteed for important data entry transactions, for example, SD order entry.

Dialog processing is used for:

Interactive processing, such as posting documents or creating sales orders

Sending a limited data volume to be inserted and updated in the database

User activity with limited transaction steps

Time-critical processing


© SAP AG 1999

NIGHT_OPERATION



D D B

Dispatcher

B D B

Dispatcher

B

Server 1 Server 2

D B BB

Choosing an Operation Mode 2

Night operation usually requires more background processes. Background processing resources must be available for high priority jobs.

Background processing is used for tasks requiring database activity that is is too time-intensive for dialog processing, such as:

Background tasks (list balances, payments, . . .)

List processing

Periodic processing

Inserting and updating large data volumes


© SAP AG 1999


Running your system






Use the System Administration Assistant to start transaction RZ04(Create Operation Modes)


You can use the System Administration Assistant to go directly to transaction RZ04 in order to configure and maintain your operation modes and instances.


© SAP AG 1999


Instance

profile

Operation mode:

Day

Operation mode: Night

Instance definition Choose: Settings → Based on current Status → New Instances → Generate

Instances / operation mode

Current work process distributionof the instance is assigned to theinstance definition for every productive operation mode

Operation modedefinition

Setting Up Operation Modes/Instances

To set up the CCMS, define at least one operation mode in one of the following ways:

Call transaction RZ04

Use the System Administration Assistant

From the main R/3 menu, choose Tools → CCMS → Configuration → Operation modes/instances

If no operation modes have been defined, the test operation mode DUMMY is displayed. Operation mode DUMMY is automatically configured for monitoring system functions, and cannot be used for operation mode switching. That is, it cannot be assigned in a timetable.

Operation modes can be of type productive or test. Only productive operation modes can be assigned in the timetable.

Instances are created during R/3 System installation. R3SETUP automatically creates a profile for each R/3 instance.

Before you can create instance definitions in R/3, you must at least one production operation mode.

It is not advisable to create instance definitions manually. The CCMS offers two non-manual methods:

If you have several servers, you can generate the current instance definition for all the active servers (shown in the graphic).

If you have few servers or if you want to add new servers, you can create an instance definition for one server by taking current settings from an active instance.

When generating instance definitions, the system imports the current instance data of every application server that is active.


© SAP AG 1999

Transaction RZ04

Operation mode:

Day

Operation mode: Night

Instancedefinition 1

Instancedefinition 2

Adapt originalwork processdistribution

Adapting Instance Definitions and Operation Modes

Night Dialog 2Background 3

Day Dialog 3Background 2

Instance 1:

Day Dialog 4Background 2

Night Dialog 2Background 4

Instance 2:

If you generate an instance definition by using the current settings from an active instance, each previous production operation mode as well as the current work process distribution of the instance are assigned to the definition.

If you create a new instance definition that is not based on the current settings of an active instance, you must assign operation modes manually.

For each assigned operation mode, you can adapt the related work process distribution for the instance definition. You can change the type of work processes. You cannot change the total number of work processes, because it is determined in the instance profile.

The minimum number of work processes for dialog and also for background processing is 2. The total number of dialog work processes is always the total number of all work processes minus all non-dialog work processes.

You can reserve one or more background work processes exclusively for high priority jobs (Class A jobs). The reserved background processes are counted in the number of background work processes.


© SAP AG 1999

ShutdownShutdown

Shutdown DAY_OPERATION

NIGHT_OPERATION

D D B

Dispatcher

B D B

Dispatcher

B

Server 1 Server 2

DD/B D/B D/B

Operation Mode Switch: Advantage

When R/3 switches between operation modes, work processes are redistributed automatically, without stopping and restarting the instances. There is no system downtime. Only work process types are changed. The total number of work processes remains unchanged after the operation mode switch.

If processes still have jobs at switch time, they are switched one by one when the jobs are completed. Thus, normal system operation is not interrupted. No program is cancelled. System performance is maintained, as R/3 buffers such as ABAP buffers and table buffers are not refreshed.

Operation mode switches are recorded in the system log. The old and the new process type are recorded for each switched work process.


© SAP AG 1999

AMarch 28

08.00 - 21.00 Op. mode A

21.00 - 08.00 Op. mode B

March 293 p.m. - 4 p.m. Op. mode C

Timetable fornormal operation (24-hour cycle)

Timetable forexceptional operation on March 29

March 29

00.00 17.0015.0008.00 21.00 23.59

B B

AB BAC

Scheduling Operation Modes

The automatic switching of operation modes is controlled by timetables. You must also maintain timetables for CCMS monitoring. Maintain or check the timetables in one of the following ways:

Call transaction SM63

Use the System Administration Assistant

From the main R/3 menu, choose Tools → CCMS → Configuration → Operation mode calendar

The timetable allows scheduling in terms of 24-hour days, divided into intervals of 60, 30, or 15 minutes. You can define normal and exceptional operation.

In normal operation, the defined time intervals for operation modes are repeated in a 24-hour cycle. You must schedule a complete period of 24 hours, not just part of a day. Otherwise, problems may occur during operation mode switching.

In exceptional operation, the defined time intervals for operation modes are activated once for a specified time period. The timetable has a higher priority than the timetable for normal operation. You can specify part of a day (without defining a 24-hour cycle).

Only productive operation modes can be switched automatically (that is, entered in a timetable).

If the timetable for normal operation is not defined, the start configuration according to the profile remains active and no automatic operation mode switch occurs.


© SAP AG 1999

Use the Control Panel (transaction RZ03) to switch operation modes manually:

Call transactionRZ03 and selectthe server you want to switch

Before you can switch toan operation mode, youmust select one

Switch the operation mode for one or allservers

111

222

333

Switching Operation Modes Manually

Sometimes, you may need to switch operation modes manually. Do so only in exceptional cases, for example, when automatic switching did not work correctly. Either call transaction RZ03 or, from the System Administration Assistant, choose Entire View → Display → Running Your System → Additional Adminsitration Tasks → R/3 System Administration → Operation Modes: Manually Switching Modes.

From the control panel, you can switch to a particular operation mode either on all servers or on an individual server.

Ensure that a manual operation switch does not disrupt system operation (for example, by providing too few dialog processes).

Before you make a manual switch of operation modes, always test it by performing a simulation of the switch. To simulate a switch, choose Tools → CCMS → Control/Monitoring → Control Panel → Control → Switch operation mode → Simulation. A test log describes which switches are possible and which errors may occur when a real switch takes place.

To switch the operation mode after a simulation, choose Control → Switch operation mode. The servers remain in the manually activated operation mode until the next switch time.


© SAP AG 1999

Database

SAP R/3 instance

Operation mode switch failure

Operating system

disp+work.exe

WP . . . gwrdWP

Inconsistencies

Configurationaccording to

operation mode Start and instance profile Start and

instance profile

Operation Mode Switch Diagnostics

If the operation mode switch fails, you should investigate the cause of the failure. The cause is most likely to be inconsistencies in the system. Inconsistencies can occur, for example, if there are different numbers of work processes:

In the instance profile on the operating system

On the database

In the operation mode definition

You should check regularly whether the number of work processes that are currently running is the same as the number entered in each of these three parts of your system.

If you change profiles and restart the system, you must adapt operation modes as well as instance definitions to correspond to the current status.

To check the operation mode switch and the work process switch within the system log, use transaction SM21 or, from the main R/3 menu, choose Tools → Administration → Monitor → System monitoring → Process overview.

To check the work process switch within the process overview, use transaction SM50 or, from the main R/3 menu, choose Tools → Administration → Monitor → System monitoring → Process overview.


© SAP AG 1999

Control Panel (transaction RZ03)

Start / Stop

Control instance and database started from operating system

Instance A

Instance B

Starting and Stopping Instances with the CCMS

You can start and stop R/3 instances with the CCMS.

When starting instances with the CCMS:

The database and at least one R/3 instance (the control instance) must have been started from the operating system.

You can use the CCMS control panel (transaction RZ03) to select an operation mode and start the remaining instances remotely. You can start multiple instances or special instances. The control panel enables you to check the startup log for each instance that has been started.

On UNIX platforms, command rexec is used to start servers remotely. For this command to function, you need to define a startup user and password in the instance definition.

On platforms without rexec, you need to use a tool with the same function as rexec. For example, to start Windows NT server instances from a UNIX server, a rexec daemon must be running on the Windows NT server.


© SAP AG 1999


Check for TransactionStart

(S_TCODE)

<TCODE> Transaction Code

01 all management functions03 display authorization

Transaction Code

CC Control Center(S_RZL_ADM)

Activity

CCMS Monitoring Authorization


© SAP AG 1999


Set up the CCMS:Import and maintain profiles

Create operation modes and instance definitions

Maintain operation modes and instance definitions

Schedule operation modes

Switch the operation mode manual

Start and stop instances with the CCMS



© SAP AG 1999


SAP Basis Knowledge Product:System Management

SAP Online Documentation:BC Computing CenterManagement System

SAP Notes under components:BC-CCM-CNF-OPM

BC-CCM-CNF-PFL


© SAP AG 1999

Unit Actions

Exercises?

Solutions



CCMS Configuration: Exercises

No. Exercise 1 Preparing your R/3 System to start

For these exercises, you should restart your R/3 System.

1.1 Under Windows NT, proceed as follows. Group 1 (QAS) using pcANYWHERE: Go to the global profile directory using Windows Explorer. Create a subdirectory called BACKUP and copy the existing profiles into it.

Group 2 (DEV) using Telnet: Go to the global profile directory. Create a subdirectory called BACKUP and copy the existing profiles into it. Under UNIX, proceed as follows. Use Telnet. Go to the global profile directory. Create a subdirectory called BACKUP and copy the existing profiles into it.

1.2 In R/3, to see if any profiles have been imported to the database, use profile maintenance (either call the transaction directly or navigate with the System Administration Assistant). If no profiles have been imported, what method would you use to import the profiles into the R/3 System?

2 Importing, maintaining, and activating profiles 2.1 Import all profiles at once into the R/3 System.

2.2 (Optional) Import a single profile (an instance profile) into the R/3 System.

2.3 Perform a check of the individual profiles you just imported.

2.4 Determine the number and the types of the R/3 System work processes.

2.5 Change the number of work processes that are configured in the instance profile for your second instance, so that the new settings take effect during the next instance restart. Add 1 more dialog work process and 1 more background work process.

2.6 Check the changes to your modified instance profile at the operating system level. Can you see the changes that you made?

3 Activating your changes To activate your profile changes, you must stop and start your instance.

3.1 Group 1. Use the Microsoft Management Console to stop your instance. Once your instance has successfully shut down, restart the relevant R/3 instance. Group 2. To shut down your R/3 instance, use stopsap with the appropriate parameters. To restart your R/3 instance, use startsap with the appropriate parameters.

3.2 Use the process overview and compare the number of work process that are now running with the number that were running in step 2.4. Is there a difference?


4 Creating operation modes and instance definitions 4.1 In CCMS, create two operation modes: Day and Night. Either call the

transaction directly or navigate with the System Administration Assistant.

4.2 Create the instance definitions for your R/3 System. What is the easiest way to create all instances in one step?

4.3 Maintain the work process distribution of your instances. Keep the current operation mode Day for both instances and set your operation mode Night to have 4 background processes on the central instance and 3 background processes on the second instance. Configure the central instance to have 2 additional update processes for Night. What happens to the dialog work processes when you add the background and update work processes? Remember to check that, after this exercise, at least 2 background work processes are configured in all operation modes.

5 Schedule operation modes 5.1 Maintain the operation timetable. Select operation mode Night to become

active within the next hour.

6 Manual switch of operation mode 6.1 Switch the operation mode for all instances manually to operation mode

Night.


CCMS Configuration: Solutions

No. Solution 1 User Profile 1.1 Under Windows NT, proceed as follows.

Group 1. In the directory G:\usr\sap\<SID>\sys\profile create a subdirectory BACKUP. Copy the profiles into folder BACKUP one by one: for XXX = DEFAULT.PFL START_DVEBMGSxx_<hostname> START_Dxx_<hostname> <SID>_DVEBMGSxx_<hostname> <SID>_Dxx_<hostname>

choose Edit → Copy XXX and then Edit → Paste XXX into BACKUP. Group 2. Change to directory G:\usr\sap\<SID>\sys\profile. To create the subdirectory, use command mkdir backup. To copy the profiles into the subdirectory, use: copy DEFAULT.PFL backup copy START_<instance name>_<hostname> backup copy <SID>_<instance name>_<hostname> backup

Under UNIX, proceed as follows. Change to directory /usr/sap/<SID>/sys/profile. To create the subdirectory, use command mkdir backup. To copy the profiles into the subdirectory, use: cp DEFAULT.PFL backup cp START_<instance name>_<hostname> backup cp <SID>_<instance name>_<hostname> backup

1.2 Check transaction RZ10 (from the System Administration Assistant, transaction SSAA, choose Entire view → Display Tasks → Running Your System → Additional Administration Tasks → SAP System Administration → Maintaining System Profiles). If you try to select a profile, you will see that no profiles have been imported. The best way to import the profiles of all active servers is all at once (see solution 2.1).

2 2.1 To import all relevant profiles at once, use transaction RZ10 and choose

Utilities → Import profiles → Of active servers. Once the import has been completed, a log file is displayed.

2.2 (Optional) Use transaction RZ10 or, from the SAP standard menu, choose Tools → CCMS → Configuration → Profile Maintenance. For the profile that is to be imported, select the instance profile name <SID>_<instance name>_<hostname>. Choose Create and enter a short description. In the administrative data path name, overwrite the capital letters in the hostname with lowercase letters. The type of profile you are importing is already known. Choose Copy.

Choose Profile → Import and select the path of the profile you are importing.


Example: G:\usr\sap\<SID>\profile\SID_DVEBMGSxx_<hostname> Choose Copy, then Save. In the following dialog box, choose Yes to activate the profile.

2.3 To perform a consistency check from within transaction RZ10, select a profile and choose Check.

2.4 Use transaction SM66 (System Wide Work Process Overview) or, from the SAP standard menu, choose Tools → CCMS → Control/Monitoring → Work Process overview. To see the processes with status wait, choose Select process and flag status wait. Note the work process type and numbers.

2.5 Use transaction RZ10 and select the instance profile of your additional instance. Select Basic Maintenance and choose Change. Change the number of work processes: add 1 more dialog work process and 1 more background work process. Choose Copy, then Save. In the following dialog box, choose Yes to activate the profile.

2.6 Call transaction AL11 and double-click DIR_PROFILE. This takes you into the profile directory. To display your instance profile, double-click it.

3 3.1 Group 1. To stop and start your R/3 instance, use the Microsoft Management

Console. You do not need to restart your central instance. Group 2. To shut down your R/3 instance, use stopsap with appropriate parameters. To restart your R/3 instance, use startsap with appropriate parameters.

3.2 Use transaction SM66 (System Wide Work Process Overview) or, from SAP Easy Access, choose Tools → CCMS → Control/Monitoring → Work Process overview. To see the processes with status wait, choose Select process and flag status wait. For your second instance, you should see 1 more dialog (DIA) work process and 1 more background (BTC) work process.

4 4.1 From transaction RZ04, choose Operation mode → Create, and create an

operation mode Day. Enter Day and a short description of the operation mode. Choose Save. Repeat this procedure for operation mode Night.

4.2 Use transaction RZ04 and choose Instances/operation modes → Settings → Based on current Status → New instances → Generate. You should see that both instances for your system have been created and that operation modes Day and Night have been assigned with the current system work process distribution from the instance profiles.

4.3 For the central instance, double-click on operation mode Day or Night. If necessary, select Other operation mode. To specify 4 background work processes at night for the central instance, select the background work process number and click the plus sign. To add 2 update work processes at night, select the update process number and click the plus sign. Then choose Save. Notice that the number of dialog work processes decreases. This is because you cannot exceed the number of configured work processes in your profile, and the number of Class A background work processes cannot exceed the number of background processes. For the second instance,


double-click operation mode Night and specify 3 background processes.

5

5.1 Using the System Administration Assistant (transaction SSAA), to access transaction SM63, choose Entire view → Display Tasks → Running Your System → Additional Administration Tasks → SAP System Administration → Operation Modes: Adjusting the Timetable. Select Normal Operation and Change. Double-click the beginning and the end of the time interval and assign this interval to a defined operation mode (operation mode Night should become active within the next hour). Fill out your timetable completely and save it.

6

6.1 To go to the control panel (transaction RZ03) from the System Administration Assistant (transaction SSAA), choose Entire view → Display Tasks → Running Your System → Additional Administration Tasks → SAP System Administration → Operation Modes: Manually Switching Modes. Choose Execute, select Choose operation mode, and double-click operation mode Night. Then choose Control → Switch operation mode → All servers. A dialog box appears: choose Yes. Call transaction SM50 and check the work process distribution. This should match what you defined for your instances in operation mode Night.

© SAP AG 1999










© SAP AG 1999


ContentsOverview of the R/3 background processing environment


Describe the basic capabilities of background processingDefine and schedule background jobs using the job wizardMonitor background jobsMake use of the R/3 background processing functionality


© SAP AG 1999

Why Background Processing?

Reasons for Background ProcessingReducing load on dialog workprocesses

Scheduling regular activities

vs

Mon Tue Wed Thu Fri Sat Sun

Mon Tue Wed Thu Fri Sat Sun

BD

Dispatcher

Dialog work processes are intended for dialog processing. For this reason, the duration of a dialog step is limited. Background processing is intended for operations that require a longer time to run.

Background processing is also suitable for activities that are scheduled to run regularly, for example database backups or financial evaluations.


© SAP AG 1999

What is a Background Job?

A job consists of one or more steps

A job step is one of the following:ABAP program (maybe with variants)

external command

external program

One job is processed by onebackground workprocess

Job 1Job 2

Job 3

Step 1

Step n

There are 6 priorities:Class A job with target server

Class A job without target server

Class B job with target server

Class B job without target server

Class C job with target server

Class C job without target server

Prio

rity

high

low

A job can be triggered

by time

by event

12

678

910

11 123

45

A background job consists of one or more steps. A step can be:

An ABAP program

An external command

An external program

Each job is processed without interruption by a single background work process.

A job can be triggered to run:

At a predefined date and time

At the occurrence of a predefined event

Background jobs can be prioritized as:

Class A (high priority)

Class B (medium priority)

Class C (low priority)

Jobs allocated to target servers have higher priority than untargeted jobs.


© SAP AG 1999

Scheduling of Jobs and Workload Balancing

Job-schedulingtable

Server 1 Server 2

The job scheduler runs on every applicationserver with background workprocessesevery rdisp/btctime seconds (default: 60 s)

If a target server is specified,jobs are not distributedacross the availablebackground servers

Job ID Name Class Time Target

0010 Job 1 A 08:00 Server10020 Job 2 C 09:100030 Job 3 C 10:200040 Job 4 B 10:20 Server2

... BD

Dispatcher

Server 3

... DD

Dispatcher

... BD B

Dispatcher

Background work processes can be configured on any R/3 instance using instance profile parameter rdisp/wp_no_btc.

There is no minimum number of background work processes. Background work processes are defined based on the number of background jobs to be processed in each instance. When the transport system is used, a minimum of 2 background work processes must be available.

The combination of job ID and job name make each job unique in the system.

Every R/3 instance with background work processes defined on it has a job scheduler running on it.

The job scheduler (ABAP program SAPMSSY2) runs in a dialog work process every rdisp/btctime seconds. The default time setting is 60 seconds.

The job scheduler checks the job-scheduling table in the database for jobs that are ready to run. Depending on their priorities, these jobs are allocated to free background work processes on the current server.

Jobs that are not allocated to target servers can be processed by any free work process. Thus, the workload is automatically distributed between the servers.

If you allocate a job to a target server, you can use the special features of a particular server (for example, that it runs on the same machine as the database). However, if you do this, you lose the benefits of automatic workload distribution.


© SAP AG 1999

Reservation for Class A Jobs

Job ID Name Class Time

0010 Job 1 A 10:000020 Job 2 B 10:000030 Job 3 C 10:00

B

B

10:00 10:30 11:00 t

B

B

No reservation

With reservation

rdisp/wp_no_btc = 2

Operation mode:2 background WPs1 reserved for Class A

2

31

1

2 3

12

678

9

1011 1

2

3

45

In normal operation, every background work process processes jobs with any priority.

You can reserve one or more background work processes for Class A jobs. To specify the number of reserved processes, you must define an operation mode in the CCMS and maintain the work process distribution for the operation mode. To maintain operation modes, call transaction RZ04 and proceed as described in unit 4 (Adapting Instance Definitions and Operation Modes).

By reserving a number of work processes, you ensure that this number of work processes remain free for Class A jobs independently of the priority of the jobs already running on the other work processes.

Which particular work processes are reserved may change during operation, but no new Class B or C job may start unless the reserved number of processes are free for possible Class A jobs.

For further details on how to reserve background work processes for Class A jobs, see SAP Note 36280.


© SAP AG 1999



Running your system






Use the System Administration Assistant to start transactionsSM36 (define a new job)SM37 (monitor jobs)

To start transactions SM36 or SM37, use the System Administration Assistant. Alternatively, use the following paths.

To start transaction SM36 (define a new job), choose System → Services → Jobs → Define job or Tools → CCMS → Jobs → Definition.

To start transaction SM37 (monitor jobs), choose System → Services → Jobs → Job overview or Tools → CCMS → Jobs → Maintenance.


© SAP AG 1999

The Job Wizard is an easy way tocreate a job.

Step-by-step dialog screens guide youthrough the process.

You can use the navigation buttons goback to previous steps.

On the last screen, you will see whatyou have defined before you save

Start condition of a job could be one of th1.) immediately - meaning as soon as pos2.) based on exact date time assignment3.) after another job4.) after an event5.) when a certain operation mode switch

ImmediatelyDate/timeAfter jobAfter eventAt operation mode switchStart on workdayJob not released

Job view

Back Complete Cancel

Congratulations!You have successfully defined a job. Choose 'Done' toactually create the job in the system.

You can also choose 'Back' to revise the job definition orCancel' to cancel the whole process.

------------------------------------------------------------------

Here is the job you have defined:

Job name : GULP

Job class : C - LOW PRIORITY

Target server :

Task

flow

Transaction SM36Job Wizard

General jobinformation

Definea step

Definestart conditions

Defining a Job Using the Job Wizard

To define a new job, use transaction SM36. From Release 4.6A, you can use the Job Wizard to define new jobs as follows:

Specify job name, class, and optional target server

Define a job step (a step can be an ABAP program, external command, or external program)

Add further steps (if necessary)

Start condition (time or event based)

Complete the definition

The Job Wizard allows you to go back and make changes at any point during the definition process.


© SAP AG 1999

R/3 System

ABAP Program External Command External Program

No selection screen

With selection screen

Variant

+predefined within R/3• Operating system• Command• Parameters

Any command onOperating System

level

External Program External Program

sapxpg

Operating System

sapxpg

Executing Programs as Job Steps

A job step can be any one of the following.

ABAP program Any ABAP program that generates a list can be used as a job step. If the program includes a selection screen, you must create a variant before you can let it run in the background. A variant is the result of assigning definite values in the fields that appear in the ABAP program selection screen. The list is stored in the R/3 spool system. When you define the step, you can set the print parametsrs (for example, output device) and a spool list recipient (this is a SAPoffice addressee).

External command An external command is any non-R/3 program, script, or command that is executed at operating system level. Since these commands are defined in R/3 by the system administrator, the administrator use R/3 authorizations to limit the scope of the commands and their availability to R/3 users.

External program An external program is also any non-R/3 program, script, or command that is executed at operating system level. The system administrator has not previously defined these programs in R/3 and no check is made for critical or dangerous programs.

In the latter 2 cases, the programs are called up at the operating system level by program sapxpg. The programs are processed

synchronously (job waits for termination of the external program) or

asynchronously (next job step is processed immediately).

The output (stdout and/or stderr) of the external program can be taken up in the job log.


© SAP AG 1999

Time based Event based

Immediate

once or periodically

if periodic, exceptions possible

At Date/Time


if periodic, exceptions possible

On chosen workday (per month)


rdisp/btctime rdisp/btcname

After event


with or without parameter

After job

status dependent

At change ofoperation mode

Job 1 Job 2

Day Night

12

678

910

11 123

45

Start Conditions of a Job

The start conditions of a job can be time based or event based.

Time based:

Immediate

At date/time

On a chosen workday (defined as a certain workday per month)

All time-based start conditions can be periodic. That is, a job can be performed at regular, defined time intervals. Days that are not workdays can be treated as exceptions.

Parameter rdisp/btctime specifies the time interval of the job scheduler.

Event based:

After event (optional parameters can be used to further specify events) These can be periodic. That is, the job can be triggered every time the event occurs.

After job (this can depend on the status of the previous job)

At change of operation mode (for example, between day and night)

Parameter rdisp/btcname specifies which application server handles events triggered from within R/3.


© SAP AG 1999

R/3 System

Definition of events

Operating System

CCMS (manually)

external sapevt

ABAP programUser event

CCMS

SAP event

Triggering of events

Definition and Triggering of Events

New events are defined by the system administrator in CCMS. Events are either SAP events or user events. SAP events are internal to the R/3 System and you should not trigger or modify them.

Events can be triggered:

For testing purposes, manually in the CCMS.

From within ABAP programs, using function module BP_EVENT_RAISE.

From outside R/3 at operating system level, using program sapevt.

The syntax for sapevt is: sapevt <event> [ -p <parameter> ] [ -t ] <[pf = <profile>]> | <[name = <SID>] [nr = <instance>]>

<event> : event name as defined in the CCMS (required)

<parameter> : parameter specified (optional)

-t : create tracefile (optional)

<profile> : pathname to profile (optional)

<SID> : R/3 System name (optional)

<instance> : R/3 System instance number (optional)

Example: sapevt gulp name=DEV nr=00

When an event is triggered, a parameter can be specified. You can define jobs that are triggered by the occurrence of an event with a certain parameter.


© SAP AG 1999

Use Copyto create a new job

Scheduled

Finished Canceled

Released

Ready

Active

Change job

Monitor Job log Spool list

(only for ABAPs)

Status of a Job

The job status can be any of the following:

Scheduled: job is created but has no start condition

Released: job is completely defined and waiting for selection

Ready: job has been selected for execution

Active: job is being executed by a background work process

Finished: the entire job has been successfully executed

Canceled: job terminated with problems

As long as a job has status scheduled or released, it can still be changed.

If execution of a job has already started, its progress can be monitored in the job log. If the job contains ABAP programs, their output is stored in spool lists.

To create the steps of a new job from an existing job, choose Copy.


© SAP AG 1999

Job overview andpath to more details

Job

log

? Job details

Selectioncriteria St

atus

Double-clickon line for ...

Spoo

l lis

t

Job Monitoring: Text Form

To monitor jobs, call transaction SM37. From Release 4.6A, the initial screen offers an extensive range of selection criteria. For example, you can select jobs by specifying one of their steps. To list event-based jobs, you must specify an event.

This job list presents the user selection at the top of the screen. The ABAP List Viewer (ALV) is used to display the list and enables you to store multiple display variants.

From the job overview, you can navigate to various detailed job-related views:

The job log enables you to monitor the progress of a job.

The spool list contains the output of ABAP programs, if any.

Job details include the job definition, execution time, and background work process number.


© SAP AG 1999

Job Monitoring: Graphical Form

To access the graphical scheduling monitor (transaction RZ01), choose Tools → CCMS → Control/Monitoring → Job scheduling monitor.

Column Job Server indicates the names of the servers. Duplicate names indicate multiple background work processes configured for the server. If a server name is not displayed, no operation mode has been defined for that server. If an operation mode has been configured to reserve background processes for Class A jobs, this is also indicated in the display.

Each box displayed by the Job Scheduling Monitor represents a background job. To find detailed information about the job, select one of the boxes.

For an explanation of all items and colors displayed, choose Legend.


© SAP AG 1999

Using ABAP job API Using external job XBP-API

A pair of jobsrunning periodically

One job withtwo predecessors

Any complex scenarioinside one R/3 System

Involving several R/3 Systems

Involving non-R/3 Systems

Job 2

See Function Groups BTCH, BTC2 See SAPNet Alias csp → Job Scheduling

Job 1Job 3

Job 2

Job 1

Job 2

Job Z

External jobschedulingsystem

Job 1 on R/3 DEVJob 2 on R/3 QASJob Z on non-R/3 System X

DEV

QAS

X

XBP

Job 1

Overview: Extending the Standard

The functions described so far do not cover all background scheduling scenarios. You can implement more advanced functions in the following ways.

The R/3 System includes various internal function modules to help you create your own job workflow. You can find these function modules in function groups BTCH and BTC2. With the help of these modules, you can create arbitrarily complex scenarios.

SAP offers a comprehensive set of interfaces to integrate CCMS with existing system management environments.

The external monitoring interface (XMI-API) logs the activity of users and agent programs.

The external interface for background processing (XBP-API) allows you to use external background job scheduling systems.

These tools enable you to schedule background processing beyond R/3 System boundaries and to include non-R/3 Systems.

For a list of available certified solutions, see SAPNet area “Complementary Software Program” (alias csp).

These topics are covered in course BC305.


© SAP AG 1999


Operation on jobs(S_BTCH_JOB)

DELE Delete jobs of other usersLIST Display spool lists of other usersPROT Display job logs of other usersRELE Release own jobs automaticallySHOW Display other users job definitions

JOBACTION

* Reserved, set to *JOBGROUP

Backgrounduser name

(S_BTCH_NAM)

<name> Authorized user when schedulingBTCUNAME

Y User is batch administratorN or empty Restricted to jobs in current client

Administrator(S_BTCH_ADM)

BTCADMIN

Authorizations 1

S_BTCH_JOB Determines the following functions: DELE : delete jobs of other users LIST : display spool requests created by jobs of other users PROT : display job logs created by other users RELE : release your own jobs automatically during scheduling SHOW : display job definitions of other users

S_BTCH_NAM Determines which authorized users you can choose when scheduling a job. An authorized user provides the authorizations required for performing a background job.

S_BTCH_ADM Grants authorizations to an administrator, enter Y. The administrator can access jobs in all clients. Without this authorization, users can only work on jobs in the client in which they are logged on.


© SAP AG 1999


System administration(S_RZL_ADM)

01 All CCMS management functions03 Only display activities in CCMSACTVT

Externalcommands

(S_LOG_COM)

<name> Name of logical commandCOMMAND

<name> Name of operating system

<name> Host name of target systemHOST

OPSYSTEM

Authorizations 2

S_RZL_ADM This authorization is required to grant update and maintenance capabilities to the system administrator for CCMS functions. Activity code 01 grants the administrator all management functions with CCMS. Activity code 03 grants only display capabilities in CCMS.

S_LOG_COM Grants authorization to execute external commands. The following fields are available: COMMAND: Logical name of the external command OPSYSTEM: Name of the operating system on the target host HOST: Host name of the target system


© SAP AG 1999

Now you are able to:Define and maintain background jobs

Distinguish between the various background processing features

Monitor background jobs

Set up an authorizations concept for background processing



© SAP AG 1999


SAP Knowledge Product System Management



© SAP AG 1999

Unit Actions

Exercises?

Solutions



Background Processing: Exercises

No. Exercise 1 (Optional) Check the background processing environment

The following steps give you practice in evaluating your background environment. Always perform these steps if problems occur in your system.

1.1 How many background work processes are configured on your SAP System?

1.2 What determines the number of available background work processes?

1.3 How many background jobs can you run at the same time?

1.4 How can you check at what intervals the job scheduler runs?

1.5 How can you find out which application server handles events triggered from within R/3?

1.6 Can you run background jobs of class A on your R/3 server?

1.7 Can you find out if you have background work processes reserved for class A jobs in your process overview (transaction SM66) or in your instance profile?

1.8 Imagine that you have no available background work processes. Can you make background work processes available without restarting your R/3 instance?

2 Create, schedule, and monitor a background job Set up and execute background jobs using different methods. Evaluate the job results.

2.1 Execute Report RSUSR000 in dialog using transaction SA38.

2.2 Execute Report RSUSR000 in background using transaction SA38.

2.3 Define a job SIMPLE_## using the Job Wizard. The job should: – Be of class C – Have 1 step: execute Report RSUSR000 – Start immediately

2.4 Check whether job SIMPLE_## ran successfully. Find data relating to the start date, steps, and job details such as client and user name. Is the spool list printed automatically?

2.5 (Optional) Determine the actual execution time of job SIMPLE_## and whether there was a delay before it started.

3 ABAP with variant and external program Execute an ABAP program using an existing variant and an external program.

3.1 Define a job STEPS_## using the Job Wizard. The job should: – Be of class C – Step 1: Execute Report RSPFPAR with variant DISPATCHER – Step 2: Execute external program whoami (check the control flags) – Start in 2 minutes


Check whether the job ran successfully.

3.2 (Optional) Create your own variant for report RSPFPAR. Schedule a job that uses this variant.

4 External commands and events handling Create a User defined event, then schedule a job with an external command to be executed based on this event. Trigger the event from CCMS and from an external program.

4.1 Display a list of external commands. What does the command ZKERNEL do?

4.2 Within CCMS, create a user event MYEVENT_##.

4.3 Define a job EVENT_## using the Job Wizard. The job should:

– Be of class C – Step 1: Execute external command ZKERNEL – Start after event MYEVENT_## and specify event periodic

Display the job in the Job Overview.

4.4 In a second session, trigger the event manually in CCMS and refresh the Job Overview.

4.5 Trigger the event at operating system level and refresh the Job Overview.

5 (Optional) Define job chains Create a job that is dependent on the job created in exercise 4.

5.1 Define a job NEXTLINK_## using the Job Wizard. The job should: – Be of class C – Step 1: Execute report RSUSR000 – Start after successful run of job created in exercise 4 Check the status of the job in the Job Overview.

5.2 What must you do to run job NEXTLINK_##?


Background Processing: Solutions

No. Solution 1 Check the background processing environment 1.1 Check in transaction SM66 (choose Select Process, flag status wait) for the

number work processes of type BTC (background).

1.2 Initially, parameter rdisp/wp_no_btc determines the number of available background work processes. You can check the parameter setting using transaction RZ11 or with Report RSPFPAR. If you use operation modes (transaction RZ04), this setting can be overwritten. Use the CCMS Control Panel (transaction RZ03) to check the current operation mode.

1.3 You can run as many background jobs in parallel as background work processes are available.

1.4 Check parameter rdisp/btctime. This parameter determines the intervals at which the job scheduler runs. To check the parameter setting, use transaction RZ11 or report RSPFPAR.

1.5 Check parameter rdisp/btcname. This parameter determines the application server for event handling. To check the parameter setting, use transaction RZ11 or report RSPFPAR.

1.6 You can run background jobs of class A on any server where background work processes are running.

1.7 If you have reserved background work processes for class A jobs, this is only visible in the operation mode definition. To find out if any background processes have been reserved for Class A jobs, in transaction RZ04 choose Instances/operation modes and view column BPA.

1.8 You can use transaction RZ04 to define an operation mode with background work processes.

2 Create, schedule, and monitor a background job 2.1 In transaction SA38, enter RSUSR000 and choose Execute.

2.2 Enter RSUSR000 and choose Background. On the next screen, choose Execute immediately. To check the job status and the spool list from this screen, you can choose Job overview.

2.3 In transaction SM36, start the Job Wizard. Enter job name SIMPLE_## and select class C but leave Target server free. Choose Continue. Select ABAP program step and continue. As ABAP program name enter report RSUSR000. Choose Continue. Do not specify any additional steps: choose Continue. As start condition, select Immediately and continue. Do not flag Period. Choose Continue and Complete.

2.4 To check job status, use transaction SM37 and select Execute. For job details, double-click the job and select Job details. Details include job ID, client, user name, and work process number. To see the defined steps of the job, choose STEP. Spool lists are only available when you use an ABAP program as a job step.


If, when defining the step, you have defined immediate output in your user defaults or set print parameters, a spool list is printed automatically.

2.5 You can determine the execution time in transaction SM37 (see solution 2.4). In transaction SM39, you can see further information regarding background jobs, for example, job name, user who scheduled job, status, start time, job duration, start delay, and average run time for periodic jobs. In the initial screen of transaction SM39, enter the job you defined in step 2.4.

3 ABAP with variant and external program 3.1 In transaction SM36, start the Job Wizard. Enter job name STEPS_## and

select class C but leave Target server free. Select ABAP program step and as ABAP program name enter report RSPFPAR with variant DISPATCHER.

As additional step, select External program as a step and enter program name whoami without additional parameters. As target server, enter the name of your application server. Check the control flags and save the proposed default settings. As start condition, select Date/time and enter the planned start time. Check whether the job ran successfully as in solution 2.4.

3.2 (Optional) In transaction SA38, enter RSPFPAR and choose Goto → Variants. Enter a name for your variant and choose Create. Fill out the selection screen as you like. Click Attributes and then enter a description of your variant. Save your input and go back (choose Back). You can then run RSPFPAR with your own variant as a job step as described in solution 3.1.

4 Create events then schedule jobs dependent on these events 4.1 To display a list of external commands in CCMS from the SAP standard

menu, choose Tools → CCMS → Jobs → External Commands (transaction SM49). To run a command in the list, select the command and choose Execute. External command ZKERNEL displays the disp+work (kernel) information.

4.2 Choose Tools → CCMS → Jobs → Maintain event. Do not modify system event names. Under User event names, select Maintain and execute. Choose Create. Enter the event ID MYEVENT_## and a description of the event, then choose Save.

4.3 In transaction SM36, start the Job Wizard. Enter job name EVENT_## and select class C but leave Target server free. Select external command ZKERNEL without further parameters. Select the operating system. As target server, enter the name of your application server. Choose Control flags and save the default settings. As start condition, select After event, select MYEVENT_## without a parameter, and set flag Period. Check the job status in transaction SM37. To ensure that your job is listed, you must enter the name of the triggering event (or *) in the selection screen.

4.4 In the SAP standard menu, choose Tools → CCMS → Jobs → Trigger event (or use transaction SM64), select your event, and trigger it without parameter.


If you refresh the Job Overview, you will see that the job has run once and is scheduled to run again.

4.5 (Optional) At the operating system level of the application server, enter sapevt MYEVENT_## name=<SID> nr=<nr>

If you refresh the Job Overview, you will see that the job has run once and is scheduled to run again.

5 Define job chains

5.1 In transaction SM36, start the Job Wizard. Enter job name NEXTLINK_## and select class C but leave Target server free. Select ABAP report RSUSR000. As start condition, select After Job, enter predecessor job name EVENT_## and select Start if the preceding job ends successfully. Complete the job definition. Check the job status in transaction SM37. To ensure that your job is listed, select Expanded job selection and in the field Start after job enter the name of the predecessor job (or *).

5.2 In a second session, trigger MYEVENT_## again. To see if it ran successfully, refresh the Job Overview.

© SAP AG 1999








Users and Authorizations


© SAP AG 1999

Users and Authorizations

ContentsAuthorization conceptProfile GeneratorUser administration


Describe the R/3 authorization conceptMaintain authorizationsCreate R/3 users and assign authorizations


© SAP AG 1999

Users in the R/3 Environment

Database Server

Dat

abas

eSe

rver Operating System

Operating System

Operating System

App

licat

ion

Serv

erPr

esen

t.Se

rver

R/3 User

OS User

DB User

OS User

OS User

Admin. User

Dispatcher

...VD B

This unit focuses on the R/3 user within the R/3 System. However, it is important for the R/3 System administrator to control access to both the operating system (OS) where the R/3 Systems reside and the database (DB). External user IDs exist both at the OS and DB levels that can be used to disrupt normal operation of the R/3 System.

Access to the R/3 System is controlled at the client level. Each R/3 user must have a user master record in the client in which that user will work. In R/3, authorizations are used to restrict access to programs and data.

This unit focuses on:

The creation of user master records

Authorization profiles

Controlling access to transactions and data in the R/3 System


© SAP AG 1999

User master record User master record

Authorizations assigned?

Objects needing protection

Vendor

Company code Plant

Material

Action

Transaction permitted?

Authorization Concept 1

Profile

Authorizationfor Task A

Authorizationfor Task B

Profile

Action

In R/3, for each user who requires access in a client, the authorization administrator creates a user master record for that user in that client.

The user master record includes one-to-many (1-n) profiles containing all the authorizations needed by the user to perform tasks in the specified client. An authorization provides the permission(s) required to access certain transactions, reports, or data. For each user activity or transaction, an authorization check is performed to see if the required authorizations have been assigned to that user.

Authorizations limit access to transactions and objects in the R/3 System that need protection, for example, a company code or vendor.

The R/3 authorization concept enables authorizations to be assigned at the transaction level. If a user who is not authorized to perform a certain task attempts to run the corresponding transaction, R/3 sends a message denying access to that transaction. Authorization checks are performed at various points during the execution of a transaction or report to verify that the user has the required authorization(s) for the objects requested. For example, R/3 may check if the user is authorized to access data for company code 001.


© SAP AG 1999

Authorization Concept 2

Profile 2Activity Group 2

Profile 3Manual

Profile 1Activity Group 1

Data BankData Bank

User Master Record Profile(s) Authorization(s) Field Values

Access to R/3 data is controlled by the field values assigned to the authorizations contained in the users profiles.

A user master record contains one or more profiles, which may result from an activity group assignment. Composite profiles contain a collection of single or composite profiles. Composite Activity Groups contain a collection of single or composite activity groups.

A user is assigned all authorizations contained in each profile entered in the user master record.

Profiles can be created and entered in the user master record using either of the following methods:

Profile Generator (Activity Groups)

Manually

Profiles generated as the result of using the profile generator must be maintained using the profile generator.


© SAP AG 1999

FinancialAccounting

Authorization

display, change

Customer company code:Authorization A

Customer company code:Authorization B

0001-0009

*

display

Object: Customercompany code

Company Code

Activity

Authorization objectObjectclass

Authorization Objects

To maintain authorizations, run transaction SU03. The initial screen lists various object classifications. An object class is a logical grouping of authorization objects that share a similar purpose or business area. For example, object class Basis: Administration contains authorization objects that control access to Basis transactions.

The authorization object is the template from which the authorization is created. It is used in the ABAP code for authorization checks. Each object has up to 10 fields that are checked using AND logic before access is granted to the desired transaction.

The authorization administrator creates authorizations from the authorization object. The authorizations contain the field values (permissions) for each field contained in the object. Field values control access to the business area or data addressed by the transaction.

To create or change an authorization, enter or change the relevant values in the fields of the authorization.

All authorizations are positive, in that they grant permissions to the user.


© SAP AG 1999

Authorization Check

SAP GUI

OK?

AuthorityCheck

No

Processing

UserContext

MessageYes

Dynpro

When a user logs on to the R/3 System, all authorizations in the profiles assigned to the corresponding user master record are loaded into the user buffer for the application server to which the user is connected. Once the dispatcher assigns the user request to an available dialog work process, the relevant program is loaded and the user context is checked to see if the user has the necessary authorizations.

The user context contains the user authorizations. These are checked against the authorization objects called in the authority check specified in the ABAP code.

The user authorizations are checked using OR logic to determine if an exact match exists. If the required authorization exists the user is allowed to proceed and processing continues. If none of the authorizations contain the required combination of field values, a message is sent denying the user access to that object.

Once the dialog step has been completed, the user context for the user is rolled out of the dialog process and the process is free to work for another user. The user context remains in the user buffer and is available for use during the next dialog step.

To adjust or cancel authorization checks either globally or for individual transactions, the authorization administrator must use transaction SU24. Checks can be adjusted, for example, if detailed authorization checks are not needed in certain transactions. To adjust or cancel checks, set profile parameter auth/no_check_in _some_cases to value Y (this is the system default value in Release 4.6).


© SAP AG 1999

Profile Generator Introduction

Activity Group 1

Activity Group 2

Activity Group N

The Profile Generator simplifies the assignment of user authorizations by selecting from the company menu transactions that belong together from the company point of view, then grouping these transactions together in activity groups.

The activity group concept allows authorization profiles to be generated to reflect a specific work center, job, organizational unit, person, or position with in the organization structure.

Maintenance of a single activity group affects each user associated with or assigned to the activity group, so administrative work is reduced.

Before you can use the Profile Generator, it must be configured.

For information on the initial configuration of the Profile Generator, in online help choose BC Basis Components → Computing Center Management Center → Users and Authorizations → SAP Authorization Concept → Procedure for Initial Installation. For additional information on configuring the Profile Generator, see the book Authorizations Made Easy available under alias http://www.sap.com/asap. Choose ASAP Accelerators → Authorizations or ASAP Accelerators → Made Easy Guidebooks.


© SAP AG 1999

Activity Group Creation and Maintenance

View: Basic maintenancefor simple administration ofusers and activity groups

View: Overview forindirect assignment

of activity groups withinorganizational structure

To use the Profile Generator, choose Tools → Administration → User Maintenance → Activity Groups (User Roles) or call Transaction PFCG.

In Transaction PFCG, the Profile Generator initial screen provides two views:

The basic maintenance view allows the administrator to create and maintain activity groups. Using this view, you can assign R/3 users to one or more activity groups. If a change in authorization is required, changing the activity group affects all users assigned to that group.

The overview enables you to associate each activity group or composite activity group with an agent. As the graphic shows, an agent can be a person or an organizational element within the structure of the company. From this view, you can associate one or more activity groups with a node on the Human Resources Organization Chart. Security can be controlled by moving individuals with the organizational structure as the user(s) inherit or disinherit the authorizations contained within the activity group associated with that node.

To maintain users using the Profile Generator, perform the following steps:

Specify activities and transactions required

Create authorization profile(s)

Maintain user assignment to created activity groups

Compare user master records

For additional information, go to Online Help and choose BC Basis Components → Computing Center Management Center → Users and Authorizations.


© SAP AG 1999

Menu and Transaction Selection

Selected menu optionsare used by the profile generatorto create required authorizations

To create an activity group, create and save the group definition. Once a group is defined, the administrator must identify which transactions are required by the users in the group and then select the transactions from the company menu (or an existing activity group or area menu).

Once transactions have been assigned to an activity group via the company menu, the Profile Generator automatically identifies the authorization objects required for the selected transactions. If the field values that are needed for the authority check are independent of the customer, they are supplied by the system.

The relations between the transaction and the required authorization objects and default values are defined by SAP in tables USOBT and USOBX. To display the table contents, use transaction SU22. Directly after system installation, the customer must copy these initial settings from tables USOBT and USOBX to tables USOBT_C and USOBX_C (which specify the customer name range) using transaction SU25. To maintain tables USOBT_C and USOBX_C, use transaction SU24. The Profile Generator refers to tables USOBT_C and USOBX_C to create the authorizations required by the system for access to the transactions selected.


© SAP AG 1999

Maintenance of Authorization Values

The Profile Generator creates the authorizations required for the selected transactions. The required fields from the authorization object are listed and must be maintained with the appropriate values to grant or restrict access.

To change a field value, click on the field or the pencil icon. Organizational units such as company code for each activity group should be maintained in a central area (choose Org. levels). To find documentation, double-click an authorization object's text in the second level.

Traffic lights indicate the status of your authorizations:

Green: all authorizations have been maintained

Yellow: some authorizations must still be maintained

Red: organizational levels must be maintained

After all required fields have been maintained, the green light indicates that the profiles can now be generated. To do so, click the red and white Generate icon. An activity group may contain one-to-many (1-n) profiles depending upon the transactions selected from the company menu. If more than 150 authorizations are required for the transactions selected, multiple profiles are generated.

Always use the Profile Generator to maintain activity group profiles.

To display technical names and icons, choose Utilities → Technical names.

To view the key for icons and colors used in this screen, choose Utilities → Legend.


© SAP AG 1999

User Assignment

Activity groups can beassigned to multiple users

or agents

Compare functionalityinsures consistency within

user master records

Authorization can bedelimited for specific

validity period

Activity groups can be assigned to multiple users or agents. Once users are assigned to the activity group, changes by the administrator to the activity group affect each user assigned.

The validity period for the user assignment enables you to delimit how long a user has access to the authorizations contained within the activity group.

If changes are made to either the activity group(s) or the user assignments, the administrator must compare the user master records. The compare function removes from the user master record all profiles that are no longer valid and inserts any newly generated profiles.

Expert mode indicates exactly which profiles were inserted and deleted. This information is available for each user affected by the comparison.

To configure the system to always perform the comparison, choose Utilities → Automatic Comparison at save.


© SAP AG 1999

The User Master Record

All user data required for R/3 System access is stored

in the user master recordin eight categories

To create and maintain user master records, use transaction SU01. For each user, the user master record contains all data and settings required for client access for the user. This data is arranged with tabs and includes the following:

Address: basic user information such as name, physical location, and telephone number

Login date: password information as well as the validity period for the record

Defaults: defined default values for start menu, date format, printers, and so on

Parameters: defined default values (PIDs) for R/3 fields such as company code 001

Systems: central user administration system information

Activity Groups: defined activity groups (with validity period) associated with user

Profiles: all profiles assigned to user master record, including standard profiles and profiles generated by the profile generator

Groups: all user groups associated with the user master record

Tab Systems only appears if central user administration is activated.

Current status and change history can be displayed for the current record. To access a detailed change history outlining all change to the user master record, use transaction SUIM.


© SAP AG 1999

Central User Administration

Client 100PRD System

Client 100Client 200

QAS System

Client 100Client 200Client 300

DEV System

With central user administration, thecreation and maintenance of all usermaster data is performed in a singleR/3 System

Managing users across the system landscape can become a complex task. Central User Administration enables you to maintain user master records in a central repository and easily access:

An overview of all users

Existing user groups

Systems defined within the system group

Activity groups

Central User Administration allows you to maintain user master records within a single client on the central system and distribute this information to all systems in your landscape. In this context, the central system is defined as an R/3 System that keeps and controls user master data for the entire system landscape.

Reasons for using Central User Administration include:

The system landscape is complex, with several clients in different systems

The same user works in more than one system

The same user ID should represent the same individual in all systems

An enormous effort is otherwise required to synchronize user data in all systems

To access Central User Administration, use transaction SCUM.

For more information on Central User Administration, take SAP Basis Class BC305 Advanced Administration.


© SAP AG 1999

Set the minimum password lengthlogin/min_password_lng

Require change of passwordlogin/password_expiration_time

Lock users after incorrect logonslogin/fails_to_user_lock

Prevent automatic unlocking at midnightlogin/failed_user_auto_unlock

Number of failed logon attempts permittedlogin/fails_to_session_end

Preventing multiple dialog user logonslogin/disable_multi_gui_login

Controlling User Logon

Parameter ValuesDefault Permitted

3 3-8

12 1-99

1 0

3 1-99

0 1

System Profile Parameters

0 999

The minimum passwork length is defined in the parameter login/min_password_lng. The default length setting is 3, values 3 to 8 are permitted.

The number of failed logon attempts is defined in the profile parameter login/fails_to_session_end. The default setting is 3, values 1 to 99 are permitted.

The number of failed logon attempts before the user is locked out is defined in the profile parameter login/fails_to_user_lock. The default setting is 12, values 1 to 99 are permitted. At the end of each day, the locks are either released by the system or deleted manually.

To prevent a lock being automatically released at midnight by the system, the profile parameter login/failed_user_auto_unlock must be set to N.

The number of days before a password expires is defined in the profile parameter login/password_expiration_time. Value 0 means there is no expiration period for passwords.

The parameter login/disable_multi_gui_login can be used to block a user from maintaining multiple logins within the same client using the same user ID. If the value is set to 1, the system enables the user to choose between Terminate the Current Sessions or Terminate this Login.

To lock or unlock users, or assign new passwords, use transaction SU01.

General password rules:

Your password must be different from the last five you have chosen

Do not begin with any sequence of three characters that is contained in your user name

Do not use “pass” or “sap” as your password

Do not begin with three identical characters

Do not begin with a question mark or exclamation mark



© SAP AG 1999

Initial Logon Procedure in SAP Clients

Client 000 001 066 New Client

User SAP* DDIC EarlyWatch SAP*

InitialPassword 06071992 19920706 support pass

! Because these users are known users, you mustprotect them against unauthorized access

Security

Clients 000, 001, and 066 are part of the R/3 delivery system.

In Client 000 and 001, there are two special users:

SAP* for initial access to the R/3 System

DDIC for the transport and correction system

To protect SAP* and DDIC from unauthorized access, you must change the initial passwords for these users in all clients of your R/3 System. We recommend that you add the user group SUPER to the user master records. This user group can only be accessed by the superuser.

Client 066 is the EarlyWatch client. Customers must change the initial user password in their own system.

SAP* is a special user. In addition to the user SAP* that is created in every client during a client copy, the user SAP* is hard coded into the kernel. The hard coded user SAP* is exempt from all authorization checks. Do not delete the user master record from any client in the R/3 system. If the user master record for SAP* is deleted from a client, the hard coded user can be accessed.

To deactivate the hard coded user SAP*, use the system profile parameter login/no_automatic_user_sapstar. See SAP Note 68048.


© SAP AG 1999

Information System

The information system provides a basis for conducting detailed analysis of user master records, profiles, authorizations, and activity groups. To access the information system, use transaction SUIM.

The information system report tree enables you to access the standard delivered SAP user analysis reports. You can search in these reports using complex search criteria that provide detailed information on:

Users

Profiles

Authorization objects

Authorizations

Transactions

User master record comparisons

Change documents

To identify pre-delivered reports from SAP for Users and User Administration, call transaction SE38. Enter RSUSR* in the program field and select the down arrow. This provides a listing of the user reports. To obtain detailed information on a report, select the report and view the documentation written by the developer.


© SAP AG 1999

System Trace for Authorizations

The R/3 System enables you to find out which authorization objects are checked when you run a particular transaction, report, or program.

To record authorization checks, use the system trace. To start the system trace, choose Tools → Administration → Monitor → Traces → System Trace or use transaction ST01.

To analyze an authorization failure, call transaction SU53 and determine which authorizations are required for your task. See SAP Note 66056.

To display all the authorizations contained in your user buffer, call transaction SU56. If all your authorizations are not displayed by this transaction, check whether:

Activity groups have been maintained since you last logged on to the R/3 System. To display your new authorizations, log off from the system and then log on again.

You have received new authorizations through a transport.

The user buffer is too small. Maintain the following R/3 profile parameter: auth/auth_number_in_userbuffer.


© SAP AG 1999


User Master Maintenance:Authorizations

(S_USER_AUT)

01 Create02 Change03 Display06 Delete07 Activate08 Display change documents22 Assign authorization profiles24 Archive

ACTIVITY

Authorization objects

Limited name spacefor the assignmentof authorization names

AUTH

OBJECT

User Administration Authorizations 1

The graphic lists the authorization objects that are checked when working with the Profile Generator and when maintaining users:

S_USER_AUT (create and change authorizations, enter authorizations in profiles, ...)


© SAP AG 1999


User Master Maintenance:User groups

(S_USER_GRP)01 Create02 Change03 Display05 Lock, unlock06 Delete08 Display change documents22 Add users to activity groups24 Archive78 Assign

User group name

Activity

User group

User Master Maintenance:User groups

(S_USER_PRO)01 Create02 Change03 Display06 Delete07 Activate08 Display change documents22 Assign profile to users /

remove assignment24 Archive

Profile name

Activity

Profile


S_USER_GRP (administer users assigned to a user group)

S_USER_PRO (create and change profiles, enter profiles in user master records, ...)


© SAP AG 1999


Transactioncode check at

transaction start(S_TCODE)

TCD Transaction code

HR: Transaction

code(P_TCODE)

PD: Personnel planningand development

(PLOG)

TCD Transaction code

INFOTYP Info typeISTAT Planning statusOTYPE Object typePLVAR Plan variantPPFCODE Function codeSUPTYP Sub type

TCD

TCD

INFOTYPISTATOTYPEPLVARPPFCODESUPTYP


Authorization object S_TCODE is checked at the start of a transaction. In the authorizations contained in this authorization object, transaction codes are listed for all the transactions that can be started by the user. Further authorization checks are usually performed during the transaction.

Authorization object P_TCODE is required for HR transactions and works similarly to S_TCODE. The Profile Generator (PFCG) is an HR transaction.

Authorization object PLOG is required for integrating HR with basis functionalty.


© SAP AG 1999

Summary


Maintain activity groups using the Profile Generator

Assign R/3 users to these activity groups

Create and maintain user master records


© SAP AG 1999


Basis Knowledge Product: System ManagementTopic: User Administration


Documentation Authorizations Made Easyfrom the R/3 Simplification Group

SAP TechNet: System Management → Forum

SAPNet:BC-CCM-USR-ADM, BC-CCM-USR-KRN,BC-CCM-USR-PFC

SAP Note 80210 - Profile Generator:Composite note


© SAP AG 1999

Unit Actions

Exercises?

Solutions



Users and Authorizations: Exercises

Changes created with the Profile Generator are Customizing changes and can result in repeated system prompts to include such changes in a Customizing request. If you receive such a prompt, choose Create Request and enter a description. If you are prompted for a change request again during this exercise, use this request.

No. Exercise 1 Create Users

Create the user ADMIN## (where ## is your assigned student number) with the specifications defined in exercises 1.1 - 1.5.

1.1 Maintain the name of the user.

1.2 Maintain the last name of the user and enter an initial password for the user.

1.3 Assign this user to the user group SUPER.

1.4 Define a default logon language for the user (choose an installed language).

1.5 Enter the user parameter XUS with the value ADMIN##. Save your user.

2 Create an activity group and assign user 2.1 Create the activity group TCC1 using the specifications defined in steps 2.2 -

2.4. Enter the description TCC Course for your activity group and then save these settings.

2.2 Specify activities for this group: switch on technical names and, from the SAP menu tree, select monitoring transactions SM50, SM51, and SM04 and application transactions ME22N, ME23N, and ME24 (to find the application transactions, choose Logistics → Material Management → Purchasing → Purchase Order). Check that your selections have been transferred to Activity group menu. Add transactions SMEN and SESSION_MANAGER by selecting Add Transaction. Save these entries.

2.3 Generate an authorization profile: use Change authorization data to check your selections and verify that you have green lights. A dialog box appears for you to maintain the organizational levels (to select values, use F4 help). Generate the profile(s) for the selected transactions. Check at the bottom of your screen that the profile(s) have been created.

2.4 Assign users: assign the user ADMIN## to the activity group created above.

2.5 Update user mater data: from within the Profile Generator, update the ADMIN## user master data. Check whether the activity group and the authorization profile are assigned to the correct user.

3 (Optional) Check the user ADMIN## 3.1 Log on to the R/3 System as user ADMIN##, then check if the user can

execute the transactions you assigned.

3.2 Is user ADMIN## authorized to maintain its own address?

3.3 Is user ADMIN## authorized to execute transaction SU53?

3.4 Log off from the R/3 System (ADMIN##) and continue working as a course participant.


4 (Optional) Copy a user 4.1 Create the new user BASIS## by copying user ADMIN##, without copying

the authorization profile or the activity group assignment.

5 (Optional) Lock users 5.1 Lock the user ADMIN##.

5.2 Check the information system and find out which users are locked.


Users and Authorizations: Solutions

Changes created with the Profile Generator are Customizing changes and can result in repeated system prompts to include such changes in a Customizing request. If you receive such a prompt, choose Create Request and enter a description. If you are prompted for a change request again during this exercise, use this request.

No. Solution 1 Create users 1.1 From the System Administration Assistant (transaction SSAA), choose Entire

view → Display Tasks → Running Your System → Additional Administration Tasks → SAP System Administration → Users: Changing a Password or call transaction SU01 directly. Enter user name ADMIN## and choose Create.

1.2 Enter the last name of the user. Select tab Logon Data and enter a password in fields Initial password and Repeat password.

1.3 Assign this user to the user group SUPER. Select group SUPER as group in field User group for authorization check.

1.4 Select tab Defaults and define a default logon language for the user.

1.5 Select tab Parameters and set parameter XUS to value ADMIN##. Save these settings.

2 Create an activity group and assign user 2.1 From the System Administration Assistant (transaction SSAA), choose Entire

view → Display Tasks → Running Your System → Additional Administration Tasks → SAP System Administration → Profile Generator: Maintaining Activity Groups or call transaction PFCG. To create the activity group, enter TCC1 and choose Create. Enter the description TCC Course for your activity group and then save (choose Save).

2.2 Select tab Menu. Switch on technical names by choosing the magnifying glass icon under Additional activities. Under Copy menus, choose From the SAP Menu and the SAP menu tree is built and displayed. To select transactions SM50, SM51, and SM04, choose Tools → Administration → Monitor → System Monitoring. To select the logistics transactions, choose Logistics → Material Management → Purchasing → Purchase order and select Create, Change, and Display. After you have selected all the transactions, choose Transfer. Check that your selections have been transferred to Activity group menu by expanding the menu. Add transactions SMEN and SESSION_MANAGER by selecting Add Transaction. Save these entries.

2.3 To display the authorization data, check your selections, and verify you have green lights, choose tab Authorizations and choose Change authorization data. A dialog box appears: use F4 help to maintain the organizational levels. Save. In the next screen, a yellow light shows that some authorization fields have not yet been maintained. Select the yellow light and assign full authorization for the subtree. To generate the profile(s) for the selected transactions, choose Authorizations → Generate. Choose Execute. Check in the status bar that the profiles were created and go back (choose Back).


2.4 Click tab User. In the column User ID, input the ID you created in step 1 (ADMIN##) and choose Enter. Save your selection.

2.5 Update the user master record by choosing User compare (in the dialog box, choose Complete compare). New profiles are transferred to the user master record for ADMIN##. After the compare, you should have a green light for the user tab. Run transaction SU01 and check that your user has received the activity group and profile.

3 Check the user ADMIN## 3.1 Log on to the R/3 System as user ADMIN##. The transactions selected above

are now available.

3.2 No.

3.3 No.

3.4 Log off from the R/3 System (ADMIN##) and continue working as a course participant.

4 Copy a user 4.1 Use transaction SU01 or, from the System Administration Assistant

(transaction SSAA), choose Entire view → Display Tasks → Running Your System → Additional Administration Tasks → SAP System Administration → Users: Copying a User. In transaction SU01, enter ADMIN##, choose Copy, then enter the name BASIS##. Deselect Authorization profiles and Activity groups.

Enter a new password for BASIS## twice and save.

5 Lock users 5.1 Use transaction SU01 or, from the System Administration Assistant

(transaction SSAA), choose Entire view → Display Tasks → Running Your System → Additional Administration Tasks → SAP System Administration → Users: Locking and Unlocking Users. Select user ADMIN## and choose User names → Lock/Unlock. A dialog box appears: choose Lock/unlock.

5.2 Use transaction SUIM or, from transaction SU01, choose Information → Information System. Within the information system tree, to display an overview of all users locked, choose User → List of User Master Records Locked Due to Incorrect Logon.

© SAP AG 1999








Spool and Print - UNIX


© SAP AG 1999

Spool and Print

ContentsSpool System overviewManaging printers and access methodsLogical Spool ServerManaging spool requests


Describe the functionality of the R/3 Spool SystemDefine output devices for local, remote, andfrontend printingDefine and make use of logical spool serversManage spool and output requests


© SAP AG 1999

Information Flow

HelloWorld

R/3 System

R/3Spool System

Operating System spoolHello

World

TemSe

Document

User action Create document

Print

Output

Output Request

Spool Request Spool Data

The R/3 System recognizes several classes of documents (for example, SAPscript texts or report lists) that can be printed.

When a request is made to print a document, a spool request is created. A spool request has two parts:

Administrative information (origin, date, author name, logical printer) is stored in the R/3 database

The data to be printed is stored in a repository called the temporary sequential database (TemSe). The R/3 Spool System uses generic representations of printer formatting commands and the R/3 internal character set to represent the characters to be printed.

TemSe data can be stored inside the R/3 database or at operating system level. Profile parameter rspo/store_location (see SAP Note 20176) determines where TemSe is located:

db stores the data in the database (default)

G stores the data in an operating system file in the global directory

The preparation of a spool request for printing is an output request. In R/3, you can either print immediately (an output request is generated immediately) or delay printing (the spool request does not lead immediately to an output request). A spool can correspond to several output requests. These can be sent to different output devices.

Usually (but not in certain printing scenarios), the R/3 System generates a device-specific, print-ready output stream, which is sent via an operating system spooler to a printer.


© SAP AG 1999

Access Methods: Local Printing

R/3 Application Server

S S ... D

Dispatcher

C Lor

Physicallylocal

Physicallyremote

Printserver

OS spool

You can configure your R/3 instance to run multiple spool work processes. This affects sequential request processing. See SAP Note 108799.

Output requests are usually sent to the spool server in the order they were created, but if more than one spool work process is configured, the requests may be printed in a different order.

If necessary, you can specify that output requests are transmitted to the host spool system in the order they were generated. This option causes request processing for this device to be restricted to a single work process within the spool server. A spool work process is temporarily reserved for this device, and all output requests for this device are stored in an internal queue in the reserved work process. Once the internal queue has been processed, the reserved work process is released.

There are various methods an R/3 Spool System can use to access an operating system spooler.

Local printing The operating system spooler runs on the same host as the R/3 spool work process.

In Windows NT systems, the spool work process uses operating system calls to pass output to the printer manager using the Windows NT API (access method C).

In UNIX systems, the output request is passed to the operating system spooler using UNIX commands, for example lp or lpr (access method L). The form of the command is specified in the R/3 System profile.

Local printing is the fastest and most reliable way of printing in R/3. Local printing does not mean that the printer is physically attached to the host running the R/3 spool work process. The operating system spooler can print on either a locally or remotely attached printer.


© SAP AG 1999

Access Methods: Remote Printing

Networkprinter

UNIX

U OS spool

Printserver

WinPC

OS spool

Printserver

saplpd


U

S S ... D

Dispatcher

S Uor

Remote printing When using remote printing, an R/3 spool work process passes the print-ready output stream to the operating system spooler on a different host. This data transfer requires moving the output stream across a network link. The operating system spooler can then print on either a locally or remotely attached printer.

Some printers haver their own operating system spooler. They can be directly attached to a network through a network card interface. They are called network printers, and can also receive output from R/3 (access method U).

In UNIX systems, the output stream is sent to a line printer demon lpd (access method U).

In Windows systems and other systems without an lpd, SAP provides the program saplpd, which receives the output stream and transfers it to the operating system spooler (access method S for a proprietary SAP protocol or U for the UNIX Berkeley protocol).

For performance reasons, the remote access methods are only suitable for LAN environments and require reliable communication partners.


© SAP AG 1999

Access Methods: Frontend Printing

Frontend PC

Printserver


SAP GUI

OS spool

S S ... D

Dispatcher

saplpd

F

Windows

others

Frontend printing Frontend printing allows R/3 users to send output to printers that are defined on their local frontend PCs (access method F). The spool administrator does not need to define these printers as output devices in R/3.

In Windows systems, the output is sent to program saplpd on the frontend PC. If saplpd is not running, it is started automatically.

In other systems (UNIX, Macintosh, ...), the output is passed to the operating system spooler.

As of Release 4.6A, all spool processing takes place in a spool work process. The spool work process waits until the output has been sent to the frontend before it continues to process other requests. Therefore, performance problems can occur when frontend printing is used.

You can set an upper limit to the number of spool work processes used for frontend printing using parameter rdisp/wp_no_spo_Fro_max. The default value of the parameter is 1.

Frontend printing only works as long as there is an active connection to the frontend PC. Therefore, frontend printing cannot be used in background processing.

For more information on frontend printing and release dependencies, see SAP Collective Note 114426.


© SAP AG 1999



Running your system






Use the System Administration Assistant to start transaction SPAD(Spool administration)

To start the spool administration transaction SPAD, use the System Administration Assistant. Alternatively, choose Tools → CCMS → Spool → Spool administration.


© SAP AG 1999

Creating a New Output Device

Local Remote Frontend

DeviceAttributesDevice type Set to match Set to match SWINSpool server Choose one Choose one -

HostSpoolAccMethodAccess method C (NT) or L (UNIX) S or U FHost printer OS printer name OS printer name _ _DEFAULTHost name Fixed - -Destination hosts - Decide -

To create a new output device, select Output devices. The fields are as follows.

Output device: The logical printer name is case-sensitive and can be up to 30 characters long.

Short name: The name the system uses to access the printer. It can be generated automatically.

Device type: The type of printer. For frontend printing in Windows systems, the device-independent printer driver SWIN can be used to shift processing from R/3 to the frontend PC.

Spool server: The R/3 application server (or logical spool server) that formats the output requests. This entry is not needed for frontend printing.

Access method: Specifies the data transfer method to the host spooler.

Host printer: The name of the printer defined at the OS level. In Windows systems, no spaces are allowed in the name and, for frontend printing, __DEFAULT accesses the default printer defined for the frontend PC. For frontend printing in other operating systems, a printer called __DEFAULT must be configured on the frontend PC.

Host name: For local printing only. Generated automatically and depends on the spool server.

Destination hosts: For remote printing only. The name of the host on which the lpd or the saplpd is running. If the printer is a network printer, the Microsoft UNC name from Windows Print Manager can be used (for example, \\P21939\P42).

If you need to perform sequential request processing, choose Output atributes and select Sequential request processing.


© SAP AG 1999

Device Types

Choosing the right device type

A suitable device type is available in R/3

Download device type from sapserv server(see SAP Note 8928)

Use generic printer format (such as PostScript) or set mode to supported device type

Use device type SWIN

Write your own device type

Choose one of the following strategies to define a device type for your printer.

In the best case, there is already a device type for the printer you wish to use.

SAP offers a suitable device type that you can download from a sapserv server. See SAP Note 8928 for an up-to-date list of supported printers.

Most printers can be driven using a generic format (for example, PostScript) or can be switched to a mode that is compatible to a standard printer for which a device type is available in R/3.

Almost all printers are delivered with Windows printer drivers. You can drive these printers with the device-independent printer driver SWIN. In this case, processing is shifted from R/3 to the Windows Print Manager.

In the worst case, you must write your own device type (or modify a copy of an existing device type). This is not advisable unless you are an expert in R/3 Spool System and printer driver code. In this case, it may be better to obtain a supported printer.


© SAP AG 1999

Logical Spool Servers

R/3 System

twdfmx03_DEV_00Log_Test

Logical Spool Server Real Spool ServerOutput Device

twdfmx03_DEV_01

Log_Prod B

Test 1

Test 2

Prod 2

Log_Prod AProd 1

Gulp

P

P

T

T

P

P

T T

P

T: Test printP: Production print

An output device can be allocated directly to a real spool server, which is an R/3 instance offering at least one spool work process.

Logical spool servers introduce an extra layer in the spool server architecture. Logical spool servers open up a wide range of further possibilities.

A logical spool server can be mapped to a real spool server or to another logical spool server.

A logical spool server can be used instead of a real spool server in R/3. For example, an output device can be allocated to a logical spool server as well as a real spool server.

Logical spool servers open up a wide range of further possibilities, such as:

Spool server switchover

Workload balancing

Transporting the printer architecture

Both output devices and spool servers can be classified for certain print jobs, for example test prints or production prints.


© SAP AG 1999

Creating a Logical Spool Server

Server class

Mapping

Class

Classify your printers and spool servers, and keep them separate:

High volume print

Production print

Test print

Logical flag

To create a new output device, select Spool servers. The fields are as follows.

Server name: The name of the logical spool server, as defined in R/3. It is case-sensitive.

Server class: The classification for print jobs.

Logical server: Identifies the spool server as a logical spool server.

Mapping: The name of the real or logical spool server that your logical server is mapped to.

Separate the spool printers and servers for the different kinds of print job:

High volume print (for example, cost-center lists)

Production print (for example, documents or cover letters)

Desktop print (for example, SAPoffice documents)

Test print

The reason for this is that a spool work process can only process one output request at a time.

To classify an output device, call transaction SPAD, choose Output devices, select the output device you want to change, then choose Edit → Classification.


© SAP AG 1999

Feature 1: Spool Server Switchover

Alternative

R/3 System



Test 2

Test 1

twdfmx03_DEV_01

Spool server switchover When creating a real or logical spool server, you can define an alternative spool server. If the normal spool server becomes unavailable, R/3 switches all the devices using this spool server to the alternative.

For this strategy to function, you must ensure that all the printers can be driven in the same way by all the spool servers involved. For example, using the local printing, you need to ensure that the same printer names appear at the operating system level of the hosts for all the real spool servers that can serve as alternatives. In the graphic, if output device Test 1 points to the printer with operating system name P42, then the printer name P42 must be listed in both servers twdfmx03_DEV_00 and twdfmx03_DEV_01.


© SAP AG 1999

Feature 2: Workload Balancing

Load comparison

R/3 System

Log_Test


Test 2

Test 1 twdfmx03_DEV_00

twdfmx03_DEV_01

Workload balancing When an alternative spool server is defined for a spool server, you can allow load balancing (load comparison). The load on a spool server is calculated from the number of spool work processes, of output requests, and of pages.

Load balancing can be activated independently for each logical or real spool server. If an output request is generated for a spool server where load balancing is active, the system searches both the mapping and the alternate definition of that server to find the spool server with the least load. The selection algorithm is recursive: as the system checks the mapping and alternate defined server hierarchies, it applies the selection rules to each level.

Sequential request processing has priority over the load balancing option for spool servers. Therefore, if a device is configured for sequential processing and it is assigned using load balancing to a spool server, load balancing is ignored for output requests generated for that device.


© SAP AG 1999

Feature 3: Transporting the Printer Architecture

R/3 System DEV

Log_Test

Prod 2

Prod 1

twdfmx03_DEV_00

Volume Log_Vol

R/3 System QAS

Log_Test

Prod 2

Prod 1

twdfmx04_QAS_00

Volume Log_Vol twdfmx04_QAS_01

Transporting the printer architecture Logical servers provide a uniform method for defining and transporting a complete printer architecture with minimal changes.

The graphic shows that a printer architecture can be transported from an R/3 development system to a quality assurance system. All the output devices and logical spool servers from the development system are transported to the quality assurance system.

To activate printing in the target system, you only need to change the mapping in each logical spool server definition for the new R/3 System environment.

Transaction SPAD provides functions for transporting both output device definitions and spool server definitions.


© SAP AG 1999

Selecting Spool or Output Requests

To display spool or output requests, call transaction SP01 or choose System → Services → Output controller

The initial screen offers a wide range of selection criteria. You can customize it to show just the selction criteria that interest you, or you can chooose a standard set of selction criteria.

As of Release 4.6A, you can also display spool or output requests from other R/3 Systems. To do so, enter a valid RFC destination in System name. If you clear the field and leave it empty, all the systems in table ALCONSEG (which lists all the systems selected for remote monitoring in transaction RZ20) are addressed.


© SAP AG 1999

Monitoring Spool and Output Requests

Log Info

Status

The displayed list shows the status of the spool or output requests that meet your selection criteria. The ABAP List Viewer (ALV) is used to display this list and enables you to store multiple display variants.

The status of a spool request is one of the following:

- : no output request for this spool request

Proc. : a spool work process is processing the corresponding output request

Waiting : a spool work process is waiting for a return code from the operating system spool

Compl. : the corresponding output request(s) has (have) been printed successfully

Error : the corresponding output request(s) has (have) not been printed successfully

<F5> : the corresponding output requests have different statuses

To navigate from a spool request to its output requests, double-click on its status. To navigate from several spool requests to their output requests, select their lines and click the Output request icon.

A log is written for every unsuccessful output request. You can use the log for error analysis.


© SAP AG 1999

Maintaining the Spool Database

Delete old spool requests

Online using transaction SPAD

Offline, schedule regularly:

Check spool database consistency


Offline, schedule daily:

Spool Database

TemSe

Output Request


RSPO1043RSPO1041

You must define a regular schedule for maintaining your R/3 spool database. Regular maintenance tasks include deletion of old spool requests and checking the consistency of the spool database.

To delete old spool requests, run ABAP program RSPO1041 with a suitable variant regularly as a background job. See SAP Note 130978.

To perform spool database consistency checks, run ABAP program RSPO1043 with a suitable variant every day (including Sundays and holidays) as a background job. See SAP Note 98065.

In exceptional situations, you can also perform these maintenance tasks online (but with limitations) using transaction SPAD.


© SAP AG 1999

Authorizations 1


Spool action(S_SPO_ACT)

BASE List spool requestsPRNT Print onceREPR Repeat printingREDI RedirectDELE Delete manuallyDSIP DisplayAUTH Change authorizationATTR Change attributes

SPOAUTH Value Value for which the user is authorized.This value must match the authorizationfield in the spool request.

SP01 Administration of spool requests (all clients)

SP0R Same as SP01 (own client)SPAD Spool administration (all clients)SPAR Client-dependant spool administrationSPAA Define output deviceSPAB Define real and logical OMSSPAC Maintain device types and related objectsSPAM Administration of spool requests

all clientsSPTD TemSe administration (all clients)SPTR Same as SPTD (own client)

SPOACTION

Systemauthorization

(S_ADMI_FCD)

S_ADMI_FCD

End users have full control over their spool requests in the output controller.

Spool administrators can manage all spool requests through authorization objects S_ADMI_FCD and S_SPO_ACT.

Authorization object S_ADMI_FCD allows the administrator to perform different management tasks, such as spool request administration and output device administration.

Authorization object S_SPO_ACT specifies what actions you can perform on which spool requests. For example, SPOACTION = BASE, DISP and SPOAUTH = xyz allow you to list and display all spool requests with the authorization field xyz.

As of R/3 Release 4.0, a spool request has its owner's user ID as default value for the authorization field. Therefore, all spool requests are implicitly protected.


© SAP AG 1999

Authorizations 2


Device authorization(S_SPO_DEV)

Value Long name of the output device

SPOPAGES Value Number of pages permitted


SPODEVICE

Maximum numberof pages

(S_SPO_PAGE)

S_ADMI_FCD

Use authorization object S_SPO_DEV to limit printer access by name.

Authorization object S_SPO_PAGE specifies the maximum number of pages a user can print on a particular output device. To activate this authorization object, set parameter rspo/auth/pagelimit to 1 in the instance profile. Once the authorization object is activated, all users must have S_SPO_PAGE authorization to be able to print.


© SAP AG 1999

Now you are able to:Describe the function of the R/3 Spool System

Define output devices for local, remote, and frontend printing

Define a logical spool server and use it on an output device

Manage spool and output requests



© SAP AG 1999


SAP Online Documentation:

BC Printing Guide

SAPNet Alias output

Basis Course:

Advanced System Administration (BC305)


For a complete list of spool request statuses, see the SAP Online Documentation:

BC Printing Guide

For information on the R/3 Spool System, see SAPNet, alias output

Basis Course Advanced System Administration (BC305) provides further information on the areas of extended and full administration in transaction SPAD.


© SAP AG 1999

Unit Actions

Exercises?

Solutions



Spool and Print: Exercises

No. Exercise 1 Define a local R/3 printer 1.1 Check which printers are configured at the operating system level of your

application server.

1.2 Within R/3, create an output device LOCAL that prints locally to one of the printers that are configured on your application server.

1.3 Submit an output request to the output device LOCAL: print the work process overview (an output request should be created immediately). Monitor your spool and output request.

2 Define a remote R/3 printer For this exercise, your instructor should give you the name of an operating system spooler on a remote server.

2.1 Within R/3, create an output device REMOTE that prints remotely to the named spooler.

2.2 Submit a spool request to the output device REMOTE: print the list of output devices (output request should be triggered manually). Monitor your spool request and submit an output request.

3 Define a logical server and assign it to an output device 3.1 Create a logical spool server LOGI and map it onto a real spool server. Do

not specify an alternative and do not select load distribution. Classify LOGI as a test server.

3.2 Change the definition of the output devices LOCAL and REMOTE to classify them as test printers and assign spool server LOGI to them.

3.3 Using the steps described in exercises 1.3 and 2.2, submit an output request to both printers, and check that the output is correct.

4 Manage spool and output requests 4.1 Display all of your own spool and output requests.

4.2 Display the contents of a spool request.

4.3 Print 2 copies of one spool request from the list. Display all output requests generated for the spool request that you just printed and check their status.

4.4 Display the attributes of the spool request printed in step 4.3. Check that the number of copies for the spool request is still 1.

4.5 Change the attributes of the spool request printed in step 4.3 to specify a default of 2 copies.

4.6 Delete all of your own spool requests.


Spool and Print: Solutions

No. Solution 1 Define a local R/3 printer 1.1 To check which printers are configured at the operating system level on your

application server: In Windows NT systems, choose Start → Settings → Printers (the group currently connected with pcANYWHERE). In LINUX systems, enter command lpc status.

1.2 Choose Tools → CCMS → Spool → Spool administration (transaction SPAD). Choose Output devices and switch to change mode using the pencil icon. Choose Output device → Create. As output device, enter LOCAL and maintain fields: Select tab DeviceAttributes and fill out fields: Device type: set to match with the definition on operating system Spool server: select a real spool server running on your application server Select tab HostSpoolAccMethod and fill out fields: Access method: C (Windows NT) or L (UNIX) Host printer: name of printer at operating system level (case-sensitive in UNIX) When you save your input, a short name is generated automatically.

1.3 To print a work process overview, run transaction SM50 and choose System → List → Print. Specify output device LOCAL and as spool option choose Print immediately. Do not select Delete after output. Choose Continue. A spool request is generated by the system. Note the spool request number given in the status bar. To monitor the status of your spool and output request, call transaction SP01 and select all spool and output requests for your user.

2 Define a remote R/3 printer For this exercise, your instructor should give you the name of an operating system spooler on a remote server (defined on a server of another group).

2.1 Choose Tools → CCMS → Spool → Spool administration (transaction SPAD). Choose Output devices and switch to change mode using the pencil icon. Choose Output device → Create. As output device, enter REMOTE and maintain fields: Select tab DeviceAttributes and fill out fields: Device type: set to match with definition on operating system Spool server: select any real spool server running on your application server Select tab HostSpoolAccMethod and fill out fields: Access method: Windows NT: S or U (saplpd must run on remote host) (to start saplpd, choose Start → Programs → SAP Frontend → SAPlpd) UNIX: U Host printer: name of printer at operating system level (case-sensitive in UNIX) Destination hosts: name of the remote server (from your instructor) When you save your input, a short name is generated automatically.

2.2 To print the list of output devices, run transaction SPAD and choose Output


devices. Then choose Output device → Print this list. Specify output device REMOTE. As spool options, do not select Print immediately and do not select Delete after output. Choose Continue. A spool request is generated by the system. Note the spool request number given in the status bar. To monitor the status of your spool request, call transaction SP01. Select your spool requests and choose Print directly for the spool request you created in this exercise.

3 Define a logical server and assign it to an output device 3.1 Choose Tools → CCMS → Spool → Spool administration (transaction

SPAD). Choose Spool Servers and switch to change mode using the pencil icon. Choose Create and maintain fields: Server name: enter LOGI Following text field: enter a short description Server class: test server or test print Logical server: check this box Mapping: select a real spool server Save this definition (choose Save).

3.2 For both output devices, do the following. Choose Tools → CCMS → Spool → Spool administration (transaction SPAD). Choose Output devices. From the displayed list, select the output devices LOCAL or REMOTE. Change the spool server assignment to LOGI. To classify the output device, choose Edit → Classification → Test print. If a warning about classification mismatch appears, check the classification of the spool servers. Save the settings.

3.3 See solutions 1.3 and 2.2. 4 Manage spool and output requests 4.1 Use transaction SP01 or choose System → Services → Output controller.

The initial screen enables you to choose either spool requests or output requests.

4.2 From the list of spool or output requests, select an item and choose Display contents.

4.3 Mark one spool request from the list and choose Print with changed parameters. The print parameters are displayed. Specify the Number of copies as 2, and then choose Print. Check the status of your output request. Select the spool request you just printed and choose Output requests. All the output requests generated for the selected spool request are displayed. To display the status description, double-click one of the output requests in column Status.

4.4 Mark the spool request you printed in step 4.3 and choose Request attributes. To display the number of copies, select tab Output attributes.

4.5 Specify the Number of copies as 2. Save the spool request. 4.6 Mark all the spool requests from your list and choose Delete. To confirm the

deletion, choose Yes (for 1 spool request) or Delete all.

© SAP AG 1999








Spool and Print - NT


© SAP AG 1999

Spool and Print

ContentsSpool System overviewManaging printers and access methodsLogical Spool ServerManaging spool requests


Describe the functionality of the R/3 Spool SystemDefine output devices for local, remote, andfrontend printingDefine and make use of logical spool serversManage spool and output requests


© SAP AG 1999

Information Flow

HelloWorld

R/3 System

R/3Spool System

Operating System spoolHello

World

TemSe

Document

User action Create document

Print

Output

Output Request


The R/3 System recognizes several classes of documents (for example, SAPscript texts or report lists) that can be printed.

When a request is made to print a document, a spool request is created. A spool request has two parts:

Administrative information (origin, date, author name, logical printer) is stored in the R/3 database

The data to be printed is stored in a repository called the temporary sequential database (TemSe). The R/3 Spool System uses generic representations of printer formatting commands and the R/3 internal character set to represent the characters to be printed.

TemSe data can be stored inside the R/3 database or at operating system level. Profile parameter rspo/store_location (see SAP Note 20176) determines where TemSe is located:

db stores the data in the database (default)

G stores the data in an operating system file in the global directory

The preparation of a spool request for printing is an output request. In R/3, you can either print immediately (an output request is generated immediately) or delay printing (the spool request does not lead immediately to an output request). A spool can correspond to several output requests. These can be sent to different output devices.

Usually (but not in certain printing scenarios), the R/3 System generates a device-specific, print-ready output stream, which is sent via an operating system spooler to a printer.


© SAP AG 1999

Access Methods: Local Printing


S S ... D

Dispatcher

C Lor

Physicallylocal

Physicallyremote

Printserver

OS spool

You can configure your R/3 instance to run multiple spool work processes. This affects sequential request processing. See SAP Note 108799.

Output requests are usually sent to the spool server in the order they were created, but if more than one spool work process is configured, the requests may be printed in a different order.

If necessary, you can specify that output requests are transmitted to the host spool system in the order they were generated. This option causes request processing for this device to be restricted to a single work process within the spool server. A spool work process is temporarily reserved for this device, and all output requests for this device are stored in an internal queue in the reserved work process. Once the internal queue has been processed, the reserved work process is released.

There are various methods an R/3 Spool System can use to access an operating system spooler.

Local printing The operating system spooler runs on the same host as the R/3 spool work process.

In Windows NT systems, the spool work process uses operating system calls to pass output to the printer manager using the Windows NT API (access method C).

In UNIX systems, the output request is passed to the operating system spooler using UNIX commands, for example lp or lpr (access method L). The form of the command is specified in the R/3 System profile.

Local printing is the fastest and most reliable way of printing in R/3. Local printing does not mean that the printer is physically attached to the host running the R/3 spool work process. The operating system spooler can print on either a locally or remotely attached printer.


© SAP AG 1999

Access Methods: Remote Printing

Networkprinter

UNIX

U OS spool

Printserver

WinPC

OS spool

Printserver

saplpd


U

S S ... D

Dispatcher

S Uor

Remote printing When using remote printing, an R/3 spool work process passes the print-ready output stream to the operating system spooler on a different host. This data transfer requires moving the output stream across a network link. The operating system spooler can then print on either a locally or remotely attached printer.

Some printers haver their own operating system spooler. They can be directly attached to a network through a network card interface. They are called network printers, and can also receive output from R/3 (access method U).

In UNIX systems, the output stream is sent to a line printer demon lpd (access method U).

In Windows systems and other systems without an lpd, SAP provides the program saplpd, which receives the output stream and transfers it to the operating system spooler (access method S for a proprietary SAP protocol or U for the UNIX Berkeley protocol).

For performance reasons, the remote access methods are only suitable for LAN environments and require reliable communication partners.


© SAP AG 1999

Access Methods: Frontend Printing

Frontend PC

Printserver


SAP GUI

OS spool

S S ... D

Dispatcher

saplpd

F

Windows

others

Frontend printing Frontend printing allows R/3 users to send output to printers that are defined on their local frontend PCs (access method F). The spool administrator does not need to define these printers as output devices in R/3.

In Windows systems, the output is sent to program saplpd on the frontend PC. If saplpd is not running, it is started automatically.

In other systems (UNIX, Macintosh, ...), the output is passed to the operating system spooler.

As of Release 4.6A, all spool processing takes place in a spool work process. The spool work process waits until the output has been sent to the frontend before it continues to process other requests. Therefore, performance problems can occur when frontend printing is used.

You can set an upper limit to the number of spool work processes used for frontend printing using parameter rdisp/wp_no_spo_Fro_max. The default value of the parameter is 1.

Frontend printing only works as long as there is an active connection to the frontend PC. Therefore, frontend printing cannot be used in background processing.

For more information on frontend printing and release dependencies, see SAP Collective Note 114426.


© SAP AG 1999



Running your system






Use the System Administration Assistant to start transaction SPAD(Spool administration)

To start the spool administration transaction SPAD, use the System Administration Assistant. Alternatively, choose Tools → CCMS → Spool → Spool administration.


© SAP AG 1999

Creating a New Output Device

Local Remote Frontend

DeviceAttributesDevice type Set to match Set to match SWINSpool server Choose one Choose one -

HostSpoolAccMethodAccess method C (NT) or L (UNIX) S or U FHost printer OS printer name OS printer name _ _DEFAULTHost name Fixed - -Destination hosts - Decide -

To create a new output device, select Output devices. The fields are as follows.

Output device: The logical printer name is case-sensitive and can be up to 30 characters long.

Short name: The name the system uses to access the printer. It can be generated automatically.

Device type: The type of printer. For frontend printing in Windows systems, the device-independent printer driver SWIN can be used to shift processing from R/3 to the frontend PC.

Spool server: The R/3 application server (or logical spool server) that formats the output requests. This entry is not needed for frontend printing.

Access method: Specifies the data transfer method to the host spooler.

Host printer: The name of the printer defined at the OS level. In Windows systems, no spaces are allowed in the name and, for frontend printing, __DEFAULT accesses the default printer defined for the frontend PC. For frontend printing in other operating systems, a printer called __DEFAULT must be configured on the frontend PC.

Host name: For local printing only. Generated automatically and depends on the spool server.

Destination hosts: For remote printing only. The name of the host on which the lpd or the saplpd is running. If the printer is a network printer, the Microsoft UNC name from Windows Print Manager can be used (for example, \\P21939\P42).

If you need to perform sequential request processing, choose Output atributes and select Sequential request processing.


© SAP AG 1999

Device Types

Choosing the right device type

A suitable device type is available in R/3

Download device type from sapserv server(see SAP Note 8928)

Use generic printer format (such as PostScript) or set mode to supported device type

Use device type SWIN

Write your own device type

Choose one of the following strategies to define a device type for your printer.

In the best case, there is already a device type for the printer you wish to use.

SAP offers a suitable device type that you can download from a sapserv server. See SAP Note 8928 for an up-to-date list of supported printers.

Most printers can be driven using a generic format (for example, PostScript) or can be switched to a mode that is compatible to a standard printer for which a device type is available in R/3.

Almost all printers are delivered with Windows printer drivers. You can drive these printers with the device-independent printer driver SWIN. In this case, processing is shifted from R/3 to the Windows Print Manager.

In the worst case, you must write your own device type (or modify a copy of an existing device type). This is not advisable unless you are an expert in R/3 Spool System and printer driver code. In this case, it may be better to obtain a supported printer.


© SAP AG 1999

Logical Spool Servers

R/3 System



twdfmx03_DEV_01

Log_Prod B

Test 1

Test 2

Prod 2

Log_Prod AProd 1

Gulp

P

P

T

T

P

P

T T

P

T: Test printP: Production print

An output device can be allocated directly to a real spool server, which is an R/3 instance offering at least one spool work process.

Logical spool servers introduce an extra layer in the spool server architecture. Logical spool servers open up a wide range of further possibilities.

A logical spool server can be mapped to a real spool server or to another logical spool server.

A logical spool server can be used instead of a real spool server in R/3. For example, an output device can be allocated to a logical spool server as well as a real spool server.

Logical spool servers open up a wide range of further possibilities, such as:

Spool server switchover

Workload balancing

Transporting the printer architecture

Both output devices and spool servers can be classified for certain print jobs, for example test prints or production prints.


© SAP AG 1999

Creating a Logical Spool Server

Server class

Mapping

Class

Classify your printers and spool servers, and keep them separate:

High volume print

Production print

Test print

Logical flag

To create a new output device, select Spool servers. The fields are as follows.

Server name: The name of the logical spool server, as defined in R/3. It is case-sensitive.

Server class: The classification for print jobs.

Logical server: Identifies the spool server as a logical spool server.

Mapping: The name of the real or logical spool server that your logical server is mapped to.

Separate the spool printers and servers for the different kinds of print job:

High volume print (for example, cost-center lists)

Production print (for example, documents or cover letters)

Desktop print (for example, SAPoffice documents)

Test print

The reason for this is that a spool work process can only process one output request at a time.

To classify an output device, call transaction SPAD, choose Output devices, select the output device you want to change, then choose Edit → Classification.


© SAP AG 1999

Feature 1: Spool Server Switchover

Alternative

R/3 System



Test 2

Test 1

twdfmx03_DEV_01

Spool server switchover When creating a real or logical spool server, you can define an alternative spool server. If the normal spool server becomes unavailable, R/3 switches all the devices using this spool server to the alternative.

For this strategy to function, you must ensure that all the printers can be driven in the same way by all the spool servers involved. For example, using the local printing, you need to ensure that the same printer names appear at the operating system level of the hosts for all the real spool servers that can serve as alternatives. In the graphic, if output device Test 1 points to the printer with operating system name P42, then the printer name P42 must be listed in both servers twdfmx03_DEV_00 and twdfmx03_DEV_01.


© SAP AG 1999

Feature 2: Workload Balancing

Load comparison

R/3 System

Log_Test


Test 2

Test 1 twdfmx03_DEV_00

twdfmx03_DEV_01

Workload balancing When an alternative spool server is defined for a spool server, you can allow load balancing (load comparison). The load on a spool server is calculated from the number of spool work processes, of output requests, and of pages.

Load balancing can be activated independently for each logical or real spool server. If an output request is generated for a spool server where load balancing is active, the system searches both the mapping and the alternate definition of that server to find the spool server with the least load. The selection algorithm is recursive: as the system checks the mapping and alternate defined server hierarchies, it applies the selection rules to each level.

Sequential request processing has priority over the load balancing option for spool servers. Therefore, if a device is configured for sequential processing and it is assigned using load balancing to a spool server, load balancing is ignored for output requests generated for that device.


© SAP AG 1999

Feature 3: Transporting the Printer Architecture

R/3 System DEV

Log_Test

Prod 2

Prod 1

twdfmx03_DEV_00

Volume Log_Vol

R/3 System QAS

Log_Test

Prod 2

Prod 1

twdfmx04_QAS_00

Volume Log_Vol twdfmx04_QAS_01

Transporting the printer architecture Logical servers provide a uniform method for defining and transporting a complete printer architecture with minimal changes.

The graphic shows that a printer architecture can be transported from an R/3 development system to a quality assurance system. All the output devices and logical spool servers from the development system are transported to the quality assurance system.

To activate printing in the target system, you only need to change the mapping in each logical spool server definition for the new R/3 System environment.

Transaction SPAD provides functions for transporting both output device definitions and spool server definitions.


© SAP AG 1999

Selecting Spool or Output Requests

To display spool or output requests, call transaction SP01 or choose System → Services → Output controller

The initial screen offers a wide range of selection criteria. You can customize it to show just the selction criteria that interest you, or you can chooose a standard set of selction criteria.

As of Release 4.6A, you can also display spool or output requests from other R/3 Systems. To do so, enter a valid RFC destination in System name. If you clear the field and leave it empty, all the systems in table ALCONSEG (which lists all the systems selected for remote monitoring in transaction RZ20) are addressed.


© SAP AG 1999

Monitoring Spool and Output Requests

Log Info

Status

The displayed list shows the status of the spool or output requests that meet your selection criteria. The ABAP List Viewer (ALV) is used to display this list and enables you to store multiple display variants.

The status of a spool request is one of the following:

- : no output request for this spool request

Proc. : a spool work process is processing the corresponding output request

Waiting : a spool work process is waiting for a return code from the operating system spool

Compl. : the corresponding output request(s) has (have) been printed successfully

Error : the corresponding output request(s) has (have) not been printed successfully

<F5> : the corresponding output requests have different statuses

To navigate from a spool request to its output requests, double-click on its status. To navigate from several spool requests to their output requests, select their lines and click the Output request icon.

A log is written for every unsuccessful output request. You can use the log for error analysis.


© SAP AG 1999

Maintaining the Spool Database

Delete old spool requests


Offline, schedule regularly:

Check spool database consistency


Offline, schedule daily:

Spool Database

TemSe

Output Request


RSPO1043RSPO1041

You must define a regular schedule for maintaining your R/3 spool database. Regular maintenance tasks include deletion of old spool requests and checking the consistency of the spool database.

To delete old spool requests, run ABAP program RSPO1041 with a suitable variant regularly as a background job. See SAP Note 130978.

To perform spool database consistency checks, run ABAP program RSPO1043 with a suitable variant every day (including Sundays and holidays) as a background job. See SAP Note 98065.

In exceptional situations, you can also perform these maintenance tasks online (but with limitations) using transaction SPAD.


© SAP AG 1999

Authorizations 1


Spool action(S_SPO_ACT)

BASE List spool requestsPRNT Print onceREPR Repeat printingREDI RedirectDELE Delete manuallyDSIP DisplayAUTH Change authorizationATTR Change attributes

SPOAUTH Value Value for which the user is authorized.This value must match the authorizationfield in the spool request.

SP01 Administration of spool requests (all clients)

SP0R Same as SP01 (own client)SPAD Spool administration (all clients)SPAR Client-dependant spool administrationSPAA Define output deviceSPAB Define real and logical OMSSPAC Maintain device types and related objectsSPAM Administration of spool requests

all clientsSPTD TemSe administration (all clients)SPTR Same as SPTD (own client)

SPOACTION

Systemauthorization

(S_ADMI_FCD)

S_ADMI_FCD

End users have full control over their spool requests in the output controller.

Spool administrators can manage all spool requests through authorization objects S_ADMI_FCD and S_SPO_ACT.

Authorization object S_ADMI_FCD allows the administrator to perform different management tasks, such as spool request administration and output device administration.

Authorization object S_SPO_ACT specifies what actions you can perform on which spool requests. For example, SPOACTION = BASE, DISP and SPOAUTH = xyz allow you to list and display all spool requests with the authorization field xyz.

As of R/3 Release 4.0, a spool request has its owner's user ID as default value for the authorization field. Therefore, all spool requests are implicitly protected.


© SAP AG 1999

Authorizations 2


Device authorization(S_SPO_DEV)


SPOPAGES Value Number of pages permitted


SPODEVICE

Maximum numberof pages

(S_SPO_PAGE)

S_ADMI_FCD

Use authorization object S_SPO_DEV to limit printer access by name.

Authorization object S_SPO_PAGE specifies the maximum number of pages a user can print on a particular output device. To activate this authorization object, set parameter rspo/auth/pagelimit to 1 in the instance profile. Once the authorization object is activated, all users must have S_SPO_PAGE authorization to be able to print.


© SAP AG 1999

Now you are able to:Describe the function of the R/3 Spool System

Define output devices for local, remote, and frontend printing

Define a logical spool server and use it on an output device

Manage spool and output requests



© SAP AG 1999


SAP Online Documentation:

BC Printing Guide

SAPNet Alias output

Basis Course:

Advanced System Administration (BC305)


For a complete list of spool request statuses, see the SAP Online Documentation:

BC Printing Guide

For information on the R/3 Spool System, see SAPNet, alias output

Basis Course Advanced System Administration (BC305) provides further information on the areas of extended and full administration in transaction SPAD.


© SAP AG 1999

Unit Actions

Exercises?

Solutions



Spool and Print: Exercises

No. Exercise 1 Define a local R/3 printer 1.1 Check which printers are configured at the operating system level of your

application server.

1.2 Within R/3, create an output device LOCAL that prints locally to one of the printers that are configured on your application server.

1.3 Submit an output request to the output device LOCAL: print the work process overview (an output request should be created immediately). Monitor your spool and output request.

2 Define a remote R/3 printer For this exercise, your instructor should give you the name of an operating system spooler on a remote server.

2.1 Within R/3, create an output device REMOTE that prints remotely to the named spooler.

2.2 Submit a spool request to the output device REMOTE: print the list of output devices (output request should be triggered manually). Monitor your spool request and submit an output request.

3 Define a logical server and assign it to an output device 3.1 Create a logical spool server LOGI and map it onto a real spool server. Do

not specify an alternative and do not select load distribution. Classify LOGI as a test server.

3.2 Change the definition of the output devices LOCAL and REMOTE to classify them as test printers and assign spool server LOGI to them.

3.3 Using the steps described in exercises 1.3 and 2.2, submit an output request to both printers, and check that the output is correct.

4 Manage spool and output requests 4.1 Display all of your own spool and output requests.

4.2 Display the contents of a spool request.

4.3 Print 2 copies of one spool request from the list. Display all output requests generated for the spool request that you just printed and check their status.

4.4 Display the attributes of the spool request printed in step 4.3. Check that the number of copies for the spool request is still 1.

4.5 Change the attributes of the spool request printed in step 4.3 to specify a default of 2 copies.

4.6 Delete all of your own spool requests.


Spool and Print: Solutions

No. Solution 1 Define a local R/3 printer 1.1 To check which printers are configured at the operating system level on your

application server:

In Windows NT systems, choose Start → Settings → Printers (the group currently connected with pcANYWHERE). In LINUX systems, enter command lpc status.

1.2 Choose Tools → CCMS → Spool → Spool administration (transaction SPAD). Choose Output devices and switch to change mode using the pencil icon. Choose Output device → Create. As output device, enter LOCAL and maintain fields: Select tab DeviceAttributes and fill out fields: Device type: set to match with the definition on operating system Spool server: select a real spool server running on your application server Select tab HostSpoolAccMethod and fill out fields: Access method: C (Windows NT) or L (UNIX) Host printer: name of printer at operating system level (case-sensitive in UNIX) When you save your input, a short name is generated automatically.

1.3 To print a work process overview, run transaction SM50 and choose System → List → Print. Specify output device LOCAL and as spool option choose Print immediately. Do not select Delete after output. Choose Continue. A spool request is generated by the system. Note the spool request number given in the status bar. To monitor the status of your spool and output request, call transaction SP01 and select all spool and output requests for your user.

2 Define a remote R/3 printer For this exercise, your instructor should give you the name of an operating system spooler on a remote server (defined on a server of another group).

2.1 Choose Tools → CCMS → Spool → Spool administration (transaction SPAD). Choose Output devices and switch to change mode using the pencil icon. Choose Output device → Create. As output device, enter REMOTE and maintain fields: Select tab DeviceAttributes and fill out fields: Device type: set to match with definition on operating system Spool server: select any real spool server running on your application server Select tab HostSpoolAccMethod and fill out fields: Access method: Windows NT: S or U (saplpd must run on remote host) (to start saplpd, choose Start → Programs → SAP Frontend → SAPlpd) UNIX: U


Host printer: name of printer at operating system level (case-sensitive in UNIX) Destination hosts: name of the remote server (from your instructor) When you save your input, a short name is generated automatically.

2.2 To print the list of output devices, run transaction SPAD and choose Output devices. Then choose Output device → Print this list. Specify output device REMOTE. As spool options, do not select Print immediately and do not select Delete after output. Choose Continue. A spool request is generated by the system. Note the spool request number given in the status bar. To monitor the status of your spool request, call transaction SP01. Select your spool requests and choose Print directly for the spool request you created in this exercise.

3 Define a logical server and assign it to an output device 3.1 Choose Tools → CCMS → Spool → Spool administration (transaction

SPAD). Choose Spool Servers and switch to change mode using the pencil icon. Choose Create and maintain fields: Server name: enter LOGI Following text field: enter a short description Server class: test server or test print Logical server: check this box Mapping: select a real spool server Save this definition (choose Save).

3.2 For both output devices, do the following. Choose Tools → CCMS → Spool → Spool administration (transaction SPAD). Choose Output devices. From the displayed list, select the output devices LOCAL or REMOTE. Change the spool server assignment to LOGI. To classify the output device, choose Edit → Classification → Test print. If a warning about classification mismatch appears, check the classification of the spool servers. Save the settings.

3.3 See solutions 1.3 and 2.2.

4 Manage spool and output requests 4.1 Use transaction SP01 or choose System → Services → Output controller.

The initial screen enables you to choose either spool requests or output requests.

4.2 From the list of spool or output requests, select an item and choose Display contents.

4.3 Mark one spool request from the list and choose Print with changed parameters. The print parameters are displayed. Specify the Number of copies as 2, and then choose Print. Check the status of your output request. Select the spool request you just printed and choose Output requests. All the output requests generated for the selected spool request are displayed. To display the status description, double-click one of the output requests in


column Status.

4.4 Mark the spool request you printed in step 4.3 and choose Request attributes. To display the number of copies, select tab Output attributes.

4.5 Specify the Number of copies as 2. Save the spool request.

4.6 Mark all the spool requests from your list and choose Delete. To confirm the deletion, choose Yes (for 1 spool request) or Delete all.

© SAP AG 1999








Installation Check - UNIX


© SAP AG 1999

Installation Check

Contents:Operating System UNIX

Installation requirementsOperating system security and performance

Database OracleInstallation requirementsDatabase security and performance

R/3 SystemRelease and System nameBasis parametersDirectory structureTransport management systemTransport route configuration


© SAP AG 1999

Installation Check


Check that the installation requirements are metCheck that the minimum hardware requirements are metCheck that the database requirements are metAnalyze the profile configurationDescribe the R/3 directory structureCheck the transport management system configurationConfigure the transport routesBack up the R/3 installation


© SAP AG 1999

Installation Check: Part 1

Operating System UNIX

UNIX


© SAP AG 1999

Installation Prerequisites

Requirements

Ensure the requirements in the installation checklist are metConsult hardware partners for sizing

SupportedOS versionOS patchesC compilermake utilitiesKernelconfigurationAdditionalsoftware

SoftwareTCP/IPconfigurationHostnameNetwork filesystem (NFS)Networkinformationsystem (NIS)

Network FrontendsCertifiedhardwareNumber ofprocessorsMemoryDisk spaceHighavailability

Hardware

When you plan an installation, you must ensure that the minimum requirements in the installation checklist provided by SAP are met. This installation checklist is contained in every installation package and can be ordered through SAPNet.

Installation requirements for frontends are contained in a separate installation checklist.

For detailed network information, refer to the manual Integration of R/3 Servers in TCP/IP Networks and to installation checklists for supported and required network products.

For detailed R/3 release information, log on to SAPNet - R/3 Frontend and look in the component XX-SER-SWREL.

The task of sizing is usually performed by SAP hardware partners, who must consider both the SAP recommendations and their own hardware specifications.


© SAP AG 1999

Check Assistance

UNIXOperating system security and performanceDisk layout

Mirroring

UNIX backup

Network layoutWorkload

Security

Dedicated host for R/3

Dedicated file or print servers

These operating system and network aspects must be considered during hardware sizing.

There are various administration tools you can use to check the server configuration, depending on the manufacturer.

To ensure that the minimum requirements are met, SAP delivers a check assistance list for each UNIX platform.


© SAP AG 1999


Oracle Database


© SAP AG 1999

Technically Correct Installation: Requirements

Database version

Database name

Directory names

Mirrored redo log files

Disk layout

Oracle database

The Oracle database version must be released for the current version of the operating system. For release information, go to SAPNet - R/3 Frontend and look under component XX-SER-SWREL Release planning. This installation check list also specifies which versions of the operating system and database can be used together.

The database name must be identical to the R/3 System identification (SID). The name assigned to the database at installation cannot easily be changed.

The naming convention for the Oracle database also cannot be changed. Database programs and R/3 programs refer to this fixed naming convention for file directories.

The redo log files (online log files) must be mirrored.

Certain restrictions apply to the physical location of the Oracle file directories. For example, redo log files, archive files, and data files should not be located together on the same physical disk.


© SAP AG 1999

Technically Correct Installation: Profiles

R/3 profiles:init<SID>.dbainit <SID>.sap

Oracle profile:init<SID>.ora

Oracle Net8 files:tnsnames.oralistener.orasqlnet.ora

Oracle database

The Oracle database profile is init<SID>.ora. This profile is configured with standard values during installation.

To ensure network and process communication for Oracle SQL*NET V8, the following files are required:

On the database server site:

- listener.ora: containing configuration information for the Oracle listener thread

On each database client site:

- tnsnames.ora: containing the connect parameters for the database client processes

- sqlnet.ora: containing administrative information for database client processes

- protocol.ora: containing the switch for tcp.nodelay (optional)

The profile init<SID>.sap contains all the information needed for backing up the database. This profile also is configured with the standard values during installation.

The profile init<SID>.dba is a parameter file for the R/3 program SAPDBA. This program is used for Oracle database administration.

Certain parameters must be set during installation for each of these profiles. However, the profiles can be adjusted later, as required.


© SAP AG 1999

Oracle Directory Structure

Server site

dbs bin network/admin

ORACLE_HOMEoriglogB

mirrlogB

sapdata<n>

sapbackup

sapreorg

...

sapdata1

origlogA

mirrlogA

saparch

sapcheck

saptrace

SAPDATA_HOME

Client site

ORACLE_HOME

network/admin

Unix environment variables: <sid>admORA_NLS: $ORACLE_HOME/ocommon/NLS_723/admin/dataORA_NLS32: $ORACLE_HOME/ocommon/NLS_733/admin/dataORA_NLS33: $ORACLE_HOME/ocommon/NLS_805/admin/data ora<sid> (ORA_NLS and ORA_NLS32 see above)ORA_NLS33: $ORACLE_HOME/ocommon/nls/admin/data

The Oracle database file tree structure on the database server site has 2 main branches:

The Oracle binaries are located in the subdirectory bin in the ORACLE_HOME directory. The ORACLE_HOME directory is also required on each server with a database client

The environment variables SAPDATA_HOME point to the directories containing database-specific files, such as data files, online redo log files, and offline redo log files.

In addition, the operating system user <sid>adm requires the following environment variables:

ORACLE_SID = <SID>

DBS_ORA_TNSNAME: set to the database identifier <SID> from tnsnames.ora

In a UNIX environment, the following environment variables are set by R/3 configuration tools:

ORA_NLS: $ORACLE_HOME/ocommon/NLS_723/admin/data

ORA_NLS32 $ORACLE_HOME/ocommon/NLS_733/admin/data

ORA_NLS33: $ORACLE_HOME/ocommon/nls/admin/data (user ora<sid>)

TNS_ADMIN: $ORACLE_HOME/network/admin


© SAP AG 1999

Example 1: Minimal Disk Layout

Paging file

OriglogBMirrlogA

SAPDATA1-N

SAPARCH

Disk 5Disk 5

Disk 4Disk 4

Disk 3Disk 3

Disk 1Disk 1

OriglogAMirrlogB

Disk 2Disk 2 Disk 6Disk 6

Disk ..Disk ..

Disk NDisk N

Non-Critical Directories

/usr/sap/<SID>/usr/sap/trans/oracle/<SID>/oracle/<SID>/sapreorg



This example shows a database disk configuration without mirrored disks.

Redo log files must be mirrored. To do this, you can use either Oracle or operating system tools or by working on RAID 1 disk systems. To ensure the highest level of security, use the Oracle tools.

This example also shows that the operating system paging file, the redo log files, the archive log files, and the Oracle data files are all located on disks that are physically separated.

When dividing the Oracle file systems between the various hard disks, it is important to remember that file systems with a high I/O load (such as redo log files) should reside on disks distributed over several controllers. For further information, see the Installation Guide.


© SAP AG 1999

Example 2: High Availability RAID Disk Layout

Disk 1�Disk 1�

Oracle database

Paging file

Disk 1Disk 1





Disk 5�Disk 5�

OriglogB

SAPARCH

Disk 3Disk 3

OriglogA

Disk 2Disk 2

Disk 5Disk 5

Disk 4Disk 4

MirrlogAMirrlogB

SAPDATA1-N

Disk NDisk N

Disk ..Disk ..

Disk N�Disk N�

Disk ..�Disk ..�

Disk 7Disk 7

Disk 6Disk 6

Disk 7�Disk 7�

Disk 6�Disk 6�

This example shows a database disk configuration using mirrored disks. Every disk containing R/3 or Oracle database directories is mirrored. The mirroring is performed using:

RAID 1: for the OS paging file, the saparch directory, and the sapdata directories

Database mirroring: for the online redo logs

You can also configure the database so that each hard disk is mirrored with operating system, using a combination of RAID 1 and RAID 5 technology. For example:

RAID 1: for OS paging file

RAID 5: for saparch and sapdata directories

When using RAID technology, intelligent RAID controllers should be used, such as a controller with a read/write cache.

For further information about database configurations, see:

The Installation Guide

BC505 Database Administration Oracle


© SAP AG 1999

Database Security

Oracle database Database user passwords

Database backup

Archive mode

SAPDBA password

To ensure databases security, the following database user passwords must be changed at R/3 installation:

User SYSTEM

User SAPR3

User SYS

The R/3 database administration tool sapdba should be also used with a password.

An R/3 System database must be backed up regularly and the database backups must be monitored. Ensure that an effective backup strategy is implemented.

It is important that the Oracle database is run in ARCHIVELOG mode.


© SAP AG 1999

Database Performance

Oracle database Location of tablespaces

Location of index and data files

DB log files vs. paging file

The physical location of the data files of the Oracle database can affect the performance of the database. One Oracle tablespace can be spread over one or several physical data files.

Ensure there is enough free disk space to allow the tablespaces to expand.

Depending on the applications and the use of your R/3 System, certain tablespaces should be allocated their own disk partitions. For further information, see the Installation Guide.

Data and index tablespaces should not be stored on the same physical unit.

If there is enough disk space available, tablespace PSAPSTABD and tablespace PSAPBTABD should be located on separate physical disks. Their associated index tablespaces should also be stored on separate physical disks.

Do not use RAID 5 for the Oracle online redo log files, the saparch directory, or the data files of tablespace PSAPROLL.

Data files must not be located together with the offline redo log files, the operating system paging file, or the online redo log files.


© SAP AG 1999


R/3 System


© SAP AG 1999

R/3 Release and System Name

R/3 ReleaseReleased by SAP for specific operating systemand database versions

R/3 System nameMust be unique in the system landscapeMust consist of three alphanumeric characters,the first being a letterMust use uppercase lettersMust be identical to the database SIDCannot be any of the reserved R/3 System names

The R/3 Release must be approved and released by SAP for the specific operating system and the database versions in this combination. The R/3 Release information is available from SAPNet - R/3 Frontend in the component XX-SER-SWREL.

When you assign a name to your R/3 System, you must follow the R/3 System naming conventions:

The R/3 System name must be unique in the system landscape

Three alphanumeric characters must be used, the first character being a letter

Uppercase letters must be used

The R/3 System name must be identical to the database SID

You cannot assign the following names to your R/3 System, as they are reserved:

ADD ALL AND ANY ASC B20 B30 BCO BIN COM DBA END EPS FOR GID INT KEY LOG MON NOT OFF OMS P30 RAW ROW SAP SET SGA SHG SID UID VAR

Choose your R/3 System name carefully. Renaming the system is complicated, and requires you to reinstall the R/3 System.


© SAP AG 1999

R/3 Basis Parameters

UNIX kernel and swap spaceCheck list OS dependencies

Check tool memlimits

R/3 memory managementCheck tool sappfpar

R/3 profile parametersTransaction RZ10

To check the UNIX kernel parameters relevant for R/3 and the swap space, you should refer to the check list OS dependencies. You can also use the R/3 tool /usr/sap/<SID>/SYS/exe/run/memlimits. This tool checks the following parameters:

Maximum heap size (maximum data segment per process)

Maximum mapped file size

Maximum protectable size

Maximum address space per process

Total available swap space

To check the minimal requirements for the R/3 memory management, run /usr/sap/<SID>/SYS/exe/run/sappfpar check pf=/usr/sap/<SID>/sys/profile/<instance_profile>. This is a very useful tool, especially if problems occur during R/3 System startup.

To check R/3 parameters in general, use transaction RZ10, select the profile to be checked, and choose Check.


© SAP AG 1999

R/3 Directory Structure

Global directories Instance directories

SYS <Instance_name>

logwork dataglobalexe profile

run dbg opt

trans tmp put

usr

sap

<SID>

<sapmnt>

<SID>

exe profile global

= Symbolic link

This graphic displays the global and instance specific R/3 file system view of a homogenous R/3 System.

Global files can be managed centrally on the central instance host, using the network file system (NFS) <sapmnt>/<SID>.

<sapmnt>/<SID> must be physically stored on the central instance host. It must also be exported explicitly as NFS in read/write mode to all dialog instance hosts and in read-only mode to all UNIX presentation servers.

To run dialog instances with executables stored locally on the dialog instance host, activate program SAPCPE.

The global transport directory /usr/sap/trans must be accessible by every R/3 instance belonging to one system landscape. This access is achieved through a soft link that points to the transport directory or through mounting the file system /usr/sap/trans using NFS.

Installing a heterogeneous R/3 System requires a different file system, which is described in the installation and OS dependencies guide.


© SAP AG 1999

R/3 Instance Numbers

TCP/IP file /etc/services

Required entries for R/3:

Dispatcher port for instance number 00-99

sapdp<Instance_number> 32<Instance_number>/tcp

Gateway port for instance number 00-99

sapgw<Instance_number> 33<Instance_number>/tcp

Message server port

sapms<SID> 36<Instance_number>/tcp

The assignment of the R/3 instance number is important. This number is fixed as part of the installation. The TCP/IP connection to the R/3 System(s) depends on this instance number, as does the connection from the frontend devices to the R/3 System(s). Therefore, you cannot run two R/3 Systems with different SIDs that have the same instance numbers on the same host. This is also important if an R/3 System group and/or several application servers are operating.

Assigning system numbers in a structured and careful way helps to ensure a technically clear system landscape.

The TCP/IP socket port entries must be the same for all R/3 instances, R/3 database servers, and all R/3 front end devices.

These entries are made in the file /etc/services. Normally, these entries are made automatically as part of the installation.

The following entries are reserved for R/3 service programs, and may not be used as R/3 System numbers:

sapgw97 (3397/tcp) SAP R/3 Frontend

sapgw98 (3398/tcp) SAPconnect

sapgw99 (3399/tcp) SAP EPS

sapdp99 (3299/tcp) SAProuter


© SAP AG 1999

Transport Management System Setup Process

Transport domain & domain controller

Configuration of tp

Transportroutes

Before you can work with the transport management system (TMS), it must be configured on all R/3 Systems in your system landscape.

The TMS configuration includes the following steps:

Configuring the transport domain: You must define which R/3 Systems in the system landscape should be combined in a transport domain and which R/3 System is to be the transport domain controller

The transport control program 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 operating system functions.

Configuring the transport routes: The transport routes are used to define in which target system you want to consolidate and deliver change requests.


© SAP AG 1999

Transport Domain

Transport domain:DOMAIN_QAS

Common transport directory Transport group:GROUP_DEV

Domain controller

DEV

QAS

PRD

Backup controller

The current status of the transport domain configuration for each R/3 System in the transport domain is displayed in the TMS System Overview. The overview also shows whether the configuration is up-to-date and if any errors occurred when the configuration is distributed. To display the TMS System Overview, call transaction STMS and choose Overview → Systems.

In a transport domain, the R/3 System, which is configured as the domain controller, is of special significance. If this R/3 System fails, no changes can be made to the TMS configuration. Therefore, it is recommended that you configure a backup domain controller.

Once you have planned your system infrastructure, you will generally not install all planned R/3 Systems at the same time. TMS allows you to configure these R/3 Systems as virtual systems of the transport domain. Therefore, you can configure the transport routes of your entire system infrastructure.


© SAP AG 1999

Common Transport Directory

Transport file forUNIXglobal parameters...system-specificparameters...

/usr/sap/trans

sapnamescofilesbufferlog

databin tmp

actlogolddata

EPS

Parameter file fortransport control

program tp

Directory /usr/sap/trans

Global transport directory for all R/3 instances in a transport domain

NFS mount: /usr/sap/trans

Transport file is generated during setup of TMS and parameters can bedisplayed in TMS

The transport control program 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 operating system functions. This transport file is located in the subdirectory bin of the directory /usr/sap/trans. Naming convention: TP_<domain name>.PFL.

To check the availability of the transport control program in an R/3 System, use Transaction STMS (System overview). Choose R/3 System → Check → Transport tool. A hierarchical list is displayed that shows the status of the individual checks. If you have not selected an R/3 System, the transport control program of all R/3 Systems in the transport domain is checked.

To display the tp parameters of an R/3 System, in the STMS System Overview double-click on one R/3 system and select tab Transport tool. A list is displayed showing the parameters set in transport profile.

To check the availability of the transport directory program in an R/3 System, call transaction STMS (System Overview) and choose R/3 System → Check → Transport directory. Test files are created in the subdirectories of the transport directory and in the last step of the check removed.


© SAP AG 1999

Transport Routes

Transport strategy defined by transport routes

Standard transport route used by all customizingchange requests

Additional transport routes can be established fordevelopment objects

Multilevel delivery: delivery routes can be chained

The configuration of the transport routes is managed in the R/3 System, which serves as the transport domain controller, and can be distributed to and activated in all other R/3 Systems connected in the transport domain.

Before you can configure the transport routes, the following requirements must be met:

The transport domain must be configured

All R/3 Systems involved must be included in the transport domain

The transport control program must be configured (is done automatically during the above steps)

The transport route configuration consists of:

System attributes

Consolidation routes

Delivery routes


© SAP AG 1999

R/3 Network Configuration

DatabaseC11

Database server dbserver

Application server A3



Central instance DVEBMGS00

Instances D00 and D01Instance D00 InstancesD00 and

D01

SAPGUI presentation server

RDBMS

R/3 System C11R/3 System C11

For performance reasons, there should be no access from the frontend devices to the database host. To install the message server on a host that is different than the database host, define the following parameters in the file DEFAULT.PFL:

SAPDBHOST = <database server>

rdisp/mshost = <application server>

For medium and large-sized R/3 installations (distributed R/3 Systems), a dedicated physical sub-network should be installed for the communication between the R/3 servers, that is, between the database servers and application servers. This is necessary to support the high volume of data between the database and application servers with an appropriate network throughput (for example, FDDI).


© SAP AG 1999

Checking the Installation: Further Steps

Che

ckin

g th

e in

stal

latio

n Installation consistency: SM28

R/3 Kernel Patch Level: SM50

Buffer synchronization: ST02

R/3 System log correctly installed: SM21

Activate Performance Monitor: report RADDBDIF

SAP license installed: saplicense

Standard passwords of sap* and ddic

Remote access using SAPROUTER

Imported Hotpackages: SPAM

Imported languages: SMLT

Operating system dependent log files

To complete the installation, perform the following steps:

To check if the operating system, including the network is configured properly, use the operating system specific log files.

To check if the database structure fits the R/3 kernel structure, perform the R/3 installation consistency check (transaction SICK or SM28). This check ensures that the correct database versions and R/3 kernel versions are used and that there are no inconsistencies in the R/3 kernel.

Buffer synchronization. This is important for additional application instances.

For detailed information about the steps to be performed, see the installation guide and the online documentation.


© SAP AG 1999

Backing Up the R/3 Installation

DatabaseC11

RDBMS

R/3 directories

R/3 CCMS

Sapdba brbackup/brarchive

OS configuration

Once the installation is complete, the administrator must back up the following:

The root file system, which includes the system structure and all configuration files, such as:

File system size

Logical volume manager configuration

Database configuration data

The RDBMS file systems

- The initial backup can also include the data file systems.

The database

- This can be performed with the R/3 CCMS andbackup tools, such as SAPDBA, BRBACKUP, and BRARCHIVE. External backup tools can also be used if they support the interface BACKINT.

The following R/3 directories:

- /usr/sap/<SID>

- /<sapmnt>/<SID>

- /usr/sap/trans

A backup cycle should also be defined for the various file systems. Since the file system data does not change very quickly, the backup cycles can be longer than for the database.


© SAP AG 1999


Now you are able to:Check that the installation requirements are metCheck that the minimum hardware requirements are metCheck that the database requirements are metAnalyze the profile configurationDescribe the R/3 directory structureCheck the transport management system configurationConfigure the transport routesBack up the R/3 installation


© SAP AG 1999








Installation Check - NT


© SAP AG 1999

Installation Check: Contents

ContentsOperating System Windows NT

Installation requirementsWindows NT analysis toolsOperating system security

Database OracleInstallation requirementsDatabase security and performance

R/3 SystemDomain and security conceptsName resolution on Windows NTR/3 instance numbersChange and transport system


© SAP AG 1999

Installation Check: Objectives


Check that the installation requirements are metAnalyze the disk configurationAnalyze the network configurationCheck that the database requirements are metAnalyze the profile configurationDescribe the R/3 directory structureCheck the transport management system configurationPerform the R/3 intallation consistency checkBack up the R/3 installation


© SAP AG 1999


Operating SystemWindows NT


© SAP AG 1999

Installation Prerequisites

Requirements

Ensure the requirements in the installation checklist are metConsult hardware partners for sizing

NT US/InternationalversionService packResource kitAdditionalsoftware

SoftwareTCP/IPconfiguration(hostname)DomainconceptR/3 securityconcept

NetworkCertifiedhardwareNumber ofprocessorsMemoryDisk spaceHighavailability

Hardware Frontends

When you plan an installation, you must ensure that the minimum requirements in the installation checklist provided by SAP are met. This installation checklist is contained in every installation package and can be ordered through SAPNet.

Only installations on certified hardware using the US/International version of Windows NT are supported by SAP.

Installation requirements for frontends are contained in a separate installation checklist.

The task of sizing is usually performed by SAP hardware partners, who must consider both the SAP recommendations and their own hardware specifications.


© SAP AG 1999

Check Assistance

General checks

Windows NT Diagnostics

Disk configuration

NT Disk Administrator

Network configuration

Control panel → Network → TCP/IP configuration

Command HOSTNAME

There are several ways to check the NT configuration. One way is to use the Windows NT diagnostics tool, which is located in the Administrative Tools (Common) program group. You can also call this tool directly by entering command winmsd from a command prompt. The diagnostics tool displays almost all the information about the server.

To check the disk configuration, use the NT Disk Manager, which is located in the Administrative Tools (Common) program group. For R/3, all disks must be formatted with NTFS.

To check the TCP/IP configuration, open the Control Panel and choose Network → TCP/IP Protocol → DNS. To check the hostname, you can also enter command hostname at the command prompt.

The hostname and its IP address assignments are contained in file %windir%\system32\drivers\etc\hosts.

The NetBIOS assignments are contained in file %windir%\system32\drivers\etc\lmhosts.

The hostname is case sensitive and is used in the R/3 profile parameters. For further information, see SAP Note 23538.

If several network cards are installed on an R/3 Server, the administrator must ensure that every network card has an unique name and is maintained in the DNS settings and in the file %windir%\system32\drivers\etc\hosts.


© SAP AG 1999

Operating System Security: Registry Backup

NT registry

HKEY_...

Hardware & system configuration (disk/drivers)

Software configuration and start environment

User configuration

rdisk /s

ntbackup

Backup local registry

Create repair disk

Information about the NT configuration and installed applications is stored in the operating system database called the registry. The information is divided up and stored in five hives.

To protect this information, you can:

Back up the complete registry, with the NT tool ntbackup and flag set backup local registry:

Create a repair disk that you can use to repair a damaged registry (not a complete backup of the registry), with the NT tool rdisk. Information about users and access control lists (ACLs) is contained in a security hive. To back up also the security hive, use the NT tool rdisk with option /s. SAP recommends backing up the security hive.

To ensure a high availability of the operating system, you can install a second Windows NT on a different disk. This will enable you to start the server immediately, in dual boot mode, even in case of a disk crash on the default operating system disk.


© SAP AG 1999


Oracle Database


© SAP AG 1999

Technically Correct Installation: Requirements

Database version

Database name

Directory names

Mirrored redo log files

Disk layout

Oracle database

The Oracle database version must be released for the current version of the operating system. You can find release information in SAPNet under component XX-SER-SWREL Release planning. This installation checklist also specifies which versions of the operating system and database can be used together.

The database name must be identical to the R/3 System identification (SID). The name assigned to the database at installation cannot easily be changed.

The naming convention for the Oracle database also cannot be changed. Database programs and R/3 programs refer to this fixed naming convention for file directories.

The redo log files (online log files) must be mirrored.

Certain restrictions apply to the physical location of the Oracle file directories. For example, redo log files, archive files, and data files should not be located together on the same physical disk.


© SAP AG 1999

Technically Correct Installation: Profiles

R/3 profiles:init<SID>.dbainit <SID>.sap

Oracle profile:init<SID>.ora

Oracle Net8 files:tnsnames.oralistener.orasqlnet.ora

Oracle database

The Oracle database profile is init<SID>.ora. This profile is configured with standard values during installation.

To ensure network and process communication for Oracle Net8, the following files are required:

On the database server site:

- listener.ora: containing configuration information for the Oracle listener thread

On each database client site:

- tnsnames.ora: containing the connect parameters for the database client processes

- sqlnet.ora: containing administrative information for database client processes

- protocol.ora: containing the switch for tcp.nodelay (optional)

The profile init<SID>.sap contains all the information needed for backing up the database. This profile also is configured with the standard values during installation.

The profile init<SID>.dba is a parameter file for the R/3 program SAPDBA. This program is used for Oracle database administration.

Certain parameters must be set during installation for each of these profiles. However, the profiles can be adjusted later, as required.


© SAP AG 1999

Server site

Oracle Directory Structure

rdbms80 bin net80\database

%ORACLE_HOME%origlogB

mirrlogB

sapdata<n>

sapbackup

sapreorg

...

sapdata1

origlogA

mirrlogA

saparch

sapcheck

saptrace

%SAPDATA_HOME%

Client site

rdbms80

%ORACLE_HOME%

nlsrtl31\data

nlsrtl32\datanet80\admin

nlsrtl33\data

The Oracle database file tree structure on the database server site has 2 main branches:

The Oracle binaries are located in \orant. The environment variable ORACLE_HOME points to this directory.

The environment variables SAPDATA_HOME and SAPDATA<n> point to the directories containing database-specific files, such as data files, online redo log files, and offline redo log files.

The directory \orant is required on each server with a database client. The environment variable ORACLE_HOME points to this directory.

The operating system user <SID>adm requires the following environment variables:

ORACLE_SID = <SID> (on the database server site)

ORACLE_HOME = \orant on both the database client and server site

SAPDATA_HOME = \oracle\<SID>

SAPDATA<n> = \oracle\<SID>\sapdata<n> for sapdata<n> (the path to directory n containing database files of the R/3 System)


© SAP AG 1999

sapdata1 ... <n>

Example 1: Minimal Disk Layout

Paging file

mirrlogAmirrlogB

saparch

Disk 5Disk 5

Disk 4Disk 4

Disk 3Disk 3

Disk 1Disk 1

origlogAoriglogB

Disk 2Disk 2 Disk 6Disk 6

Disk ..Disk ..

Disk NDisk N

Other directories:\usr\sap\<SID>\usr\sap\trans\orant\oracle\<SID>\sapreorg

This example shows a database disk configuration without mirrored disks.

Redo log files must be mirrored. To do this, you can use Oracle techniques (software mirroring) and/or RAID systems (hardware mirroring).

This example also shows that the Windows NT paging file, the redo log files, the archive log files, and the Oracle data files are all located on disks that are physically separated.


© SAP AG 1999

sapdata1 ... <n>

Example 2: High Availability RAID Disk Layout

Disk 1�Disk 1�

Paging file

Disk 1Disk 1Other directories:

\usr\sap\<SID>\usr\sap\trans\orant\oracle\<SID>\sapreorg

Disk 5�Disk 5�

saparch

Disk 3Disk 3Disk 2Disk 2

Disk 5Disk 5

Disk 4Disk 4

mirrlogAmirrlogB

Disk NDisk N

Disk ..Disk ..

Disk N�Disk N�

Disk ..�Disk ..�

Disk 7Disk 7

Disk 6Disk 6

Disk 7�Disk 7�

Disk 6�Disk 6�

origlogBoriglogA

This example shows a database disk configuration using mirrored disks. Each disk containing R/3 or Oracle database directories is mirrored. The mirroring is performed using:

RAID 1 for the OS paging file, the saparch directory, and the sapdata directories

Software mirroring for the online redo log files

You can also configure the database so that each hard disk is mirrored with operating system, using a combination of RAID 1 and RAID 5 technology. For example:

RAID 1 for OS paging file and the saparch directory

RAID 5 for the sapdata directories

Software mirroring for the online redo log files

When RAID technology is used, it should be used with intelligent RAID controllers (for example, controllers with a read/write cache).

For further information about database configurations, see:

The Installation Guide

BC505 Database Administration Oracle


© SAP AG 1999

Database Security

Database user passwords

Database backup

Archive mode

Oracle database

To ensure databases security, change the passwords for the database users SYSTEM, SYS, and SAPR3 at R/3 installation. For information about changing the password of user SAPR3, refer to SAP Note 50088.

An R/3 System database must be backed up regularly and the database backups must be monitored. Ensure that an effective backup strategy is implemented.

It is important that the Oracle database is run in ARCHIVELOG mode.


© SAP AG 1999

Database Performance

Location of tablespaces

Location of index and data files

DB log files vs. paging file

Oracle database

The physical location of the data files of the Oracle database can affect the performance of the database. One Oracle tablespace can be spread over one or several physical data files.

When dividing the Oracle file systems between the various hard disks, you should ensure that file systems with a high I/O load (such as redo log files) reside on disks distributed over several controllers. For further information, see the Installation Guide.

If there is enough disk space available, tablespace PSAPSTABD and tablespace PSAPBTABD should be located on separate physical disks. Their associated index tablespaces should also be stored on separate physical disks.

Data and index tablespaces should not be stored on the same physical unit.

Do not use RAID 5 for the Oracle online redo log files, the saparch directory, or the data files of tablespace PSAPROLL.


© SAP AG 1999


R/3 System


© SAP AG 1999

R/3 Release and System Name

R/3 Release

Released by SAP for specific operating systemand database versions

R/3 System name

Must be unique in the system landscape

Must consist of three alphanumeric characters,the first being a letter

Must use uppercase letters

Must be identical to the database SID

Cannot be any of the reserved R/3 System names

The R/3 Release must be approved and released by SAP for the specific operating system and the database versions in this combination. R/3 Release information is available from SAPNet in the component XX-SER-SWREL.

When you assign a name to your R/3 System, you must follow the R/3 System naming conventions:

The R/3 System name must be unique in the system landscape

Three alphanumeric characters must be used, the first character being a letter

Uppercase letters must be used

The R/3 System name must be identical to the database SID

You cannot assign the following names to your R/3 System, as they are reserved:

ADD ALL AND ANY ASC B20 B30 BCO BIN COM DBA END EPS FOR GID INT KEY LOG MON NOT OFF OMS P30 RAW ROW SAP SET SGA SHG SID UID VAR

Choose your R/3 System name carefully. Renaming the system is complicated, and requires you to reinstall the R/3 System.


© SAP AG 1999

R/3 Basis Parameters

R/3 memory management on Windows NT

Has a minimal number of relevantprofile parameters

Has dynamically self-enhancingextended memory

R/3 profile parameters

To check the profile parameters,use transaction RZ10

The R/3 System features zero administration memory management under Windows NT:

To simplify maintenance and configuration of the application server and to use the available resources optimally, it has a minimal number of relevant profile parameters.

It requires no manual settings and adapts itself dynamically to user memory requests.

It recognizes hardware changes, such as memory enhancement, and sets the parameters correspondingly.

The basis for the memory management is the dynamically self-enhancing extended memory, which is "infinitely" large. The extended memory is initially set to the size of the profile parameter PHYS_MEMSIZE [PM]. If the user requests more memory, the extended memory enhances itself in steps of "[PM] / 2" up to the set limit of the profile parameter em/max_size_MB or until the address space in the NT-pagefile is used up. The standard value for em/max_size_MB is set to 20 000 MB, so the size of the NT pagefile is the actual limit for the enhancement of the extended memory.

For detailed information, see SAP Note 88416 and the Online Documentation BC Basis Kernel Components BC Memory Management.

To check R/3 profile parameters in general, use transaction RZ10, select the profile to be checked, and choose Check.


© SAP AG 1999

Domain Concept

DatabaseC11

Application servers

RDBMS

R/3

R/3

Primary domaincontroller (PDC)

Backup domaincontroller (BDC)

Database server

Domain A Domain B

Domain R/3

Resource domain

Account domains

The graphic shows a 3-tiered R/3 System that is divided into several domains.

The NT domain concept protects the R/3 System against access on the NetBIOS level.

If the R/3, A, and B domains are not trusted, you can access R/3 using a SAP GUI over TCP/IP but not on file system level (mapping a network drive).

The primary domain controller (PDC) manages the domain user accounts and synchronizes information with the other backup domain controllers (BDC) in the domain.

For performance and security reasons, no R/3 or database instance should run on the primary domain controller or the backup domain controller.


© SAP AG 1999

R/3 Domain Security Concept

Service userSAPService<SID>

Interactive user<SID>ADM

User account

Global groupSAP_<SID>_GlobalAdm

Member of Member of

Member ofMember of Member of

Domain R/3

ACLACL

ApplicationserverLocal groupSAP_<SID>_LocalAdm

ACLR/3 objects

Full control

ACLACL


ACLR/3 objects

Full control

ACLACL


ACLR/3 objects

Full control

In the R/3 domain, the SAP user accounts are realized using global and local groups. The two R/3 users <sid>adm and SAPService<SID> are members of the global group. The global group gathers users at the domain level and places them in the appropriate local groups. Permissions given to a local group are only valid on the actual application server.

An access control list (ACL) consists of one or several access control entries (ACEs). The ACL controls the access to R/3 objects, such as file permissions. To ensure system security, only the local group SAP_<SID>_LocalAdm and the account SYSTEM are members of all R/3 object ACLs.

With the user account SAPService<SID>, you cannot log on interactively. Therefore, you do not need to change the password periodically. Each time you change the password, you must adapt the SAP Service user account.


© SAP AG 1999

R/3 Directory Structure

\\<SAPGLOBALHOST>\sapmnt

Global directories Instance directories

SYS

logwork dataglobalprofile exe

run dbg opt

trans

<Instance_name>

tmpput

\\<SAPLOCALHOST>\saploc

usr

sap

<SAPSID>

The graphic shows the structure of the R/3 file system tree with the universal naming convention (UNC) file names.

These shares are provided by the NT server service as NetBIOS names.


© SAP AG 1999

Shared Directories

Transport directory:\\$<SAPTRANSHOST>\sapmnt\trans (if defined)

else \\<SAPGLOBALHOST>\sapmnt\trans

Global directory for all R/3 Systems

Global directory:\\<SAPGLOBALHOST>\sapmnt

System-wide data for one R/3 System

Instance directory:\\<SAPLOCALHOST>\saploc

Instance-specific data

If your R/3 system consists of several R/3 instances on different application servers, the file systems beginning with the name <SAPGLOBALHOST> must be available across the whole system.

The file system \\<SAPGLOBALHOST>\sapmnt\trans must be available to all R/3 Systems of the same transport group. Therefore, each R/3 instance must have the authorization to read and write to this file system, which is stored on one application server.

A central transport host, which can be accessed from all R/3 Systems in a Windows NT domain, can also be configured. To do this, set the instance specific parameter DIR_TRANS and the transport profile (TP_<domain name>.PFL) parameter transdir. For further information, see SAP Note 62739 (Configuring a central transport host).

The universal naming convention (UNC) file names are created by the Windows NT directory sharing function. For example, \\<SAPGLOBALHOST>\sapmnt is the UNC file name for the physical file system <drive>:\usr\sap.


© SAP AG 1999

Name Resolution on Windows NT

Own hostname(TCP/IP)?

etc\匼 lmhosts lmhosts cache

Domain name service(DNS - TCP/IP)

Windows internet name service (WINS)

Local broadcast

etc\hosts匼(TCP/IP)

!TCP/IP name resolution

NetBIOS name resolution

yes

no

When R/3 accesses a resource that is hostname-dependent, the operating system searches the host using NT name resolution.

Windows NT uses both a computer name (Control Panel → Network) and a hostname (Control Panel → Network → TCP/IP Protocol → DNS). The computer name is only used for addressing in the LAN manager (NetBIOS), and the hostname is used for addressing in TCP/IP. The computer name is usually written in uppercase, and the hostname is normally created in lowercase during network configuration. The R/3 System uses only the TCP/IP name, which is case sensitive. The R/3 System differentiates between uppercase and lowercase.

Windows NT provides an IP name resolution and a NetBIOS name resolution. The IP name resolution is followed by the NetBIOS name resolution if the hostname cannot be returned. As of Windows NT 4.0, if the flag Enable DNS for Windows resolution is set in the TCP/IP configuration, the NetBIOS name resolution can be followed up by the IP name resolution.

If Windows NT returns the hostname, it uses the above IP resolution order. If the NetBIOS name resolution is used, inconsistencies with the hostnames in the R/3 profiles can occur, as the NetBIOS computer name is always returned in uppercase, for example, with the profile default.pfl.

All references to the host name in R/3 profiles, such as rdisp/btc_name, SAPDBHOST, and SAPLOCALHOST, must contain the TCP/IP host name. The only exception is SAPGLOBALHOST, which is written in uppercase during the installation procedure. If any problems occur when you adjust the profiles, restart the R/3 System and the SAP Services.


© SAP AG 1999

R/3 Instance Numbers

TCP/IP file %windir%\system32\drivers\etc\Services

Required entries for R/3:Dispatcher port for instance number 00-99

sapdp<instance_number>32<instance_number >/tcp

Gateway port for instance number 00-99sapgw<instance_number>

33<instance_number>/tcp

Message server portsapms<SID>

36<instance_number>/tcp

The TCP/IP socket port entries must be the same for all R/3 instances, R/3 database servers, and R/3 frontend devices in the file <drive>:\winnt\system32\drivers\etc\Services (normally performed during installation).

The assignment of the R/3 instance number is fixed as part of the installation. Both the TCP/IP connection to the R/3 System(s) and the connection from the frontend devices to the R/3 Systems depend on this instance number. So you cannot run two R/3 Systems with different SIDs but the same instance numbers on the same host. This is also valid if you are operating an R/3 System group and/or several application servers.

The following entries are reserved for R/3 service programs, and may not be used as R/3 System numbers:

sapgw97 (3397/tcp) SAP OSS

sapgw98 (3398/tcp) SAPconnect

sapgw99 (3399/tcp) SAP EPS

sapdp99 (3299/tcp) SAProuter

The TCP/IP settings (hostname, IP addresses, services entries) and the functions that were executed by the R/3 kernel can be checked using the R/3 tools sapntchk.exe (ASCII version) or sapsychk.exe (win32 version). Both tools are located in the directory \\<SAPGLOBALHOST>\sapmnt\<SID>\SYS\exe\run. When they are executed, a logfile is generated. For further information, see SAP Note 65761.


© SAP AG 1999

Transport domain & domain controller

Configuration of tp

Transportroutes

Transport Management System Setup Process

Before you can work with the transport management system (TMS), it must be configured on all R/3 Systems in your system landscape.

The TMS configuration includes the following steps:

Configuring the transport domain

- You must define which R/3 Systems in the system landscape should be combined in a transport domain and which R/3 System is to be the transport domain controller.

Configuring the transport control program tp

- The transport control program 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 need to adjust the transport profile using operating system functions.

Configuring the transport routes

- The transport routes are used to define in which target system you want to consolidate and deliver change requests.


© SAP AG 1999

Transport Domain

Transport domain:DOMAIN_QAS

Common transport directory Transport group:GROUP_DEV

Domain controller

DEV

QAS

PRD

Backup controller

The current status of the transport domain configuration for each R/3 System in the transport domain is displayed in the TMS System Overview. The overview also shows whether the configuration is up-to-date and if any errors occurred when the configuration is distributed. To display the TMS System Overview, call transaction STMS and choose Overview → Systems.

In a transport domain, the R/3 System, which is configured as the domain controller, is of special significance. If this R/3 System fails, no changes can be made to the TMS configuration. Therefore, it is recommended that you configure a backup domain controller.

Once you have planned your system infrastructure, you will generally not install all planned R/3 Systems at the same time. TMS allows you to configure these R/3 Systems as virtual systems of the transport domain. Therefore, you can configure the transport routes of your entire system infrastructure.


© SAP AG 1999

Common Transport Directory

Transport file forNT globalparameters...system-specificparameters...

<drive>:\usr\sap\trans

sapnamescofilesbufferlog

databin tmp

actlogolddata

EPS

Parameter file fortransport control

program tp

Directory <drive>:\usr\sap\trans

Global transport directory for all R/3 instances in a transport domain

SHARE : \\$<SAPTRANSHOST>\sapmnt\trans (if defined)else \\<SAPGLOBALHOST>\sapmnt\trans

Transport file is generated during setup of TMS

The transport control program 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 need to adjust the transport profile using operating system functions. This transport file is located in the subdirectory bin of the directory <drive>:\usr\sap\trans. Naming convention: TP_<domain name>.PFL.

To check the availability of the transport control program in an R/3 System, choose R/3 System → Check → Transport tool. A hierarchical list is displayed that shows the status of the individual checks. If you have not selected an R/3 System, the transport control program of all R/3 Systems in the transport domain is checked.

To display the tp parameters of an R/3 System, in the STMS System Overview, double-click on an R/3 System and select tab Transport tool. A list is displayed that shows the parameters set in the transport profile.

To check the availability of the transport directory program in an R/3 System, choose R/3 System → Check → Transport directory. Test files are created in the subdirectories of the transport directory and in the last step of the check removed.


© SAP AG 1999

Transport Routes

Transport strategy defined by transport routes

Standard transport route used by all customizingchange requests

Additional transport routes can be established fordevelopment objects

Multilevel delivery: delivery routes can be chained

The configuration of the transport routes is managed in the R/3 System, which serves as the transport domain controller, and can be distributed to and activated in all other R/3 Systems connected in the transport domain.

Before you can configure the transport routes, the following requirements must be met:

The transport domain must be configured

All R/3 Systems involved must be included in the transport domain

The transport control program must be configured (this is done automatically during the above steps)

The transport route configuration consists of:

System attributes

Consolidation routes

Delivery routes


© SAP AG 1999

Che

ckin

g th

e in

stal

latio

n

Checking the Installation: Further Steps

Installation consistency: SM28

R/3 Kernel Patch Level: SM51

Buffer synchronization: ST02

Correct hostname: SM51

Activate Performance Monitor: report RADDBDIF

SAP license installed: saplicense

Standard passwords of sap* and ddic

Remote access using SAPROUTER

Imported Hotpackages: SPAM

Imported languages: SMLT

Windows NT: Event Viewer

The following steps must be performed in order to complete the installation:

To check if the NT system, including the network and the services, is configured properly, use the NT Event Viewer

To check if the database structure fits the R/3 kernel structure, perform the R/3 installation consistency check (transaction SICK or SM28). Perform this check to ensure that the correct database versions and R/3 kernel versions are used, and to ensure that there are no inconsistencies in the R/3 kernel.

To check if the hostname is correctly spelled (case sensitive), run transaction SM51.

For detailed information about the steps to be performed, see the installation guide and the online documentation.


© SAP AG 1999

Back Up the R/3 Installation

DatabaseC11

RDBMS

R/3 directories

NT registry

rdisk /s

ntbackup

ntbackup

ntbackup

R/3 CCMS

SAPDBABRBACKUPBRARCHIVE

Disk configurationDisk administrator

NT directories

ntbackup

Once the installation is complete, the administrator must back up the following:

The operating system with the registry

- For security reasons, a second NT operating system should be installed on a separate disk, so that the server can be restarted immediately after a hardware failure

The disk configuration, which is managed by the NT disk administrator

The relational database management system (RDBMS) in the directories

- \oracle

- orant

The R/3 directories

- \usr\sap

- usr\sap\trans

- <homedir> of <sid>adm

The database

- This can either be performed with the R/3 CCMS or with backup tools, such as SAPDBA or BRBACKUP and BRARCHIVE. If they support the interface BACKINT, you can also use external backup tools. To perform an initial backup, you can also use ntbackup.


© SAP AG 1999


Now you are able to:Check that the installation requirements are metAnalyze the disk configurationAnalyze the network configurationCheck that the database requirements are metAnalyze the profile configurationDescribe the R/3 directory structureCheck the transport management system configurationPerform the R/3 installation consistency checkBack up the R/3 installation


© SAP AG 1999








Installation Guide


© SAP AG 1999

Installation Guide

ContentsDiscussion of the Installation Guide

Installation planningInstallation preparationsInstallation tools


Describe the necessary steps to plan a SAPinstallationDescribe the necessary steps to prepare a SAPinstallationDescribe the SAP installation tools


© SAP AG 1999








SAP Data Archiving


© SAP AG 1999

SAP Data Archiving

ContentsWhy archive data?Data archiving technologyConcepts for data archivingUsing R/3 data archiving tools


Perform the necessary preparations for data archivingArchive application data in conjunction with businessdepartmentsMonitor archiving runs and solve problemsAccess and display archived data


© SAP AG 1999

What is Data Archiving?

Application dataStored in files on the hard disk

Deleted in the database

Evaluated in files without reloading into the database

R/3 database

Archive file

Application data is moved

To prevent confusion with other data backup and archiving methods, we define data archiving as the removal of application data belonging to completed business processes from the database.

The removed data is compressed and stored in another location, for example, in a file system, an optical archive, or in a hierarchical storage management (HSM) system.

To access the data stored in the archive files, you can use application reports.

You can also access the archived data through the Archive Information System (SAP AS).

Data archiving is not:

Reorganization of the database

Backup or restoring of the database

A database offline redo log file (these files are also often called archive files)

Optical archiving for outgoing documents, spool lists, or scanned documents

Database reorganization is independent of data archiving. Data archiving cannot be used to remove test data from the database.


© SAP AG 1999

Why Archive Data?

High availabilityBackup and recovery

Release upgrade

Euro conversion

Efficient use of resourcesReduced hardware costs

Reduced administration costs

Shorter response times in dialog modeSmaller index trees

Fewer selection variants

Databasesize isincreasing

Large data volumes increase storage capacity requirements and administrative outlay for the database.

To check the fill level and size of the database, use transaction DB02 or choose Tools → CCMS → Control/Monitoring → Performance Menu → Database → Tables/Indices.

Database security often requires mirroring or replication of data. Hardware investment increases with the data volumes to be administered. Also, the time needed for a database backup increases in proportion with the volume of data to be backed up.

In daily business, departmental end-users experience performance problems when, for example, an entire table must be searched. If indexed access is available, the index for a large table can also be large. Searching a large index is more time-consuming than searching smaller index trees. Using data archiving to reduce the size of database tables is advantageous both for database administrators and for departmental end-users.


© SAP AG 1999

Data Archiving Process

14.1214.1314.14

Write programfor the archiving object

13.2213.2313.24

Delete programfor archive file 1

...

R/3 Database

Archive file 1 Archive file 2

Start can be triggered manually or automatically

111

222

333

333

Data archiving can run parallel to normal user workload. Its effect on system performance depends on the archiving object used and the amount of data to be archived.

Before deleting data in the database, the delete program compares the contents of the archive file with the same data stored in the database. Deletion takes place only if both sets of data are identical. Deletion can be selected to start automatically or manually in the Customizing of each individual archiving object.

If an automatic start of deletion has been selected in Customizing, a deletion program starts after each archive file is completed or after the last archive files is completed for all archive files (in this case, in the definition of the archive object, set the flag Start at End).

This 2-step archiving procedure ensures maximum data security during archiving.


© SAP AG 1999

Archiving Objects

R/3 database

R/3 applicationdata objects

Archiving

object

Customizingfor an archive run

Write program for thearchiving object

14.1214.1314.14

Delete program for the archiving object

Optional programs (create Index)

Archiving application data references information stored in archiving objects in the R/3 System. Only R/3 System data that is described in the archiving objects can be archived.

An archiving object describes a logical unit of business data that belongs together (including a description of the data model).

You can create your own customer archiving objects for customer tables (use transaction AOBJ).

An archiving object contains the following main elements:

Information about tables containing data to be archived

A write program that selects the data and writes it to an archive file or files

A delete program that compares the data in the archive files with the data in the database, and deletes the database data if both are identical

Documentation for the archiving object (from the application transaction, access transaction SARA and choose Info, or choose Tool → Administration → Administration → Archiving)

Customizing settings for the archiving run

Transaction DB15 provides information about which database tables belongs to which archiving object and vice versa.


© SAP AG 1999

Archive Development Kit (ADK)

Archiving system with tertiary storage media

Application

Manual

Database

Operating system

R/3 System

Archive file

ADK Adjustment of codepage, structurechanges, number format,compression, files handling

SAP ArchiveLink

The Archive Development Kit (ADK) is the interface between the archiving programs of the applications and the archive files.

The archiving programs use the function modules of the ADK to write the archive data to disk.

The archived data is selected using application programs. The ADK performs the physical access to the archived data.

The ADK sometimes splits the data to be archived among several archive files and compresses the data automatically (by a factor of up to 5, but cluster table data is not compressed).

If you use the SAP ArchiveLink interface for secure storage of archived data, the ADK transfers the data from the archiving program to SAP ArchiveLink.

If an ABAP program accesses an archive file, the ADK ensures that the data is returned in the same format as currently found in the R/3 Repository. This adaptation is independent of the hardware platform on which the data was archived.

You can use the ADK to create your own archiving objects and use these to archive data from tables defined by your company.

Do not use the ADK to create archiving objects for archiving data from tables defined in the R/3 standard.


© SAP AG 1999

Archiving system with tertiary storage media(HSM or optical archivesystem)

Adjustment of codepage,structure changes, number format,compression, files handling

ADK

SAP ArchiveLink

Archive file(s)on disk

Safekeeping of Archive Files

There are different methods for storing archive files on tertiary storage media and for administering them:

Using a hierarchical storage management system (HSM)

- A HSM system simulates a very large file system. The archive files that are created during the archive run are directly written in the file system of the HSM system. To use a HSM system, you must adapt the path of the archive files to the HSM system in the customizing data of the archive object.

Using an external archive system through SAP ArchiveLink

- If you want to store the archive files on an external archive system via SAP ArchiveLink, the files must reside on the disk until the delete program has finished (and the data in the database is removed). After the delete program has finished sucessfully, you can forward the archive files to the third party product for storage.

Manual administration

- If you do not use one of the above methods, you can store your archive files manually on tapes or CDs.

For a list of third party archiving solutions, see SAPNet, alias csp.


© SAP AG 1999

Accessing Archived Data

Analysis (Reporting)Individual programs for each archive object

SAP Archive Information System

Direct AccessIndividual programs for accessing certain archiving objects(from application transaction)


An index must be created on the archive for direct access

Special Case: ReloadAvailable for a few archiving objects

Used only for correcting errors after archived data is deleted

Data records incorrectly selected for archiving

Residence time incorrectly customized

Almost all archiving objects are supplied with an individual analysis program, which sequentially reads the archive files and creates a spool list.

For some archiving objects, you can simultaneously analyze archived data and data in the database. For example, almost all analyses of FI documents can use data from the database and/or the archives. All programs referring to the logical database BRF can automatically access data in the database and in archive files. No special coding is needed.

The SAP Archive Information System provides various tools for reporting and accessing archived data (see next graphic).

Reload should only be used for correcting errors, for example when data is archived too soon and deleted in the database. Reload is available, for example, for:

FI documents (restricted after changeover to the Euro)

SD documents


© SAP AG 1999

Archive Information System


Archive Retrieval Configurator

Archive Information Structure

Archive Files

create search

Archive Explorer

Direct

The SAP Archive Information System (SAP AS) is an archiving environment-integrated generic tool for implementing searches in R/3 data archives. The search for and display of data follows rules set in the Archive Information Structures, which the user can define and fill with data from the archive.

The Archive Retrieval Configurator allows you to create Archive Information Structures with the help of field catalogs, and to fill the structures with data from the archive. The archive information structure, which represents a kind of archive index, provides the basis for archive data reporting.

The Archive Explorer allows fast searches of archived data. It does this by accessing the archive information structures that have been created and stored in transparent database tables using the Archive Retrieval Configurator. The Archive Explorer allows direct access to individual data objects in the archive, which you can then display in both technical and application-specific views.

To work with the Archive Information System, use transaction SARI or choose Tools → Administration → Administration → Archiving → Information System.

The archiving data can be represented in a technical or business oriented view. Both views enable you to access the archived data directly. The technical view offers additional functions such as search, sort, and condensation.

The Archive Information System can also be used in Releases earlier than 4.6. For more information, see SAP Note 99388.


© SAP AG 1999

Preparations for Data Archiving

Configure at least 2 background work processes(IT)

Ensure that sufficient hard disk space is available(IT)

Customize logical file and path names(BD)

Customize the archiving object, including test and productionvariants for the delete program(BD)

BD = Business Department (for example HR department)IT = Information Technology department

Archiving

object

Dispatcher

B B

Customizing is performed for each archiving object, to define, for example:

Residence time after which data can be removed from the database

Size of the archive files to be written

Number of data records in each archive file

Startup of the delete program (automatic or manual)

Test and production variants

Because the delete program can be started automatically, you should make at least two background work processes available for parallel processing of the write programs and the delete programs. The write program should be executed on the server where the database is located.

For workload distribution purposes, the delete jobs should run on additional application servers. The job Submit handles the submission of the write job and finds all available background work processes.

An archiving run is completed only after all the delete programs have successfully deleted the archived data from the database.

To customize the logical file and path names, use transactions SF01 and FILE.

To determine how much hard disk space is needed for archiving, perform a test run without writing data to files.


© SAP AG 1999

Data Archiving Steps

Use transaction SARA(BD)

Maintain one variant for each specific archiving run(BD)

Archiving object

2 variants for the delete program(only defined once)

Archiving run

1 variant for each archiving run

The central transaction for the archiving process and the customizing is transaction SARA.

An archiving run is started either by the administrator in agreement with the application users, or by a member of the business department who has the necessary authorizations.

You should always use transaction SARA to create the archiving jobs (for details, see SAP Note 133707).

For each archiving run, a specific program variant determines which data should be archived. Depending on the archiving object, there may be several parameters to maintain. Provided that the background job that used the program variant has been deleted, the program variant can be reused.


© SAP AG 1999

Monitoring an Archiving Run

During an archive run, monitor the status in transaction RZ20Monitor background jobs using the Job Overview fromtransaction SARA (IT), check spool lists (BD)Analyze management data in transaction SARA (IT)Check additional information in the net graphic(for example FI_ACCRECV)

Sales figures A/P, A/R, G/L

archived: 1.8.99

Financial accounting documents

archived: 1.8.99 archived:

Customer master data

FI FI

FI

FI_DOCUMNT FI_ACCRECV

FI_MONTHLY

To monitor the phases of data archiving at runtime, the ADK function modules are integrated in the global monitoring architecture of the CCMS. The ADK Monitor displays the status and error situations. During and after archiving, the system collects statistical data such as runtime, and the size and number of archive files. This makes it easier to restart and plan archiving jobs.

To monitor background processes, use transaction SM37. Check whether the scheduled archiving runs were processed, and at what time the processing occurred. Depending on the settings in Customizing, especially on the maximum number of data objects and the file size, a certain number of write jobs is generated. For each write job, one delete job may be created. These jobs create spool lists that can be viewed in R/3. The management data displayed in transaction SARA provides, for example, information on the size and location of archive files, and the number of data records contained in each archive file.

The net graphic provides an overview of dependencies between various archiving objects and a plan for ordering your archiving. For example, you must never archive customer master records until all FI documents belonging to this customer have been archived. When you archive data, follow the plan in the net graphic.


© SAP AG 1999

Error Handling

Termination due to:External problems result in termination of the background process

An archive file exists with the same name

File system is full, archiving directory not available

Terminated archiving runs can be executed again

There are three possible outcomes of a data archiving run:

All the data is successfully archived

Data archiving is terminated due to an error before the files are deleted

One or more of the delete runs are terminated

Several archive files are written during an archiving run. For each archive file, a delete job is started.

If an error occurs, always proceed as follows:

If an archive file cannot be fully written, back up the completed archive files and delete the partially written ones. Then restart the archiving run to archive the remaining data that was not written and deleted.

If all the archive files are written, but the delete jobs are not processed or are only partially processed, restart the delete jobs manually.

If the write job is terminated and delete jobs are configured to start manually, you can delete archive files that were fully written before termination, then restart the archiving run.


© SAP AG 1999

Dataanalysis

Design andconcept Test Implem-

entationBuilding a

project team

Project leaderITBusinessdepartment(revision)Application teammembersExternal teammembers

Table sizeRate of growthAccessoryarchiving objectsDependencesLegalpreconditionResidence timeAccess demandsAuthorizationsPhysical storagemedium

Documentationconcept(revision)Archivingconcept:application /technical viewImplementationplan: activitiesand timeplanLong termarchiving plan:administration ofarchive files

SAP NotesTransportsVariantsServer config.CustomizingStorage systemExecution ofArchiving runIf necessary:rework

Experiences fromthe test phasePreparationExecutionFollow-up

Phases of an Archiving Project

From the start of an R/3 implementation project, you should consider data archiving. It is an important factor for the performance of your R/3 System.

Data archiving requires teamwork between the IT department and the application departments. Archiving projects must be planned and carried out on an interdepartmental, companywide basis.

The graphic shows important steps and milstones within an archiving project. Use it to gain an impression of the preparation required and the time phases involved.

It is part of the responsibility of a database administrator to reduce the size of the database by using it to store only data that applications must be able to access online. Any data that no longer needs to be accessed online should be archived. Application departments should decide which data can be archived.

You should develop an archiving strategy that enables you to maintain an approximately constant data volume in the database and to prevent data storage or access problems from arising.


© SAP AG 1999

Data Archiving Authorization


Archiving(S_ARCHIVE)

01 Everything is allowed02 Change mode in archive managemt.03 Read and analyze archive files and

display in archive management

APPLIC

ACTVT

Application Name of application areaarea (for example FI, BC, ...)...

Archive Name of archive object(for example, FI_BANKS)ARCH_OBJ

Operation on jobs(S_BTCH_JOB)

* Reserved, set to *

DELE Delete jobs of other usersLIST Display spool lists of other usersPROT Display job logs of other usersRELE Release own jobs automaticallySHOW Display other users job definitions

JOBACTION

JOBGROUP

S_ARCHIVE is the main authorization object used for data archiving. Specify in S_ARCHIVE exactly which archiving objects are to be processed and which options are to be used.

To ensure that maximum amounts of data are archived, you also need appropriate authorizations from the application where the data is produced. To find these authorizations, read, for example, documentation on the archiving object MM_MATBEL (Material documents). This documentation is accessed through "Info" in transaction SARA.

Because data archiving runs in the background, you also need authorization for creating background jobs.


© SAP AG 1999



Explain the need for data archiving

Prepare the system for an archiving run

Customize an archiving object

Start and monitor an archiving run(together with the business department)

Check the results

Successful archiving depends on a number of factors:

Cooperation between the business departments and the system administrators

A thorough knowledge of the available documentation, for example:

SAP Online Help

Info in Transaction SARA

SAP Notes

Availability of sufficient background work processes

Optimal modifications during Customizing

Well-organized storage for archive files


© SAP AG 1999


SAP Online DocumentationData Archiving

ADK


Training coursesBC660

BC670

SAPNethttp://sapnet.sap.com/data-archiving

http://sapnet.sap.com/adk


© SAP AG 1999

Unit Actions

Exercises?

Solutions



Data Archiving: Exercises

Changes created within the Customizing of an archive object can result in repeated system prompts to include such changes in a Customizing request. If you receive such a prompt, choose Create Request and enter a description. If you are prompted for a change request again during this exercise, use this request.

No. Exercise 1 Archiving data

Before starting the exercises, groups working on QAS must execute report ZPREPARCH (use transaction SE38).

1.1 Call the archive management initial screen. Enter the object US_PASS and display the net graphic.

1.2 Customize this archiving object. Specify the following: That an archive file cannot exceed 10 MB That a maximum of 20 objects can be added to an archive That the deletion program starts automatically Define 2 variants for the delete program (test run and production run), save this Customizing data, and go back to the initial screen of transaction SARA.

1.3 Choose Archive, then define a variant for this special archiving run (archive all up to today; do not run the deletion program as a test run; generate archive files). Set archiving to run in the background and maintain spool parameters. Start the archiving run.

1.4 Monitor the background jobs. View spool lists and job protocols.

2 Finding documentation 2.1 In the archive management initial screen, select object MM_MATBEL, and

find out the name of the delete program used.

2.2 Find out which database tables are accessed by the delete program defined for object MM_MATBEL.


Data Archiving: Solutions

Changes created within the Customizing of an archive object can result in repeated system prompts to include such changes in a Customizing request. If you receive such a prompt, choose Create Request and enter a description. If you are prompted for a change request again during this exercise, use this request.

No. Solution 1 Archiving data

Before starting the exercises, groups working on QAS must: – Execute report ZPREPARCH (use transaction SE38) – Call transaction SE06, then select System change option and change

global setting to Modifiable. 1.1 Call transaction SARA or choose Tools → Administration → Administration

→ Archiving, enter object name US_PASS, and display the net graphic by choosing Goto → Network graphic.

1.2 Enter object name US_PASS. Choose Customizing → Technical Settings and set the following: Define the size of an archive file as follows: Size in MB: 10 Max. number of data objects: 20

Settings for delete program: Start automat. Create the following two variants: – Select Variant beside field Test run variant. A dialog box appears: enter

TEST and choose Create. In the next dialog box, choose Continue. On the next screen, Test run is already selected. Select Attributes and enter a description. Save and go back.

– Select Variant beside field Production run variant. A dialog box appears: enter PROD and choose Create. In the next dialog box, choose Continue. On the next screen, deselect Test run. Select Attributes and enter a description. Save and go back.

Save your archiving specifications. You are now prompted for change request information: Choose Create Request. Provide a description for the change request. Save the new change request. Choose Enter. Your archiving specifications are now saved. Return to the archive management initial screen.

1.3 Choose Archive, enter your variant name VAR##, where ## is your group number, and choose Maintain. Select For all selection screens. Enter today’s date (do not run the deletion program as a test run), and select Generate archive file. Choose Attributes. Enter a description of your variant, save, and return to the screen Create archive files. Maintain the start date (choose Immediate) and the spool parameters (specify an output device that you have


defined previously), and choose Execute.

1.4 From the main archive management screen, choose Job Overview and view spool lists and job logs.

2 Find documentation 2.1 In transaction SARA, enter the name of the archiving object and choose

Delete → Program documentation.

2.2 To see the tables accessed by the delete program defined for this archiving object, from the main archive management screen (transaction SARA), choose DB tables (transaction DB15).

© SAP AG 1999








System Monitoring


© SAP AG 1999

System Monitoring

ContentsAlert Monitor 4.6Alert Monitor handlingAlert Monitor configuration


Explain the Alert MonitorCustomize the Alert MonitorConfigure your own Alert MonitorHandle alerts


© SAP AG 1999

Monitoring: What, Why, Who, When

What - Components in R/3:

R/3 (application servers, buffers, applications, ?

Database: (performance, backup, ?

Operating system: (CPU, file system, ?

12

9

6

3

11 1

7 58 4

210

Why -Keep the system runningImprove performance

Who -Administrators

When -Periodically

The R/3 System consists of many software and hardware components that contribute to the overall availability and performance of your R/3 installation. These components include: The operating system (CPU, physical memory, disks, ...) The database The R/3 buffers R/3 services (dialog, update, enqueue, spool, ...)

All these components must be monitored regularly. The main goals of system monitoring are as follows:

To keep the system running To analyze and correct errors To improve performance

System monitoring is performed by different persons depending on their area of responsibility: R/3 System administrators are responsible for assuring the performance of R/3 Database administrators are responsible for assuring the consistency of the database and for restoring the database if a database inconsistency or data loss occurs

Operating system administrators are responsible for providing physical storage media The R/3 System should be monitored regularly at least once a day. However, we recommend more frequent monitoring than this, depending on the size of the installation.

The System Administration Assistant provides a suitable tool for developing a daily, weekly, or monthly monitoring plan.


© SAP AG 1999

Part 1: Monitoring Concept and Alert Monitor

<SID>

<host>_<SID>_<No>

<SID>

Operating Syst.

BuffersCPUDisk

Database

Transport

SD

BackupPerformance

All objects summarized inmonitoring tree

Display history and present state,especially alerts

Method assignment for:Analyzing alertsReaction and notificationData collection

Monitoring Objects

Monitoring AttributesCPU idle %CPU idle %

All objects to be monitored are summarized in one tree, which displays all the information necessary for monitoring and maintaining your system.

Each system component is represented by a monitoring object. These objects have different attributes, for example, CPU utilization is an attribute of the object CPU, and the buffer hit ratio is an attribute of the object buffers. These attributes receive data and may create alerts. The monitoring objects summarize alerts and propagate them to higher tree nodes. Use this information to display the current status of your system or to analyze its history and any alerts that occur.

The term monitoring tree element (MTE) is used to denote any node in the tree.

The alert monitor comes with numerous pre-delivered collection methods for all vital aspects of your system.

The monitoring infrastructure is implemented in C and offers C and ABAP interfaces for adding new MTEs. Using MTEs, external providers can also embed their objects or tools in the monitoring tree architectures.


© SAP AG 1999

Monitoring Architecture Terminology

Monitoring ArchitectureMonitoring Architecture

Data supplierData

supplierData

supplierData

supplierData

supplierData

supplier

DB OS R/3

Monitoring object

Monitoring object

Monitoring object

Data ConsumerData Consumer

A P IA P I

PerformanceDB

Data supplierData

supplier

R/3 Syslog

MonitorMonitor

FM

Analyze

Data Consumer: RZ20Data Consumer: RZ20

The alert monitoring framework consists of Data Suppliers (collection methods), Data Consumers (transaction RZ20, CCMS Monitoring Sets), and the Monitoring Architecture. This architecture is delivered ready to use with collection methods already created for all major components in the R/3 System environment. Typical data suppliers already active for reporting include: host operating system, R/3 database, R/3 Systems, instances, and their related services and components, and API for external components outside the R/3 System.

Data Suppliers, also called Collection Methods, are programs that collect information on different parts of the R/3 System and its environment. The collected data is then passed on to the monitoring infrastructure. Data suppliers “plug into” the monitoring architecture and use its services for displaying and managing the system information.

Monitoring Objects represent something in the R/3 System or environment that should be monitored. A monitoring attribute is one type of information that is reported on a particular monitoring object.

The Data Consumer is the layer of the architecture for displaying alerts and status data. The information collected by the various collection methods is passed to the data consumer through the monitoring architecture.

The Performance Database represents a series of tables in the R/3 database that store the collected information and performance data.


© SAP AG 1999

The Alert Monitor (Transaction RZ20)

Monitoring Tree ElementsMonitoring Tree Elements All tree nodesAll tree nodes

Represent one physical or logical objectSummarize alerts andpropagate to higher nodes

Represent one physical or logical objectSummarize alerts andpropagate to higher nodes

Receive data and may create alertsUse data for analysisalerts

Receive data and may create alertsUse data for analysisalerts

Monitoring ObjectsMonitoring Objects

Monitoring AttributesMonitoring Attributes

ViewView

From the SAP Easy Access Menu, choose Tools → CCMS → Control/Monitoring → Alert Monitor or call transaction RZ20 directly.

The monitoring tree presents a hierarchy of system components displayed by the alert monitors. In Release 4.6, the alert monitor is delivered with standard monitor sets (for example, the SAP CCMS Monitor Templates) to provide detailed information on specific aspects of your system.

The alert monitor uses thresholds and rules to generate alerts whenever anything abnormal occurs in your R/3 System or its environment. Alerts direct your attention to critical situations so that you do not have to discover these for yourself. The alert monitor reports alerts up through the monitoring tree. The color of an MTE always represents the highest alert in all MTEs in its branch.

In each monitor, you can switch between a view of the current system status or open alerts:

Current system status shows the latest reported data on each MTE. The color of the alert and the alert message text reflect this data. They show the most serious current problem.

Open alerts shows where alerts exist that have not yet been analyzed and set to complete. The colors are set according to the most serious unprocessed alert. This view does not necessarily reflect the current status of the system.


© SAP AG 1999

Thresholds and Analysis Methods

View properties to define or change thresholds or analysis

method assignment

Display alerts to view detailed information on each

monitoring attribute

Select Start Analysis Methodto execute analysis method for

monitoring attribute

The alert monitor uses a color scheme to indicate the severity of each alert displayed:

Green: component OK

Yellow: warning

Red: problem

White: no data

Alerts are displayed for each monitoring attribute. To view alerts, select a monitoring attribute and choose Display alerts. A historical overview of the alerts for the selected monitoring attribute is displayed.

To start the analysis method for a specific alert, double-click on the alert. Release 4.6 comes with all analysis method assignments required to monitor your R/3 System. If necessary, the administrator can maintain additional method assignments. To maintain threshold values or method assignments for a monitoring attribute, select the attribute and choose Properties. Use the tabs to display values for modification.


© SAP AG 1999

Creating Your Own Monitor

Select MTEsSelect MTEs

Creating your own monitor by using a SAP CCMS Monitor

Template

Creating your own monitor by using a SAP CCMS Monitor

Template

Use right mouse button

SAP has predefined a wide variety of monitors in the SAP CCMS Monitor Templates and in the SAP CCMS Technical Expert Monitors. In addition, you can quickly and easily build additional monitors to meet special requirements. For example, if you want to monitor the relationship between your CPUs, operating system paging, and the R/3 System dialog response time, you can build an alert monitor that contains only these MTEs.

To create a monitor, choose Tools → CCMS → Control/Monitoring → Alert monitor or call transaction RZ20. Activate the maintenance function by choosing Extras → Activate maintenance function. There are 2 ways to create your own monitors:

Choose Monitor (set) → Create and specify whether you want to create a new monitor set or to create a new alert monitor in an existing monitor set (without using a SAP monitor template).

Use SAP CCMS Monitor Templates. Copy the monitor template to your monitor set, right-click on the desired MTEs, and choose Create monitor. In the next screen, the marked MTEs are selected. Save your changes. A dialog box asks for the name of the new monitor (this method is shown in the graphic).

Monitors that are created by explicitly picking MTEs from the tree are called static monitors. Static monitors are not automatically updated to include changes to the MTEs from which they are built.


© SAP AG 1999

Monitor Remote Systems

Goal: Monitor the 2 systems DEV and QAS from 1 system

Goal: Monitor the 2 systems DEV and QAS from 1 system

Preparation:

Use transaction RZ21 to define remote systems

Change monitor definition

Technical infrastructure → Create remote monitoring entry

After installing an R/3 System, you can use transaction RZ20 to monitor the system. To monitor all systems of your system landscape centrally from one system, first customize the alert monitor by choosing Tools → CCMS → Configuration → Alert monitor or calling transaction RZ21. Then, to specify the remote systems by System ID and RFC destination (which must have been created beforehand), choose Technical infrastructure → Create remote monitoring entry.

Next, to change your monitor definitions (you can only change your own monitors), choose Tools → CCMS → Control/Monitoring → Alert monitor or call transaction RZ20. Activate the maintenance function by choosing Extras → Activate maintenance function.

Then, double-click on the monitor and choose Monitoring change. Parameter R3system defines which systems can be monitored by an alert monitor. Change parameter R3system from <CURRENT> (only the current R/3 System can be monitored) to <ALL> (all R/3 Systems defined in RZ21 can be monitored). Save the changes.


© SAP AG 1999

Part 2: Analysis Methods

RZ20

Call analysis method directlyfrom transaction RZ20

Which are the most important analysis methods?Background information on the analysis methodsWhat information can you get from these methods (transactions)?Which actions are available?Troubleshooting using the analysis methods (Roadmap)

The following graphics discuss the related analysis methods in more detail.

All instances displayed in transaction RZ20 have the same structure. They are divided into the following parts:

Operating system

Database client

R/3 services (R/3 work processes)

R/3 basis system, containing the buffers and memory management

R/3 ABAP

R/3 System log, where important messages are stored

Security

Server configuration

Here, we focus on the main analysis methods for analyzing the alerts shown in the alert monitor.


© SAP AG 1999

R/3 Syslog

Transaction RZ20groups the R3Syslogalerts by topic

Transaction SM21logs informationabout errors andincidents in thesystem

Syslog displays therecent history of theR/3 System

R3Syslog (View in RZ20)

BasisSystemDatabaseCCMSBackgroundCommunicationSpoolSecurityTransportSystemBatchInputApplicationsCustomerMiscellaneousSyslogFreq

Use the analysis tool SM21 to look in more detail at the alerts shown in RZ20

The MTE R/3 System log provides information about the different parts of your R/3 System. To see the log information for a time frame, call transaction SM21.

To view the system log, choose Tools → Administration → Monitor → System log.

The system log shows various messages, including error messages. Some of these provide information about, for example, operation mode switches or system start up. Other log messages show errors that occurred in the system (such as update errors, deletion of lock entries, or aborted programs).

The R/3 System log provides information about such errors. To analyze these errors, you must use other analysis tools.

If you use the System Administration Assistant for your daily system checks, it provides you with direct access to transaction SM21.


© SAP AG 1999

R/3 Syslog: Details

CentralCentralloglogfilefile

rslgsend rslgsend Applicationserver 2

LocalLocalloglogfilefile

message 2

Applicationserver 1


message 1

rslgsend

Central instance


message x

rslgcoll

UNIX only!

In UNIX systems, programs rslgcoll and rslgsend are started during the startup of an instance.

The system log contains information about the R/3 System. This information is categorized into problem classes as follows:

S : status messages

W : warning messages

K : system kernel messages from the basis system

T : transaction messages

X : other messages

The information includes: timestamp, client, user, transaction code, and a short text. The work process that generated the message is also displayed.

You must monitor the system log separately for each application server. In UNIX systems, you can collect the system log in a central log.


© SAP AG 1999

R/3 Services

Provides an overview ofusers, work processes,and services in R/3

R/3 Services (view in RZ20)

Gateway_summaryDialogSpoolBackgroundUpdateEnqueue

Transactions

SMGW

SM12

AL08SMLG

SM04

SM50

SM51

SM66

Use the available analysis tools to look in more detail at alerts shown in RZ20

The MTE R3Services provides an overview of all R/3 work processes.

This unit provides more detailed information about the following work process types together with their related transactions:

Dialog

Update

Enqueue


© SAP AG 1999

Monitoring: R/3 Servers and Instances

Applicationserver 1

Applicationserver 2

Applicationserver x

...

Information:

Instance namesHostnameTypes of work processesRelease NotesWork process overviewUser overview

Action:

Remote Logon

SM51

R/3 System

Transaction SM51 provides an overview of available servers.

You can use this transaction to:

Examine the processes of the server you are logged on to

Display the users of the system

Display the system log

Display the OS collector state

Dynamically switch to another server

Release Notes in this transaction show:

R/3 kernel release

R/3 release

Database release

OS release

If you use the System Administration Assistant for your daily system checks, it provides you with direct access to rransaction SM51.


© SAP AG 1999

Monitoring: R/3 Work Processes

ApplicationServer 1

DD V E B S

Dispatcher

ApplicationServer x

DD D D B B

Dispatcher

.

.

.

SM66

SM50

SM50

Information:

Work process type and statusDetail infoCPU timeUserReport / Table

Action:

Start and stop WPsDebuggingTrace

SM50 / SM66

Work processes do most of the processing in the R/3 System. They execute dialog steps in user transactions, updates, lock administration, and so on.

To display the current status of the work processes on the application server where you are logged on, choose Monitor → System monitoring → Process overview or call transaction SM50. To get updated information, refresh the display. To view the work processes on the whole R/3 System, call transaction SM66.

The Process Overview displays information about:

Number: The internal ID number of a process. The number is used to identify messages that pertain to a work process in the system log.

Type: The type of work process:

- DIA: Work process for executing dialog steps in user transactions

- UPD: Update process for making V1 (time-critical) database changes

- UP2: Update process for executing V2 (not time-critical) database changes

- ENQ: For locking or releasing SAP lock objects

- BTC: For processing background jobs

- SPO: For spool formatting processes

PID: Process ID of the work process (in the operating system)

Status: The current status of the work process (can be Running, Waiting, Hold, or Ended)


© SAP AG 1999

Monitoring: R/3 Users

ApplicationServer 1

ApplicationServer x

.

.

.

SM04

SM04

AL08

Information:

UserClientTerminalTransaction

Actions:

Start and stop WPsDebuggingTraceEnd session

SM04 / AL08

Transaction SM04 provides an overview of users on a specific server. Transaction AL08 provides an overview of all the users in the R/3 System.


The user overview provides information about:

User logged on to server (R/3 user name)

Terminal at which the user is working. The terminal name corresponds:

- For a UNIX frontend, to the the display variable of the frontend process

- For a Windows or OS/2 frontend, to the host name on which the frontend was started

Last executed R/3 transaction (transaction code)

Time at which the user last initiated a dialog step by entering data

Number of external sessions (R/3 sessions) that the user has opened (up to 6). To display detailed information on a user session, choose Sessions.

Type of connection (GUI or RFC)


© SAP AG 1999

SMLG

Group A

Group B

Database

Message server

Group A: AS 2,3Group B: AS 1,2

Applicationserver 1

SAP Logon

Group B

Applicationserver 2

Applicationserver 3

Action:Create Logon Groups

Logon Groups

Logon groups enable an R/3 System to distribute the load on instances in the group more evenly and therefore more efficiently. A logon group consists of a group of instances. To create logon groups, call transaction SMLG. After a logon group has been defined, users can log on to the system by choosing the group. The user is automatically routed to the instance with the best response time. This process is called load balancing.

After you have configured logon groups, you must install and configure SAP Logon on your frontend PCs (this program replaces the SAP GUI icon on the PC). SAP Logon displays a list of all the configured logon groups.

You can also configure logon groups for different groups of users. If load balancing is employed, only the programs and tables used by the group are buffered on the application server. Therefore, the application server requires less memory. For example, if users working with the SD module form a logon group, the server may only need to buffer SD data and programs.

To create logon groups, choose Tools → CCMS → Configuration → Logon Groups.


© SAP AG 1999

Update Processing 1

Enqueue server

. . .. . .

Dialog server

1Lock table inmain memory

DispatcherDispatcher

Message Message serverserver

DatabaseVB*

2

D-WP D-WP V-WP

D-WP

E-WP D-WP

Dispatcher

Locking mechanisms on relational database systems cannot be used for complicated business objects, such as delivery orders located in several tables. To coordinate parallel access to this business object data in an R/3 System, the enqueue work process is used.

The locks (also known as enqueues) are handled by the enqueue work process in a lock table in main memory on the server where the enqueue process is running.

When a lock is requested, the lock table is checked for an entry from this data set. If there is already an entry of this type, the request is rejected and the user notified.

If the dialog and enqueue work process are not located on the same server, communication is enabled by the message server.

For every business data object, a lock object is defined in the ABAP dictionary. The customer name range for a lock object must start with EY or EZ.

A lock object can have:

Mode S (shared lock) for read access, or

Mode E (exclusive lock) for write access.

An update in R/3 is usually executed asynchronously. The update information is written into a set of tables (VBMOD, VBHDR, VBDATA, ...). When the transaction has finished, the database is updated from these tables.

The update process can be performed in several steps. The time-critical part of an update is called a V1 update, the non-time-critical part a V2 update. An example of a V2 update is the creation of statistical business data.


© SAP AG 1999

Update Processing 2

DatabaseVB*

Enqueue server

. . .. . .

Dialog server

DispatcherDispatcher

4

5

Commit Work


3Message Message

serverserver


6 D-WP D-WP V-WP E-WP D-WP

D-WP

An update is triggered at the end of an SAP transaction by a Commit Work. This is done explicitly in the coding or implicitly at the end of an SAP transaction by default.

The update work process reads the data from the VB* tables and executes the updates in the corresponding tables of the R/3 database. Once the update is successfully completed, the entries in the VB* tables and in the lock table are deleted.

If an error occurs, the lock table entry is deleted, but the entries in the VB* tables are not deleted. The user is notified immediately by an express mail. Depending on the business data object, the entry may be reposted.

You can update the database asynchronously using ABAP keyword Call function ... in update task. In special cases only, you can also update the database synchronously inside a dialog service (this is also called a hard update).

© SAP AG 1999

Monitoring: Asynchronous Update

DB VB*SM13

Information:

Is updating active?Update modulesUpdate dataError information

Action:

PostingTest postingStart update

To display terminated updates, call transaction SM13 or choose Tools → Administration → Monitor → Update.

When using transaction SM13 for V1 updates, we do not recommend “posting” or repeating the transaction.

If an update error occurs, first solve the problem that caused the error. Then restart the transaction.

If a V1 update was successful but the V2 update aborts, we recommend that you use transaction SM13 to post the aborted V2 update.



© SAP AG 1999

Monitoring: R/3 Locks

. . .V-WPV-WP

Dispatcher


E-WPE-WP D-WP D-WP

SM12

Information:

Locked tablesLock holderLock type / Lock area

Action:

Delete locks (only in special cases)

Test enqueue

To display the current database locks, call transaction SM12. This transaction provides information about:

The user who initiated the lock

The user’s client

The table that locked

The lock argument

Analyze lock entries considering the following:

Is the user who holds the lock really using the transaction?

Has the user started an update transaction and then left the computer?

Is it a long-running transaction with several locks?

Is the lock still active due to a terminated update?



© SAP AG 1999

Monitoring: ABAP Dumps

Information:

User program or transaction dateError ID (useful as keyword for searching in SAP Notes)Exact position in programCode where the error occurs

For every ABAP dump,there is also an entry in the system log

What happened?

Error Analysis

How to correct the error

A list of keywords for searching in SAP Notes

General description of the error thatoccurred in the system. Program name or function module is mentioned

ABAP runtime error <Error ID>

Detailed description of the reason why the program terminated abnormally Example: <xy> field length too small

ST22

If you receive an error message in the R/3 System log, or if you see a terminated update in the update service analysis transaction, check for dumps using the dump analysis transaction (transaction ST22), or choose Tools → Administration → Monitoring → Dump analysis.

Transaction ST22 enables you to analyze short dumps from the current and previous day.

The dump analysis function shows you:

What happened

What you can do

How to correct the error

The dump analysis function also provides an error ID and keywords that you can use to search in SAPNet, as well as information about:

The system environment

Users and transactions

Transaction ST22 enables you to analyze the following data:

Date, time, user, client

Contents of system and data fields

Contents of internal tables and application tables

If you use the System Administration Assistant for your daily system checks, it provides you with direct access to transaction ST22.


© SAP AG 1999

Time Definitions for a Dialog Step

Database

SAP

GU

I

Dis

patc

her

D-WP

RequestQueue

Task Handler

Dynpro Processor

ABAP Processor

DB Interface

UserContext

1

2

3

4

8

9 9

1

9

Net

wor

kDBBP

SGA

Net

wor

k

PXABuffer

5

R/3Buffer

Wai

ttim

e

Rol

ltim

e

Load

time

Response time

DB request time

6

Process-ing time

7

7

Once you have established a connection from your SAP GUI with a dispatcher, and processing has started in the system, the following steps are triggered:

Data is transferred with the SAP GUI protocol through TCP/IP to the dispatcher.

The dispatcher classifies the request and places it in the appropriate request queue.

The request is passed in order of receipt to a free dialog work process. The following steps are sub-proceses of the work process.

The task handler executes the recovery of the user context. This step is called a roll-in. The user context contains, for example, data on sessions still running for this user and its authorizations.

The task handler calls the dynpro processor, which converts the screen data into ABAP variables.

The ABAP processor processes the code for the process-after-input (PAI) module of the preceding screens, along with the process-before-output (PBO) module of the following screen, and, if necessary, communicates with the database.

The dynpro processor reconverts the ABAP variables into dynpro fields. When the dynpro processor has completed processing, the task handler is reactivated.

The current user context is stored by the task handler in shared memory (roll-out).

The resulting data is passed back through the dispatcher to the frontend.


© SAP AG 1999

Monitoring: Workload Analysis

Applicationserver 1

Applicationserver 2

Applicationserver x

...

Dis

patc

her

Task handler

Dynpro Processor

ABAP Processor

DB-SS

12

9

6

3

11 1

7 58 4

210

ST03Information:

Response timeDB request timeLoad timeWait timeCPU time...

Different task types:

DialogUpdate BackgroundRFCTotal

The Workload Monitor displays detailed information about the work processes on the different application servers.

The information can be split up for different types of work processes and contains data such as:

Average response time

Average database request time

Number of steps

Roll-in and roll-out time

Average wait time

For more detailed information, investigate the following:

Transactions or reports with the longest times

Time profile

Memory profile


© SAP AG 1999

R/3 Basis System

R/3 BasisSystem (view in RZ20)

TraceSwitches R3Dev.Trace

R3SystemTrace

Memory Management

Buffers Program Single Record Generic Key Screen ... Provides information on the

status of the buffers and systemmemory management

Developer traces are written in the instance work directoryon operating system level

ST11 AL11

ST01

The trace facility enables you to trace different kinds of operationsin your R/3 System

ST02

Use the available analysis tools to look in more detail at alerts shown in RZ20

The MTE R/3 BasisSystem provides information about traces, memory management, and buffers. Developer traces contain technical information for use in the event of problems with your system. To use the entries in the developer traces, you need detailed technical knowledge of the host systems in which your R/3 System is running and of the R/3 System itself.

The traces can be useful in diagnosing problems that are internal to either the host system or R/3. For example, the disp+work process reports an inability to create work processes in the developer trace.

Developer traces are written in files in the work directory of the R/3 application server that generated the trace. To watch them in transaction ST11, choose Tools → Administration → Monitor → Traces → Developer Traces. To watch them in transaction AL11, choose Tools → CCMS → Control Monitoring → Performance Menu → Exceptions/Users → Exceptions → SAP directories → DIR_HOME.

You can turn developer traces on and off and set the trace level dynamically from within R/3 or with system profile parameters or command-line arguments.

Use transaction ST01 to trace, for example, ABAP program calls, lock operations, or RFC calls. When the trace is no longer needed, you should turn it off.

Memory management is discussed in course BC315 (System Monitoring).


© SAP AG 1999

Monitoring: Buffers

Applicationserver 1

Applicationserver 2

Applicationserver x

...Name-

tabPXA

Buffer ...

TableBuffer

ST02Information (buffers):

Hit ratioFree spaceSwaps...

Information (SAP memory):

Current in useMax. usedOn diskIn memory...

The R/3 buffers store frequently used data, and make this data available to the local application server instance. This helps to reduce the number of database accesses, the load on the database server (it does not need to be accessed repeatedly to obtain the same information), and network traffic, thus improving system performance.

The data buffered includes ABAP programs, screens, ABAP Dictionary data, and company-specific data, which typically remain unchanged during system operation.

Transaction ST02 displays buffer statistics of all important R/3 buffers.

Statistics displayed by this transaction include, for example:

Hit ratio

Allocated space

Remaining free space

Swaps

Transaction ST02 displays the following R/3 buffers: nametab, program, CUA, screen, calendar, table

For more detailed information, choose Detail Analysis Menu.


© SAP AG 1999

Buffer Synchronization

DDLOG

rdisp/bufrefmode =sendon exeauto

sendoff exeoff

insertSelect from DDLOG

60 s

If you have several application servers that buffer the same table, the servers must be synchronized to ensure consistency when inserts or table updates are executed.

Every modifying action on buffered data that could also be buffered by other application servers produces synchronization datagrams. The datagrams are written to a central database table (DDLOG). Every application server periodically reads the datagrams written since the last synchronization, and checks its buffers for data to be refreshed.

Buffer synchronization can be controlled by changing the appropriate parameters in the instance profile.

The parameter that guarantees the synchronization is rdisp/bufrefmode. If the system consists of more than one application server, the parameter should be set to sendon/exeauto,.

The standard refresh time is 60 seconds. To change this to a different time period, set the parameter rdisp/bufreftime.

Transports are also written into DDLOG. Therefore, even in a central system, the parameter rdisp/bufrefmode should be set to sendoff/exeauto.

These parameters are usually set correctly during the installation of R/3 components.


© SAP AG 1999

Database (view in RZ20)

<DB System>space managementperformancebackup/restoreR/3 consistencyrunning jobshealth

Use the database analysis tools to look in more detail at alerts shown in RZ20

DB12DB13

DB02

ST04

Backup logs

Database Monitoring

St

t

The database has a significant effect on the performance of the entire system. Therefore, transaction RZ20 provides alerts concerning the database system.

The MTE Database provides information about space management, performance, backup and restore, and running jobs.

Transaction ST04 is the standard tool for monitoring database behavior and performance and is used to analyze several alerts concerning performance issues in the alert monitor. The R/3 Database Monitor (transaction ST04) displays the important parameters and performance indicators for the database, such as database size, database buffer quality, and database configuration.

The R/3 Database Monitor also provides the date and time when the database was started. Before you analyze the information in the R/3 Database Monitor, we recommend that you run the database for several hours with a typical database workload.

The Detail Analysis Menu of the SAP Database Monitor displays more detailed information on SQL requests, database parameters and change history, and statistics for analyzing database activity.

If you use the System Administration Assistant for your daily system checks, it also provides you with direct access to the database transactions.


© SAP AG 1999

Operating System (view in RZ20)

CPUPagingOS_CollectorFilesystems...

Use the analysis tool ST06 to look in more detail at alerts shown in RZ20

Provides information on theoperating system of the hostswhere R/3 instances reside ST06

Operating System

The MTE Operating System provides information about memory allocation, CPU utilization, the status of the operating system collector (OS collector), and so on.

Bottlenecks in these areas can significantly affect R/3 System performance.

To investigate the operating system, use transaction ST06.

This transaction displays CPU utilization, page rates, and some disk statistics.

For more information about the operating system, choose Detail Analysis Menu.

The OS collector is a program called saposcol. This is a standalone program that runs in the operating system background independently of the R/3 instances. It collects data on the following operating system resources:

Virtual and physical memory

CPU

Storage management

Physical disk

Network


© SAP AG 1999


Running your system






For error analysis, use the System Administration Assistant


In the System Administration Assistant, under Running your system is a link to Trouble Shooting, Service and Support.


© SAP AG 1999

Startup/Shutdown Problems

Operationalproblems

Performanceproblems

Where do you find the log files,error codes, and check proceduresfor the start and stop process?

Troubleshooting Roadmap for operational problems concerning any type of work process, batch input, printing, CTS, or interfaces

List of important monitors

Problem oriented view

Troubleshooting Roadmap: Problem Oriented View

111

222

333

The troubleshooting guide has been developed to help you administer your R/3 System. It can help you to find the solutions to some common problems as well as to analyze unusual difficulties.

The guide offers a roadmap view of problems. You can use this structured roadmap to analyze the problem through a question-and-answer procedure. You can also use the technical views to go directly to the area that you suspect is causing the problem.

The Troubleshooting Roadmap is intended mainly to accelerate the diagnosis process and ensure that you do not overlook any important aspects of the problem. It provides two views:

A problem oriented view

A technical view

With the problem oriented view, you can classify R/3 problems in a multistage hierarchy that leads you step by step to the technical cause of the problem.

To find the Troubleshooting Roadmap, choose Running your system → Troubleshooting, Service and Support → Troubleshooting.


© SAP AG 1999

Net-work

Technical view

Database

Application

Operating System

Network

Checklist for database files, logfiles,file distribution, startup and stop, updatestatistics, database locks, processes, ...

Work process analysis, problems withbackground processing, update, enqueue, spool, memory management, ...

Files and directory checks (permissionsand fill level), memory and swapping,error messages at OS level, ...

Hosts and services file, connection toapplication server, SAP GUI version,saprouter, localhost entry, ...

Troubleshooting Roadmap: Technical View

111

222

333

444

The technical view of the roadmap guides you through a set of checks for any R/3 System layer that you wish to study.

The database checks should only be performed on the database server.

Checks on the operating system, application, and network are relevant for all application servers in your R/3 System.


© SAP AG 1999

Example: Technical View Application

For each of the checks listed in the left half of the Troubleshooting Roadmap screen, a short text in the right half of the screen describes in detail which commands, transactions, or programs you should use for the analysis.


© SAP AG 1999

ABAP Programs for Checks and Cleanup

RSBTCDEL Delete background logsRSPO1041 Delete old spool requestsRSPO1043 Check consistency of spool DBRSBDCREO Reorganize BI folders and logsRSSNAPDL Delete ABAP short dumpsRSSTAT60 Reorganize table MONIRSORA811 Delete old brbackup/brarchive (not all databases)RSORASNP Reorganize logs SNAP and STAT$RSCOLL00 Performance monitor collector run

Program that starts tool dispatching for CCMS Monitoring Architecure

The

Collector of Performance Database (CCMS) Program for Reorganization of Performance Database (CCMS)

se programs must be scheduled using transaction RZ21

We recommend that you schedule these reports to run periodically.

See SAP Note 16083 for a list of the required programs, their parameters, and the recommended repeat intervals. In addition, names are suggested for the required jobs. Follow the recommendations, as the naming conventions enable SAP Support to check quickly and easily whether these jobs have been activated in your system. .

For the physical reorganization of the database, you may need other programs at OS level, such as sapdba.


© SAP AG 1999


Check for TransactionStart

(S_TCODE)

<TCODE> Transaction code

01 All management functions 03 Display authorization

Transaction Code

CC Control Center(S_RZL_ADM)

Activity

CCMS Monitoring Authorization


© SAP AG 1999


Now you are able to:Explain the basics of the monitoring architectureDefine your own alert monitorMonitor a remote system from the alert monitorWork with the most important analysis tools


© SAP AG 1999


Technical Core CompetenceKnowledge Product

Monitoring Architecture -Factsheet in SAPNet


To find the factsheet Monitoring Architecture in SAPNet, choose Information → Media Center → Media by Topic → System Management → CCMS → Literature → Monitoring Architecture.


© SAP AG 1999

Unit Actions

Exercises?

Solutions



System Monitoring: Exercises

No. Exercise 1 Navigate through the monitor sets and monitors 1.1 Start the CCMS Monitoring Environment. The initial screen displays the

CCMS monitor sets. Expand the monitor set SAP CCMS Monitor Templates. Which monitors are available in this monitor set?

1.2 Display monitor Entire System.

1.3 Which system view (Current system status or Open alerts) is active? Switch the view.

1.4 Expand the tree <SID> → Application Server → <instance name> → OperatingSystem → CPU. Where can you find monitoring tree elements, monitoring objects, and monitoring attributes?

1.5 Whenever you start transaction RZ20, you are in display mode. Activate the maintenance function.

2 Display alert details and call analysis methods 2.1 How can you display details and alerts of an MTE? (As an example, use the

MTE OperatingSystem.) What information is displayed on these detailed data screens?

2.2 Analyze alerts for CPU by starting the analysis method for the monitoring object CPU.

2.3 Which transaction screen has the analysis tool taken you to? Go back to the alert display screen.

2.4 Display the preconfigured threshold values for the CPU_Utilization. Go back to the alert display screen.

3 Creating your own monitor set 3.1 Go back to the initial screen of transaction RZ20 and create a monitor set

called TCC_TEAM_## that only you can modify but all users can view. Check that the maintenance functions are activated.

3.2 Check that your new monitor set appears in the list of all monitor sets in the initial screen of transaction RZ20. What do the icons behind the monitor sets mean?

4 Copying a monitor 4.1 Check that the maintenance functions are active. Copy the monitor Entire

System from the monitor set SAP CCMS Monitor Templates to the monitor Team_##_ALL of your monitor set TCC_TEAM_##.

5 Create a new monitor from an existing SAP monitor template 5.1 Check that the maintenance functions are active.

5.2 Create a new monitor for the operating system and the R/3 System log. Display the monitor Team_##_ALL you created in step 4.1 and use this monitor to create your new monitor containing the MTEs OperatingSystem and R3Syslog with name Team_##_OS.


5.3 Look at the monitor set TCC_TEAM_## that you created in step 3.1. Do you see a new monitor called Team_##_OS?

6 (Optional) Monitor Remote Systems 6.1 Customize the alert monitor using transaction RZ21.

If you are working on DEV, create a remote monitoring entry for QAS (use RFC destination QAS). If you are working on QAS, create a remote monitoring entry for DEV (use RFC destination DEV).

6.2 Change the monitor Team_##_ALL that you created in exercise 4.1, so that you can monitor all systems in your system landscape (DEV and QAS) from one system.


System Monitoring: Solutions

No. Solution 1 Navigate through the monitor sets and monitors 1.1 To call the alert monitor, use transaction RZ20 or choose Tools → CCMS →

Control/Monitoring → Alert monitor. The initial screen shows you the monitor sets. Expand the monitor set SAP CCMS Monitor Templates. This monitor set contains the following monitors: background processing, buffers, communications, database, dialog overview, entire system, operating system, security, spool system, syslog, system configuration.

1.2 To display the monitor Entire System, double-click it or choose Monitor → Load monitor.

1.3 The top of the monitor tree shows the active view. See the line View: <view> (<date>, <time>). To switch to the other view, choose Views and select the view. Alternatively, from the application toolbar choose Open Alerts or Current Status.

1.4 Expand the tree <SID> → Application Server → <instance name> → OperatingSystem → CPU . To locate monitoring tree elements, monitoring objects, and monitoring attributes in this tree, switch on the legend by choosing Extras → Legend. All the tree nodes are called monitoring tree elements. For example, CPU is a monitoring object and CPU_Utilization is one of its related monitoring attributes.

1.5 To activate the maintenance function in transaction RZ20, choose Extras → Activate Maintenance Function.

2 Display alert details and call analysis methods 2.1 To display details of an MTE (for example, OperatingSystem), select the MTE

and choose the jigsaw icon (Display details). The details show you, for example, the highest alert that occurred in this branch. To see an overview of which alerts occurred in which instance and when (date and time), select the context box and choose Display alerts. The list also contains the information about the monitoring attributes that raised the alerts. The alert text describes the alert in more detail. For example, the alert text File system for 98% full (threshold value: 95%) describes the monitoring attribute Percentage_Used in the branch Filesystems.

2.2 To analyze an alert, position the cursor on the monitoring attribute and start the analysis method either from the application toolbar by selecting the caliper icon (Start analysis method) or from the menu bar by choosing Edit → Nodes (MTE) → Start methods → Start analysis method.

Example: Expand the tree <SID> → Application Server → <instance name> → OperatingSystem → CPU → CPU_Utilization and proceed as above to call the related analysis method.

2.3 The analysis method has taken you to transaction ST06 (Operating System Monitor). Go back to the alert display screen (choose Back).

2.4 To display the preconfigured threshold values for CPU utilization, select the monitoring attribute CPU Utilization and choose Properties. Tab Performance Attribute displays the threshold values delivered by SAP. If you switch to


mode Change (choose the icon or choose Properties → Display <–> Change), you can adapt the values to your own needs. For most systems, there is no need to change the preconfigured values.

3 Create your own monitor set 3.1 Go back to the initial screen of transaction RZ20 and check that the

maintenance functions are active (if they are not, choose Extras → Activate Maintenance Function). Choose Monitor (set) → Create. A dialog box asks if you want to create a new monitor set or a new monitor. Select New monitor set and choose copy/enter. The next dialog box asks for the name of the monitor set (enter TCC_TEAM_##) and the attributes (for modifiability, select Only by me and flag Public). Choose Copy.

3.2 The new monitor set should appear in the overview CCMS monitor sets under My favorites. To see what the icons behind the monitor sets mean, choose Extras → Legend.

4 Copy a monitor 4.1 To call the alert monitor, use transaction RZ20 or choose Tools → CCMS →

Control/Monitoring → Alert monitor. Verify that the maintenance functions are active (if they are not, choose Extras → Activate Maintenance Function). Select the monitor Entire System from the monitor set SAP CCMS Monitor Templates and choose Copy. A dialog box appears that asks you to select the monitor set you created previously and to enter a name for the new monitor (use name TEAM_##_ALL).

5 Create a new monitor from an existing SAP monitor template 5.1 To call the alert monitor, use transaction RZ20 or choose Tools → CCMS →

Control/Monitoring → Alert monitor. Check that the maintenance functions are active (if they are not switched on, choose Extras → Activate Maintenance Function).

5.2 Expand the monitor set (TEAM_##_ALL) you created in step 3.1. Double-click the monitor (TEAM_##_ALL) that you created in step 4.1. The monitor is displayed. Expand tree <SID> → Application Server → <instances>. For each instance shown in the tree, mark OperatingSystem and R3Syslog. Press the right mouse button and choose Create monitor. A dialog box appears: choose Yes. You are now in the screen Edit monitor definition and the MTEs for the new monitor are already selected. Choose Save. A dialog box appears: enter the name TEAM_##_OS and copy. In the next screen, save again.

5.3 Look at your monitor set TCC_TEAM_##. The new monitor is listed.

6 (Optional) Monitor remote systems 6.1 Call transaction RZ21 or choose Tools → CCMS → Configuration → Alert

Monitor. Then choose Technical infrastructure → Create remote monitoring entry. If you are working on DEV, create a remote monitoring entry for QAS (use RFC destination QAS). If you are working on QAS, create a remote monitoring entry for DEV (use RFC destination DEV).


If no suitable RFC destination is available, create one. To define an RFC destination, open a new session and call transaction SM59. Choose Create and enter the following data: RFC destination: RFC_<SID>, where <SID> is the remote system (DEV or QAS) Connection type: 3 (R/3 connection) Description: Remote entry for alert monitor – choose Enter Target Host: <remote host> System number: <system number of remote host> Logon data: appropriate course user Save your settings and close this session. In session Monitoring: Registering New Contexts for Monitoring, fill in fields Target system ID and Target system RFC destination. Save these settings.

6.2 Call transaction RZ20 or choose Tools → CCMS → Control/Monitoring → Alert monitor. Check that the maintenance functions are active (if they are not, choose Extras → Activate Maintenance Function). Select the monitor TEAM_##_ALL that you created in step 4.1 and choose Monitor (set) → Change. Select Rule CCMS_DEFINE_R3_SYSTEMS and choose Edit → Change nodes. Continue and change parameter R3system from CURRENT to ALL. Continue and save these settings. Check the changes you made by calling the monitor TEAM_##_ALL. The remote system is now included in the monitoring tree.

© SAP AG 1999








SAPNet


© SAP AG 1999

SAPNet

ContentsSAPNet - Web Frontend and SAPNet - R/3 FrontendOverview / Access / Functions


Compare SAPNet - Web Frontend and SAPNet - R/3 FrontendSet up a connection to SAPNet - R/3 FrontendUse SAPNet functions


© SAP AG 1999

SAPNet - Web Frontend versus R/3 Frontend

SAPNet - Web Frontend SAPNet - R/3 Frontend

Contents

Access

Information aboutSAP, products,services, ...

Communication, discussion forums, ...

Support

Self services

Messages

Support

Service connectionsfor Remote Services

InternetRemote connection

Remote connection

User ID Your S-User ID (S00...) Your S-User ID (S00...)

SAPNet offers the user two frontends:

SAPNet - Web Frontend is an Internet interface

SAPNet - R/3 Frontend is an R/3 interface

Many functions are available through both frontends. Some functions are only available through one of them.

For both frontends, you need an S-user ID. You should obtain this ID as early as possible by fax from SAP.

SAPNet - R/3 Frontend was formerly known as the Online Service System (OSS).


© SAP AG 1999

SAPNet - Web Frontend - Overview

SAPNet - Web Frontend: http://sapnet.sap.com

SAP Homepage: http://www.sap.com

SAPNet User ID

You can access SAPNet - Web Frontend through your Web browser:

To access SAPNet - Web Frontend:

From the SAP public homepage http://www.sap.com, enter your S-user ID

Directly, use URL http://sapnet.sap.com

You can navigate in SAPNet using aliases: type the alias directly after the URL.


© SAP AG 1999

SAPNet - R/3 Frontend - Overview

To access SAPNet - R/3 Frontend, you need to have installed a SAP GUI and maintained certain technical settings.

There are two ways to log on:

From within R/3, choose System → Service → SAP Services (transaction OSS1).

From SAP Logon.

For further details, see SAP Note 17285.


© SAP AG 1999

Access to SAPNet - R/3 Frontend

DEV

Customer

PRD

QAS saprouter

saplogon

SAP

saprouter O01

To access SAPNet - R/3 Frontend, you need a service connection to SAP.

The application level gateway SAProuter acts as a secure gateway into and out of your SAP environment, and it is used whenever you access SAPNet - R/3 Frontend.

SAProuter only accepts incoming data if it complies with the SAP internal protocol, and if the data is received on a predefined port number from a predefined IP address.



© SAP AG 1999

User Administration

R/3 Frontend path:SAPNet → Administration →User Administration

Web Frontend alias:user-admin

SAPNet UserAdministrator

SAPNet Users

User requestsAuthorizationsReporting...

You can use your initial SAPNet S-user ID to obtain further S-user UDs. Your SAPNet user administrator should tailor the new user profiles to the required authorizations (for example, to allow access to SAP Notes only).



© SAP AG 1999

Notes Search

Notes DatabaseR/3 Frontend path:Gen. functions → Notes

Web Frontend alias:notes

Customer

One of the major features of SAPNet is the extensive Notes database.

You can enter the Notes database:

By entering a Note number

By specifying detailed selection criteria

SAP interprets the keywords that you enter in terms of known SAP index words. You can increase the efficiency of your search by using words that are known to the SAP indexing system.



© SAP AG 1999

Messages

R/3 Frontend path:SAPNet → Messages

Customer

Notes Database

Message

SAP

Web Frontend path:Use message wizard, chooseOnline Services → Customer messages

If you have a problem with your R/3 System, first check:


SAP training materials

The SAP Notes database

If you still have a problem, you can create a message for SAP. In the message, state the circumstances in which the problem arose (for example, transaction code, error message, release information, component affected).

Give your message a priority:

Very high only if a fatal error occurs in your production system

High for a nonfatal error in your production system or a fatal error in a nonproduction system

Medium for less urgent messages

Low for nonurgent messages

Before submitting the error message, you should choose Find solutions to display notes that may assist in solving your problem.

To submit the message to SAP, choose Send to SAP.



© SAP AG 1999

SSCR Keys

R/3 Frontend path:SAPNet → Registr. → SSCR

Web Frontend alias:sscr

Customer

Registerdevelopers and objects

for eachinstallation and release

To make changes to an R/3 System, you must register the developers and objects with SAP Software Change Registration (SSCR). You need a separate registration for each installation and for each new R/3 release.

To work in ABAP Workbench, a developer needs a developer key. To obtain this key, enter the developer’s R/3 user name in the SAPNet SSCR area. This is a 20-character key and must be entered once into your R/3 System. To avoid errors, use the cut and paste function.

If a developer plans to modify an SAP object, the developer needs an object key for the object. This is also a 20-character key and is also obtained from the SAPNet SSCR area. This procedure keeps track of modified objects, and helps make an upgrade process run more smoothly.



© SAP AG 1999

CD Registration

R/3 Frontend path:SAPNet → Registr. → CD

Customer

RegisterKnowledge Product CDs

Knowledge Product CDs contain multimedia information including:

Text files

Videos

Training materials

These CDs can be obtained individually from SAP. They are also distributed in some training courses.

Before you can use the CDs, you must register through SAPNet.



© SAP AG 1999

SAP Patch Service

R/3 Frontend path:SAPNet → Service →SAP Patch Service

Web Frontend alias:ocs

Customer

Support packagesLegal change patchesBusiness Warehouse patchesAdd-on packages...

SAP delivers corrections for its products through the Online Correction Service (OCS):

Support packages

Legal change patches

Business Warehouse patches

Component support packages

Add-on support packages

SAP recommends that you always apply the latest packages and patches as soon as possible.

Support packages are specific to a release level and must be applied in numerical order.



© SAP AG 1999

Training Information

Web Frontend alias:educationservices

Course descriptionsSchedulingPricesOnline registrationHotel information...

For up-to-date information about SAP training courses and schedules, look in SAPNet.


© SAP AG 1999

TechNet

Web Frontend alias:TechNet

Knowledge BaseForumRemote Learning...

SAP TechNet is a technically focused online service offering expert advice and new communication channels for SAP employees, partners, and customers.

SAP TechNet is divided into separate topics. Each topic has two parts:

Knowledge base: contains articles with recommendations and best practices

Forum: here you can ask questions about R/3, get expert opinions on specific issues, and exchange ideas and experiences with other users


© SAP AG 1999



Compare SAPNet - Web Frontend and SAPNet - R/3 Frontend

Set up a connection to SAPNet - R/3 Frontend

Administer SAPNet users

Search for SAP Notes

Create a problem message

Register developers and objects

Register Knowledge Product CDs

Use the SAP Patch Service

Get training information

Access TechNet
